Définir d'abord l'objectif
Le choix d'une licence n'est pas une question de goût mais de ce que vous voulez. La plupart des projets se situent quelque part entre ces deux objectifs.
- Être utilisé le plus largement possible — si vous voulez que le code entre sans contrainte dans des produits d'entreprise, d'autres projets open source ou des applications fermées, une licence permissive est avantageuse.
- Que les améliorations reviennent publiquement — si vous voulez que les modifications de ceux qui redistribuent votre code soient elles aussi publiées, le copyleft convient.
Permissive : large adoption, peu de frictions
La MIT, la BSD, l'ISC et l'Apache-2.0 n'exigent guère plus que la conservation des mentions. La plupart des services juridiques d'entreprise les inscrivent sur leur liste pré-approuvée, ce qui accélère l'adoption. En revanche, vous ne pouvez pas empêcher quelqu'un de modifier le code et de l'intégrer dans un produit fermé.
Parmi les licences permissives, le choix porte surtout sur deux points.
- Brevets : Apache-2.0 si vous avez besoin d'une licence de brevets explicite et d'une clause de rétorsion, sinon MIT.
- Compatibilité avec la GPL-2.0 : la FSF considérant que l'Apache-2.0 ne peut pas entrer dans un projet GPL-2.0-only, MIT et BSD sont plus pratiques dans l'écosystème du noyau Linux.
Copyleft : la publication en chaîne
La GPL impose la publication pour tout le programme combiné, la LGPL pour la bibliothèque, la MPL fichier par fichier. Pour les logiciels qui tournent sur des serveurs, l'AGPL comble le vide de la GPL. Avec un copyleft, certaines entreprises peuvent hésiter à utiliser le code ou à y contribuer. De nombreuses entreprises restreignent notamment l'usage de l'AGPL par leur politique interne. C'est peut-être l'effet recherché, ou un effet secondaire indésirable.
Les usages de l'écosystème comptent aussi
Une licence engendre moins de frictions lorsqu'elle correspond aux usages de la communauté.
| Écosystème | Licences courantes | Remarque |
|---|---|---|
| JavaScript (npm) | MIT, ISC | Beaucoup de petits paquets, préférence pour les permissives courtes |
| Rust (crates.io) | MIT OR Apache-2.0 | Rust lui-même utilise cette double licence |
| Python (PyPI) | MIT, BSD-3-Clause, Apache-2.0 | BSD-3 fréquente en calcul scientifique |
| Go | BSD-3-Clause, MIT, Apache-2.0 | La bibliothèque standard de Go est en BSD-3 |
| Modules du noyau Linux | GPL-2.0-only | Pratiquement obligatoire pour se combiner au noyau |
| Outils GNU pour poste de travail | GPL-3.0-or-later | Valeur par défaut des projets GNU |
| Bibliothèques C/C++ | LGPL, MIT, BSL-1.0 | Le mode de liaison influence le choix |
Liste de contrôle pour décider
- Vérifier les dépendances : assurez-vous que les licences des bibliothèques déjà utilisées ne limitent pas vos options. Si vous distribuez un programme combiné avec une bibliothèque GPL, vos options se réduisent aux licences compatibles avec la GPL.
- Vérifier votre statut : le code écrit dans le cadre d'un emploi appartient généralement à l'entreprise. Vérifiez si la politique open source de votre entreprise impose une licence.
- Mode d'utilisation : l'effet du copyleft varie selon qu'il s'agit d'un logiciel installé, d'une bibliothèque ou d'un service.
- Mode de contribution : si vous comptez accepter des contributions externes, gardez à l'esprit qu'il sera difficile de changer de licence plus tard, car les droits d'auteur de plusieurs personnes se mêleront.
- Modèle de revenus : si vous comptez vendre une licence commerciale séparée, envisagez ensemble une double licence copyleft + commerciale et un accord de licence de contributeur (CLA).
En une phrase
- Être largement utilisé avant tout → MIT (Apache-2.0 si les brevets vous préoccupent)
- Récupérer les améliorations de la bibliothèque tout en laissant libres ceux qui l'utilisent → MPL-2.0 ou LGPL-3.0
- Que tous les programmes dérivés soient publiés → GPL-3.0
- Que même les versions modifiées de logiciels serveur soient publiées → AGPL-3.0
- Ne poser aucune condition → 0BSD, Unlicense, CC0
Dans l'assistant de choix, répondez à ces critères sous forme de questions pour obtenir des candidats et leurs raisons.
Cet article est fourni à titre d'information générale et ne constitue pas un conseil juridique. Pour toute décision importante, consultez un professionnel.
Sources
- choosealicense.com — https://choosealicense.com/
- FSF, Various Licenses and Comments about Them — https://www.gnu.org/licenses/license-list.html
- Licence de Rust (MIT OR Apache-2.0) — https://github.com/rust-lang/rust