Pourquoi proposer plusieurs licences pour un même code
Le titulaire des droits peut autoriser le même code selon plusieurs conditions à la fois. Le destinataire en choisit une et en respecte les conditions. Ce choix répond principalement à deux objectifs.
- Élargir la compatibilité — pour s'accorder avec plusieurs écosystèmes différents.
- Modèle économique — pour publier en open source tout en vendant une licence commerciale séparée.
Type 1 : deux licences permissives ensemble — MIT OR Apache-2.0
C'est la méthode utilisée par le langage Rust et la plupart des crates Rust. L'utilisateur choisit la MIT ou l'Apache-2.0, selon ce qui l'arrange.
- En choisissant l'Apache-2.0, il obtient une licence de brevets explicite.
- En choisissant la MIT, il peut aussi intégrer le code dans des projets GPL-2.0-only (la FSF considérant l'Apache-2.0 comme incompatible avec la GPL-2.0).
On bénéficie ainsi des deux avantages, ce qui explique sa popularité auprès des auteurs de bibliothèques. Par convention, le dépôt contient deux fichiers : LICENSE-MIT et LICENSE-APACHE.
Type 2 : copyleft + commercial — « la GPL, ou payer »
Le code est publié sous GPL ou AGPL, et une licence commerciale est vendue par contrat séparé aux entreprises qui ne veulent pas assumer l'obligation de publier le source. MySQL (GPL + licence commerciale Oracle) et Qt (LGPL-3.0/GPL + commerciale) en sont des exemples typiques.
Ce modèle ne fonctionne que si le titulaire détient les droits sur l'ensemble du code. En effet, il n'a pas le droit de vendre sous licence commerciale du code apporté par des contributeurs externes uniquement sous GPL.
CLA et DCO
- CLA (Contributor License Agreement) : contrat par lequel le contributeur accorde à l'entité qui gère le projet des droits étendus (y compris de changer la licence) sur sa contribution, ou lui cède ses droits d'auteur. Elle est de fait nécessaire pour une double licence commerciale. Il existe aussi des formes, comme l'ICLA de la fondation Apache, qui accordent seulement le droit de relicencier en laissant le droit d'auteur au contributeur.
- DCO (Developer Certificate of Origin) : le contributeur confirme à chaque commit qu'il a « le droit de soumettre ce code sous la licence de ce projet » (
git commit -sajoute une ligneSigned-off-by:). Le noyau Linux l'utilise. Le DCO n'accordant pas de droit de relicencier, il ne suffit pas pour une double licence commerciale.
Comment l'écrire en expression SPDX
La relation entre plusieurs licences s'écrit avec une expression de licence SPDX.
| Expression | Sens | Exemple |
|---|---|---|
A OR B | On en choisit une (double licence au choix) | MIT OR Apache-2.0 |
A AND B | Les deux doivent être respectées (parties différentes mélangées) | MIT AND BSD-3-Clause |
A WITH exception | Ajoute une exception à une licence | GPL-2.0-only WITH Linux-syscall-note |
| Parenthèses | Définissent l'ordre de combinaison | (MIT OR Apache-2.0) AND Unicode-3.0 |
Confondre OR et AND inverse complètement le sens. Si l'utilisateur peut choisir, c'est OR ; s'il doit tout respecter, c'est AND.
Points d'attention
- Les droits déjà accordés demeurent : même si vous ne gardez ensuite que la licence commerciale, l'autorisation accordée pour les versions déjà distribuées en open source reste généralement valable.
- Ce n'est pas de l'« open core » : le modèle où le cœur est open source et les fonctions supplémentaires sont vendues sous licence commerciale fermée n'est pas une double licence. La double licence consiste à proposer deux licences pour le même code.
- Ne pas confondre avec les licences à source disponible : de plus en plus de projets passent à des licences comme la BUSL ou la SSPL, dont le source est visible mais qui ne sont pas open source selon l'OSI. C'est une stratégie différente de la double licence.
- Des fichiers de mention exacts : pour une licence au choix, fournissez le texte intégral de chaque licence et indiquez clairement dans le README que l'on peut « choisir l'une ou l'autre ».
Exemple d'application
Pour appliquer une double licence à la Rust, téléchargez depuis le générateur les fichiers MIT et Apache-2.0, enregistrez-les sous LICENSE-MIT et LICENSE-APACHE, et indiquez license = "MIT OR Apache-2.0" dans les métadonnées. Dans l'en-tête de chaque fichier, écrivez SPDX-License-Identifier: MIT OR Apache-2.0.
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
- SPDX Specification, License Expressions — https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
- Rust API Guidelines, Licensing — https://rust-lang.github.io/api-guidelines/necessities.html
- Developer Certificate of Origin — https://developercertificate.org/
- Apache ICLA — https://www.apache.org/licenses/contributor-agreements.html