Par souci de clarté, ne dites pas « sous licence GNU GPL 2 » !

par Richard Stallman

Lorsque j'ai écrit la licence publique générale GNU (GNU GPL) en 1989, je savais que des changements pourraient être nécessaires et que la FSF pourrait un jour avoir à publier une nouvelle version. J'ai donc nommé la licence « version 1 » et défini un cadre permettant à ses utilisateurs de mettre à jour leurs programmes vers les versions ultérieures de la licence.

Il n'existait pas de moyen établi de faire cela avec une licence libre ; autant que je sache, cela n'avait jamais été fait. Il était déjà arrivé que des développeurs publient une nouvelle version d'un programme sous une licence différente, ou peut-être qu'ils republient d'anciennes versions en permettant de les utiliser sous une licence différente, mais ils n'avaient jamais mis en place un moyen systématique d'offrir à leurs utilisateurs la possibilité de choisir une version future d'une licence pour des versions déjà publiées d'un programme.

Ne sachant pas comment les développeurs allaient accueillir cette innovation, j'ai décidé de donner à chacun d'eux le choix d'autoriser les versions futures. Cela signifiait que les développeurs pouvaient publier un programme sous GNU GPL 1 seulement [only] ou bien sous GPL version 1 ou toute version ultérieure [or any later version]. Les développeurs font part de leur choix dans l'avis de licence placé au début de chaque fichier source. C'est à cet endroit que la GPL demande de le faire.

La Free Software Foundation exhorta les développeurs à choisir ou toute version ultérieure, ce qui donnait aux utilisateurs la liberté de faire usage du logiciel sous la GNU GPL, soit dans sa version 1, soit dans sa version 2 (quand elle serait disponible), ou encore dans sa version 3 (dès qu'elle paraîtrait). Et ils seront libres de l'utiliser sous la version 4 de la licence si jamais nous sommes obligés de faire une version 4.

Depuis, la FSF a publié la version 2 de la GNU GPL (en 1991) ainsi que la version 3 (en 2007). Chacune donne le choix aux développeurs d'exiger la version en question ou de permettre l'utilisation de leur œuvre sous une version ultérieure (la GPL 3 permet également l'option « proxy » dans laquelle on spécifie une page web pouvant par la suite donner la permission d'utiliser une version ultérieure déterminée).

Publier un programme avec la permission d'actualiser sa licence est vital pour éviter des incompatibilités entre logiciels publiés sous différentes versions de la GPL.

Deux licences de type copyleft sont presque inévitablement incompatibles en l'absence d'un mécanisme de compatibilité explicite. Cela est dû au fait que chacune d'elles exige que les versions modifiées d'un programme soient publiées exactement sous la même licence. Par conséquent, du code mis à disposition sous GPL « version 2 seulement » ne peut pas être inclus dans du code publié sous GPL « version 3 seulement ».

Le mécanisme de compatibilité entre versions de la GPL consiste à publier un programme sous « version N ou toute version ultérieure ». Un programme publié sous GPL-2.0 ou ultérieure peut être inclus dans du code sous GPL-3.0 ou ultérieure car « 3 ou ultérieure » découle de « 2 ou ultérieure ».

Certains développeurs se disent « Je vais publier mon travail maintenant sous GNU GPL version 3 seulement. Lors de la sortie de la GPL version 4, si elle me convient, je modifierai la licence de mon programme afin d'en autoriser l'utilisation sous la version 4. » Cela fonctionnera bien si vous êtes l'unique auteur, à supposer qu'à ce moment-là vous soyez toujours vivant, en bonne santé, joignable et attentif à la sortie de la nouvelle version. Mais le copyright s'étend sur une période de temps absurde de nos jours ; en l'absence de réforme majeure, le copyright sur votre code prendra fin 70 ans après votre décès aux États-Unis (et 100 au Mexique). Avez-vous pris vos dispositions pour que vos héritiers examinent la question du passage de votre code à la GPL version 4 si vous n'êtes plus là pour le faire ?

Mais même de votre vivant il y aura des ennuis. Que se passera-t-il si nous publions la version 4 de la GNU GPL dans dix ans et qu'à ce moment-là cinquante autres personnes ont ajouté du code à votre programme et publié leurs ajouts sous « GPL-3.0 seulement » pour suivre votre exemple ? Vous pouvez approuver l'utilisation de la GPL 4 pour le programme que vous avez initialement publié, mais ce serait un travail énorme que de contacter les cinquante autres développeurs à ce moment-là pour obtenir leur permission d'utiliser le code qu'ils ont ajouté sous les termes de la GPL 4.

La solution pour éviter ces problèmes est d'approuver les futures versions de la GPL dans l'avis de licence, dès le début. Placez dans chaque fichier source non trivial un avis de licence conforme au modèle présenté à la fin de la version de la GPL que vous utilisez.

Du fait de notre façon de gérer la compatibilité entre licences, lorsque les gens vous disent qu'un programme est publié sous « GNU GPL version 2 », il reste une ambiguïté sur sa licence. S'agit-il de la GPL-2.0 seulement, ou bien de la GPL-2.0 ou ultérieure ? Pouvez-vous fusionner ce code avec des logiciels publiés sous GPL-3.0 ou ultérieure ?

Lorsque des sites tels que GitHub invitent les développeurs à choisir « GPL 3 » ou « GPL 2 » parmi d'autres licences sans jamais soulever la question des versions à venir, cela conduit des milliers de développeurs à laisser planer un doute sur la licence de leur code. Demander à leurs utilisateurs de choisir entre « seulement » ou « ultérieure » leur permettrait de lever cette ambiguïté. Ce serait également l'occasion d'expliquer en quoi ce dernier choix évite des incompatibilités futures.

Les indicateurs abrégés de licence tels que « GPL-2.0 » ou « GPL-3.0 » entraînent également une confusion. Les personnes ou organisations ne connaissant pas la différence entre « 2 seulement » et « 2 ou ultérieure » seront tentées d'écrire « GPL-2.0 » dans les deux cas sans réaliser qu'on doit faire la distinction.

Par conséquent, lorsque vous utilisez les indicateurs de licence SPDX, veuillez utiliser ceux-ci :

• GPL-2.0-only ou GPL-2.0-or-later
• GPL-3.0-only ou GPL-3.0-or-later
• LGPL-2.0-only ou LGPL-2.0-or-later
• LGPL-2.1-only ou LGPL-2.1-or-later
• LGPL-3.0-only ou LGPL-3.0-or-later
• AGPL-3.0-only ou AGPL-3.0-or-later
• GFDL-1.3-only ou GFDL-1.3-or-later

Et s'il vous plaît, ne faites pas usage des anciens indicateurs de licence, qui sont ambigus et vont devenir obsolètes :

• GPL-2.0
• GPL-3.0
• LGPL-2.0
• LGPL-2.1
• LGPL-3.0
• AGPL-3.0
• GFDL-1.3

Offrir aux développeurs le choix entre GPL version « 1 seulement» et GPL version « 1 ou ultérieure » paraissait nécessaire en 1989 mais cela a créé une complexité dont nous pourrions nous passer. Depuis, plusieurs licences offrant inconditionnellement aux utilisateurs la possibilité de choisir une version actualisée ont été largement adoptées. On peut citer la Mozilla Public License et l'Eclipse Public License. Chaque version déclare que l'utilisateur est libre d'utiliser l'œuvre sous une version ultérieure de la même licence le cas échéant. La licence Creative Commons à copyleft (CC BY-SA), quant à elle, permet aux utilisateurs d'actualiser la version de la licence quand ils modifient leur œuvre.

Peut-être devrions-nous adopter une telle approche pour les prochaines versions de la GNU GPL ; c'est une chose à garder en tête pour plus tard.

Nous sommes reconnaissants à SPDX de leur décision de modifier les identifiants courts des licences GNU afin de rendre plus explicite le choix entre « ou ultérieure » et « seulement ». La prochaine version de la liste d'identifiants reconnus par SPDX (SPDX License List) utilisera les recommandations ci-dessus. Les identifiants prêtant à confusion tels que « GPL-2.0 » deviendront obsolètes. Nous prions les personnes qui les utilisent encore de bien vouloir les remplacer dès que possible par les nouveaux identifiants, plus explicites.

En employant des indicateurs de licence explicites du type seulement et ou toute version ultérieure, nous pouvons rendre la communauté attentive à la différence entre les deux et encourager les développeurs à faire clairement état de leur choix.