Comment choisir sa licence open source : guide

Tous les logiciels libres ne sont pas open source. Pour ne pas être confronté au droit d’auteur classique, il convient de choisir une licence open source. Ce n’est pourtant pas si facile, car il y en a à profusion, avec des termes relativement difficiles à saisir, car ambigus.

L’univers du logiciel libre et open source n’est pas un tout. Il est constitué de nombreux éléments qui le rendent difficile à cerner :

• GPL version 2,
• GPL version 3,
• licence Apache,
• Mit,
• Artistic,
• Eclipse,
• Mozilla,
• CDDL,
• CeCILL, etc.

Le site GNU a même compté des centaines de licences, tout aussi différentes les unes des autres. Certaines ont des similarités entre elles ou sont compatibles, tandis que d’autres fonctionnent différemment. Avant d’opter pour une licence ou une autre pour un projet, ou encore se servir d’un composé libre trouvé en ligne, il est impératif de s’assurer de la licence sous laquelle son auteur l’a publié. À un expert dans le domaine de préciser que si des développeurs publient un logiciel sans licence, celui-ci sera obligatoirement soumis au droit d’auteur classique. On ne peut donc pas le copier ni le redistribuer…

Beaucoup de licences ont ainsi fait leur apparition, mais une qui vient d’émerger se distingue particulièrement. Il s’agit de la GNU GPL ou GNU General Public License dont la version 2 et la version 3 sont très utilisées. Il y a aussi les licences DBS et MIT plus libres et qui ne se différencient entre elles qu’à quelques détails près.

Une centaine de licences sont en effet apparues dernièrement. La cause en revient aux développeurs qui en privilégient une dizaine environ. Selon une récente enquête de Black Duck :

• 27 % environ des projets développés actuellement le sont sous licence GPL version 2,
• 16 % sont réalisés sous la licence MIT,
• 15 % le sont sous Apache 2.0,
• 11 % sous licence GPL version 3.

Peu de projets sont réalisés avec les autres licences autres que celles citées dessus. Il en est de même pour celles diffusées de manière confidentielle. D’après l’expert, l’essentiel est de faire en sorte qu’elles soient compatibles. Tout un chacun peut élaborer sa propre licence à condition qu’il veille à sa compatibilité avec d’autres licences. Cela évite les termes incompatibles qui engendreront des problèmes une fois que plusieurs logiciels ou bibliothèques de programmation sont intégrés ensemble. D’ailleurs, la législation préconise la compatibilité des licences.

Copyleft ou pas, une grande ambiguïté

Il convient de différencier les licences libres de celles qui ne le sont pas, copyleft ou pas. Les licences BSD ne disposent pas de copyleft, la clause où l’auteur du logiciel autorise les autres développeurs à se servir, modifier et distribuer un logiciel. Pour cela, il faut qu’ils conservent des clauses identiques à celles de la licence initiale ou garder celle-ci. C’est une nuance qui fait toute la différence, surtout, du côté des éditeurs de logiciels. On appelle cela l’effet contaminant de la licence. Il signifie que si un éditeur intègre une librairie de programmation éditée en GPL v2, il doit publier son logiciel avec sous la même licence, ce, avec les sources.

Il est donc interdit de faire sien le travail des autres dédiés à la communauté, ainsi que l’inclure dans un logiciel privatif. Le GNU GPL n’accepte pas une telle pratique, ce qui n’est le cas pour la famille BSD. Bon nombre d’entreprises qualifient aussi cette méthode d’inacceptable, ce qui contraint certains éditeurs à opter pour la double licence. Ils éditent leurs logiciels en GPL pour la communauté et en licence commerciale pour les entreprises. La pratique de dual licencing entre licences libres apparaît aussi progressivement. Il concerne les projets dont certains de leurs composants sont développés sous licence GPL et d’autres, sous MIT plus permissive suivant l’inspiration du développeur. La licence GPL version 2 autorise cette pratique à condition que les modules soient vraiment indépendants. Dans le sens contraire, le serveur http Apache qui est édité sous licence Apache de la famille BSD, peut être intégré dans une offre commerciale.

D’authentiques licences, mais difficilement applicables

Ces divers regards sur le coding sont à l’origine de l’apparition de nombreuses licences. Tout un chacun souhaite créer la licence qui répond à ses objectifs, ses convictions morales ou des fois, à ses opinions politiques. Certains développeurs précisent entre autres que leurs codes ne doivent pas être repris ni utilisés à des fins militaires ou similaires. De ce fait, les 2 principaux développeurs du projet GPU, Tiziano Mengotti et René Tegel y ont ajouté une clause de «  no military use » en 2006. Le logiciel étant un outil d’échange de fichiers en peer-to-peer, ils ne veulent pas qu’il serve à faire du mal à quelqu’un de quelle manière que ce soit. Même s’ils l’ont fait avec de bonnes intentions, cette clause est pourtant difficile à appliquer dans la réalité.

D’autres développeurs souhaitent interdire l’usage commercial de leur code, une clause tout aussi difficilement applicable que la précédente. En effet, si un développeur écrit un logiciel libre et qu’il souhaite ensuite empêcher les autres de le vendre, cela risque d’engendrer des soucis. Personne ne pourra pas par exemple commercialiser une compilation de logiciels qui inclura celui du développeur sur un CD. Ces termes de licence, quoique légitimes, car élaborés avec toutes les bonnes intentions du monde, risquent de rendre difficile leur application. C’est pourquoi elles ne sont pas tellement utilisées.

La licence HESSLA ou Hacktivismo Enhanced-Source Software License Agreement fait partie des licences dont la diffusion se fait de manière confidentielle. Elle a été éditée par Oxblood Ruffin, Cult of the Dead Cow et Eric Grimm. Le premier est membre des groupes de haciking Hacktivismo et le dernier est avocat de l’Electronic Frontier Foundation. Cette licence interdit à tous ceux qui l’utilisent de violer avec les droits de l’homme ou d’espionner les utilisateurs du logiciel.

CeCILL, des licences libres de la même famille éditées en France

Le lancement de la licence CeCILL en 2004 initié par le CEA, le CNRS et l’INRIA est une autre preuve de l’existence de nombreuses licences. C’est une licence de même type que la GPL, mais compatible avec la législation française. Créée en France, elle a été reconnue par l’Open Source Initiative. Sa compatibilité avec la GPL a été en outre validée par la Free Software Foundation. 

Comme elle est conçue pour être utilisée uniquement en France, la licence CeCILL n’est pas visible dans les statistiques de Black Duck. Elle compte pourtant 40 projets environ, selon son site officiel. Elle a même engendré une autre, une version 2 qui enlève tout doute sur son éventuelle incompatibilité avec la GPL version 2. Deux autres licences CeCILL s’y sont ajoutées :

• la CeCILL-B, de la famille BSD,
• la CeCILL-C de la famille C (Composant logiciel).

Cette dernière reprend les clauses de la licence LGPL ou GNU Lesser General Public Licence, une licence GPL réduite.

Voici quelques informations sur certaines licences open source

GNU General Public Licence (GPL)

C’est une licence copyleft, la plus populaire et la plus utilisée par les développeurs. Rédigée en premier par Richard Stallman, elle est disponible en v2 et v3 et existe en plusieurs déclinaisons comme la LGPL. Elle est pourtant qualifiée de licence contaminante, ce qui signifie que tout logiciel embarquant du code GNU GPL devient GNU GPL.

MIT

MIT est une licence non copyleft, mais très permissive, appelée aussi licence X11. Compatible GNU GPL, elle s’utilise surtout dans les petits programmes.

BSD

BSD est aussi une licence non copyleft, permissive et ne présente que de petites restrictions. Elle est compatible GPL et se décline en plusieurs licences BSD actuellement. L’Apache est l’une d’elles et la plus populaire. Il ne faut toutefois pas utiliser la licence BSD originale dont la clause de publicité est maintenant retirée.

Artistic

Artistic est une licence non copyleft de la communauté Perl. Compatible GNU GPL, elle ne peut être utilisée que dans sa version 2. Les clauses vagues de sa version originale ayant été pointées du doigt par FFF, elle a dû être déclinée en v2.

Apache

Apache est également non copyleft et compatible avec la licence GNU GPL v3. Destinée à l’origine aux packages Apache, elle est très utilisée par d’autres, car persmissive. Elle n’est toutefois pas compatible avec la GNU GPL2.

CeCILL

Copyleft, CeCILL est qualifiée d’open source par OSI ou Open Source Initiative depuis sa v2.1. Version française de la GNU GPL, la licence CeCILL a été complétée par la CeCILL-B, de la famille BSD et CeCILL-L (proche LGPL). Elle est cependant peu connue en dehors de l’Hexagone.