Des gens nous demandent souvent quelle licence nous leur recommandons d'utiliser pour leur projet. Nous avons déjà publié des écrits à ce sujet, mais l'information se retrouve dispersée entre différents essais, entrées de FAQ et commentaires de licences. Cet article rassemble cette information en une source unique pour en faciliter le suivi et la référence.
Les recommandations ci-dessous sont ciblées sur la mise sous licence d'une œuvre que vous avez créée – que ce soit la modification d'une œuvre existante, ou une œuvre originale. Ces recommandations ne s'intéressent pas au problème que pose la combinaison d'œuvres publiées sous des licences différentes. Si vous cherchez de l'aide pour cela, veuillez vous reporter à notre FAQ sur les licences.
Quand vous contribuez à un projet existant, vous devriez généralement publier vos versions modifiées sous la même licence que l'œuvre originale. Il est bon de coopérer avec les mainteneurs du projet, et utiliser une licence différente pour vos modifications rend souvent cette coopération très difficile. Vous ne devriez le faire que s'il y a pour cela une excellente raison.
Utiliser une licence différente peut se justifier dans le cas où vous faites des changements majeurs à une œuvre placée sous une licence sans copyleft. Si la version que vous avez créée est bien plus utile que l'original, alors cela vaut la peine de copylefter votre œuvre, pour les mêmes raisons qui nous font normalement recommander le copyleft. Si vous êtes dans cette situation, veuillez suivre les recommandations pour un nouveau projet, ci-dessous.
Si pour une raison quelconque vous choisissez de publier vos contributions sous une licence différente, vous devez vous assurer que la licence originale permet d'utiliser le matériel sous la licence que vous avez choisie. Pour minimiser l'impact sur les autres contributeurs, montrez explicitement quelle licence s'applique à chaque partie de l'œuvre.
Nous recommandons différentes licences pour différents projets, essentiellement selon la destination du logiciel. En général, nous recommandons d'utiliser la licence qui a le plus fort copyleft n'interférant pas avec cette destination. Notre essai « Qu'est-ce que le copyleft ? » explique en détail le concept de copyleft, et pourquoi c'est généralement la meilleure stratégie de mise sous licence.
Il n'y a que deux sortes de projets qui à notre avis ne devraient pas du tout avoir de copyleft. Les premiers sont les petits projets. Nous prenons 300 lignes comme critère : quand le code source d'un paquet logiciel ne dépasse pas cela, les avantages du copyleft sont d'habitude trop réduits pour justifier l'ennui d'avoir à s'assurer qu'une copie de la licence accompagne toujours le logiciel.
Les seconds sont des projets mettant en œuvre des standards libres qui font concurrence à des standards privateurs,1 par exemple Ogg Vorbis (qui fait concurrence à MP3 pour l'audio) et WebM (qui fait concurrence à MPEG-4 pour la vidéo). Pour ces projets, une large utilisation du code est vitale pour faire avancer la cause du logiciel libre, et apporte plus que de mettre un copyleft sur le code du projet.
Dans ces situations particulières où le copyleft n'est pas approprié, nous recommandons la licence Apache 2.0. C'est une licence de logiciel permissive, non protectrice, qui a des clauses empêchant les contributeurs et les distributeurs de faire des recours en violation de brevet. Cela n'immunise pas le logiciel contre la menace des brevets, mais cela empêche effectivement les détenteurs de brevets de mettre en place un « leurre » qui consiste à diffuser le logiciel sous des clauses libres tout en exigeant des destinataires qu'ils consentent à des royalties ou autres clauses non libres, au moyen d'une licence de brevet.
Dans tous les autres cas, nous recommandons un copyleft, quel qu'il soit. Si votre projet est une bibliothèque, et que les développeurs utilisent déjà une bibliothèque alternative publiée sous une licence non libre ou permissive, alors nous recommandons d'utiliser la GNU Lesser General Public License (LGPL), ou GPL amoindrie. Contrairement au cas précédent où le projet implémentait un standard, ici l'adoption ne servira, en soi, aucun but particulier ; aussi il n'y a-t-il aucune raison d'éviter complètement le copyleft. Pourtant, si vous demandez aux développeurs qui utilisent votre bibliothèque de publier leur travail sous un copyleft complet, ils vont simplement utiliser les alternatives disponibles et cela ne fera pas non plus avancer notre cause. La GPL amoindrie a été conçue pour combler le hiatus entre ces deux cas, en permettant aux développeurs de logiciel privateur d'utiliser la bibliothèque qu'elle couvre, mais en fournissant un copyleft faible qui bénéficie aux utilisateurs quand ils le font. Si vous voulez en savoir plus sur notre analyse de ces cas, lisez « Pourquoi vous ne devriez pas utiliser la LGPL pour votre prochaine bibliothèque ».
Si votre programme, après que d'autres l'aient amélioré, a une chance d'être exécuté sur un serveur et d'interagir avec ses utilisateurs sur un réseau, et si vous avez peur que de ce fait moins de développeurs contribuent aux versions diffusées, nous recommandons la GNU Affero General Public License (AGPL) ou GPL Affero. Les termes de l'AGPL sont presque identiques à ceux de la GPL ; la seule différence importante est qu'elle a une clause supplémentaire conçue pour s'assurer que les personnes utilisant le logiciel sur un réseau seront en mesure d'obtenir son code source. Cette clause ne traite pas tous les problèmes qui surviennent quand les utilisateurs font leurs tâches informatiques sur un serveur – elle n'empêchera pas les utilisateurs d'être lésés par le logiciel en tant que service – mais elle fait tout ce que peut faire une licence. Pour en apprendre plus sur ces questions, lisez « Pourquoi la GPL Affero ? ».
Dans tous les autres cas, nous vous recommandons d'utiliser la version la plus récente de la GNU General Public License (GPL) pour votre projet. Son copyleft fort convient à toutes sortes de logiciels et protège la liberté des utilisateurs de nombreuses façons.
Pour la documentation, nous recommandons la GNU Free Documentation License (FDL) ou licence de documentation libre. C'est une licence à copyleft fort pour les ouvrages éducatifs, écrite à l'origine pour les manuels de logiciels ; elle contient des clauses qui répondent spécifiquement aux problèmes courants qui surviennent quand ces ouvrages sont distribués ou modifiés.
Certaines documentations contiennent du code source de logiciel. Par exemple, le manuel d'un langage de programmation peut contenir des exemples pour que les lecteurs comprennent. Vous devriez à la fois les inclure dans le manuel sous les termes de la FDL, et les diffuser sous une autre licence appropriée au logiciel. Faire ceci facilite le réemploi du code dans d'autres projets. Nous vous recommandons de placer les petits morceaux de code dans le domaine public en utilisant la CC0, et de distribuer les morceaux plus gros sous la même licence que le projet logiciel associé.
Cette section se rapporte à toutes les autres œuvres d'utilité pratique que vous pouvez inclure dans le logiciel. Pour vous donner quelques exemples, cela comprend les icônes et autres graphismes fonctionnels ou utiles, les polices et les données géographiques. Ces recommandations ne s'appliquent pas aux œuvres artistiques (par opposition aux œuvres fonctionnelles ou éducatives), ni à l'expression d'opinions ou de jugements.
Si vous créez ces œuvres spécifiquement pour vous en servir dans un projet logiciel, nous vous recommandons généralement de les publier sous la même licence que le logiciel. Cela ne pose pas de problème avec les licences que nous avons recommandées : la GPLv3, la LGPLv3, l'AGPLv3, and la GPLv2 peuvent toutes s'appliquer à n'importe quel type d'œuvre – pas uniquement logicielle – qui puisse être placée sous copyright et qui ait clairement une forme privilégiée pour les modifications. Utiliser la même licence que pour le logiciel rendra plus facile le respect de la licence par les distributeurs, et éliminera tout doute concernant les problèmes potentiels de compatibilité. Utiliser une licence libre différente peut se justifier si cela offre un avantage pratique spécifique, comme une meilleure coopération avec d'autres projets libres.
Si votre œuvre n'est pas créée en vue de son utilisation avec un projet logiciel particulier, ou si la licence du projet ne convient pas, alors nous vous recommandons de choisir une licence à copyleft appropriée à votre œuvre. Nous en répertorions quelques-unes dans notre liste des licences. Si aucune ne semble particulièrement appropriée, vous pouvez utiliser la Creative Commons Attribution-ShareAlike, qui est une licence à copyleft adaptée à toute une variété d'œuvres.