d o c t r i n e

EXPERTISES - FÉVRIER 2014 55

A côté des logiciels propriétaires, des logiciels l ibres, des logiciels tombés dans le domaine public à l ’ initiative de leur auteur… il existe aussi des logiciels dits « orphelins » ou parfois dénommés logiciels « abandonnés » par le monde du « libre ». Problèmes et solutions.

Un logiciel orphelin peut se définir comme un logiciel qui a perdu tout lien de gestion de propriété intel-

lectuelle du fait que son propriétaire, entreprise, a disparu par sa liquida-tion. Ce terme de logiciel orphelin recouvre l’ensemble des progiciels, des développements spécifiques, des applications spécifiques à base de progiciels, des solutions logicielles regroupant des composantes progi-cielles et logicielles spécifiques. Cette analyse concerne aussi les sites inter-net ainsi que les bases de données dans le respect des droits qui leurs sont attachés.

Les logiciels orphelins se retrouvent donc sans interlocuteur identifiable susceptible de répondre tant en matière de pérennité d’utilisation qu’en matière de gestion des droits de propriété intellectuelle, sauf si des clauses spécifiques figurent dans le contrat qui lient l’auteur, l’éditeur ou le prestataire de service à son client : contrat de développement, de conces-sion, de droit d’usage ou de mainte-nance. Ces logiciels deviennent-ils des créations « abandonnées » comme semblent le définir la communauté des internautes ?

Le terme « abandonné » pourrait faire penser que le logiciel est désormais libre, mais il n’en est rien. En effet, aucun acte juridique ne permet de prouver que cet abandon de gestion de droit, met à la disposition des clients

Droit d'auteur Les logiciels orphelins

voire des internautes, le logiciel orphe-lin sous statut de logiciel libre. Le droit d’auteur persiste semble-t-il mais le détenteur des droits apparaît incertain. Cette incertitude ne peut en aucun cas générer une décision d’accorder le statut de logiciel « libre » faute de déci-deur.

Le nombre de logiciels dans cette situation s’amplifie au fil du temps avec notamment la disparition d’en-treprises sans repreneur de l’activité. Ces situations ne sont pas qu’un cas d’école mais bien une réalité.

Cette problématique repose sur des situations réelles. En présence d’une telle situation, il semble préférable de réagir amiablement si possible, judi-ciairement si nécessaire. Néanmoins, des précautions contractuelles opéra-tionnelles peuvent réduire les risques d’une telle problématique.

LES CAS DE LOGICIELS ORPHELINS

Les situations rendant les logiciels orphelins deviennent de plus en plus nombreuses. Une des circonstances premières engendrant des logiciels orphelins résulte des liquidations judiciaires ou volontaires d’entreprise s’il n’y a aucune reprise partielle ou totale. Ainsi, l’arrêt complet de l’acti-vité provoque l’arrêt du lien de gestion de propriété du logiciel. Ces arrêts émanent de clôture d’éditeurs de logiciels, de prestataires de services

informatiques mais aussi d’entreprises industrielles, commerciales, presta-taires de services, propriétaires de logiciels… sans pour autant étendre les droits d’auteur afférant aux logi-ciels concernés.

L’activité d’un éditeur liquidé se retrouve, en général, partiellement ou totalement reprise avec son ou ses logiciel(s). Parfois, la reprise partielle entraîne l’arrêt involontaire de lien sur des logiciels non identifiés dans l’inventaire comptable ou technique. Certains logiciels se retrouvent sans lien parce qu’ils n’intéressent pas le repreneur ou que ce dernier n’a pas eu connaissance de leur existence ou de leur intérêt, ou bien que l’activité n’a pas été reprise.

Tout auteur qui a cédé préalablement ses droits d’édition à l’éditeur en liqui-dation, va se retrouver concerné qu’il y ait reprise ou non de son logiciel par un repreneur. S’il n’y a pas reprise, l’auteur pourrait récupérer ses droits d’édition si les dispositions de son contrat de cession le prévoyaient.

En revanche, les salariés qui ont participé individuellement ou collec-tivement à la réalisation de logiciels devenus orphelins, ne peuvent juridi-quement, de par le silence de la loi, se voir restituer leurs droits en tant qu’auteur, pour les éditer eux-mêmes ou les transférer à un autre éditeur ; leur création de salariés a été transfé-rée d’office à leur employeur (1).

EXPERTISES - FÉVRIER 201456

Pour les entreprises qui ont fait déve-lopper des logiciels spécifiques par des prestataires informatiques, désormais en liquidation, une incertitude persiste si aucune cession contractuelle des droits de propriété n’a été effectuée au client par le fournisseur. En effet, faute de dispositions précises concer-nant la cession (destination, durée, pays, utilisateurs, environnement tech-nique), le prestataire reste propriétaire desdits développements comme le précise la jurisprudence constante, et accorde la concession de droit d’utili-sation propre à l’activité du client pour lequel le développement a été réalisé. La signature d’un contrat de mainte-nance ne suffit pas pour justifier de la cession des droits de propriété. Bien au contraire, ce contrat renforce la propriété du prestataire, car il recon-naît très souvent la compétence tech-nique du prestataire au point qu’il apparaît être techniquement le seul à pouvoir effectuer les corrections et qu’aucune disposition n’autorise en général un tiers à en effectuer , moins encore de révolution.

Toutefois, cette règle d’attribution des droits de propriété au prestataire se trouve fortement restreinte quand une partie, voire presque la totalité des matériels de conception prépara-toire, est réalisée par l’équipe métier du client. Dans ce cas, le client et le fournisseur deviennent coproprié-taires. La copropriété, sauf règlement spécifique, ne résout pas l’incertitude juridique qui apparaîtrait en cas de liquidation au niveau de la part de copropriété dudit prestataire. On y est également confronté quand la réalisa-tion du développement spécifique s’ef-fectue à l’initiative et sous la direction du client rendant le développement collectif (œuvre collective) tout en lais-sant au prestataire la responsabilité de l’exécution de ses livrables. Enfin, cette situation surgit aussi quand des développements sont assurés avec des outils facilitant la programmation itérative excluant au maximum les analyses techniques habituellement rédigées entre informaticiens.

La problématique se retrouve aussi lorsque des développements spéci-fiques - propriétés d’entreprise - sont

associés à des équipements. Faute d’inventaire avec indications des équi-pements auxquels ces développements spécifiques sont dédiés, lesdits dévelop-pements - propriétés de l’entreprise - se retrouvent séparés de leurs équipements dédiés lors de la liquidation de l’entre-prise. Une telle dissociation rend le logiciel et/ou l’équipement beaucoup moins attractif(s) voire inutilisable(s), ou peu utilisable(s). Ainsi un logiciel spéci-fique qui est attaché à un ou plusieurs équipements, se retrouve parfois sans lien technique faute d’être cédé avec le ou les équipement(s) associé(s). Cette dissociation entraîne une déva-lorisation dudit développement et de l’équipement associé. De même, lors de rachats de matériels informatiques, le liquidateur ne soupçonne pas forcé-ment l’existence de développements spécifiques. Il arrive même parfois que l’activité ou le fonds de commerce soit vendu d’un côté et les ordinateurs et serveurs de l’autre. Les applications avec leurs fichiers notamment au niveau commercial se trouvent alors dispersés et deviennent sans valeur du fait de cette dispersion.

Cette incertitude de gestion des droits existe aussi si l’éditeur n’offre pas de contrat de maintenance. Les arrêts de l’activité de diffusion et de l’activité de maintenance de ce type d’éditeurs ont à terme une incidence. Le client n’est donc pas forcément informé de la disparition de l’éditeur. La liquida-tion sans repreneur ne permettra plus au client d’augmenter à l’avenir le nombre d’utilisateurs ou d’obtenir une nouvelle version.

Même si le contexte n’est pas une liquidation d’entreprise, il faut citer les cas de quelques éditeurs ou intégrateurs qui arrêtent une acti-vité ou la maintenance d’un logiciel quelqu’en soit le motif sans propo-ser de solution pérenne. En effet, ces prestataires notifient parfois ces arrêts à leurs clients sans leur propo-ser de leur céder, voire concéder les sources avec les matériels de concep-tion préparatoire et l’exécutable dès qu’ils n’assurent plus la mainte-nance ; et ce afin qu’un tiers assure la continuité de la maintenance, tiers de préférence non concurrent.

Des logiciels libres peuvent se retrou-ver sans lien de propriété, mais cette situation est moins préoccupante car l’utilisateur peut, par la nature de la plupart des licences libres - accès aux sources et possibilité de modifi-cations -, maintenir ledit logiciel. Dans ce cadre, sauf si la maintenance est payante pour une version non complè-tement libre, le client, voire la commu-nauté des internautes peut pallier la défaillance de l’auteur ou de l’éditeur.

Face à un tel vide, les clients ne peuvent disposer d’un service de maintenance pour maintenir le logi-ciel. Sauf s’ils disposent d’un accès légal aux sources, ils ne peuvent inter-venir eux-mêmes ou faire intervenir un tiers. Le client peut se contenter de cette insécurité technique et/ou bien il devra changer de logiciels avec un surcoût de réinvestissement.

Les principaux cas énoncés ci-avant font ressortir le vide dû à l’absence de lien de gestion de la propriété générée par les liquidations.

LES DÉMARCHES AMIABLES ET CONTENTIEUSES

Face à la dure réalité de l’abandon de lien de gestion de propriété d’un logi-ciel, les utilisateurs peuvent se retrou-ver démunis ou contrefacteurs malgré eux. En effet, si plus aucune entreprise ne détient de lien de gestion de droit, la situation juridique du client se révèle complexe. Par contre, si un repreneur poursuit l’activité avec la reprise des droits et obligations de l’ancien éditeur en toute légalité, cette problématique de lien de gestion disparaît.

L’arrêt de la diffusion et de la main-tenance d’un progiciel interdit dans le futur l’ajout d’utilisateurs supplé-mentaires ou la mise en service de nouvelles versions, et surtout la main-tenance corrective. La situation s’avère identique pour les développements spécifiques.

Face à cette réalité de perte d’interlo-cuteur, plusieurs démarches légales ou contractuelles existent mais pas forcé-ment fructueuses. Chaque cas emporte une démarche très souvent spécifique.

EXPERTISES - FÉVRIER 2014 57

Les principales situations recensées concernent toutes les situations énumé-rées ci-avant de liquidation volontaire ou judiciaire d’un éditeur détenant les droits d’un auteur dans le cadre d’un contrat d’édition, d’un éditeur proprié-taire de ses réalisations, d’une société de service informatique propriétaire d’un développement spécifique dont le client ne dispose que d’un droit exclusif de concession de droit d’usage ou d’entreprise propriétaire d’un logi-ciel notamment lié à des équipements.

Le client recherche en général chez un éditeur la continuité du service de maintenance corrective avec de l’assistance, l’accès aux évolu-tions du produit dans le cadre de la maintenance évolutive mais aussi la possibilité d’augmenter le nombre d’utilisateurs ou de postes de travail. La non-reprise du logiciel par un acquéreur d’un éditeur en liquidation, est source de difficulté pour les clients.

En l’absence d’interlocuteur, le client se retrouve démuni. Néanmoins, de plus en plus de contrats d’éditeurs permettent d’accéder aux sources en cas de défaillance : soit en direct, soit via un club utilisateurs, soit via une structure contractuelle collective afin de mutualiser les coûts de reprise.

L’accès auxdites sources devient un processus bien connu mais parfois complexe juridiquement et surtout techniquement. Ce processus peut être facilité grâce à une clause d’accès aux sources en cas de défaillance avérée de l’éditeur, ou encore par un contrat indi-viduel d’entiercement entre le client, l’éditeur et le tiers de confiance (2).

Ces dispositifs contractuels sont des outils facilitateurs de l’accès aux sources, néanmoins ces dispositifs performants ont des limites. Les sources ne sont pas forcément commentées, notamment lorsque le logiciel a été développé de façon itérative ou mal documentée car non accompagné de la partie des matériels de concep-tion préparatoires nécessaires à la compréhension des sources (3). Les sources non commentées ou mal docu-mentées entraînent des surcoûts de reprise conséquents. Puis elles ne sont

pas forcément dans leurs dernières versions diffusées, l’exemplaire de sources déposé ne l’a peut être été qu’à titre d’original pour prouver l’ori-ginalité du logiciel (source et matériel de conception préparatoire) quant à son contenu et à sa date d’ancienneté, nécessaire en cas de revendication de tiers. Ce dépôt comprend en général la liste des outils qui permettent de l’uti-liser, voire une copie de l’exécutable des outils eux-mêmes à condition que le dépôt de l’exécutable de chacun de ces outils soit en conformité avec leur contrat de concession de droit d’usage. L’exemplaire des sources a, si le dépo-sant le précise lors de son dépôt, pour destination la communication en cas de défaillance de l’éditeur ou du pres-tataire lui-même et uniquement pour assurer les corrections du logiciel.

De plus, s’il n’y a pas de distinction entre le dépôt de l’original et le dépôt d’une copie en tant que copie pour séquestre collectif, les dirigeants ou le liquida-teur lors de la liquidation pourront chercher à bloquer la communication des sources de façon contentieuse en empêchant que l’accès à un tel dépôt porte atteinte à l’intégrité de l’œuvre et par conséquent au patrimoine intellec-tuel de l’entreprise, et ce pour éviter de dévaloriser la valeur de reprise.

L’auteur, les personnels qui ont réalisé les matériels de conception prépara-toire dudit logiciel, ses développeurs, voire le dirigeant de l’entreprise en liquidation, peuvent chercher à conserver ou restaurer un lien de gestion soit pour continuer à exploiter le logiciel, soit pour le maintenir, soit pour le faire évoluer, ou pour perdurer sa distribution.

Pour les auteurs indépendants, l’au-teur pourra toujours reprendre l’édi-tion ou la transférer à un autre éditeur, si le contrat d’édition le prévoit. Pour les salariés, les dirigeants, la démarche s’avère différente car ils devront effec-tuer une offre de reprise acceptable dans le respect du formalisme de la procédure de liquidation.

Parfois, des éditeurs concurrents ou des clients essayent d’embaucher des consultants et/ou des développeurs

de l’entreprise en liquidation pour poursuivre la maintenance voire récu-pérer de façon détournée le logiciel. Néanmoins, sans attribution des droits d’auteurs sur ledit logiciel par le tribu-nal, une telle démarche est illégale. Il s’avère donc nécessaire d’effectuer une proposition de reprise. Bien sûr, il arrive parfois qu’un éditeur concur-rent cherche à refaire une nouvelle version d’un logiciel par l’embauche de l’équipe à l’origine du logiciel précédent. Si tel était le cas, il serait préférable que le nouvel employeur veille fortement à ce que le nouveau produit parte d’une page blanche sans reprendre le moindre matériel de conception préparatoire, ni de programme du logiciel antérieur pour éviter de se retrouver contrefacteur, en dehors de toute autre action judiciaire du fait de ses agissements.

Lorsque la reprise concerne une activité, le projet de reprise présen-té au tribunal est une démarche courante pour ce type de procédure. En revanche, d’autres demandes s’avèrent plus complexes car moins courantes comme la reprise d’un logiciel sans l’activité qui y est asso-ciée mais avec reprise éventuelle du personnel sauf si le concurrent de l’éditeur déchu cherche à capturer le parc installé pour remplacer le parc existant par son propre logiciel mais aussi la cession de droits au client sur un développement spécifique. En effet, ces cessions peuvent être parfois de faibles prix et nécessitent des négocia-tions lorsque le liquidateur conteste le faible montant.

Chez l’éditeur, très souvent les mêmes outils logiciels sont intégrés ou servent à leur réalisation dans plusieurs progiciels. Ces outils logi-ciels sont notamment des biblio-thèques programmées, des interfaces, des pages types d’écran, des pages d’aide... voire des outils de déve-loppement, des bases de données, propriétés ou non de l’éditeur. S’il y a dispersion du patrimoine progiciel de l’éditeur lors de la liquidation, une nouvelle incertitude va naître du fait de ces outils logiciels. S’ils n’appartiennent pas à l’éditeur, il est primordial que lors de la cession, soit

EXPERTISES - FÉVRIER 201458

indiquée la liste des outils logiciels libres ou propriétés d’autres éditeurs afin que l’acquéreur fasse le néces-saire. En revanche, si ces outils sont la propriété de l’éditeur, il est impéra-tif que soit effectuée une duplication desdits outils quand ils se retrouvent associés à plusieurs logiciels afin que soit effectuée avec la cession du progiciel, une cession partielle de ces outils logiciels. Cette cession partielle se fait impérativement avec interdic-tion de revendication entre nouveaux titulaires des droits sur ces outils clonés. Dans le cas contraire, chaque acquéreur d’un des logiciels de l’édi-teur se retrouverait contrefacteur de chacun des autres acquéreurs.

En ce qui concerne l’arrêt de la main-tenance de progiciels par un éditeur ou un prestataire de service sans proposer un logiciel de substitution, la solution s’avère contractuelle. En effet, avant l’arrêt définitif de la main-tenance d’un logiciel, certains éditeurs ou prestataires, à la demande de leur client, proposent une solution tran-sitoire de maintenance corrective restreinte pour le client, le temps que celui-ci change de produits. La mainte-nance restreinte recouvre uniquement un service de fourniture de correctifs existants et de conseils pour mettre en œuvre des solutions de contour-nement, par le SAV de l’éditeur ou du prestataire.

Ainsi, si rien n’est fait au cours de la liquidation après cette période, les difficultés s’amplifient.

LES PRÉCONISATIONS POUR RÉDUIRE LES RISQUES

La tenue d’un inventaire des dévelop-pements spécifiques, ou progiciels, de leurs mises à jour et leurs correctifs, devient indispensable. L’inventaire comptable et l’inventaire technique permettent après harmonisation, en cas de liquidation judiciaire, de sensi-biliser l’administrateur et le tribunal à la réalité du patrimoine intellectuel, dénommé aussi immatériel de l’entre-prise en liquidation. Ces inventaires facilitent l’identification du patrimoine logiciel et sa valeur théorique notam-ment en cas de reprise.

En plus de cet inventaire mis à jour périodiquement, d’autres précautions restent à prendre. En matière de progi-ciels, la reprise rapide de l’activité de l’éditeur en liquidation prime pour assurer la pérennité de son offre progi-cielle si celle-ci apparaît toujours inté-gralement ou partiellement attractive. Il faut savoir qu’en matière de logi-ciels comme dans tout autre domaine d’activités, la lenteur d’une liquidation est un facteur de dépréciation du patri-moine immatériel.

Tout client titulaire d’un contrat de concession de droit d’usage et de maintenance peut se prémunir préala-blement avec des logiques de gestion des risques prévoyant un accès aux sources en cas de défaillance prolon-gée de l’éditeur.

En la matière, deux approches sont à analyser : soit le logiciel est substi-tuable en toute compatibilité, soit le logiciel est assez facilement mainte-nable du fait de la bonne qualité du code des sources et/ou des commen-taires des sources.

La première approche s’utilise si le remplacement semble moins coûteux que l’accès aux sources. La seconde approche s’avère un peu coûteuse et entre dans le cadre du processus de gestion des prévisions des risques contractuels.

La seconde approche nécessite, pour chaque client sous maintenance dési-reux d’accéder aux sources en toute sécurité, de suivre les recommanda-tions suivantes. Il convient d'abord de surveiller que l’accès aux sources ne concerne pas l’original mais bien une copie des sources effectuée par l’éditeur lui-même et de préférence la dernière version opérationnelle instal-lée chez le client. Il faut ensuite appré-cier, par échantillonnage le niveau de complexité des sources pour savoir si l’accès auxdites sources présente un intérêt, s’il est possible de les corriger dans des délais raisonnables en cas de dysfonctionnement, etc. Le temps de reprise et de corrections ainsi que les compétences nécessaires voire le budget prévisible ne permettent peut être pas de pallier la défaillance. Il

est ensuite nécessaire de signer un contrat tripartite d’entiercement d’un exemplaire des sources concédées par l’éditeur, contrat signé entre l’éditeur, son client et l’organisme d’entierce-ment et assurer un suivi des versions, des mises à jour et des correctifs pour savoir quand effectuer un nouveau dépôt. Enfin, il faut examiner à chaque dépôt pour entiercement le respect du niveau de qualité des sources, de l’exé-cutable voire des matériels de concep-tion préparatoires s’ils sont nécessaires à la compréhension des sources.

Face à la défaillance réelle et prolon-gée de l’éditeur du progiciel, le dépôt dédié au client devient un outil de gestion des risques. Ce dépôt dédié a pour objectif de sécuriser le client sur un niveau de qualité des sources, sur l’octroi d’une concession de droit d’usage d’un exemplaire des sources commentées avec éventuellement les matériels de conception préparatoire nécessaires et la liste des outils logi-ciels voire leurs exécutables.

Pour assurer la bonne opérationna-lité du dépôt dédié, la signature de deux contrats s’impose, de préférence concomitamment au processus de dépôt, à savoir un contrat bipartite de concession d’un exemplaire des sources entre l’éditeur et le client, un contrat tripartite de dépôt dédié d’un exemplaire des sources auprès d’un tiers détenteur, entre l’éditeur et le client et le tiers détenteur.

Ces contrats s’avèrent utiles pour garantir la pérennité de la mainte-nance d’une solution par l’accès aux sources en cas de défaillance avérée de l’éditeur sans avoir à supporter d’éventuelles contestations par le liqui-dateur ou devant le tribunal.

L’Agence de protection des programme (APP) et Logitas, chacune dans leurs spécialités offrent des solutions en complément de ces contrats.

L’accès aux sources pourrait être mutualisé par le club utilisateurs pour les clients détenteurs de contrat de maintenance en cours de validité. Dans ce cas, les processus correctifs sont confiés à un autre prestataire, de

EXPERTISES - FÉVRIER 2014 59

préférence non concurrent, au travers d’une convention de partage de coûts de maintenance.

En cas de reprise, se pose le problème de dévalorisation du progiciel s’il y a eu accès aux sources, alors qu’un futur repreneur fait une proposition de reprise ; d’où l’intérêt d’une reprise rapide pour éviter de dévaloriser le patrimoine de l’éditeur.

Avant de lancer la réalisation d’un développement spécifique, il s’avère important de définir les droits afférents aux documents de conception prépa-ratoire, aux sources de l’application,aux outils propriété du développeur et aux autres outils non propriété du développeur.

Toutefois, il pourra être décidé soit que le prestataire cède la propriété du développeur spécifique dès l’ori-gine au client en ce qui concerne les éléments élaborés par le prestataire seul, ou ceux établis en commun en y précisant bien la destination, soit que le prestataire concède avec une option de cession dont le montant est prédéfini s’il intervient un constat de défaillance, y compris la liquida-tion. Qu’il y ait cession ou concession, les sources ainsi que le matériel de conception préparatoire doivent être mis contractuellement à la disposition du client.

Les logiciels spécifiques nécessitent de mettre en place des solutions de gestion des risques de la part des clients. Il paraît important que le client, s’il n’y a pas eu de cession de la propriété du développement spécifique à l’issue de la recette positive de sa commande, puisse prévoir préventivement dans le contrat de maintenance ou dans un accord séparé, qu’en cas de liqui-dation du prestataire sans reprise, la propriété du développement dont il a payé la réalisation, lui soit cédée d’of-fice contre un complément financier. Cette prévention concerne aussi la concession de droit d’usage des outils logiciels du prestataire intégrés dans les développements spécifiques. Cette concession ne concerne toutefois pas les outils déjà payés à l’éditeur ou à d’autres éditeurs (OS, SGBD…).

Ainsi, le client et le prestataire se doivent de fixer la valeur de la cession du développement spécifique et de la concession de l’ensemble des outils logiciels associés qui entrent éventuel-lement dans le contrat de développe-ment ou de maintenance. Il apparaît prudent que cet accord conditionnel intègre aussi le droit pour le client de faire effectuer la maintenance par un tiers en cas de défaillance prolongée du prestataire. La fixa-tion de cette valeur s’effectue avec la recherche de la meilleure optimisa-tion financière possible pour chaque partie. Cette valorisation s’effectue avec une logique de pondération à la baisse en fonction de la durée de l’abonnement de la maintenance. La cession porte de préférence sur une cession dite partielle pour une desti-nation d’usage donnée. En principe, la cession partielle concerne l’activité de l’entreprise cliente ou d’un groupe, voire plus si le développement sert à la réalisation d’un logiciel destiné à être édité et diffusé ou si l’application est stratégique. La cession peut être condi-tionnée au constat de défaillance du prestataire selon un processus arrêté en commun avec séquestre.

Ainsi, la rupture du lien de gestion entraîne des conséquences domma-geables. Ce risque nécessite de prendre de précautions préalables. En matière de progiciel, si le progiciel est interchangeable à moindre frais, les difficultés apparaissent passagères. A l’opposé, si le progiciel se trouve incontournable ou stratégique, et son remplacement particulièrement coûteux, l’accès aux sources, même s’il faut faire intervenir des compétences de haut niveau pendant une durée conséquente, semble préférable si les sources apparaissent lisibles par lesdites compétences. Pour les déve-loppements spécifiques, la cession des droits, même partielle, avec exclusi-vité pour le client est une garantie si le client ne veut pas que son applica-tion soit utilisée par des concurrents. Par contre, si le client préfère que son développement puisse permettre une mutualisation de la maintenance par la diffusion du développement qu’il a payé, une cession partielle au client s’avère préférable, tout en autorisant

en parallèle que le prestataire puisse diffuser ledit logiciel avec des contre-parties pour le client. Ainsi, Il faut toujours prévoir l’éventualité d’une rupture de lien de gestion de droit de propriété intellectuelle.

Didier ADDAConseil en propriété industrielleDirecteur gérant Cabinet Technologie Partenaires conseils

(1) Article L113-9 du code de la propriété

intellectuelle « Sauf dispositions statutaires ou

stipulations contraires, les droits patrimoniaux

sur les logiciels et leur documentation créés

par un ou plusieurs employés dans l'exercice

de leurs fonctions ou d'après les instructions

de leur employeur sont dévolus à l'employeur

qui est seul habilité à les exercer ».

(2) L’APP comme Logitas offrent ce type de

possibilité avec chacun leurs spécificités

propres à leur secteur.

(3) Selon la directive n°91/250/CEE du Conseil,

du 14 mai 1991, concernant la protection

juridique des programmes d'ordinateur, les

matériels de conception préparatoires (« consi-

dérant que, aux fins de la présente directive,

le terme « programme d'ordinateur » vise les

programmes sous quelque forme que ce soit, y

compris ceux qui sont incorporés au matériel ;

que ce terme comprend également les travaux

préparatoires de conception aboutissant au

développement d'un programme, à condition

qu'ils soient de nature à permettre la réalisa-

tion d'un programme d'ordinateur à un stade

ultérieur ») ; le logiciel, selon l’article L112-2

13èment du code de propriété intellectuelle,

comprend aussi les matériels de conception

préparatoires.