Bibliothèque ou SDK que vous publiez
Inversion de perspective : vous ne êtes plus le consommateur mais le fournisseur. Deux contraintes se répondent.
Ce qui se passe réellement
| Question | Réponse |
|---|---|
| Un tiers reçoit-il le logiciel sous forme exécutable ? | Oui, et sous forme source le plus souvent |
| Votre licence contraint-elle vos utilisateurs ? | Oui — c’est le point central |
| Vos dépendances contraignent-elles votre licence ? | Oui |
La règle qui gouverne tout
On ne peut pas publier sous une licence plus permissive que la plus restrictive de ses dépendances.
Une bibliothèque qui embarque un composant GPL ne peut pas être publiée sous MIT. La licence que vous affichez doit être compatible en aval avec tout ce que vous incluez.
Corollaire : la composition de vos dépendances est une décision de produit, pas une décision technique. Ajouter une dépendance LGPL à un SDK permissif transfère une contrainte d’ingénierie à tous vos utilisateurs, souvent sans qu’ils s’en aperçoivent.
Le verdict pour vos dépendances
| Famille de la dépendance | Verdict | Effet sur votre publication |
|---|---|---|
| Permissive | ● | Aucun. Vous restez libres de votre licence |
| Copyleft faible fichier (MPL) | ◐ | Vos fichiers restent libres ; les fichiers MPL modifiés doivent être publiés |
| Copyleft faible bibliothèque (LGPL) | ○ | Vos utilisateurs héritent de la contrainte de remplacement, souvent à leur insu |
| Copyleft fort (GPL) | ○ | Votre bibliothèque devient GPL. Choix légitime, mais qui doit être délibéré |
| Copyleft réseau (AGPL) | ○ | Votre bibliothèque devient AGPL, ce qui la rend inutilisable par la plupart des intégrateurs |
| Source-available | ✕ | Vous ne pouvez pas redistribuer |
Le choix de votre propre licence
C’est une décision commerciale autant que juridique.
| Votre licence | Qui peut vous intégrer | Ce que vous en retirez |
|---|---|---|
| Apache-2.0 | Tout le monde | Adoption maximale, et protection brevets pour vous comme pour eux. Le choix par défaut d’un SDK destiné à être adopté |
| MIT | Tout le monde | Adoption maximale, aucune protection brevets |
| MPL-2.0 | Tout le monde, avec réciprocité par fichier | Les améliorations de votre code vous reviennent, sans bloquer l’intégration |
| LGPL | Tout le monde, avec contrainte de liaison | Réciprocité forte, mais exclut de fait l’embarqué et le mobile |
| GPL / AGPL | Uniquement les projets libres | Modèle de double licence : gratuit pour le libre, payant pour le propriétaire |
| BSL / source-available | Selon les restrictions | Protection contre la revente en service managé, au prix de la sortie du libre |
Le modèle de la double licence — GPL ou AGPL d’un côté, licence commerciale de l’autre — suppose de détenir l’intégralité des droits sur le code. Ce qui conduit au point suivant.
Le CLA, sujet à traiter avant la première contribution externe
Sans accord de licence de contributeur (CLA) ou, a minima, sans DCO, chaque contributeur conserve ses droits sur sa contribution. Conséquences :
- impossible de relicencier plus tard sans le consentement de chacun ;
- impossible de proposer une licence commerciale sur du code que vous ne détenez pas entièrement ;
- difficile de faire appliquer la licence en cas de violation par un tiers, faute de détenir tous les droits.
C’est une décision à prendre avant d’accepter la première contribution externe. La rattraper après suppose de retrouver chaque contributeur, ou de réécrire sa contribution.
Les pièges de ce scénario
La dépendance transitive invisible. Votre SDK est Apache-2.0, mais il tire une dépendance LGPL. Vos utilisateurs héritent de la contrainte de liaison sans que rien ne le leur signale. La parade : publier votre propre SBOM avec le SDK, et documenter explicitement les licences transitives à obligations.
Les licences imbriquées dans un dépôt. Un dépôt annoncé MIT dont un sous-dossier
vendor/ est GPL. Votre déclaration de licence devient inexacte.
Le code d’exemple. Les extraits que vous publiez dans la documentation sont réutilisés tels quels par vos utilisateurs. S’ils ne portent pas de licence explicite, leur statut est incertain — préciser qu’ils sont sous la même licence, ou sous une licence plus permissive.
Les fichiers générés. Un SDK généré depuis une spécification d’interface hérite parfois de
la licence du générateur. Vérifier ce que dit le générateur sur la sortie qu’il produit — les
exceptions du type Autoconf-exception existent précisément pour cela.
La marque. Aucune licence libre ne concède de droits sur la marque. Un utilisateur peut forker votre code, il ne peut pas l’appeler comme vous.
Ce que le CRA ajoute
Beaucoup, et c’est souvent ignoré : une bibliothèque mise sur le marché séparément est un produit comportant des éléments numériques à part entière (art. 3, point 1).
Elle a donc, pour elle-même : son dossier technique, son SBOM, sa période de support, sa politique de divulgation coordonnée, son marquage CE.
Sauf si elle est mise à disposition hors activité commerciale, auquel cas elle sort du champ — voir Le logiciel libre. La frontière est celle du caractère commercial, pas celle de la licence : publier un SDK sous Apache-2.0 en accompagnement d’une offre payante reste une activité commerciale.