La protection du logiciel et son régime juridique

Le logiciel : son particularisme :

On sait qu’un logiciel est un programme adressé à un ordinateur en vue de traiter une information. Le principe retenu par les législateurs français et européen est celui de la protection des logiciels par le droit d’auteur. Mais le logiciel doit être original pour que le logiciel soit protégé par le droit d’auteur. Il sera qualifié d’original si son auteur a fait preuve d’un effort personnalisé qui dépasse la simple mise en œuvre d’une logique automatique et contraignante..

• 1 : La protection du logiciel :

Alors qu’autrefois on se demandait s’il ne fallait pas protéger le logiciel par les brevets il n’est plus contesté aujourd’hui que le logiciel soit couvert par le droit d’auteur : son particularisme a été consacré par une loi du 10 mai 1994, qui a transposé en droit interne une directive européenne.

En fait, dès l’arrêt Pachot (Assemblée plénière 7 mars 1986, D 1986, 405), il était admis que le logiciel soit protégé par le droit d’auteur. Comme les traités internationaux prohibaient la brevetabilité des programmes informatiques, que les USA avaient choisi de le protéger par le copyright (celui-ci protégeant l’investissement le logiciel s’intégrait particulièrement bien dans le moule du copyright), qu’au sein de l’Union européenne on avait renoncé à une protection par un droit sui generis, il ne restait que le choix d’une protection par le droit d’auteur. C’est une règle de raison plus qu’un cri du cœur, même si le logiciel est le produit d’une activité intellectuelle exprimée dans un langage particulier. En fait les pays de l’Union se sont alignés sur les USA, pour éviter de trop grandes distorsions de protection, et c’est pourquoi on a adopté le réceptacle du droit d’auteur, même s’il est vrai, qu’aujourd’hui, on s’oriente à nouveau vers la brevetabilité de certains logiciels[11].

En vérité le logiciel est comme une verrue car les habits du droit d’auteur sont mal taillés pour lui, à telle enseigne qu’on l’a soumis, en partie, à un régime dérogatoire au sein de la Propriété littéraire et artistique. En effet on s’éloigne fort de l’art, même utilitaire. Comment chercher l’empreinte de la personnalité dans des instructions données à une machine ? La jurisprudence n’est pas dupe, qui utilise fréquemment le critère de l’effort personnalisé.

Cela étant tous les programmes ne sont pas protégés. C’est ainsi qu’il a été jugé que les fonctionnalités (on dit aussi applications) d’un logiciel, à savoir sa capacité à effectuer une tâche déterminée ou à obtenir un certain résultat, n’est pas protégeable, car cela ne relève que du domaine des idées non protégeables (Civ 1^ère 13 déc 2005, JCP 2006.II. 1896, obs crit Masquart).

• 2 Le régime juridique du logiciel :

1. A) L’étendue des droits du créateur et l’attribution partielle de ces droits à l’utilisateur :
2. a) Le droit d’exploitation :

L’article L 122-6 du CPI décrit les droits du créateur, droits qu’il peut concéder, en tout ou partie, à l’utilisateur. La représentation n’ayant pas de sens pour un logiciel, l’article mentionne le droit de reproduction et les droits de traduction (dans un autre langage informatique), d’adaptation, d’arrangement ou de modification.

L’utilisateur n’a donc pas le droit, sauf clause contraire, de modifier le logiciel et de le faire évoluer (sous réserve, article 122-6-1 du CPI, de corriger les bogues et des modifications qui permettent l’usage d’un logiciel conformément à sa destination), mais ne permettent pas à l’utilisateur de faire évoluer le logiciel (en ce sens l’esprit du texte : Lamy Informatique, n ° 144), même si, en pratique, lorsque le code source lui a été transmis, il ressent la solution contraire[12].

L’utilisateur n’a pas le droit d’effectuer une copie privée (article 122-6 2° du CPI a contrario), si ce n’est la copie de sauvegarde (voir infra).

L’exercice du droit d’adaptation suppose que le code-source soit communiqué.

Très souvent aucun droit n’est transmis au client dans le contrat de licence : on en déduit alors que le client n’a qu’un simple droit d’utilisation.

1. b) L’épuisement des droits :

Il joue sans avoir à distinguer entre représentation (ce droit étant inexistant) et reproduction (article 122-6- 3° du CPI). Il ne concerne que la vente et pas la location (cf la jurisprudence Warner : CJCE 17 mai 1988, JCP éd E 1988.II.15297, obs Vivant et A. Lucas). Cela rend illicites, en cas de vente (par vente il faut comprendre toute acquisition d’un droit d’utilisation qui ne serait pas une licence), la clause d’incessibilité du contrat, ainsi que la clause d’interopérabilité qui impose, pour acquérir la version 2, de justifier avoir acheté la version 1.

1. c) La communication des programmes sources :

Lorsqu’il s’agit d’un logiciel spécifique et non d’un logiciel standard on peut se demander s’il y a une obligation tacite de transmettre le code source : Bordeaux 24 sept 1984 (inédit) l’a pensé, mais en sens contraire, sous le sceau de l’évidence, le TGI Paris (réf) 10 avril 2002 (Expertises 2002, 207), de même que Versailles 6 oct 1994 (Expertises 1995, 78), ont estimé le contraire pour un logiciel spécifique. Il semble logique de refuser l’accès aux sources dès lors que le droit de modifier le logiciel n’a pas été transmis par le titulaire des droits sur ledit logiciel par voie d’une cession de droits. Cependant on pourrait envisager une obligation de communication sur le fondement de l’obligation de délivrance si cette communication était nécessaire à atteindre les objectifs fixés par le contrat. Ce serait tout particulièrement utile pour corriger les bogues (droit réservé à l’utilisateur par l’art L 122-6-1) : en effet, corriger les bogues implique aussi de corriger le code-source. En pratique les contrats de développement prévoient rarement la communication du code-source, ce qui enchaîne le commanditaire à l’éditeur pour ce qui est de la maintenance.

Pour les logiciels libres le libre accès est généralement prévu par la licence, car ce sont des logiciels « open sources » qu’il est dans la philosophie du projet de faire évoluer et d’en autoriser la duplication.

Pour éviter d’avoir à communiquer le code source à l’utilisateur, lequel pourrait outrepasser, grâce à cela, les prérogatives qui lui ont été accordées par contrat ou par l’article 122-6-1, les parties peuvent le confier à un tiers séquestre tel que l’APP (Agence de protection des programmes), ce qui est intéressant pour le créateur de logiciel qui peut ainsi contractualiser et contrôler l’accès de ses clients au code-source et se ménager une preuve en cas de contestation d’antériorité de sa création, ou dans le cadre de l’exécution de l’obligation de maintenance, ou lorsque le fournisseur est en faillite. Les faits d’un arrêt rendu (Com 24 janv 2006, Expertises 2006, 432, Lecardonnel) révèlent les difficultés pratiques qui peuvent se rencontrer. En l’espèce le donneur de licence n’était pas titulaire des droits et, donc, le liquidateur judiciaire de la société n’était pas habilité à autoriser l’APP à fournir une copie du code source.[13]

On notera que la réforme de 2006 (dite DAVSI=droits d’auteur et voisins dans la société de l’information) prévoit que les logiciels de partage doivent faire l’objet d’une déclaration préalable auprès de l’Etat avec communication du code source.

1. d) La copie de sauvegarde : (art 122-6-1.II du CPI)

L’utilisateur n’a droit qu’à une seule copie de sauvegarde, sauf lorsqu’on lui a accordé le droit de reproduction.

1. e) La décompilation : (article 122-6-1.IV du CPI)

C’est le reverse engineering du code source et sa duplication (voir Pinto et Taylor, la décompilation des logiciels : un droit au parasitisme, Dalloz 1999, doctr. 463). Par exemple, lorsqu’on change de système d’exploitation, il s’agit, face à un problème technique, d’accéder au code source du logiciel afin de l’analyser et de résoudre le problème. Le code source n’est généralement pas fourni avec le logiciel, à la différence du code objet, qui est le langage binaire compris par la machine. L’informaticien va alors « désosser » le code objet et le traduire dans en langage assembleur compréhensible par l’homme (concrètement il faut faire une copie du programme). Cela va révéler les idées et principes exprimés par le langage. Certes, lorsqu’on achète un logiciel on n’a généralement que le code binaire et pas le code source, ce qui ne permet pas de modifier le code source. Mais à partir du code binaire un bon technicien va pouvoir remonter, en partie pour le moins, au code source et effectuer ainsi du piratage. Le danger est donc que des informaticiens ne décompilent les logiciels de leurs concurrents pour réutiliser leurs idées. Les constructeurs étaient donc hostiles à la décompilation, bastion avancé du clonage

Finalement la directive européenne ne l’a autorisée, sous strictes conditions, que lorsqu’elle est « indispensable pour obtenir les informations nécessaires à l’interopérabilité avec d’autres logiciels ».

Les abus sont difficiles à déceler, d’où la rareté de la jurisprudence. Mais il reste qu’on peut redouter, le plus souvent, que ce soit des concurrents mal attentionnés qui recourent à la décompilation.

1. B) Autres aspects du statut légal :
2. a) Création de salarié et de « freelance » :

Le code prévoit que l’œuvre appartient ab initio à l’employeur (article L 113-9 du CPI), ce qui est dérogatoire du droit commun d’auteur, rapproche le logiciel du brevet et l’éloigne du statut des bases de données avec lequel il a par ailleurs, pourtant, des règles communes.

C’est une règle qui n’a pas été harmonisée par la directive européenne et les solutions varient d’un pays à l’autre.

Attention ! Ce particularisme ne concerne pas les oeuvres de commande. Si une œuvre était créée en commun par des salariés et des indépendants (« freelances ») la qualification d’œuvre collective, si elle était retenue, aboutirait cependant au même résultat, à savoir conférer la titularité des droits ab initio à l’entreprise employeur et commanditaire.

1. b) Rémunération :

En matière de logiciel elle peut être forfaitaire : article 131-4 5° du CPI.

Si les droits appartiennent à l’employeur le salarié doit-il être rémunéré, en plus de son salaire, pour sa création ? Rien n’est dit dans le code, qui prévoit toutefois la possibilité d’une rémunération forfaitaire en cas de cession de droits (art L 131-4-5°), hypothèse qui ne nous concerne pas ici, puisque par hypothèse il n’y a pas de cession de droits, ceux-ci étant légalement détenus, par l’effet de la loi, à l’employeur.

1. c) Durée de protection :

Elle est, comme en droit commun, de 70 ans, ce qui est une durée inutile car trop longue compte tenu de l’espérance de vie d’un logiciel. Point de départ du délai : la création de l’œuvre si le titulaire du droit est une personne morale, le décès du créateur si c’est une personne physique.

1. d) Droit moral (L 121-7 du CPI) :

En la matière on est plus proche du brevet que du droit d’auteur.

• Rien sur le droit de divulgation : si le créateur est un salarié on discute quant à savoir si le créateur est dépourvu ou non de cette prérogative.
• L’article prive expressément le créateur, sauf clause contraire, d’un droit de retrait ou de repentir
• Le droit au nom est discuté en raison du silence de la loi
• Pour le droit au respect l’article L 121-7 du CPI se contente de recopier l’article 6 bis de la Convention de Berne : l’auteur ne peut s’opposer à une modification que si elle porte atteinte à son « honneur ou à sa réputation », ce qui n’a pas de sens pour un logiciel. On voir mal comment une modification de logiciel pourrait porter atteinte à l’honneur de son créateur. Autant l’avouer il n’y a pas, concrètement, de droit au respect.

1. e) Saisie-contrefaçon :

L’art 332-4 est une disposition commune avec les bases de données (à lire). A noter le délai, à fixer par voie réglementaire, pour assigner au fond. Idem en matière de droit d’auteur.

1. f) Nantissement :

Comme pour le brevet, dont il se rapproche sur ce point, il est prévu par un texte (article L 132-4 CPI), mais il n’est pas utilisé en pratique, la valeur d’un logiciel étant trop instable et éphémère pour inspirer confiance.

1. g) La loi du 1^er août 2006 (DAVSI) :

L’art 15 dispose que les importations depuis un Etat membre de l’Union européenne de logiciels susceptibles de traiter des œuvres protégées et intégrant des mesures techniques de protection doivent faire l’objet d’une déclaration préalable auprès des services de l’Etat chargés de la sécurité informatique, ainsi que de la communication du code source. Le but est de pouvoir contrôler la propagation des logiciels de partage.

1. C) Autres aspects du régime juridique :
2. a) Logiciel, oeuvre dérivée :

• Si l’adaptation est originale le client aura un double droit d’utilisation (œuvre composite) : le 1^er sur l’œuvre adaptée, le second sur l’adaptation, dans les limites d’un simple droit d’utilisation ou des droits spécifiés dans le contrat conclu avec le fournisseur
• S’il s’agit d’une nouvelle version il y a, dès lors que l’adjonction constitue un « effort personnalisé », œuvre dérivée. Un arrêt contestable a affirmé que tel n’avait pas été le cas dans l’espèce soumise (Versailles 4 oct 2001, JCP ed E 2002, 1334, n°1, obs. Sardain).
• Si le fournisseur fournit une faible adaptation d’un L standard (simple paramétrage et adaptation aux besoins du client) le fruit de l’adaptation appartient au créateur de l’œuvre 1^ère puisque le fournisseur n’aura pas fait œuvre originale. C’est ce qui a été opportunément jugé par Paris 14 juin 2006 (GP 18-19 avr 2007, p 41).

NB : le paramétrage est le complètement du programme : ex pour un logiciel de calcul de la TVA il s’agira d’implémenter les taux de TVA.

1. b) Concurrence déloyale :

Le pillage des idées d’un logiciel est facile. Comme le note M. le Tourneau (Folles idées sur les idées, CCE févr 2001, chr n°4) « il est aisé de modifier l’apparence d’un logiciel en conservant ses fonctions, sa structure, ses performances ». La solution est alors de se protéger par l’action en concurrence déloyale, puisque les idées ne sont pas protégeables en tant que telles par le droit d’auteur (Paris 16 févr 1994, PIBD,III, 309). Récemment la Cour de cassation a précisé qu’en l’absence de similitudes de forme, la reprise des fonctionnalités (idées) était punissable sur le fondement de la concurrence parasitaire (Civ 1^ère 13 déc 2005, JCP 2006.IV.1092).

Comme en droit commun il peut y avoir cumul avec concurrence parasitaire : il a été jugé ainsi au motif que le logiciel contrefait avait été intégré dans un processus distinct de proposition commerciale : Paris 9 mars 2005, GP 15-17 janv 2006, p31.

1. c) Le droit d’agir en contrefaçon :

Lorsque l’auteur du logiciel accorde une licence à certains utilisateurs (ex à des fins pédagogiques) un droit de distribution et/ou de fabrication et/ou de simple usage il faut savoir qui, du concédant ou du licencié, dispose de l’action en contrefaçon. Généralement rien n’est précisé dans le contrat et c’est alors que la qualification revêt son importance. Normalement c’est le propriétaire qui dispose de l’action en contrefaçon, qui, sauf clause contraire, n’est pas accordée au licencié (CA Paris 4^ème ch. B, 4 février 1994 JCP ed. E. 1994, I, n°357, n°4).

Si on adopte la qualification de licence le licencié n’a pas, en principe, le droit d’agir en contrefaçon ; si on adopte une qualification de contrat sui generis ou de droit d’usage il faudra rechercher, opération souvent divinatoire, la volonté des parties.