Comparatif des licences open source : attention aux pièges
Attention à la fausse liberté qui se cache derrière le concept d'open source. Les licences open source n'ont de libre que le nom et il convient de se pencher attentivement sur leur contenu pour ne pas commettre d'impair. Si les pionniers du libre étaient opposés, par principe, à toute forme d'action judiciaire, les esprits ont depuis évolué. Il y a quelques années, quatorze entreprises, dont Samsung, étaient poursuivies pour violation de la licence GNU-GPL par le Software Freedom Law Center. Plus récemment, Free a été assigné en justice pour le même motif.
| GNU GPL | BSD (Berkeley Software Design) | MIT License | MPL (Mozilla Public License) | Apache 2.0 | |
|---|---|---|---|---|---|
| Accès au code source | Oui | Oui | Oui | Oui | Oui |
| Droit de duplication | Oui, sous certaines conditions | Oui, implicitement | Oui | Oui, implicitement | Oui, implicitement |
| Droit de procéder à des modifications avec intégration dans un autre programme | Oui mais obligation d'annoncer la modification | Oui, pas d'obligation d'annoncer la modification | Oui, pas d'obligation d'annoncer la modification | Oui, pas d'obligation d'annoncer la modification | Oui, pas d'obligation d'annoncer la modification |
| Compatibilité inférieure | Aucune | Potentiellement avec toute licence | Potentiellement avec toute licence | Potentiellement avec toute licence | Potentiellement avec toute licence |
| Projets | AbiWord, Drupal, Git, Linux, MariaDB, MySQL... | Angle, Eudora, Flex, Go, Java OpenGL, TinyOS... | Angular, Bitcoin, GitLab, Visual Studio Code... | Adobe Flex, LibreOffice, Mozilla Firefox... | Android, GrapheneOS, Hadoop, .Net... |
Source : Metalaw Avocats Associés
D'autres risques pèsent sur les entreprises qui s'affranchiraient du contenu des licences. "Les membres des communautés open source sont très attachés aux règles du libre et n'hésitent pas dénoncer les entreprises qui les enfreignent", avance Géraldine Salord, avocat au Barreau de Paris et associé fondateur de Metalaw Avocats Associés. Au-delà de cette atteinte à la réputation, ils peuvent aussi rendre public le code produit estimant que celui-ci relève de l'open source. Pour rajouter à la complexité, il existe des milliers de licences open source et il s'en crée presque tous les jours, aux côtés des licences les plus connues des familles GNU et OSI.
Déterminer l'élément déclencheur
Pour Géraldine Salord, la première question à se poser avant de choisir une licence porte sur la finalité de la solution open source. "Les effets contraignants de la licence ne se déclenchent que lors de certaines actions. Cet élément déclencheur est généralement l'exploitation commerciale du code. Une entreprise pourra modifier le code pour un usage interne sans que cela porte à conséquence." Ainsi, un laboratoire qui a une finalité de recherche ne provoquera pas, pour la plupart des licences, d'élément déclencheur.
En revanche, une entreprise privée peut vouloir redistribuer commercialement tout ou partie du code. "Le simple fait d'intégrer de l'open source comme le ferait un constructeur automobile dans un système embarqué qui est ensuite vendu peut constituer un élément déclencheur", illustre Géraldine Salord. L'utilisation d'un site web ou d'un modèle d'IA à usage externe peut aussi constituer un élément d'activation. Il en va de même d'un transfert technologique entre un sous-traitant qui fait appel à une brique open source et un donneur d'ordre.
Evaluer la comptabilité entre licences
Par ailleurs, la juriste rappelle que presque plus aucun logiciel n'est aujourd'hui développé en partant de rien. "Des langages de programmation comme JavaScript ou Python ou le langage C permettent de créer des logiciels en faisant appel à des banques de composants pré-écrits, des bibliothèques et des plugins qui peuvent être chacun soumis à une licence différente", constate-t-elle.
"Plus une licence est libre, plus elle s'impose aux autres par capillarité"
Un logiciel peut ainsi appeler plusieurs composants soumis chacun à des licences qui leur sont spécifiques. Il s'agit donc de voir quel est le degré de compatibilité des licences entre elles. "Cette notion de compatibilité pose de manière sous-jacente la question de la contamination", poursuit Géraldine Salord. "Plus une licence est libre, plus elle s'impose aux autres par capillarité. La licence sera dite à fort copyleft lorsqu'elle présente un caractère très contaminant."
Particulièrement contaminante, la licence GNU GPL v2 s'impose aux autres composants. A l'inverse, la licence MIT, à copyleft faible, se soumet entièrement aux autres licences. Elle permet une redistribution à 100% avec des composants d'autres licences. Il suffit simplement de mentionner la présence de cette licence dans le code de l'application commercialisée.
Composition ou dérivation ?
A ce stade, il convient de distinguer le fait d'assembler des briques ou d'intégrer des briques entre elles. Dans le premier cas, on parle de composition car on crée des liens entre des briques sans modifier leur code. Dans le second, il s'agit d'intégration ou dérivation. La fusion entre briques nécessitant la modification de leur code source.
Partant de là, la compatibilité supérieure désigne la capacité d'un composant sous une licence open source donnée d'être soumis aux dispositions d'une autre que sa licence d'origine. "Une licence A accepte d'être absorbée par une licence B", schématise Géraldine Salord. "A contrario, la compatibilité inférieure désigne la capacité d'une licence d'accueillir un composant soumis à d'autres licences. La brique sous licence B accepte d'intégrer une brique initialement sous licence A."
"Tout l'enjeu pour une organisation consiste à pouvoir utiliser ces solutions sous licence libre côte à côte"
Avec GPL v2, qui a un copyleft particulièrement fort, c'est l'ensemble du logiciel qui doit être sous GPL v2. Cette licence interdit de faire mention d'une autre licence. Suivant les versions, des licences GPL peuvent être incompatibles entre elles. GPLv3 accepte, par exemple, de cohabiter avec la licence Apache, qui est permissive.
Des particularités peuvent apparaître. BSD est une des licences les plus permissives avec MIT mais BSD a créé une variante dite BSD à trois clauses qui permet à l'utilisateur de ne pas reprendre la clause de citation de la licence BSD. Cela permet donc de la rendre compatible avec la GNU GPL V2. "Tout l'enjeu pour une organisation consiste à pouvoir utiliser ces solutions sous licence libre côte à côte", résume Géraldine Salord. "Cela suppose de s'assurer que leurs licences respectives soient compatibles. GPL v3 liste les licences qui sont compatibles. D'autre licences, très courtes, ne les mentionnent pas."
Une stratégie de licence "by design"
Au regard de ces contraintes, une entreprise doit définir, en amont d'un projet, le type de licences avec lesquelles elle accepte de travailler et donc d'en restreindre volontairement le nombre. A cet effet, le cabinet Metalaw Avocats Associés propose des tableaux de correspondances pour indiquer à une entreprise ce qu'elle peut faire ou non en combinant des licences.
L'absence de stratégie de licence pourrait aller jusqu'à remettre en cause un projet. "Un projet open source peut comporter une dizaine ou une vingtaine de briques open source", observe Géraldine Salord. "Les ingénieurs vont les utiliser sans se soucier de la comptabilité. A la fin, l'application ne pourra être exploitée ou bien il faudra la reprendre et remplacer certains composants."
Par ailleurs, une entreprise doit se poser la question de ce qui constitue véritablement un avantage concurrentiel à ses yeux. "Il est recommandé de cloisonner les différentes parties d'un logiciel pour les rendre hermétiques entre elles, conseille Géraldine Salord. "Cela évite la contamination et donnera accès à des briques stratégiques." Tout un travail d'architecture à entreprendre, là aussi, en amont.