English [en]   français [fr]   русский [ru]  

GNU Health Conference  18-20 novembre, Las Palmas (Espagne) #GNUHealthCon2016

[Traduit de l'anglais]

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.

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 (1).

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 » : elle 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 (2).

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 dit que les programmes étendus doivent être sous la licence A, et que la licence B 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é 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 gommer l'incompatibilité inhérente aux nouvelles versions des 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. C'est ce que fait Creative Commons : par exemple, la CC BY-SA version 4.0 (version actuelle) permet explicitement à tout utilisateur de passer aux versions ultérieures de la CC BY-SA une fois qu'elles existeront. La Fondation Mozilla utilise la même approche.

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é pratique (3). Nous devrions peut-être inclure une clause de mise à niveau dans la GPL version 4, si jamais nous avons besoin d'une version 4.

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 permission 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 (4) ? 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.

Notes

1. 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.

2. 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.

3. 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.

4. 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.

HAUT DE LA PAGE


[logo de la FSF]« Notre mission est de préserver, protéger et promouvoir la liberté d'utiliser, étudier, copier, modifier et redistribuer les programmes informatiques, et de défendre les droits des utilisateurs de logiciel libre. »

La Fondation pour le logiciel libre (FSF) est le principal sponsor institutionnel du système d'exploitation GNU. Soutenez GNU et la FSF en achetant des manuels et autres, en adhérant à la FSF en tant que membre associé, ou en faisant un don, soit directement à la FSF, soit via Flattr.