La licence comme donnée du SBOM
Le CRA n’impose pas la conformité aux licences. Mais le SBOM qu’il rend obligatoire est exactement l’outil qui permet de la démontrer — c’est le meilleur argument de financement du projet côté Juridique, et son bénéfice le plus immédiat.
Cette page traite de la licence en tant que donnée : comment elle s’exprime dans un SBOM et ce qu’on peut en calculer. Le fond du droit est ailleurs :
- ce que chaque famille impose → Les familles de licences ;
- quand une obligation se déclenche → Ce qui déclenche une obligation ;
- le verdict par type de produit → Neuf scénarios ;
- votre politique et votre processus → Propriété intellectuelle.
Les identifiants SPDX
La liste de licences SPDX est le référentiel mondial des identifiants de licence :
MIT, Apache-2.0, BSD-3-Clause, MPL-2.0, LGPL-2.1-only, GPL-3.0-or-later,
AGPL-3.0-only, et plusieurs centaines d’autres. CycloneDX comme SPDX l’utilisent.
Un identifiant normalisé est ce qui rend une licence calculable : sans lui, « GPL v3 ou supérieure », « GPLv3+ » et « GNU General Public License version 3 » sont trois chaînes distinctes qu’aucune politique automatique ne peut confronter à une liste.
Les expressions de licence
Elles couvrent les cas composés, et chacune a une conséquence juridique différente :
| Expression | Sens |
|---|---|
MIT |
Licence unique |
MIT OR Apache-2.0 |
Au choix du destinataire : vous sélectionnez celle qui vous convient, et vous le documentez |
GPL-2.0-only AND MIT |
Cumulatif : les deux jeux d’obligations s’appliquent |
GPL-2.0-only WITH Classpath-exception-2.0 |
Licence assortie d’une exception normalisée qui en limite la portée — à ne jamais ignorer, elle change le verdict |
LicenseRef-… |
Licence hors liste SPDX, dont le texte doit être joint au document |
NOASSERTION |
Indéterminée — un défaut bloquant, pas une licence |
Le suffixe -only ou -or-later n’est pas cosmétique : il détermine si vous pouvez appliquer
une version ultérieure de la licence, et donc la compatibilité avec le reste de l’arbre.
GPL-2.0-only et GPL-2.0-or-later n’ont pas les mêmes conséquences.
Déclarée contre constatée
Le format SPDX distingue deux champs que CycloneDX ne sépare pas aussi nettement :
| Champ | Signification |
|---|---|
PackageLicenseDeclared |
Ce que le projet affirme — le champ du manifeste, le fichier LICENSE |
PackageLicenseConcluded |
Ce que l’analyse établit, après examen du contenu des fichiers |
L’écart entre les deux est la donnée intéressante. Un dépôt déclaré MIT dont l’analyse
conclut MIT AND GPL-2.0-only a un sous-dossier que personne n’avait regardé — c’est
exactement le piège des
licences multiples dans un même dépôt.
Documenter la licence constatée n’est pas une coquetterie : c’est ce qui démontre, en cas de litige, que vous avez vérifié plutôt que cru sur parole.
Ce que le SBOM permet de calculer
Une fois les licences correctement renseignées, quatre opérations deviennent automatiques :
| Opération | Sortie |
|---|---|
| Confrontation à la politique par contexte d’usage | Blocage ou avertissement en CI |
| Génération du fichier d’attributions | NOTICE livré avec le produit |
| Inventaire par licence du portefeuille | Rapport pour un audit ou une diligence |
| Différentiel entre deux versions | Détection d’un changement de licence en amont |
Le dernier point est sous-estimé : comparer le champ de licence d’une version à l’autre est la seule façon de repérer à temps qu’un composant d’infrastructure a changé de licence — voir Les pièges.
La qualité de donnée, condition de tout le reste
Un SBOM dont une part significative des composants porte NOASSERTION ne permet aucune
analyse. Les causes habituelles :
| Cause | Remède |
|---|---|
| Le générateur ne lit que les manifestes | Ajouter un outil d’analyse de contenu, à cadence réduite |
| Le manifeste ne déclare pas de licence | Remonter à la source, et traiter l’absence comme bloquante |
| Licence exprimée en texte libre non normalisé | Normalisation vers un identifiant SPDX |
| Composant vendorisé, absent du manifeste | Analyse par empreinte de fichier |
Le seuil de NOASSERTION toléré doit figurer dans la
politique de qualité SBOM, au même titre que la couverture
des identifiants — et être bloquant en construction.
Référentiels utiles
ISO/IEC 5230 (OpenChain, conformité des licences) et ISO/IEC 18974 (OpenChain, assurance sécurité du logiciel libre) décrivent des systèmes de management reconnus, utiles pour structurer le dispositif et pour répondre aux exigences de clients grands comptes.