Comprendre SPDX pour documenter clairement les licences de ses dépendances logicielles

SPDX permet de documenter les licences des dépendances logicielles avec des identifiants courts et normalisés, comme MIT ou Apache-2.0. Les SPDX licences dépendances facilitent un inventaire homogène des composants tiers, mais un identifiant ne remplace ni le texte de licence, ni les avis de copyright, ni l’analyse des obligations de redistribution.

SPDX est une norme ouverte qui décrit les composants logiciels, leurs licences, leurs copyrights et certaines relations de dépendance dans un format exploitable par les équipes techniques et les outils de conformité. Le point utile est simple : réduire les libellés imprécis tels que « licence Apache » ou « GPL » et conserver une information vérifiable, maintenable et lisible par une machine.

SPDX en quelques mots : à quoi sert cette norme ?

SPDX, pour Software Package Data Exchange, est une norme ouverte destinée à décrire les composants d’un logiciel et les informations qui leur sont associées. La SPDX License List regroupe des licences et exceptions courantes sous des identifiants stables, ce qui évite de comparer des intitulés libres, incomplets ou contradictoires d’un dépôt à l’autre.

SPDX ne délivre pas une conformité automatique : la norme rend l’information de licence plus structurée, donc plus vérifiable. Une équipe peut utiliser cette structure dans des fichiers source, un manifeste de dépendances, une SBOM ou un registre interne de composants.

Un identifiant SPDX réduit l’ambiguïté sur le nom d’une licence ; il ne supprime pas les obligations attachées au composant concerné.

Pourquoi les licences de dépendances doivent être documentées

Une dépendance est un composant externe requis par un projet pour compiler, tester, exécuter ou enrichir une application. Une dépendance directe apparaît souvent dans un fichier comme package.json, pom.xml, requirements.txt ou go.mod. Une dépendance transitive est installée parce qu’une dépendance directe en a elle-même besoin.

La conformité des dépendances devient difficile lorsque le projet contient des dizaines ou des centaines de composants tiers. Un inventaire des composants logiciels permet de relier chaque paquet à une version, une source, une licence de dépendance, un avis de copyright éventuel et les actions attendues lors de la distribution.

• Identifier les composants embarqués dans un livrable, un conteneur ou une bibliothèque distribuée.
• Retrouver rapidement le texte de licence et les avis nécessaires lors d’un audit de licences.
• Éviter qu’un même composant soit décrit comme « Apache », « Apache v2 » et Apache-2.0 dans trois outils différents.
• Préparer une SBOM sans reconstruire l’inventaire à la main à chaque version.

Comment lire et utiliser un identifiant SPDX ?

Un identifiant SPDX est une référence courte, officielle et non ambiguë à une licence ou à une exception inscrite dans la SPDX License List. Pour documenter une dépendance, l’équipe doit vérifier la licence déclarée par son éditeur, rechercher son identifiant exact dans la liste officielle et conserver la source de cette attribution.

La règle pratique consiste à copier l’identifiant tel qu’il apparaît dans la liste SPDX, y compris les traits d’union et les suffixes comme -only ou -or-later. Une approximation visuelle paraît anodine, mais elle casse la détection automatique et peut masquer une différence de périmètre entre deux licences.

Identifier correctement une licence

La documentation officielle de SPDX distingue les licences, les exceptions et les identifiants dépréciés. Les identifiants dépréciés ne doivent pas être introduits dans une nouvelle documentation lorsque l’expression recommandée existe ; la liste officielle indique les remplacements éventuels.

Le bon réflexe consiste à partir du fichier de licence ou de la notice fournie par le composant, puis à rechercher l’identifiant correspondant dans la liste officielle. Le nom affiché par un registre de paquets reste un signal utile, mais il peut être absent, imprécis ou erroné.

Information trouvée	Notation SPDX adaptée	Ce que l’équipe doit vérifier
Licence MIT clairement déclarée	MIT	Le texte de licence et les avis de copyright fournis.
Apache License, Version 2.0	Apache-2.0	Les notices, le fichier NOTICE éventuel et le périmètre de distribution.
GNU GPL version 3 uniquement	GPL-3.0-only	L’absence de formulation autorisant les versions ultérieures.
Texte de licence spécifique à un fournisseur	LicenseRef-Interne	Le texte complet, son origine et une validation adaptée au contexte.

Une annotation simple dans un fichier source

Une ligne SPDX peut être placée dans l’en-tête d’un fichier lorsqu’elle décrit la licence applicable à ce fichier. La syntaxe ci-dessous est documentée par SPDX ; l’emplacement exact du commentaire dépend toutefois du langage et des conventions du dépôt.

// SPDX-License-Identifier: MIT

Un fichier source sous licence MIT n’autorise pas à conclure que toutes les dépendances du projet utilisent MIT. Les annotations de fichiers servent à décrire des unités de code ; l’inventaire des dépendances doit être tenu dans un manifeste, une SBOM ou un registre de conformité distinct.

Comment documenter les licences de ses dépendances étape par étape ?

La documentation des licences de dépendances commence par un inventaire reproductible, puis associe chaque composant à une version, une source et une expression SPDX vérifiée. Une démarche courte mais traçable vaut mieux qu’un tableur rempli une fois et oublié dès la prochaine mise à jour de paquet.

Les outils d’analyse peuvent accélérer la collecte, mais une équipe doit prévoir une revue des résultats ambigus. Les paquets sans licence détectable, les métadonnées contradictoires et les licences personnalisées nécessitent une investigation manuelle et parfois un avis juridique spécialisé.

1. Recenser les dépendances directes et transitives. Exportez le graphe de dépendances depuis le gestionnaire de paquets ou l’outil de build, puis figez la version analysée.
2. Conserver la provenance de chaque composant. Notez le registre, le dépôt source, l’archive ou l’image de conteneur dont provient le composant.
3. Relever la déclaration de licence. Vérifiez les métadonnées du paquet, le fichier LICENSE, les en-têtes de code et les notices incluses.
4. Associer l’identifiant SPDX exact. Utilisez la SPDX License List officielle plutôt qu’une liste recopiée ou un libellé approché.
5. Documenter les obligations identifiées. Conservez les textes, avis, exceptions et décisions internes qui seront nécessaires lors de la redistribution.
6. Rejouer le contrôle à chaque livraison. Une nouvelle version de dépendance peut modifier la licence, la notice ou la chaîne transitive.

Un scan de licence est un point de départ. La documentation exploitable commence lorsque le résultat est relié à une version, une preuve et une décision de traitement.

Exemple de registre de dépendances pour un projet fictif

Le tableau suivant illustre un projet fictif nommé « Portail-API ». Les composants, versions et décisions sont donnés comme exemple de structure ; ils ne décrivent pas un inventaire réel et ne valent pas avis juridique.

Composant fictif	Version suivie	Expression SPDX	Preuve conservée	Action de suivi
Bibliothèque HTTP	4.2.0	MIT	Fichier LICENSE de l’archive	Inclure la notice si le livrable est redistribué.
Moteur de rapports	2.8.1	Apache-2.0	Texte de licence et fichier NOTICE	Vérifier les avis à reproduire.
Plugin externe	1.0.3	LicenseRef-Editeur	Contrat et texte transmis par l’éditeur	Faire valider les conditions spécifiques.

Comment comprendre les expressions de licence SPDX ?

Une expression de licence SPDX décrit la licence applicable lorsqu’un composant propose plusieurs options, combine plusieurs éléments ou utilise une exception connue. Les opérateurs AND, OR et WITH doivent être lus comme des informations de licence, pas comme des raccourcis permettant de choisir librement une obligation plus favorable.

La documentation SPDX décrit aussi l’opérateur + dans certains contextes historiques et des formes actuelles plus explicites telles que -or-later. Pour une nouvelle documentation, l’équipe doit privilégier les identifiants et expressions recommandés par la version officielle consultée.

• MIT : une seule licence est déclarée pour le composant.
• MIT OR Apache-2.0 : le titulaire propose deux régimes ; le choix applicable doit être documenté selon le contexte de distribution.
• GPL-2.0-only WITH Classpath-exception-2.0 : une exception SPDX précise modifie certains effets de la licence de base.
• MIT AND Apache-2.0 : plusieurs licences s’appliquent conjointement à des éléments couverts par le composant ou sa distribution.

Les opérateurs SPDX décrivent une relation entre licences ; ils ne tranchent pas la compatibilité entre votre produit, vos modes de distribution et les obligations applicables. Une expression complexe mérite une lecture des textes concernés, surtout lorsque le logiciel est distribué à des clients ou intégré à un produit commercial.

SPDX, CycloneDX et fichiers de licence : quelles différences ?

SPDX, CycloneDX et les fichiers de licence répondent à des besoins voisins mais non interchangeables. SPDX fournit un vocabulaire et des formats pour décrire les composants et leurs licences ; CycloneDX est également utilisé pour les SBOM ; le fichier LICENSE reste une preuve textuelle essentielle attachée à un composant.

Le choix dépend du flux de travail : une équipe peut produire une SBOM dans un format demandé par un client tout en normalisant les expressions de licence avec SPDX. La présence d’une SBOM ne dispense pas de conserver les textes requis ni de traiter les obligations de redistribution.

Élément	Usage principal	Limite à connaître
SPDX	Identifier les licences, exceptions et composants avec un vocabulaire normalisé.	Ne constitue pas une analyse juridique complète.
CycloneDX	Échanger des SBOM et des informations de composants dans des chaînes de sécurité.	Le format ne remplace pas la vérification de la donnée source.
Fichier LICENSE ou NOTICE	Conserver le texte et les avis liés à un composant.	Le texte seul est moins facile à agréger automatiquement.

Pour les équipes qui doivent choisir entre copyleft fort et obligations réseau, notre dossier sur les différences entre GPL et AGPL apporte un complément utile. La décision dépend du logiciel distribué, de l’accès réseau proposé et du texte exact de la licence retenue.

Les erreurs fréquentes avec SPDX licences dépendances

Les erreurs les plus coûteuses ne viennent pas toujours d’une licence complexe. Elles apparaissent souvent lorsqu’une équipe confond une donnée technique, une preuve documentaire et une décision de conformité. Un inventaire robuste doit rendre ces trois niveaux visibles.

• Confondre SPDX avec une licence. SPDX est une norme de description ; l’erreur masque le fait que les obligations viennent du texte de licence du composant.
• Oublier les dépendances transitives. Un manifeste incomplet peut laisser hors inventaire une bibliothèque effectivement embarquée dans le produit final.
• Faire confiance à un scan sans revue. Un outil peut détecter plusieurs fragments, mal interpréter un fichier ou manquer une licence personnalisée.
• Utiliser un identifiant approximatif ou déprécié. Une notation non officielle nuit à l’interopérabilité et complique les contrôles automatisés.
• Ne pas archiver les preuves. Sans archive de la version analysée, du texte et de la source, une décision est difficile à justifier plusieurs mois plus tard.

Formats, mises à jour et sources à consulter

La SPDX License List est publiée dans plusieurs formats, notamment JSON, JSON-LD, RDFa/HTML, RDF Turtle, RDF/XML, texte et modèles, selon le dépôt officiel spdx/license-list-data. Ces formats facilitent l’intégration dans un pipeline de build, un outil d’inventaire ou un contrôle de qualité interne.

Une automatisation utile doit stocker la version de la liste SPDX utilisée lors de l’analyse, car les identifiants et les statuts peuvent évoluer. La version 3.28.0 est indiquée par SPDX pour le 20 février 2026 ; une équipe doit vérifier la version disponible au moment de son intégration plutôt que de figer cette référence sans contrôle.

Sources utiles à consulter

• SPDX License List : identifiants, textes, exceptions et statut des licences ; source de référence pour la notation.
• Documentation SPDX sur les informations de licence : syntaxe des identifiants et expressions ; utile avant d’écrire des annotations.
• Open Source Initiative : informations de référence sur les licences open source reconnues et leurs textes.
• Code.gouv.fr : repères français sur les licences libres reconnues pour les codes sources publics.

Questions fréquentes sur SPDX

SPDX est-il une licence ?

Non. SPDX est une norme ouverte de description des composants logiciels et de leurs informations de licence. Les identifiants SPDX renvoient à des licences, à des exceptions ou à des références de licence personnalisées.

Un identifiant SPDX remplace-t-il le texte de la licence ?

Non. Un identifiant facilite l’identification et l’automatisation, mais le texte de la licence, les avis de copyright et les fichiers NOTICE éventuels restent importants. Les obligations concrètes dépendent du composant, de la licence et du mode de distribution.

Que faire lorsqu’une dépendance ne contient aucune licence ?

Une absence de licence explicite ne doit pas être interprétée comme une autorisation d’usage ou de redistribution. L’équipe doit rechercher la source officielle, contacter l’éditeur si nécessaire et bloquer ou encadrer l’usage selon sa politique de conformité.

Peut-on créer un identifiant SPDX pour une licence interne ?

Une licence non présente dans la SPDX License List peut être référencée avec un identifiant de type LicenseRef-.... Cette référence locale doit être accompagnée du texte complet de la licence et d’une documentation claire sur son origine.

SPDX suffit-il pour produire une SBOM ?

SPDX peut servir de format de SBOM et porter des informations de licence structurées. Une SBOM fiable dépend néanmoins de la qualité de l’inventaire, de la couverture des dépendances transitives et de la mise à jour des données à chaque livraison.