La protection juridique du logiciel en droit français est-elle suffisante ?

Un logiciel est le fruit de l'expression d'une idée. Tout comme un écrit, une photo, une musique, il est composé d'un fond et d'une forme. Le fond correspond au contenu lui-même, au but dans lequel il a été créé. Dans le cas d'un logiciel, il s'agit de toute la phase de sa conception : les idées de fonctionnalités, les algorithmes, son organisation générale. Ce fond étant complètement immatériel, il a besoin d'être concrètement exprimé. C'est là que joue le savoir-faire du programmeur, afin de donner sa forme au logiciel, tout comme un écrivain mettrait en phrases ses idées, et choisissant les mots permettant d'atteindre au mieux son but.

Cette description du cheminement de la création d'un logiciel montre que ce dernier est complètement le fruit d'une création intellectuelle, raison pour laquelle la loi actuelle classe les logiciels dans les «œuvres de l'esprit». Étant le produit de l'imagination d'un homme, il est important que le logiciel en résultant reste attaché à cette personne, par exemple par l'intermédiaire de son nom. De même, une autre personne ne doit pas pouvoir reprendre cette création sous nom, ce qui diffuserait à tort l'information qu'elle en est aussi l'auteur, et donc limiterait la paternité effective de l'auteur réel, tel que la percevrait alors l'opinion publique.

Cependant, si le logiciel est rattaché à son auteur, l'image véhiculée par le logiciel se répercute sur celle de l'auteur. Il est donc important que l'image transparaissant du logiciel soit sous le contrôle de l'auteur : soit parce qu'il s'agit de ce qu'il a personnellement écrit, soit parce qu'il a donné son accord pour effectuer une modification. L'accord peut toutefois être implicite lorsque les modifications sont mineures et ne peuvent vraisemblablement pas impacter l'image que donne le logiciel : l'important étant surtout de respecter l'esprit originel donné par l'auteur.

Cette image dépend aussi de la qualité du logiciel. Étant donné que cette qualité croît généralement avec le temps mis à le réaliser, l'auteur doit pouvoir lui-même décider à quel moment son travail est terminé, c'est-à-dire à quelle date son logiciel pourra être diffusé ; une diffusion prématurée sans son accord d'une version non finalisée ne pouvant que lui porter préjudice.

Pour les mêmes raisons de paternité de l'idée originale et de respect de l'image de l'auteur, celui-ci peut souhaiter empêcher la création d'un logiciel similaire au point que les utilisateurs aient du mal à faire la différence entre les deux logiciels, comme le cas d'OpenOffice reprenant quasiment à l'identique les interfaces et les fonctionnalités de Microsoft Office. La duplication exacte ne fait pas partie de ce cas, car elle ne peut pas se différencier de l'original. Elle ne peut porter préjudice à l'auteur que du point de vue du profit qu'il peut tirer de ce logiciel, comme nous le verrons dans la partie suivante.

Notre société actuelle est profondément ancrée autour de l'argent. Un auteur, comme toute autre personne, a besoin d'argent pour se nourrir, se loger… L'écriture de logiciel est une activité qui demande souvent de nombreuses ressources en temps, il n'est donc pas toujours possible d'exercer une autre activité rémunératrice en parallèle.

L'équilibre entre l'intérêt financier du créateur et l'intérêt de l'utilisation du produit par le public est nécessaire à la bonne marche de l'économie. L'industrie pharmaceutique est un exemple flagrant de domaine dans lequel il est primordial de permettre un accès aisé des utilisateurs aux médicaments. Seulement, la protection grâce aux brevets protège les investissements financiers qui permettent le développement de la recherche, ce qui ne va pas sans créer de conflits avec les pays en voie de développement, très demandeurs de médicaments, comme lors du procès de Prétoria en 2001, sur les brevets sur les antirétroviraux¹ . Les uns font appel à la nécessité pour le plus grand nombre d'accéder à des médicaments à bas prix, les autres mettent en avant la protection de leurs investissements financiers et donc leur rentabilité. En matière de logiciel aussi, se pose la problématique du financement des activités de recherche et de production, préalables aux premières ventes, et donc diffusions, du produit fini.

De cet aspect très pratique, ressort un besoin plus général : permettre à l'auteur de choisir les modalités de diffusion. En effet, même si l'auteur souhaite diffuser son logiciel gratuitement, il est légitime qu'il puisse interdire à d'autres personnes d'en faire du profit, ou simplement garantir que même en le redistribuant à titre onéreux, les clients de ces autres personnes aient accès au code source, et puissent le modifier librement, comme le prévoit par exemple la licence GPL².

Ainsi, il est important qu'un auteur, ou le distributeur de logiciels qu'il a choisi, puisse contrôler la manière dont les copies sont réalisées. Ce contrôle s'effectue grâce à un contrat avec l'utilisateur, souvent appelé licence d'utilisation. La revendication principale d'un distributeur de logiciel est de réclamer qu'un logiciel acheté sous la forme d'un CD-ROM, ou via un téléchargement en ligne, ne puisse être installé que sur une unique machine à un instant donné. Il s'agit là de mimer ce qu'il se passe lors de la vente d'un bien matériel, comme un aspirateur : acheter un CD-ROM d'un logiciel puis l'installer sur plusieurs stations reviendrait alors à acheter un aspirateur et le multiplier pour l'utiliser en même temps dans le salon et la chambre. De ce point de vue, il est légitime qu'un distributeur de logiciels puisse imposer qu'il n'y ait, lorsqu'il vend n licences d'utilisations d'un logiciel, que n copies installées de ce logiciel, ou n instances du logiciel lancées en même temps.

Jusque là, nous ne nous soucions que des copies strictes, identiques bits à bits, du logiciel. Ce n'est cependant pas le seul souci d'un auteur de logiciel, nous reviendrons donc sur le problème de la réécriture complète du logiciel par une autre personne. Contrairement au point de vue de la partie précédente qui était la potentielle dévalorisation de l'image du logiciel originel à cause de la mise en circulation d'une copie de mauvaise qualité, nous nous intéresserons ici aux copies ayant des fonctionnalités similaires et pouvant impacter le profit effectué par l'auteur du logiciel original. Ici, le mot profit ne signifie pas uniquement profit financier, mais aussi toutes autres sortes de gains, et en particulier, la renommée ou la diffusion d'une philosophie, comme c'est le cas pour le logiciel libre. Idéalement, un auteur pourrait souhaiter qu'aucun logiciel ayant des fonctionnalités similaires ne puisse être diffusé. L'existence potentielle d'un tel monopole drastique révèle le besoin de limiter le pouvoir de protection d'un auteur sur son logiciel, afin de ne pas léser l'utilisateur au profit de l'auteur, ce que nous allons aborder dans la partie suivante.

(1) Florent Latrive, Du bon usage de la piraterie, Introduction. Exils éditeur, 2004

(2) Licence GPL : http://www.gnu.org/copyleft/gpl.html (anglais) http://fsffrance.org/gpl/gpl-fr.fr.html (français)

Nous venons de recenser certains besoins de protection du logiciel, mais il ne s'agit là que du point de vue de l'auteur. En effet, un logiciel est fait pour être utilisé, il faut donc au moins garantir à l'utilisateur qu'il aura le droit de s'en servir !

La liberté d'utilisation et la liberté de la concurrence sont intimement liées. La question de la liberté d'utilisation d'un algorithme ou d'une technique novatrice concerne moins l'utilisateur final que le programmeur d'un futur produit, qu'il réponde au même besoin ou non, et qui ferait appel à des techniques très récemment développées. Du point de vue de la liberté d'entreprendre, il est difficile de se refuser à utiliser un procédé reconnu et performant sous prétexte qu'il est breveté, alors qu'il répond au besoin du programmeur, et y répond même d'autant mieux que le programmeur ne connaît pas de solution plus efficace et rapide.

Lors de cette considération, il s'agit non de recopier des lignes de codes déjà existantes, mais bien de construire un logiciel tirant parti d'une idée, d'un principe ou d'une méthode, déjà utilisés et revendiqués par une personne morale. Ce principe peut prendre la forme d'un parcours algorithmique, d'une structure de données efficace relativement à tel ou tel usage, d'une méthode permettant d'imbriquer un programme dans un module plus grand, ou encore d'un comportement proposé à l'utilisateur, comme le clic droit pour faire apparaître un menu contextuel… pour reprendre des exemples qui ont été discutés outre-Atlantique. Nous sommes donc loin de la considération de code source ouvert ou fermé, puisque les entreprises peuvent souhaiter protéger certains comportements du logiciel, visibles à l'utilisateur.

Dans un objectif de diffusion du savoir et des technologies, les principes et méthodes de base doivent donc pouvoir être utilisés par la concurrence pour construire leurs logiciels propres. La question est plus délicate s'il s'agit de créer un logiciel rendant un service identique, avec les mêmes innovations technologiques — qui ne sont donc plus des innovations —, et vendu à moindre coût.

La copie conforme d'un logiciel, quant à elle, est actuellement encadrée par les licences d'utilisation. Celles-ci définissent par exemple combien de copies un utilisateur peut effectuer pour son usage personnel, éventuellement pour des sauvegardes, mais aussi combien d'instances du logiciel peut utiliser simultanément une entreprise sur les postes de travail de ses employés. Comme dit précédemment, la loi doit permettre au propriétaire du logiciel de contrôler l'usage qui en est fait, mais sans empêcher le propriétaire d'en autoriser la copie pour un certain usage, voire la diffusion en tant que logiciel libre, s'il le souhaite. Dans ce domaine spécifique du logiciel libre, le problème de l'exclusivité d'une invention peut entrer en conflit avec la liberté de modifier, d'améliorer le logiciel, ou de s'en inspirer pour d'autres réalisations, sous certaines conditions définies dans les licences.

Dans ce cas, sans préjuger d'autres conséquences dans les disciplines autres que le logiciel, il serait impossible d'utiliser ces méthodes brevetées dans les logiciels libres. En effet, si une telle méthode brevetée se trouvait être utilisée dans un logiciel libre, l'exploitation libre de ce logiciel entrerait en contradiction avec le brevet. Les utilisateurs, pour des raisons professionnelles ou personnelles, de systèmes à base de logiciels libres, seraient donc considérablement lésés.

Cela pose également le problème d'interopérabilité des structures de documents : un document utilisant un format breveté ne pourrait être visionné, ni modifié, que par un logiciel autorisé par le titulaire du brevet. Cela semble très prometteur d'un point de vue lucratif pour le titulaire du brevet, mais se posent alors des questions de libre concurrence, pour les autres éditeurs de logiciels, et également d'utilité, pour les utilisateurs. La situation de monopole ou d'oligopole qui serait ainsi engendrée le serait évidemment au déficit de l'utilisateur. Ceci est encore plus vrai dans le cas d'une faillite de l'éditeur ayant souscrit un contrat de maintenance — ou ayant l'habitude de maintenir son logiciel — avec ses clients. Néamoins, l'article L122-6-1 alinéa I du Code de la Propriété Intellectuelle peut sauver ici l'utilisateur :

I. Les actes prévus aux 1º et 2º de l'article L. 122-6 ⁷ ne sont pas soumis à l'autorisation de l'auteur lorsqu'ils sont nécessaires pour permettre l'utilisation du logiciel, conformément à sa destination, par la personne ayant le droit de l'utiliser, y compris pour corriger des erreurs.

Toutefois, l'auteur est habilité à se réserver par contrat le droit de corriger les erreurs et de déterminer les modalités particulières auxquelles seront soumis les actes prévus aux 1º et 2º de l'article L. 122-6, nécessaires pour permettre l'utilisation du logiciel, conformément à sa destination, par la personne ayant le droit de l'utiliser.

L'utilisateur a donc la possibilité de désassembler et modifier le logiciel à des fins de corrections d'erreurs, de bogues. Le brevet logiciel ne devrait donc pas pouvoir, en aucun cas, entraver ce droit.

De plus, le concept de l'interopérabilité entre logiciels figure déjà dans la législation française sous l'article L122-6-1 alinéa IV du code de la propriété intellectuelle :

IV. La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1º ou du 2º de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes :

1º Ces actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin ;

2º Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au 1º ci-dessus ;

3º Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité. Les informations ainsi obtenues ne peuvent être :

1º Ni utilisées à des fins autres que la réalisation de l'interopérabilité du logiciel créé de façon indépendante ;

2º Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante ;

3º Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.

(7) NDA La reproduction, la traduction, l'adaptation, l'arrangement, la modification…

Est entendu que la traduction du logiciel à des fins autres que l'interopérabilité relève de la contrefaçon.

Dès lors, étant donné que toute personne — sous les trois conditions visées par l'article — peut décompiler le code d'un logiciel d'origine afin de procéder à l'interopérabilité, par exemple, de structures de données entre un logiciel et un autre⁸, cette personne peut être amenée à exploiter, dans son propre logiciel, une méthode ou un algorithme breveté, à des fins d'interopérabilité avec le logiciel d'origine. Comment concilier cela avec les restrictions sur l'exploitation de la méthode ou l'algorithme dues au brevet ?

D'autre part, toujours dans l'hypothèse où les brevets sur les méthodes et les algorithmes seraient autorisés, l'application de la loi à un auteur de logiciel dérivé de cette méthode ou de cet algorithme serait problématique. En effet, le caractère breveté d'une invention n'interdit non pas sa divulgation, mais bien son exploitation par un tiers — sans autorisation du titulaire du brevet, bien entendu. L'article L613-15 du Code de la Propriété Intellectuelle définit les conditions à l'exploitation d'une invention brevetée issue d'un brevet antérieur.

Le titulaire d'un brevet portant atteinte à un brevet antérieur ne peut exploiter son brevet sans l'autorisation du titulaire du brevet antérieur ; ledit titulaire ne peut exploiter le brevet postérieur sans l'autorisation du titulaire du brevet postérieur.

Lorsque le titulaire d'un brevet ne peut l'exploiter sans porter atteinte à un brevet antérieur dont un tiers est titulaire, le tribunal de grande instance peut lui accorder une licence d'exploitation du brevet antérieur dans la mesure nécessaire à l'exploitation du brevet dont il est titulaire et pour autant que cette invention constitue à l'égard du brevet antérieur un progrès technique important et présente un intérêt économique considérable. (…)

Une personne tierce peut donc prendre connaissance de la méthode novatrice qui fait l'objet du brevet dit antérieur, créer un logiciel s'inspirant de cette méthode, et l'exploiter — comprendre : le diffuser ou le vendre. La nature fermée du logiciel dont les sources ne sont pas nécessairement disponibles rend difficile l'appréciation du terme s'inspirer de cette méthode. Le logiciel représente bien un progrès notable par rapport à la simple méthode initialement brevetée, nous sommes donc bien, sur ce point, dans le cadre de l'article L613-15. Or le programmeur fera valoir ses droits à l'exploitation de son œuvre, et demandera peut-être à breveter son logiciel. Le titulaire du brevet antérieur pourrait accuser le programmeur d'avoir utilisé sa méthode novatrice à des fins d'exploitation, entrant ainsi en conflit sur les termes de l'exploitation du logiciel. Le titulaire du brevet antérieur avancera la présomption selon laquelle le nouvel exploitant utilise la méthode brevetée, mais sans pouvoir nécessairement le prouver. L'article renvoie ce type de litige devant le tribunal de grande instance. Nul doute qu'une modification législative en ces termes entraînerait de nombreux recours devant les tribunaux, du moins si le cadre de l'article L613-15 n'est pas plus strictement redéfini.

(8)Marie Barel et Frédéric Raynal, Vulnérabilités logicielles et droit : responsabilité, recherche et divulgation, in MISC n°23 (janvier-février 2006), pp.16-23, Diamond Editions.

En conséquence, limitons-nous uniquement à l'hypothèse de la suppression stricte de la mention ainsi que les programmes d'ordinateur de l'article L611-10 du CPI, en conservant pour acquis l'interdiction de brevet sur un algorithme ou sur une méthode. Ceci permettrait alors le dépôt d'un brevet sur une réalisation logicielle, novatrice, susceptible d'application industrielle, c'est-à-dire offrant directement un service à l'utilisateur. En ce sens, la copie bit à bit non explicitement autorisée d'un logiciel, suivie de son exploitation, serait illégale : mais elle l'est déjà en vertu des lois sur la contrefaçon, et souvent de la licence d'exploitation. Sur ce point donc, la valeur ajoutée de cette modification est nulle. Notons par ailleurs que dans ce cas, un logiciel libre ne peut donc être soumis à un brevet, puisque le logiciel libre doit pouvoir être exécuté librement, à discrétion.

Cependant se pose la question de la réalisation ex nihilo d'un logiciel aux fonctionnalités équivalentes, avec des moyens de développements entièrement distincts. Là encore, nous entrons dans des difficultés d'appréciations. Il est tentant, et utile du point de vue du consommateur, de recoder depuis zéro un logiciel remplissant à peu près les mêmes fonctions qu'un logiciel antérieur propriétaire et payant. À l'excès, nous avons vu que cela peut aller à un manque à gagner certain pour l'éditeur du logiciel antérieur. À l'inverse, avec une protection excessivement forte par brevet sur les fonctionnalités apportées par le logiciel antérieur, s'il est interdit de développer et d'exploiter un nouveau logiciel répondant au même besoin, nous entrons dans la situation de monopole, sans parler des technologies sous-jacentes — format de stockage des données, etc. —, que nous avons traitées au paragraphe précédent.

Ce type d'excès est habituellement modéré par l'alinéa 1 de l'article L611-2 du CPI, protégeant les inventions pour une durée de vingt ans. Cette durée permet, dans les applications industrielles conventionnelles, la rentabilisation des investissements ayant abouti à l'innovation, sans entraver le progrès technologique à long terme. Cependant, en matière de logiciel, les investissements sont bien moindres aussi bien en termes financiers qu'en termes de durée, et les manques à gagner — ou les bénéfices — peuvent être considérables durant les toutes premières années d'exploitation du logiciel. Nous sommes donc très loin des vingt années spécifiées par la loi, mais nous constatons la difficulté de protéger suffisamment l'inventeur durant les premiers mois d'exploitation de son innovation.

Le juste compromis législatif peut s'avérer difficile à trouver, et pour deux raisons essentielles. D'une part, l'appréciation de la proximité de deux logiciels pourra souvent mener à débat. D'autre part, les recours devant le tribunal de grande instance, prévus notamment par l'article L613-15 du CPI dans le cadre de l'exploitation d'un brevet portant atteinte à un brevet antérieur, et par l'article L615-19 du CPI dans les cas de contrefaçons, risquent d'être nombreux, du moins tant qu'une jurisprudence n'est pas clairement établie.

Enfin, le logiciel, outre sa capacité à être développé, exploité et distribué très rapidement en regard des applications industrielles classiques, possède aussi la capacité à traverser les frontières très facilement. Ainsi, une protection par brevet contre l'exploitation par un tiers d'un logiciel sur le territoire national, n'empêchant donc pas la réalisation et l'exploitation d'un logiciel similaire à l'étranger, pas plus que son importation sur le territoire national — sauf cas particulier —, ne peut s'appliquer contre l'exploitant résident à l'étranger. Le consommateur quant à lui peut utiliser ce logiciel similaire, bien entendu tant qu'il n'en effectue pas une exploitation sur le territoire national portant atteinte au brevet.

Les logiciels, bien qu'étant déjà protégés par le code de la propriété intellectuelle en qualité d'œuvre de l'esprit, souffrent ainsi d'un manque de protection lorsqu'il s'agit d'innovations que l'on pourrait qualifier d'industrielles, dès lors qu'elles mettent en jeu de la recherche, de l'exploitation, du commerce et des flux financiers. À ce titre, certains pays ont amendé leur législation pour y inclure le droit de breveter un logiciel, voire un algorithme, une méthode, un format, etc. D'autre part, des lobbies industriels cherchent à s'affranchir de ces différences nationales, grâce notamment à l'éventuelle reconnaissance mutuelle des brevets sur le territoire de la Communauté Européenne⁹, en cours de discussion actuellement¹⁰ .

Néanmoins, ces éventuels brevets logiciels, de par la nature même du secteur informatique, ne peuvent pas être considérés sur le même plan que les brevets d'innovation traditionnels. Une modification du droit français amenant à légaliser le dépôt de brevets sur les logiciels n'irait pas sans certains excès, s'il n'y a pas en amont une réflexion précise sur les modifications à apporter, ou du moins des dispositions encadrant strictement ce type de brevets, et permettant de concilier les intérêts des créateurs et ceux du public.

(9) Brevet communautaire, Approche politique commune. Note 7159/03 du 7 mars 2003 du Conseil de l'Union européenne, dossier interinstitutionnel 2000/0177. http://register.consilium.eu.int/pdf/fr/03/st07/st07159fr03.pdf

(10) Consultation de la Commission européenne sur le brevet communautaire (mars 2006) : http://www.ffii.fr/consultation-brevet-communautaire-ffii-france