Droit de propriété et Open Source

Le grand développement de la question de la protection du logiciel par les mécanismes de propriété intellectuelle provient de l’utilisation de l’informatique dans l’industrie. Quatre vingt pourcents des brevets déposés ont une application dans l’industrie. La logique de baisse des coûts a conduit les acteurs du marché à mettre en place une base technique commune et à déplacer l’innovation au niveau de la couche logicielle du processus de production. Se pose donc la question de la protection de ces innovations logicielles.

La propriété intellectuelle doit en effet être appréhendée différemment concernant les créations logicielles. La source du problème provient de l’originalité de la création informatique : le logiciel change d’état entre sa conception et sa diffusion. C’est le code source écrit par le développeur qui une fois compilé, sera distribué. On est en face d’un processus qui n’existe pas en matière littéraire ou audiovisuelle : dans le cas d’un ouvrage par exemple, il n’existe pas cette césure entre la version créée et la version distribuée.

Ces dix dernières années, le milieu de l’Open source s’est considérablement développé. Il trouve son origine dans le Freeware (logiciel dont l’utilisation est gratuite) : concept inventé par Richard Stallman [1] en 1984. Les deux notions ne doivent pas être confondues car elles sont bel et bien distinctes. Alors que le Freeware est gratuit à la distribution, ce n’est pas nécessairement le cas du logiciel dit « libre « . Le propre du logiciel libre est de rendre disponible au public son code source afin de permettre les modifications. Possibilité qui n’est pas nécessairement offerte à l’utilisateur d’un freeware. On oppose le logiciel libre au logiciel propriétaire. Le terme de logiciel commercial ne semble pas approprié. Il renvoie en effet à une autre distinction qui ne semble pas adéquate : commercial est opposé à gratuit alors que propriétaire est opposé à Open Source. Le succès des projets Open Source va toujours croissant : Apache, le serveur Web concurrent de IIS (son équivalent Microsoft) représente en ce début d’année 2004 67% des serveurs Web dans le monde [2].

L’opposition entre logiciels libres et logiciels propriétaires fait rage depuis que les deux lobbies s’affrontent ouvertement concernant la brevetabilité des logiciels.

L’open source est régi par différents types de licences d’utilisation, qui schématiquement sont regroupées dans deux grandes familles : GPL (General Public License) et BSD (Berkeley System Distribution). La licence GPL permet une modification du code source qui ne souffre aucune limite. L’obligation de l’utilisateur/contributeur est de diffuser la nouvelle version du logiciel à laquelle aboutira son travail.

Il ne s’agit pas ici de traiter de la question de l’opportunité de l’utilisation des logiciels libres, mais plutôt de la façon dont leur émergence et leur généralisation a modifié les concepts fondamentaux de droit de propriété et de propriété intellectuelle.

Le problème majeur est la conciliation entre la libre diffusion du logiciel développé sous licence Open Source et le Droit de Propriété (I). Question mise en exergue il y a peu avec les débats européens sur les brevets logiciels qui posent le problème de la brevetabilité des logiciels libres (II).

I La protection des logiciels libre.

Les logiciels libres ne sont pas en marge totale de nos droits de propriété classiques. Leur statut à part ne les place pas en dehors de tout cadre juridique ; ils ne sont pas exemptés des règles de la propriété intellectuelle (A), mais différents aménagements posent des problèmes lors de leur distribution (B).

A L’application de la propriété intellectuelle à l’Open Source.

1 – Le code source d’une création logicielle est toujours protégé.

En dehors de toute protection par une licence d’exploitation de libre ou propriétaire, l’éditeur de logiciel, (dans le cas d’une entreprise), tout comme le programmeur solitaire voient leur travail protégé par les règles de base de la propriété littéraire et artistique. En effet le code source de toute création logicielle est protégé comme l’est toute oeuvre de l’esprit du simple fait de sa création. A des fins de preuve de l’antériorité, il est possible de déposer le code source à l’Agence de Protection des Programmes [3], selon un mécanisme assez proche de celui du dépôt de brevet classique.

Bien entendu, la non divulgation du code source protège du parasitisme, et évitera que le code ne soit copié à l’identique ou bien imité par un concurrent. Mais même en cas de diffusion libre, l’usage non autorisé ou non conforme d’un code source est susceptible de recours devant les tribunaux. Les logiciels développés en Open Source ne sont donc pas dépourvus de toute protection juridique.

On peut même affirmer le contraire : la licence GPL est créatrice d’un certain nombre de droits et obligations. Ici encore on distingue deux grands types de licences GPL ; les licences copyleft et les licences non-copyleft. Alors que les premières obligent à ce que tous les distributeurs continuent de faire s’appliquer la même licence GPL qu’à l’oeuvre originale, la deuxième permet de transférer autant de droit que le désire le développeur du code modifié. Les logiciels distribués sous licence GPL non-copyleft étant marginaux, nous ne traiterons que du cas de ceux qui sont copyleftés.

Le système de GPL est aussi protecteur (contraignant) que le système du CLUF (Contrat de Licence d’Utilisateur Final) utilisé dans le logiciel propriétaire. En effet, si la simple diffusion d’un logiciel libre n’entraîne aucune conséquence juridique (là où la diffusion d’un logiciel propriétaire constitue du piratage), il n’en va pas de même lorsque l’utilisateur touche au code. En effet, la modification du code source du logiciel libre a les mêmes effets que le «  Shrink-wrap «  du logiciel propriétaire. Dès lors que le code source a été modifié, l’auteur du « nouveau « logiciel est réputé avoir tacitement accepté la licence GPL qui était attaché au logiciel originel et ne peut s’y soustraire.

2 – La GPL reste un régime contraignant générateur de sécurité juridique pour les développeurs.

C’est une fois de plus ici une des règles du transfert de propriété qui vient donner tout son sens aux termes de la licence GPL. Car en effet la stricte application de la règle nemo plus juris est nécessaire au bon fonctionnement de ce système de protection des droits. Chacun des utilisateurs/développeurs ne pourra octroyer plus de droit à ses propres utilisateurs/développeurs qu’il ne lui en a été offert par le développeur original. La possibilité de modifier le code n’est octroyée qu’à la condition que la version modifiée du logiciel soit elle même distribuée sous licence GPL. Ainsi, à chaque fois qu’un logiciel modifié circule et est modifié à son tour, la condition subsiste et ne peut être écarté par aucun des acteurs de la chaîne de licences. La GPL peut dans cette optique fixer les règles de la redistribution de l’oeuvre modifiée. Par exemple, Red Hat [4] permet les modifications du code source de sa distribution, mais interdit que l’oeuvre dérivée soir distribuée sous le nom « Red Hat « .

Néanmoins, l’obligation de redistribution et par conséquent de divulgation pose des problèmes évidents dans le cadre d’une utilisation en entreprise. Elle empêche en effet totalement de garder secrète toute innovation technique et d’en un tirer profit monopolistique. L’exemple de Kiss [5], qui développe et commercialise des platines de salon permettant de lire DVD et DivX [6] est tout à fait parlant. En utilisant de code de MPlayer (Un logiciel de lecture de DivX distribué sous licence GPL) et en le modifiant, sans pour autant le redistribuer, ils tirent un profit économique d’un logiciel Open Source qui ne leur appartient pas, et ce sans jouer le jeu de la libre diffusion indiquée dans la GPL. Si Kiss se conformait à la licence GPL, ils devraient redistribuer le code source de la version modifiée de MPlayer qu’ils utilisent [7]. Toutefois en redistribuant le code, ils perdent le monopole sur leurs modifications et ainsi une grande part de l’avantage qu’ils peuvent tirer de leurs travaux de recherche. Mais l’obligation de redistribution n’est pas un simple « gentleman agreement« , et le non respect de la licence GPL les expose à d’éventuelles poursuites. Les utilisateurs/développeurs de logiciels libres sont donc pris entre deux feux : s’il est dangereux de dépenser des sommes importantes en Recherche et Développement si vous êtes dans l’incapacité de tirer un quelconque avantage concurrentiel de ces investissements, il l’est tout autant de ne pas se conformer à la licence d’utilisation d’un logiciel.

Même si les règles du droit de propriété applicables aux logiciels libres sont quasi-identiques à celles appliquées aux autres créations de l’esprit, la licence GPL est en complète opposition avec la philosophie patrimoniale du copyright et vient rendre troubles certaines notions juridiques en matière de transfert de propriété.

B Les difficultés du transfert de propriété du Copyleft.

1 – Open Source = Bien public ou Bien commun de l’humanité ?

Deux types de biens publics sont à envisager. Dans un premier cas, il est possible d’envisager les logiciels libres en tant que biens publics comme des biens non appropriables. Cette hypothèse semble séduisante dans la mesure où elle respecte la philosophie classique de l’Open Source qui est que la connaissance appartient à tous. Pourtant, il parait difficile de rendre un code source totalement non appropriable dans la mesure où cela bloquerait toute possibilité d’exploitation commerciale. Les logiciels, même libres, restent tout de même fondamentalement différents de l’air que nous respirons !

Dans un deuxième cas, il est possible d’envisager la notion de bien public sous l’angle de la nationalisation. Ce cas de figure apparaît de facto comme complètement irréel.

Avec la réception de la demande de classement des logiciels libres au patrimoine mondial de l’UNESCO, celle-ci a montré sa volonté d’encourager le développement de ce type de logiciels. « L’UNESCO a toujours encouragé l’extension et la diffusion de la connaissance et reconnaît que dans le domaine du logiciel, le logiciel libre diffuse cette connaissance d’une manière que le logiciel propriétaire ne permet pas. L’UNESCO reconnaît aussi que le développement du logiciel libre encourage la solidarité, la coopération et le travail communautaire entre les développeurs et les utilisateurs des nouvelles technologies «  [8]. Toutefois, aucune action concrète n’a réellement été menée, et cette déclaration de principe n’a donc pas engendré de réelle évolution.

2 – Logiciels sans maîtres offrant peu de garanties.

Parallèlement à cela, se pose aussi le problème des garanties offertes à l’utilisateur du logiciel. D’une part la garantie d’éviction pose problème. Rien ne protège l’utilisateur/développeur secondaire de logiciel libre d’être perturbé dans son utilisation par le droit antérieur d’un autre utilisateur/développeur secondaire. Le cas s’est déjà présenté en matière de brevets avec la revendication par Unisys de la propriété du format GIF [9]. Concernant les logiciels propriétaires à l’inverse, le détenteur de la licence originelle (le véritable propriétaire) du logiciel est connu et peut offrir une garantie d’éviction et une garantie du fait des tiers bien plus fiable.

A l’inverse, en matière de responsabilité civile pure (logiciel entraînant un dommage), les deux camps viennent à se rapprocher. En effet, les logiciels libres sont fournis « as is « , c’est-à-dire en l’état. Les clauses limitatives de responsabilité sont admises dans les licences GPL comme dans les licences de logiciels propriétaires, dans le respect des législations nationales [10]. Une difficulté ajoutée par le développement communautaire des logiciels libres est l’absence d’interlocuteur unique. Il s’agira donc ici de savoir qui supporte la responsabilité des dommages causés. Finalement, il sera rarement question de la responsabilité des éditeurs de logiciel, mais plutôt de celle des prestataires (SSII, intégrateur ou autre) avec qui la responsabilité est aménagée contractuellement.

Alors que la protection des logiciels libres et de leurs utilisateurs semble assurée par différents mécanismes juridiques, le débat a été relancé il y a plusieurs mois maintenant avec la proposition de directive européenne sur la brevetabilité des logiciels.

II La brevetabilité des logiciels.

A Un état de faits insatisfaisant.

1 – La brevetabilité des logiciels est une réalité.

En France, aucun texte n’autorise le dépôt de brevet concernant un logiciel à proprement parler. La loi de 1968 sur les brevets pose cette hypothèse comme exception. En effet à cette époque, IBM est le seul acteur de l’informatique dans notre pays, et la possibilité de breveté ses inventions dans tous les domaines des Technologies de l’Information et de la Communication naissantes lui confèrerait un avantage bien trop important. La pratique de l’INPI est longtemps restée fidèle à cette ligne de conduite [11]. La Convention de Munich de 1973 sur le brevet européen reprend cette exclusion dans son article 52-2. Cette position est par la suite transposée dans l’article L.611-10 du Code de la Propriété Intellectuelle.

Mais c’est une décision de 1986 dans l’affaire Vicom [12] qui va amorcer le changement. Par cette décision, l’Office Européen des Brevets (OEB) va autoriser dans certaines conditions que soit déposé un brevet pour une invention sous forme logicielle. L’invention devra présenter une caractéristique technique qui va au-delà de la simple fonction informatique. C’est à la suite de la décision IBM [13] de 1998 que l’OEB va réunir les pays européens en conférence diplomatique afin de modifier la convention pour l’accorder avec la jurisprudence actuelle. Le nouveau texte parle de la nécessité d’une « contribution technique « , critère qui ressemble comme un jumeau au « caractère technique « de l’invention. Le critère d’innovation n’est-il pas fondamental quel que soit le type de découverte brevetée ? La forme est indifférente en théorie. L’exclusion et son exception viennent à manquer de pertinence depuis que cette jurisprudence a été entérinée.

2 – Le bilan de cet état de faits est mitigé.

Après bientôt vingt ans de jurisprudence, cinq ans d’application de ce nouveau texte, et à l’heure des discussions sur la directive « concernant la brevetabilité des inventions mises en oeuvre par ordinateur « il convient de dresser un bilan de cette pratique. Depuis 1986, 30 000 brevets de logiciels ont été déposés en France. Ils concernent tous des innovations techniques sous forme logicielle mais dans des domaines autres que l’informatique pure. Toutefois, la France, à l’instar de l’Espagne, applique des critères plus stricts que ceux de l’OEB. Des pays tels que l’Angleterre et l’Allemagne appliquent la jurisprudence communautaire à la lettre là où les Pays Bas n’ont pas encore pris de position claire.

Le problème majeur est l’insécurité juridique créée par cet état de faits : alors que les brevets de logiciels sont prohibés, il en existe un grand nombre au niveau national ou européen. Comment les acteurs des différents marchés (industriels, éditeurs de logiciels,…) peuvent-ils concevoir une politique de Recherche et Développement pérenne alors que les règles qui sont censées les protéger ne sont pas clairement établies ?

La seconde incertitude en la matière est le positionnement des logiciels libres autour de cette interdiction largement contournée. Si pour les acteurs de l’open source, la brevetabilité représente la mort du logiciel libre, elle est avancée par les éditeurs de logiciels propriétaires comme la seule possibilité de protéger leurs investissements. Sans discuter de la viabilité de l’un ou l’autre de ces modèles économiques (et idéologiques), il apparaît que certaines critiques sont infondées. L’argument principal des détracteurs des brevets logiciels est le risque de voir se reproduire l’affaire Unisys [14]. Même si dans cette affaire, les utilisateurs n’ont aucunement pâtit de la revendication sur l’algorithme GIF. Leurs craintes semblent devenir réalité avec le procès SCO v. IBM que nous vivons en ce moment. OEB menace en effet d’attaquer l’ensemble des utilisateurs commerciaux de Linux en raison d’une prétendue contrefaçon de partie du code source d’Unix dans le code source de GNU/Linux. Quid de l’avenir des développeurs et des utilisateurs du système GNU/Linux dans l’hypothèse du succès (très improbable tout de même) d’une telle action d’envergure.

D’autre part, toute demande de brevet doit porter sur une innovation qui n’est pas « connue de l’homme du métier « . Si ce critère fondamental continu d’être respecter (et il paraît évident qu’il le sera), aucun acteur du marché ne se verra accorder de brevet sur le double-clic !

Compte tenu de la nébulosité des critères de l’OEB, de l’absence d’harmonisation entre les pratiques nationales, et des opinions divergentes entre développeurs de logiciels libres et éditeurs de logiciels propriétaires, la nécessité d’une législation adaptée et claires se fait de plus en plus sentir.

B Une direction incertaine pour une nécessaire évolution.

1 – Les évolutions proposées par la Directive

La principale nouveauté de ce texte résulte de l’article 3 qui prévoit que « les Etats membres veillent à ce qu’une invention mise en oeuvre par ordinateur soit considérée comme appartenant à un domaine technique« . En d’autres termes, les logiciels ne sont plus exclus par principe de la brevetabilité. Au contraire, si la rédaction de cet article est maintenue, elle instaurerait une présomption de caractère technique pour toute invention mise en oeuvre par ordinateur. Une méthode commerciale mise en oeuvre par ordinateur serait-elle de ce seul fait considérée comme technique, et donc susceptible d’être brevetée, à l’inverse de ce qui a été décidé récemment par la Cour d’Appel de Paris le 10 janvier de l’année dernière [15] ?

A l’exception de son article 3, la proposition de directive n’apporte donc rien de bien nouveau par rapport à la pratique de l’OEB et de certains offices nationaux. Elle aurait néanmoins pour effet de ratifier cette jurisprudence et de « sécuriser« devant les juridictions nationales les brevets de logiciels déjà déposés.

La Convention voit dans le brevet une sauvegarde de l’innovation en protégeant l’inventeur tout en dévoilant le fonctionnement de la découverte. Dans cette optique, la durée du brevet de 30 ans ne diffère-t-elle pas les possibilités d’innovations d’autant ?

En outre, il convient de regretter le silence du projet sur l’un des principaux problèmes posés par la brevetabilité des logiciels : la co-existence sur un même procédé ou produit d’un brevet et de droit d’auteur. Cette question fondamentale a notamment des incidences sur les relations avec l’auteur/inventeur salarié (titulaire des droits, rémunération…), l’exploitation des droits (formalisme des concessions de droits, obligation d’exploiter…), le contentieux (compétence, prescription, auteur de la contrefaçon…). Autant de sujets sur lesquels le droit d’auteur et le droit des brevets n’apportent pas, en l’état, la même réponse.

2 – L’avenir du droit des brevets logiciels.

Il y a peu de chances à mon sens que le nombre de brevets augmente réellement. Le critère pour la recevabilité de toute demande de dépôt de brevet est le caractère « innovant « . Or, les véritables innovations en matière informatique ne sont pas légions : seules des améliorations de procédés existant sont découverts, et la majeure partie d’entre eux se verra certainement refusé l’octroi d’un monopole. La dernière véritable innovation en matière informatique fut le SQL (Structured Query Language) : Le modèle relationnel a été inventé par E.F. Codd (Directeur de recherche du centre IBM de San José) en 1970. Depuis lors, rien ne semble avoir réellement bouleversé le paysage des nouvelles technologies au point qu’un monopole sur cette invention bloquerait toute créativité.

Néanmoins, il reste indéniable que les débats autour de la directive européenne n’ont pas permis de vraie discussion. Il n’a pas été accordé d’attention suffisante aux logiciels libres. Dans l’état actuel des choses, seuls les éditeurs de logiciels propriétaires profitent du système des brevets, et rien dans le nouveau texte n’envisage de créer un brevet adapté à l’Open Source.

Par ailleurs, il y a fort à parier que même si la brevetabilité ne sonnera pas le glas des acteurs de l’Open Source, elle posera un certain nombre de problèmes quasi insolubles. Même si le dépôt de brevet et l’utilisation de licence GPL ne sont pas incompatibles juridiquement parlant, les deux approches semblent très difficilement conciliables en pratique. Il devient difficile de contrôler la rétribution du détenteur du brevet pour une invention dont on ne maîtrise pas la diffusion. Il devient donc impossible de rétribuer les éditeurs de logiciels libres avec les mécanismes classiques de la brevetabilité.

Finalement, si la vision d’un avenir monopolistique avancée par les libertaires de l’informatique est extrême dans la noirceur du tableau, il n’en subsiste pas moins certaines incertitudes. En effet, alors que le brevet sur certaines fonctionnalités des feuilles de style CSS [16] appartient à Microsoft, cela n’empêche pas leur très large utilisation sur le Web. A l’inverse, on peut s’interroger sur les retombées d’un brevet déposé sur un protocole de communication. Ce monopole ainsi acquit par une grande entreprise ferait de tous les utilisateurs de systèmes d’information une clientèle captive.

Finalement, on arrive à une situation on ne peut plus paradoxale avec IBM qui vient de déposer un brevet [17] sur un mode de rétribution des développeurs Open Source. Il est question de faire des demandes de développement de fonctionnalité à la communauté du libre. Le projet retenu sera payé par l’éditeur demandeur, mais les projets non retenus seront aussi financés. Dans cette optique, on reste Open Source, mais reste-t-on libre ?

Bibliographie

Sites Visités

Clever Age – http://www.clever-age.com/

Le journal du Net – http://www.journaldunet.fr/

http://www.internet-juridique.net/

http://linuxfr.org/

GNU’s Not Unix ! (Free Software Foundation) – http://www.gnu.org/

Comment ça marche ? – http://www.commentcamarche.net

ZDNet – http://www.zdnet.fr

Colloques

Séminaire d’analyse économique : Mutation de l’Etat dans la Société Post-Industrielle.

Bertrand WARUSFEL (Avocat, Professeur à l’Université Paris V) : Droits de propriété sur les logiciels libres.

Documents

Garanties et responsabilités dans les logiciels libres – Me Valérie SEDALLIAN (Avocat à la Cour de Paris – http://www.internet-juridique.net/).

Interview de Michel ROCARD (Parlement Européen) du 06/010/2003.

Les logiciels libres à l’épreuve du marché

  • Me Benoît de ROQUEFEUIL (Cabinet Alain Bensoussan).

Quelle brevetabilité pour les logiciels ? -par Sylvain STAUB et Jean-Frédéric GAULTIER (Avocats à la Cour – Clifford Chance).

Vingt ans de logiciels libres : quels défis pour demain ? – par Richard STALLMAN (Président de la Free Software Foundation).

Ouvrages

La création multimédia et le droitMallet-Poujol N. – Litec 2000

Internet : enjeux juridiquesFalque-Pierrotin I. – La Documentation française 1997

 

[1] Fondateur de la Free Software Fondation.

[2] Etude réalisée par la société anglaise Netcraft et repris dans un article du Journal du Net du 14/01/2004 (http://solutions.journaldunet.com/0…).

[3] Cf. le site de l’Agence : http://app.legalis.net/

[4] Entreprise de distribution Linux (http://www.fr.redhat.com/).

[5] Cf. Le site du constructeur Kiss : http://www.kiss-technology.com/.

[6] Le Div-X et ses dérivés est un format de compression de la vidéo, de la même façon que le MP3 est un algorithme de compression du son.

[7] La seule mesure qui a été prise par les développeurs de MPlayer a été la diffusion de cette information sur leur site web : http://www.mplayerhq.hu/homepage/de….

[8] Bordeaux, le vendredi 12 juillet 2002

[9] Unisys a revendiqué en 1983 un brevet sur le format de compression LZW, qui est à la base de la compression des images GIF.

[10] En France : dol ou tromperie, manquement à une obligation essentielle du contrat (CF. Arrêt Chronopost Cour de Cassation 22 Octobre 1996), Article L132-1 du Code de la Consommation et Responsabilité du fait des produits défectueux (1386-1 à 1386-18 du Code Civil).

[11] Chambre Commerciale de la Cour de Cassation : Mobil Oil Corp. 28 mai 1975

[12] Vicom, 15 juillet 1986, T208/84, JOOEB 1987,14

[13] IBM, 1er juillet 1998, T1173/97

[14] Cf. supra I B 2)

[15] S.A. Sagem c. Le Directeur de l’INPI, Cour d’appel de Paris, 10 janvier 2003.

[16] Cf. le site du World Wide Web Consortium : http://www.w3.org/Style/CSS/.

[17] Brevet n° 6,658,642.

Tweet about this on TwitterShare on Facebook

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.