open source

Comprendre l'Open source

Article rédigé par Thomas CAVACECE

Temps de lecture : 6mn| Open Source

Depuis l’apparition du « Logiciel libre » dans les années 1980, puis son évolution en « Open Source » à la fin des années 2000, l’exploitation des codes sources mis à disposition du public a explosé.

Ce sujet d’actualité est complexe, tant pour les juristes spécialisés que pour les ingénieurs et développeurs qui l’exploitent.

Le recours à ces éléments s’accentue d’année en année, et leur utilisation tend à devenir plus intense avec l’émergence des IA génératives telles que ChatGPT, GITHUB Copilot…

Dans ce contexte, il est important que les professionnels du numérique soient formés, a minima, aux bases, aux risques et aux bonnes pratiques liés à l’utilisation de logiciel en open source.

Qu’est-ce que l’open source ?

L’Open Source est communément défini comme un code source librement accessible, par opposition à un code source propriétaire, qui n’est normalement pas accessible à tous.

L’Open Source Initiative, organisation dédiée à la promotion des logiciels en open source, ne donne pas de définition précise mais pose dix critères pour qu’un code soit considéré comme open source.

Les 10 critères de l’open source

  • Redistribution gratuite,
  • Code source accessible
  • Œuvre dérivée permise,
  • Intégrité du code source de l’auteur[1]

Il s’agit là des quatre critères principaux, mais à cela, il faut ajouter d’autres critères, y compris les ceux afférents aux licences appliquées.

  • Pas de discrimination entre personnes ou groupes
  • Pas de discrimination entre les domaines d’application
  • Permettre la distribution de la licence
  • La licence ne doit pas être spécifique à un autre produit
  • La licence ne doit pas restreindre l’utilisation d’autres logiciels
  • La licence doit être technologiquement neutre

L’Open Source s’oppose donc aux licences propriétaires que l’on peut trouver sur le marché, pour les logiciels ou suites de logiciels (Ex : Microsoft Office 365…).

Les libertés liées au code distribué en open source

Il existe quatre libertés concernant les codes sources distribués en Open Source :

  • Liberté d’utiliser : la liberté de faire fonctionner le code source, peu importe son usage ;
  • Liberté de modifier : il s’agit de la liberté d’étudier et de modifier le code source mis à disposition ;
  • Liberté de redistribuer des copies du code source mis à disposition ;
  • Liberté de distribuer une version modifiée du code source.

Ces principes s’accompagnent d’obligations. En effet, Open Source ne signifie pas une totale liberté. Des licences ont été créées et déterminent les conditions d’usage, de modification et de redistribution de ces codes. Il existe deux catégories principales de licence Open Source : Permissive (sans copyleft) et non Permissive (avec copyleft).

Les différentes types de licences open source

Les licences permissives

Les licences permissives, sans copyleft, sont les plus libres. Elles permettent une exploitation du code ou une intégration dans un code existant sans réelle restriction.

Parmi ces licences, nous retrouvons la licence BSD[2], la licence Apache[3] ou encore la licence MIT. Celles-ci permettent à chacun d’utiliser, d’étudier, d’améliorer, de distribuer le contenu. Les principales obligations sont de maintenir la licence, de mentionner l’auteur et la licence.

De plus, si vous souhaitez intégrer du code Open Source soumis à une licence permissive, vous ne risquez pas une contamination de votre code propriétaire. Vous pourrez ainsi rester propriétaire de votre code, tout en maintenant la licence permissive sur la partie intégrée. Il n’existe que trois obligations liées à ces licences : mentionner l’auteur, mentionner la licence et maintenir la licence.

Ainsi, ces licences sont les plus proches de l’idée de licence libre et de promotion d’un partage des connaissances et avancées en matière de codage.

Les licences non permissives

En plus de ces licences sans copyleft, il existe les licences non permissives que l’on peut diviser en deux catégories : avec copyleft fort et avec copyleft faible. Cette notion de copyleft fort ou faible va déterminer les libertés accordées par ces licences ainsi que l’impact de l’intégration d’un code Open Source à un code propriétaire.

Parmi ces licences, nous pouvons retrouver la GNU GPL[4] ou la CeCiLL[5] avec un copyleft fort. Il existe aussi une version LGPL5 (Light GPL) ou la licence MLP[6] avec un copyleft faible.

L’intégration d’un code soumis à l’une de ces licences va avoir un impact bien plus important que les licences permissives. En effet, les licences avec un copyleft fort vont vous accorder le droit d’utiliser, modifier, accéder au code source, l’améliorer ou le distribuer dans une nouvelle version. Mais en contrepartie, vous devrez le redistribuer sous la même licence. Vous ne pourrez donc pas l’exploiter comme un code propriétaire.

De plus, l’articulation de ces licences entre elles est plus complexe et nécessite une étude plus approfondie. Les licences avec un copyleft faible seront plus souples. L’impact de celle-ci sur votre code propriétaire dépendra de la méthode d’intégration. Par exemple, si vous intégrez, à votre code propriétaire, du code Open Source soumis à une licence LGPL, par dérivation, l’ensemble de votre code sera soumis à cette licence et vous devrez le redistribuer dans les mêmes conditions. En revanche, si le code est intégré par composition, vous resterez propriétaire de vos briques, mais les briques Open Source seront soumises à la licence LGPL.

Ces subtilités montrent encore une fois la nécessité de mettre en relation les équipes techniques et juridiques afin de se prémunir contre une contamination totale du code.

Les risques liés à l’utilisation d’open source

Il existe de nombreux risques liés à l’utilisation et l’intégration d’une partie de code Open Source lors du développement d’une solution numérique.

Risque de dévaluation du logiciel

Le premier risque est la dévaluation de votre produit. En effet, si votre société se base sur l’édition de logiciels ou sur la mise sur le marché d’une solution numérique, un code propriétaire « contaminé » par une licence non permissive peut vous obliger à distribuer vos codes source dans les mêmes conditions. Cette dévaluation peut entraîner une perte financière mais aussi réputationnelle.

Risques civils et pénaux

Les risques juridiques sont aussi à prendre en compte dans l’utilisation de l’Open Source. En effet, ne pas respecter les licences vous expose à des risques civils et pénaux.

Dans une décision du 5 octobre 2022[7], la Cour de cassation a confirmé la possibilité pour le titulaire de droit d’agir sur le fondement de la contrefaçon en cas de violation d’un contrat de licence.

Un opérateur télécom avait intégré, au sein de ses solutions numériques, un logiciel soumis à une licence libre. Considérant qu’il s’agissait d’une violation de la licence et des droits de propriété intellectuelle, le titulaire de droit avait assigné l’opérateur en contrefaçon de droit d’auteur et parasitisme.

Tout d’abord débouté de ses demandes en première instance, le titulaire de droit se voit reconnaître le parasitisme mais voit rejetée la demande en contrefaçon. La Cour d’appel se justifie en rappelant que l’atteinte résultait d’une violation du contrat de licence et que seule une action contractuelle pouvait être engagée.

La Cour de cassation casse et annule cet arrêt en rappelant la décision de la Cour de justice de l’Union européenne, rendue le 18 décembre 2019[8] : « la directive [2004/48] et la directive [2009/24] doivent être interprétées en ce sens que la violation d’une clause d’un contrat de licence d’un programme d’ordinateur, portant sur des droits de propriété intellectuelle du titulaire des droits d’auteur de ce programme, relève de la notion d’ « atteinte aux droits de propriété intellectuelle », au sens de la directive [2004/48], et que, par conséquent, ledit titulaire doit pouvoir bénéficier des garanties prévues par cette dernière directive, indépendamment du régime de responsabilité applicable selon le droit national ».

Ainsi, la violation d’un contrat de licence peut entraîner une action civile contractuelle ou une action pénale en contrefaçon.

Il est donc important de respecter certaines bonnes pratiques afin de limiter les risques.

Les bonnes pratiques de gestion des open source

Tout d’abord, les acteurs, développeurs, ingénieurs, juristes doivent être formés aux bases de l’Open Source et à ses enjeux.

Il est fondamental de tenir un registre listant les parties de codes, les briques ou les logiciels Open Source ainsi que les licences qui s’appliquent, afin d’avoir un suivi et de ne pas risquer d’intégrer une solution en violation d’une licence.

Enfin, il n’est pas rare que les éditeurs mettant à disposition un logiciel Open Source proposent aussi une licence propriétaire, avec plus d’options et un meilleur suivi. Il est donc possible, dans certains cas, d’évaluer la possibilité de choisir une licence propriétaire (souvent payante) au lieu d’une licence libre. Enfin, il faut effectuer des audits réguliers afin de limiter les risques.

En cas de doute, il est important de se rapprocher d’un conseil juridique qui pourra vous accompagner et évaluer les risques.

L’Agence pour la Protection Des Programmes l’APP est une association loi 1901 fondée en 1982 et dont la vocation est d’informer et de former les juristes d’entreprise aux enjeux de la PI et des nouvelles technologies. Elle propose des solution de dépôt de propriété intellectuelle, d’entiercement d elogiciel et d’audit de la PI du code source, incluant notamment une analyse exhaustive des open source.

 

[1] https://opensource.org/osd/

[2] https://opensource.org/license/bsd-3-clause/

[3] https://www.apache.org/licenses/LICENSE-2.0

[4] https://www.gnu.org/licenses/licenses.fr.html#GPL

[5] https://cecill.info/

[6] https://www.mozilla.org/en-US/MPL/

[7] Cass., 1ère Civ., 5 octobre 2022, n°21-15.386

[8] CJUE, 18 décembre 2019, C-666/18, IT Development SA c/ Free Mobile

Vous avez aimé l’article ? 

N’hésitez pas à le partager et à nous suivre sur nos réseaux sociaux pour en apprendre plus