English [en]   français [fr]   日本語 [ja]   русский [ru]  

L'original de cette page est en anglais.

Comment choisir une licence pour votre propre travail

La maintenance de cette page est assurée par le Licensing and Compliance Lab (Labo des licences et de la conformité) de la Free Software Foundation. Vous pouvez soutenir nos efforts en faisant un don à la FSF. Vous avez une question qui ne trouve pas de réponse ici ? Consultez nos autres ressources sur les licences ou contactez le Compliance Lab à licensing@fsf.org.

Introduction

Des gens nous demandent souvent de leur recommander une licence 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.

Ces recommandations s'appliquent aux œuvres utilitaires, ce qui comprend le logiciel, la documentation et quelques autres choses. Les œuvres d'art et celles qui expriment un point de vue sont un autre sujet ; le projet GNU n'a pas de position particulière sur la manière dont elles doivent être publiées, à part qu'on doit pouvoir les utiliser sans logiciel non libre (en particulier, sans DRM). Toutefois, on peut parfaitement appliquer ces recommandations aux œuvres associées à un programme particulier.

Les recommandations ci-dessous s'appliquent au choix d'une licence pour une œuvre que vous avez créée – que ce soit la modification d'une œuvre existante, ou une œuvre originale. Elles 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.

Une fois que vous aurez vu ce que nous recommandons ici, si vous souhaitez être conseillé vous pouvez écrire à <licensing@gnu.org>. Notez que l'équipe des licences mettra probablement plusieurs semaines à vous répondre ; si vous n'avez rien reçu au bout d'un mois, envoyez un nouveau message.

Contribuer à un projet existant

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 la version originale, 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.

Logiciel

Nous recommandons différentes licences pour différents projets, grosso modo 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 en matière de 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 cette longueur, 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 adapté, nous recommandons la licence Apache 2.0. C'est une licence de logiciel très laxiste (sans copyleft) 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 en revanche cela empêche les détenteurs de brevets de mettre en place un « leurre » qui consiste à diffuser le logiciel sous des clauses libres, puis à exiger des destinataires qu'ils acceptent des 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 bien très laxiste, alors nous recommandons d'utiliser la licence publique générale GNU amoindrie (LGPL). Contrairement au cas précédent où le projet implémentait un standard, ici l'adoption du code ne servira, en soi, aucun but particulier ; aussi 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 licence publique générale GNU Affero (AGPL). 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 visant à garantir 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 licence publique générale GNU (GPL) pour votre projet. Son copyleft fort convient à toutes sortes de logiciels et comporte de nombreuses protections garantissant la liberté des utilisateurs.

Documentation

Pour les manuels, les textes de référence et autres gros ouvrages de documentation, nous recommandons la licence GNU de documentation libre (FDL). C'est une licence à copyleft fort pour les ouvrages éducatifs, écrite à l'origine pour les manuels des 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.

Pour les textes courts de documentation, de moindre importance (les cartes aide-mémoire par exemple), il vaut mieux utiliser la GNU all-permissive license (licence GNU complètement permissive) puisqu'une copie de la GNU FDL aurait du mal à tenir sur une carte aide-mémoire. N'utilisez pas la CC-BY parce qu'elle est incompatible avec elle.

Pour les pages de manuels, nous recommandons la GNU FDL si la page est longue et la GNU all-permissive license si elle est courte.

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 adaptée au logiciel. Cela 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é.

Autres données des programmes

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. Vous pouvez aussi suivre ces recommandations pour les œuvres artistiques, mais si vous ne le faites pas nous ne vous critiquerons pas.

Si vous créez ces œuvres dans le cadre d'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 d'éventuels problèmes 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 destinée à un projet logiciel déterminé, ou si la licence du projet ne convient pas, alors nous vous recommandons de choisir une licence à copyleft adaptée à votre œuvre. Nous en répertorions quelques-unes dans notre liste des licences. Si aucune ne semble particulièrement bien adaptée, vous pouvez utiliser la Creative Commons paternité, partage dans les mêmes conditions (CC BY-SA), une licence à copyleft qui convient à toutes sortes d'œuvres.


Note de traduction
  1. Autre traduction de proprietary : propriétaire. 

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

Haut de la page