Compatibilité des licences entre elles et placement sous nouvelle licence

par Richard Stallman

Si vous souhaitez combiner deux programmes libres en un seul ou fusionner du code provenant d'un programme avec le code d'un autre, la question se pose de savoir si leurs licences permettent cette combinaison, ou bien l'interdisent [1].

Fusionner des programmes qui ont la même licence ne pose aucun problème si cette licence a des clauses raisonnables, comme c'est le cas de presque toutes les licences de logiciel libre [2].

Qu'en est-il lorsque les licences sont différentes ? En général, nous disons que plusieurs licences sont compatibles s'il existe un moyen de fusionner des séquences de code régies par ces différentes licences tout en les respectant toutes. Souvent, mais pas toujours, il en résulte un programme constitué de différentes parties dont chacune est régie par l'une de ces licences compatibles. Cette possibilité de combinaison (ou son absence) est une caractéristique d'un ensemble donné de licences et ne dépend pas de l'ordre dans lequel elles entrent en jeu. Cet ensemble détermine également quelle licence doit être utilisée pour le programme combiné.

Nous divisons les licences en trois classes : laxiste (également appelée « permissive » ou « bonne poire »), intermédiaire et copyleft. Une licence laxiste ne fait rien qui interfère avec l'intégration du code qu'elle régit à un logiciel privateur. Une licence à copyleft interdit cette opération en exigeant que tout programme réutilisant ce code soit régi par la même licence. Une licence intermédiaire pose certaines conditions à l'ajout de code privateur mais n'essaie pas de l'interdire.

En général les licences permissives ou laxistes (BSD modifiée, X11, Expat, Apache, Python, etc.) sont compatibles l'une avec l'autre, parce qu'elles n'ont pas d'exigence concernant le code tiers qui est ajouté au programme. Elles vont jusqu'à permettre de placer l'ensemble du programme (éventuellement modifié) dans un logiciel privateur ; c'est pourquoi nous les appelons « licences bonnes poires » : elles ne savent pas dire non quand un utilisateur essaie de priver les autres de leurs libertés.

Dans une combinaison de programmes sous licences laxistes, chaque partie conserve sa licence d'origine. Lorsque le code est fusionné à un point tel que les parties ne peuvent plus être identifiées, ce code doit porter toutes les licences des parties fusionnées. Puisque de toute façon toutes les licences sont laxistes, cela ne crée aucun problème pratique, à part la longueur de la liste de licences [3].

De la même manière, les licences laxistes sont habituellement compatibles avec n'importe quelle licence à copyleft. Dans un programme combiné, les parties qui à l'origine étaient sous des licences laxistes les conservent et l'ensemble du programme combiné est sous la licence à copyleft. Une licence laxiste particulière, Apache 2.0, a des clauses concernant les brevets qui sont incompatibles avec la version 2 de la GPL ; comme je pense que ces clauses sont bonnes, j'ai rendu la GPL version 3 compatible avec elles.

La seule exception remarquable est la licence BSD d'origine, avec son odieuse « clause publicitaire ». Cette condition exigeait un avis spécial dans toute publicité pour tout produit contenant tout code publié sous la licence BSD d'origine. C'était, et cela reste, incompatible avec toutes les vraies licences à copyleft. De plus, c'était la galère pour chaque distribution, qui voyait s'accumuler des programmes ayant des exigences similaires mais différentes en ce qui concerne la publicité. C'en est arrivé au point où une distribution BSD nécessitait 70 avis différents.

J'ai à peu près éliminé ce problème en convainquant le doyen Hal Varian de faire en sorte que l'Université de Californie à Berkeley publie la « licence BSD modifiée » (sans clause publicitaire) et republie le code de la distribution système de Berkeley (BSD) sous cette dernière licence. De nos jours, la licence BSD d'origine est (heureusement) rarement utilisée, mais nous devons toujours veiller à ne pas parler de la « licence BSD ».

En général, deux licences à copyleft différentes sont inévitablement incompatibles à moins qu'elles n'aient des clauses de compatibilité explicites. Ce n'est pas dû à des erreurs de détail, c'est inhérent à la notion de copyleft. Le principe du copyleft est que « les versions modifiées ou étendues doivent être sous la même licence ». Si la licence A du programme P dit que les programmes étendus doivent être sous la licence A, et que la licence B du programme Q dit que les programmes étendus doivent être sous la licence B, il y a un désaccord irrémédiable ; la licence du programme combiné (qui comprend le code de P et le code de Q) doit être A, et elle doit être B.

C'est pourquoi les versions 2 et 3 de la GPL sont incompatibles ; c'était inévitable. Suivant le même principe, les conditions de la CC BY-SA 4.0 seraient intrinsèquement incompatibles avec celles de la CC BY-SA 3.0 et les auteurs n'y pourraient rien.

Il y a deux méthodes pour éviter le problème d'incompatibilité causé par les versions différentes de licences à copyleft.

La méthode de la FSF consiste à demander aux gens de publier sous la « GNU GPL version N ou toute version ultérieure ». Ce choix de licences est compatible avec la version N, et aussi avec la N+1 (parce qu'elle propose la version N+1 en option). Quand on combine du code sous « GPL 3 ou ultérieure » avec du code sous «  GPL 2 ou ultérieure », la licence de la combinaison est leur intersection, c'est-à-dire « GPL 3 ou ultérieure ».

Nous espérons ne jamais avoir besoin de faire une GNU GPL version 4, mais rien n'est parfait et nous ne pouvons pas partir du principe que nous avons prévu tous les problèmes. En publiant votre code sous GNU GPL 3 ou ultérieure, vous lui permettez de passer à la GPL version 4, si jamais nous avons besoin de cette version.

L'autre méthode est de faire en sorte que chaque version de la licence permette explicitement l'évolution vers les versions ultérieures. La Fondation Mozilla utilise cette approche, de même que PHP. Creative Commons, quant à elle, l'utilise pour CC BY-SA: la version 4.0 (version actuelle) permet explicitement à tout utilisateur de passer aux versions ultérieures de la CC BY-SA pour les œuvres modifiées.

Seules les licences GNU donnent aux auteurs le choix de permettre, ou non, l'évolution vers les futures versions de la licence. Lorsqu'en 1989 j'ai écrit la première version de la GNU GPL, j'ai envisagé d'y inclure une option de mise à niveau comme celle qu'on trouve actuellement dans les licences Creative Commons, mais j'ai pensé qu'il était plus correct de laisser le choix aux auteurs. L'auteur pourrait ainsi publier un programme sous « GPL 1 seule » ou « GPL 1 ou ultérieure ».

Depuis, j'en suis venu à me demander si cette décision était judicieuse. Des programmes comme Linux, qui ne permettent d'utiliser qu'une seule version de la GPL et refusent les mises à niveau de la licence, sont cause d'incompatibilité en pratique [4]. Si jamais nous faisons une version 4, nous devrions peut-être y inclure une clause de mise à niveau qui permette automatiquement d'utiliser le programme sous les versions ultérieures, 5 et suivantes.

Certaines licences à copyleft permettent des combinaisons inter-copylefts au moyen d'une clause explicite (autorisation de relicencier) donnant la permission de mettre le code sous une autre licence à copyleft. Par exemple, la CeCILL donne la permission explicite de relicencier le code en GNU GPL version 2 ou ultérieure. Si un programme P est sous CeCILL et que vous voulez le combiner avec un programme Q qui est sous GPL version 3 ou ultérieure, la CeCILL dit que vous pouvez le faire, et ensuite placer la combinaison ou le code fusionné sous GPL version 3 ou ultérieure.

L'autorisation explicite de relicencier n'est pas la même chose que la compatibilité (bien que le fait de relicencier le code puisse le rendre compatible avec d'autres codes) et elle n'est pas symétrique. Par exemple, la CeCILL donne la permission explicite de relicencier du code en GNU GPL, mais la GNU GPL ne permet pas de relicencier en CeCILL. Vous ne pouvez donc pas combiner ces deux programmes P et Q, puis distribuer la combinaison sous CeCILL ; cela violerait la GPL du fait que la combinaison utilise le programme Q. Le seul moyen licite de publier ce programme combiné est de le placer sous la, ou les version(s) appropriée(s) de la GPL.

De même, la CC BY-SA 4.0 permet explicitement de relicencier les versions modifiées en GNU GPL version 3, mais la GNU GPL version 3 ne permet pas de relicencier en CC BY-SA. Ce problème ne devrait d'ailleurs jamais se poser pour du code logiciel ; Creative Commons dit en effet que ses licences ne sont pas destinées au code et que la licence à utiliser pour le code est la GNU GPL. Mais il y a d'autres sortes d'œuvres (plans de matériel, graphismes et musique de jeux par exemple) où vous pourriez avoir l'occasion de fusionner des documents sous CC BY-SA avec des documents sous GNU GPL. On peut le faire en utilisant la permission de relicencier que donne explicitement la CC BY-SA.

Malheureusement, la CC BY-SA ne permet pas de relicencier en utilisant les futures versions de la GPL. Ce que vous devez faire, quand vous relicenciez en GPL un document régi par la CC BY-SA 4.0, c'est de vous désigner vous-même comme représentant des auteurs pour indiquer, le moment venu, si les futures versions de la GPL sont autorisées pour ce document. Si un jour il y a une GPL version 4 et que Creative Commons donne la permission de relicencier de CC BY-SA en GPL version 4, vous pourrez, en tant que représentant des auteurs, autoriser rétroactivement l'utilisation de ce document sous GPL version 4 (alternativement, vous pouvez demander aux auteurs de ce document de donner dès maintenant leur permission).

La licence publique générale GNU ordinaire et la licence publique générale GNU Affero sont deux licences à copyleft différentes et sont de ce fait naturellement incompatibles. Nous avons mis en place une clause spéciale pour les rendre explicitement compatibles : vous pouvez faire un programme combiné contenant à la fois du code source régi par la GNU GPL version 3 et un autre code source régi par la GNU GPL Affero. C'est permis parce que ces deux licences le disent explicitement et spécifient que l'AGPL s'applique au programme combiné. Cependant, vous ne pouvez pas simplement relicencier en GNU Affero GPL du code régi par la GNU GPL, que la « version ultérieure » soit mentionnée ou non ; l'inverse n'est pas possible non plus ; aucune des deux licences ne donne cette permission. Notez également que la GNU GPL Affero version 3 n'est pas une « version ultérieure » de la GNU GPL ordinaire version 2, parce que la GNU GPL Affero et la GNU GPL sont deux séries de licences différentes.

La licence publique générale GNU amoindrie, version 3, est en réalité la licence publique générale GNU version 3 avec quelques permissions en plus. La GPL version 3 dit au paragraphe 7 que vous pouvez toujours supprimer les permissions supplémentaires, et ainsi mettre le code sous GNU GPL ordinaire version 3 sans le modifier. Si un programme autorise l'utilisation du code sous GNU LGPL, version 3 ou ultérieure, vous pouvez le relicencier en GPL version 3 ou ultérieure ; pour chaque future version N (N > 3) de la GPL, nous ferons une LGPL version N qui sera constituée de la GPL version N et de permissions supplémentaires.

La licence publique générale GNU amoindrie version 2.1, quant à elle, permet explicitement de relicencier en GNU GPL, version 2 ou ultérieure.

Les licences intermédiaires sont celles qui ont des exigences substantielles concernant la redistribution, tout en n'étant pas des licences à copyleft. Parmi elles on compte l'Eclipse Public License et la Mozilla Public License. Les licences intermédiaires ont tendance à être incompatibles avec toute licence à copyleft parce que leurs exigences ne permettent pas de placer le programme combiné sous copyleft. La Mozilla Public License permet de relicencier en GNU GPL sauf quand le code refuse explicitement cette permission.

Enfin, qu'en est-il des doubles licences [5] ? Une double licence [dual licensing] est une « disjonction ». Cela signifie que l'avis de licence du programme donne le choix entre deux licences différentes au minimum. Par exemple, les anciennes versions de Perl avaient une double licence : l'Artistic Licence et la licence publique générale GNU, disjointes. Cela signifie que, pour redistribuer Perl, chaque utilisateur pouvait choisir d'utiliser l'une ou l'autre, ou bien la disjonction des deux, comme la version de Perl diffusée à l'origine. Une disjonction est compatible avec un ensemble d'autres licences si l'une quelconque des licences proposées en choix dans la disjonction est compatible avec cet ensemble.

Quand vous choisissez une licence pour votre code, veuillez choisir la GNU GPL version 3 ou ultérieure, ou bien une licence compatible avec elle. De cette façon vous rendez possible la combinaison de votre code avec la presque totalité des logiciels libres. De plus, choisir la GPL ou l'AGPL, version 3 ou ultérieure, fera le maximum pour défendre les libertés de tous les utilisateurs de toutes les versions de votre code.

Comment combiner du code

Un ensemble de licences est dit compatible lorsqu'on peut légalement combiner ou fusionner plusieurs programmes qui sont régis par l'une de ces licences. Quelle licence choisir dans ce cas pour le programme combiné ?

Chacune des licences de logiciel libre dit que vous devez conserver la licence avec le code qu'elle régit. Au sens strict, cela veut dire que l'ensemble de licences régissant le programme combiné inclut les licences de toutes ses parties. Cependant, vous souhaitez quelquefois une réponse synthétique à la question de savoir quelle licence régit le programme. Quelles sont les licences auxquelles une personne utilisant le programme combiné doit faire attention ?

Pour le déterminer, on part d'une liste de toutes les licences pertinentes. Ensuite, on peut supprimer toute licence qui est englobée par une autre licence de la liste.

Nous disons qu'une licence A englobe une licence B lorsqu'on respecte implicitement B lorsqu'on respecte A.

Par exemple, la GNU GPL version N et la GNU GPL Affero version N englobent toutes deux la GNU GPL amoindrie version N, et toutes trois englobent la GNU GPL amoindrie version 2.1.

Toute version N d'une licence GNU englobe la licence Apache 2.O pourvu que N soit au moins égal à 3.

La GNU GPL, version N, englobe toutes les versions de la Mozilla Public License et est compatible avec elle.

La licence Apache 2.0 englobe les licences BSD, Expat, X11, ISC et CC-0. La BSD à 3 clauses englobe la BSD à 2 clauses? Les licences BSD englobent les licences Expat, X11 et ISC, ainsi que la CC0.

Cette liste n'a aucune prétention à l'exhaustivité, mais si on nous informe d'autres cas qui n'y figurent pas, nous les ajouterons.

Qu'une une licence soit englobée par une autre ne dispense pas d'inclure une copie de son texte dans toute distribution du programme combiné.

Notes

Il n'est pas exclu que d'autres problèmes juridiques se fassent jour à propos d'une combinaison donnée de programmes, problèmes qui ne soient pas en relation avec les licences de copyright des programmes que l'on veut combiner. Nous ne traitons ici que des implications des licences elles-mêmes.
La principale licence effectivement utilisée qui ne soit pas raisonnable est la licence de TeX : si deux programmes ont des licences exactement équivalentes à celle de TeX, il n'y a aucun moyen licite d'en distribuer une version fusionnée.

En effet, pour distribuer une version modifiée de TeX en respectant sa licence, il faut obligatoirement distribuer la version d'origine accompagnée d'un fichier de différences. Si A et B sont publiés séparément de cette façon, et ensuite fusionnés, distribuer le programme fusionné en tant que « A accompagné d'un fichier de différences » viole la licence de B. Le distribuer en tant que « B accompagné d'un fichier de différences » viole la licence de A. Le distribuer sous toute autre forme viole les deux licences.

Ce n'est pas une coïncidence si TeX a été publié en 1982. Notre communauté a depuis lors appris à rédiger des licences raisonnables.
Lorsqu'on distribue un programme sous forme de code source, il est d'habitude suffisant de laisser les avis de licence du code source tels qu'ils sont ; pour les licences laxistes, les exigences supplémentaires concernant les avis de licence n'apparaissent généralement que lorsqu'on distribue des binaires sans le code source.
En outre, la version 2 de la GPL permet toujours à du matériel de rendre des binaires non libres en les refusant tous à l'exception de certains binaires signés, et elle ne permet toujours pas la distribution des binaires par torrent, comme au jour de sa publication. Nous avons remédié à ces défauts et à d'autres dans la version 3, mais nous ne pouvons changer la version 2.
Certains, de manière inexplicable, utilisent le terme « double licence » pour désigner la vente d'exceptions, mais c'est un abus de langage. Voir Vendre des exceptions. Notez que si la licence vendue comme exception comprend du code qui n'est pas présent dans la version libre ordinaire, ce n'est pas de la vente d'exception, c'est du logiciel non libre.