vademecum-logiciel-libre

Vademecum juridique pour les auteurs de logiciel libre

Libre ou non, un logiciel est une œuvre de l’esprit régie par le droit d’auteur. Le droit d’auteur protège toutes les formes du logiciel (code objet, du code source et travaux préparatoires tels qu’un modèle UML).

Le droit d’auteur réserve l’essentiel des droits à l’auteur. De ce fait, un logiciel ou son code source ne doivent pas être utilisés en l’absence d’information claire sur les droits concédés.

Un logiciel n’est pas brevetable « en tant que tel » en Europe. Les bases de données soumises à un droit sui generis en Europe.

Le droit d’auteur se décompose en les droits patrimoniaux et le droit moral (je ne sais pas pourquoi, même s’il y en a plusieurs, on parle toujours du droit moral au singulier) :

  • Droits patrimoniaux (on appelle le titulaire de ces droits « l’ayant droit »)
  • Ce sont les droits liés à l’exploitation de l’œuvre (révélation, mise sur le marché, exécution, traduction, adaptation).
  • Si d’une manière générale, ils sont dévolus à l’auteur, dans le cadre d’une activité salariée de développement de logiciel, ils sont automatiquement dévolus à l’employeur qui est seul habilité à les exercer :
  • Un salarié n’a donc pas le droit de publier un logiciel - quelque soit sa licence - sans l’accord de son employeur.
  • Il appartient à l’employeur - et non au salarié - de choisir les modalités de diffusion du logiciel et ses conditions d’utilisation (i.e. sa licence, qu’elle soit libre ou propriétaire).
  • La cession (transfert exclusif) et la licence (transfert non exclusif) des droits patrimoniaux sont permises (l’employeur peut donc céder ses droits à un tiers).
  • La durée des droits patrimoniaux est de 70 ans après la mort de l’auteur (ou de la première publication en cas d’œuvre collective) en France et de 95 ans aux États-Unis.
  • Droit moral
  • Il est inhérent à l’auteur (la personne physique qui a écrit le code), il est perpétuel, inaliénable (ne peut être cédé) et imprescriptible (ne peut être retiré).
  • Dans le cadre d’une activité salariée de développement logiciel, le droit moral de l’auteur se réduit au droit de paternité de l’œuvre (i.e. le droit moral est amputé du droit de retrait (aussi dit « droit de repentir ») et du droit au respect de l’œuvre).
  • Un salarié peut donc apparaitre comme auteur d’un logiciel (i.e. le mentionner dans le code source ou l’indiquer dans son CV).

Copyright

  • Le régime du copyright se substitue au droit d’auteur dans les pays dont le système juridique relève de la common law (Commonwealth, USA). Le copyright se focalise sur les droits patrimoniaux et ignore le droit moral, mais la jurisprudence a progressivement imposé la reconnaissance et le respect de la paternité.
  • On trouve souvent des mentions de copyright – par ex. « Copyright 2017-2019, Ma Boite » – dans le code source d’une application :
  • Cette mention est sans effet sur le régime juridique (en France, l’œuvre reste soumise au droit d’auteur). Mais elle facilite l’identification de l’ayant droit (le droit d’auteur n’impose aucune mention de l’ayant droit dans l’œuvre et ce dernier peut donc être très difficile à identifier) et sa compréhension est « universelle ». Elle est donc recommandée.

Dans ce qui suit, je vais parler d’œuvre dérivée et d’œuvre composée. Voici à quoi correspondent ces termes dans le cadre d’un logiciel :

  • Une œuvre dérivée (ou travail dérivé) est une œuvre résultant de la modification d’une œuvre pré-existante (par exemple, une photographie retouchée est une œuvre dérivée de la photographie originelle). Dans le cadre d’un logiciel, une version modifiée d’une application ou d’une bibliothèque est une œuvre dérivée quelque soit le but et le volume de la modification (correction de bogue, ajout fonctionnel, optimisation, traduction, etc.).
  • Une œuvre composée (ou travail composé) est une œuvre intégrant d’autres œuvres pré-existantes (par exemple, une œuvre réalisée par assemblage de photographies est une œuvre composée). Dans le cadre d’un logiciel, une application liée à des bibliothèques, dynamiquement ou statiquement, est une œuvre composée. C’est aussi le cas d’une œuvre intégrant des fragments de code source exogène (les fameux « copier/coller » que font sans sourciller les développeurs après avoir trouvé la solution à leur problème sur le net).

Le régime du copyright n’effectue aucune distinction de la sorte : tout est œuvre dérivée pour lui, d’où les longues explications que l’on trouve dans les licences se référant au copyright pour tenter de distinguer les deux cas et d’appliquer des conditions différentes aux deux.

Les licences libres sont nombreuses (moins que les licences propriétaires, n’en déplaise aux détracteurs du libre et aux juristes). Même si les dispositions de ces licences font que certaines sont plus appropriées aux bibliothèques et d’autres aux applications, elles peuvent toutes être utilisées pour des bibliothèques, des applications ou de simples fragments de code (des « snippets » tels qu’on en trouve beaucoup dans les manuels d’utilisation, sur Github ou les forums traitant de développement). Ces licences peuvent être classées en 3 familles :

  • Licences permissives : BSD, Apache, MIT, X, CeCILL-B
  • Elles s’appliquent au logiciel libre mais ni aux travaux dérivés, ni aux travaux composés. Ces licences sont utilisées pour tout type de logiciel.
  • Licences faiblement diffusives (aussi dites à copyleft faible ou réciprocité faible) : GNU LGPL (L pour Lesser), EPL, MPL, CDDL, CeCILL-C
  • Elles s’appliquent au logiciel libre ET aux travaux dérivés, mais pas aux travaux composés. Ces licences sont généralement utilisées pour les bibliothèques.
  • Licences fortement diffusives (aussi dites à copyleft fort ou réciprocité forte) : GNU GPL, CeCILL, EUPL (et non EPL)
  • Elles s’appliquent au logiciel libre ET aux travaux dérivés ET aux travaux composés. La limite d’application de ces licences est le lien binaire (l’exécutable avec les bibliothèques auxquelles il est lié statiquement ou dynamiquement). Ces licences sont généralement utilisées pour protéger des applications.
  • Cas particulier des licences fortement diffusives GNU AGPL (A pour Affero) et OSL :
  • Les autres licences, qu’elles soient permissives, faiblement diffusives ou fortement diffusives, ont un point commun : leurs obligations ne s’imposent à l’utilisateur qu’à partir du moment où celui-ci communique le logiciel à un tiers. S’il n’atteint jamais ce point (i.e. s’il réserve le logiciel à un usage interne à l’entité morale au sein de laquelle il a été créé), il peut faire ce qu’il veut, y compris créer des « chimères juridiques » en assemblant des composants incompatibles sur le plan juridique (ce que je déconseille vivement car il arrive toujours un moment où l’on a envie de transmettre à un tiers un logiciel qui était « réservé à un usage interne » ; il est donc préférable de faire les choses proprement dès le début, tant sur le plan technique que juridique). On dit que la distribution (i.e. la fourniture du logiciel à un tiers) est l’évènement déclencheur des obligations. Ces licences ont été conçues avant l’avènement du cloud et du SaaS. Elles ne les ont pas anticipés et certains margoulins l’ont bien compris : puisque l’évènement déclencheur des obligations est la distribution de l’application, ils ne fournissent qu’un service à distance et se gardent bien de distribuer leur application, d’où l’émergence du fameux « mode SaaS » (qui n’a pas toujours pour seul but de libérer l’utilisateur final de la charge de l’administration du service). L’application ne tourne donc que sur les serveurs du fournisseur de service, elle n’est jamais distribuée (modulo la partie exécutée par le navigateur de l’utilisateur, vis-à-vis de laquelle le margoulin prendra plus de précautions). Certains développeurs de logiciels libres se sentent à juste titre floués par le mode SaaS. Pour le contrer, les licences AGPL et OSL assimilent la mise à disposition des services du logiciel à une distribution : la mise à disposition du service constitue un évènement déclencheur des obligations.

Comme indiqué plus haut, les brevets sur les logiciels « en tant que tels » sont interdits en Europe et c’est une excellente chose qui nous évite notamment les turpitudes des « Patent trolls » qui extorquent légalement des milliards de dollars aux entreprises américaines. Mais dans les faits, l’INPI et l’OEB ne se gênent pas pour accorder des centaines de brevets sur les logiciels chaque année. Pour cela, il suffit que le demandeur maquille la description du procédé pour ne pas faire apparaitre qu’il s’agit d’un logiciel ou faire comme si ce logiciel était accessoire dans le procédé. Les conseillers en propriété intellectuelle sont passés maitres dans cet art avec la bienveillance de l’INPI qui a tout intérêt à ce que le brevet soit accordé (cela lui assure une rente pendant 20 ans). Malheureusement, un tel brevet est de la poudre de Perlinpinpin (expression que j’utilisais déjà 10 ans avant que Macron ne soit connu des Français). En effet, si en Europe, le détenteur d’un brevet sur un logiciel attaque une entreprise pour violation de ce brevet, l’entreprise attaquée n’aura pas à prétendre qu’elle ne viole pas le brevet, mais simplement à démontrer que ce brevet porte sur un procédé purement logiciel. Le juge considérera alors que la plainte n’est pas fondée et il annulera au passage le brevet. L’INPI ne sera pas inquiétée (« oups, pardon, nous avons manqué de clairvoyance dans notre analyse »), le titulaire du brevet est le seul dindon de la farce : il aura payé un conseiller en propriété intellectuelle et l’INPI pour une protection fictive (mais les brevets sont des actifs qui rassurent les investisseurs, ce qui motive en partie leur existence).

Le procès ayant opposé les sociétés Exalead et Sinequa et la décision rendue par le tribunal de grande instance de Paris le 19 mars 2010 illustrent bien ce que je viens d’expliquer.

  • vademecum-logiciel-libre.txt
  • Dernière modification: 2019/11/21 11:50
  • par sdinot