Les pièges qui échappent à la matrice

La matrice famille × scénario traite le cas normal : un composant identifié, sous une licence connue, dans un produit défini. Les incidents réels viennent presque toujours d’ailleurs.

1. Le changement de licence en amont

Le risque le plus actif de la période. Plusieurs projets d’infrastructure majeurs ont quitté une licence libre pour une licence source-available au cours des dernières années — bases de données, moteurs de recherche, outils d’infrastructure, supervision, systèmes de tickets.

Le mécanisme : les versions déjà publiées restent sous l’ancienne licence, définitivement. Mais les versions suivantes ne le sont plus — et vos correctifs de sécurité viennent des versions suivantes.

L’organisation se retrouve alors devant trois options, toutes coûteuses :

Option	Coût
Rester sur la dernière version libre	Plus de correctifs de sécurité en amont : dette réglementaire directe au regard du CRA
Basculer sur un fork communautaire	Maturité incertaine, écosystème fragmenté
Accepter la nouvelle licence	Négociation commerciale, restrictions d’usage, coût récurrent

Ce qu’il faut mettre en place :

épingler les versions et les licences dans le SBOM, et comparer d’une version à l’autre — un changement de champ license est un événement à traiter, pas une donnée parmi d’autres ;
surveiller les dix à vingt composants d’infrastructure critiques, ceux dont le remplacement prendrait des mois ;
inscrire ce risque au registre des risques de conformité, avec un porteur nommé.

2. L’absence de licence

Un dépôt public sans fichier de licence n’est pas libre. En l’absence de concession expresse, le droit d’auteur s’applique dans sa plénitude : tous droits réservés. La visibilité du code ne concède rien, et les conditions générales d’une forge ne concèdent au mieux qu’un droit de consultation et de duplication interne à la plateforme.

En SPDX, cela s’écrit NOASSERTION. Dans une politique de licences, cela doit être bloquant — au même titre qu’une licence interdite, et non traité comme une métadonnée manquante.

Variante fréquente et plus insidieuse : le dépôt annonce une licence dans son fichier README mais ne contient aucun texte de licence, ou en contient un autre.

3. Les licences multiples dans un même dépôt

Le dépôt se déclare MIT. Un sous-dossier vendor/, third_party/ ou contrib/ contient du code sous une autre licence, parfois du copyleft.

Aucun gestionnaire de paquets ne le voit : ils lisent le champ de licence déclaré dans le manifeste, pas le contenu des fichiers.

La seule parade est l’analyse du contenu des fichiers, par empreinte, avec les outils dédiés — voir Générateurs. C’est lent, verbeux, et c’est la différence entre une conformité déclarative et une conformité établie.

4. Le code copié

Depuis un forum ou un site de questions-réponses. Les contributions des principales plateformes sont sous licence de partage à l’identique. Un extrait substantiel copié dans du code propriétaire pose, en théorie, une question de contamination. La pratique universelle est de l’ignorer pour quelques lignes triviales, et la doctrine considère qu’en deçà d’un seuil d’originalité il n’y a pas d’œuvre protégeable. Le risque devient réel pour une fonction entière recopiée.

Depuis un autre projet. Le copier-coller d’une fonction depuis un projet sous copyleft crée une œuvre dérivée, sans qu’aucun gestionnaire de dépendances n’en garde trace.

Le code vendorisé. Copier un composant dans votre arborescence plutôt que le déclarer en dépendance casse la traçabilité : il n’apparaît ni au manifeste, ni au SBOM produit depuis le manifeste. Il n’apparaît qu’à l’analyse de contenu.

5. Le code généré par intelligence artificielle

Sujet ouvert, qu’il faut traiter comme tel plutôt que trancher.

Les faits établis : les assistants de génération de code sont entraînés sur du code public, sous licences variées, dont du copyleft. Il est démontré qu’ils peuvent restituer des extraits substantiels quasi identiques à leur source, en particulier pour du code peu commun.

Les questions ouvertes : le statut juridique de la sortie, la titularité des droits, la qualification d’œuvre dérivée, et la responsabilité en cas de reproduction. Aucune réponse jurisprudentielle stabilisée à ce jour en Europe.

Ce qui est raisonnable en attendant :

activer les filtres de correspondance proposés par les outils, qui bloquent la restitution d’extraits identiques à du code public connu ;
relire le code généré pour les fonctions non triviales, comme on relit une contribution ;
ne pas générer de code dans les zones où une contamination serait irrattrapable — cœur cryptographique, composant destiné à être publié sous licence permissive ;
documenter la position retenue, pour ne pas avoir à l’improviser lors d’une diligence d’acquisition, où la question est désormais posée.

6. Les assets, ignorés par tous les outils

Aucun scanner de dépendances ne regarde les polices, les icônes, les images, les sons, les modèles 3D ou les jeux de données. Ils sont pourtant à l’origine de problèmes très concrets, parce que leurs licences sont souvent plus restrictives que celles du code.

Asset	Piège
Polices	`OFL-1.1` : clause de nom réservé, le sous-ensemblage est une modification. Polices commerciales : licences par domaine ou par nombre de pages vues
Icônes	`CC-BY-NC` interdit dans un produit vendu ; `CC-BY` impose une attribution rarement faite
Images	Banques d’images : licence par usage, souvent non transférable au client
Sons	Mêmes règles, plus les droits voisins
Jeux de données	`ODbL` : copyleft sur les bases dérivées. Décisif pour un produit d’apprentissage automatique
Modèles pré-entraînés	Licences propres, parfois avec restrictions d’usage — famille dite « responsable »

Ce qu’il faut faire : tenir un inventaire des assets distinct du SBOM logiciel, avec la source, la licence, la preuve d’acquisition et le périmètre d’usage concédé. Personne ne le fait spontanément ; c’est pourtant le premier endroit où un audit trouve quelque chose.

7. Les incompatibilités mutuelles

Deux licences peuvent être libres toutes les deux et impossibles à combiner. Les combinaisons à connaître :

Combinaison	Statut
`Apache-2.0` + `GPL-2.0-only`	Incompatible selon la position de la FSF
`Apache-2.0` + `GPL-3.0`	Compatible
`CDDL-1.0` + `GPL-2.0`	Incompatible — c’est l’origine du problème ZFS sous Linux
`GPL-2.0-only` + `GPL-3.0-only`	Incompatible entre elles
`GPL-2.0-or-later` + `GPL-3.0`	Compatible, par bascule en v3
`BSD-4-Clause` + `GPL`	Incompatible — clause de publicité
`EPL-1.0` + `GPL`	Incompatible ; l’EPL-2.0 le résout par une clause optionnelle
Deux copylefts forts différents	Généralement incompatibles entre eux

Une incompatibilité ne se contourne pas : elle rend la distribution de l’œuvre combinée impossible. Elle se détecte tôt, ou elle se paie en réécriture.

8. Les clauses de brevets et leur effet en retour

Apache-2.0, GPL-3.0, MPL-2.0 et EPL-2.0 comportent une concession de brevets assortie d’une résiliation : engager une action en contrefaçon de brevet contre un contributeur au sujet de ce logiciel fait perdre la concession, et parfois la licence entière.

Pour une entreprise détentrice d’un portefeuille de brevets, c’est un sujet de direction juridique et non d’équipe technique : une stratégie contentieuse peut être neutralisée par le choix d’une bibliothèque fait trois ans plus tôt par un développeur.

9. Le CLA absent

Sans accord de licence de contributeur ni certificat d’origine, chaque contributeur externe conserve ses droits. Conséquences pour un projet que vous publiez :

relicenciement impossible sans le consentement de chacun ;
double licence commerciale impossible ;
action en contrefaçon difficile contre un tiers qui violerait votre licence, faute de détenir tous les droits.

À trancher avant la première contribution externe. Voir Bibliothèque / SDK.

10. Les fausses licences libres

Des textes qui ressemblent à des licences libres sans en être :

Texte	Problème
Commons Clause	Un avenant greffé sur une licence libre, qui en retire le droit de vendre. « MIT + Commons Clause » n’est pas MIT
JSON License	Contient la clause « le logiciel sera utilisé pour le Bien, pas pour le Mal » : ambiguë, non libre en pratique, plusieurs fondations l’interdisent
Licences « maison »	Rédigées par l’auteur, non revues, à l’interprétation imprévisible. À traiter comme du propriétaire
Licences « éthiques »	Restrictions d’usage selon la finalité. Sortent de la définition du libre et posent un problème d’appréciation permanent

Ce que ces dix pièges ont en commun

Aucun n’est détecté par un scanner de dépendances lisant les manifestes. Tous exigent soit une analyse du contenu des fichiers, soit une surveillance dans le temps, soit une décision de gouvernance.

C’est la raison pour laquelle la conformité aux licences ne se réduit pas à un outil : elle suppose une politique, un registre, une veille et un propriétaire nommé — voir Propriété intellectuelle.