Liste de contrôle de conformité des licences : que vérifier avant de partager une preuve

Une bonne page identifie le produit livré, liste les composants tiers avec leurs licences révisées, inclut le texte intégral des licences ou des liens fiables, et affiche l'attribution là où les licences l'exigent. Les achats et les auditeurs attendent plus qu'une liste de paquets npm.

Si votre page se contente de dire « nous utilisons de l'open source » sans inventaire, sans texte de licence ni périmètre clair, elle ne satisfera pas une demande de divulgation de licences tierces. Cela reste vrai même si l'ingénierie a passé une revue de sécurité interne.

Le besoin est généralisé : le rapport 2025 Open Source Security and Risk Analysis de Black Duck a constaté que 97 % des bases de code auditées contenaient de l'open source, si bien que presque tous les produits portent des obligations tierces, qu'elles soient documentées ou non.

• Nom et version du produit (ou canal de version) couverts par la page.
• Inventaire des composants tiers et open source, directs et transitifs là où votre processus l'exige.
• Identifiants de licence au format SPDX ou équivalent, après révision humaine, pas de simples suppositions issues du registre.
• Texte intégral de la licence pour chaque composant, ou liens stables qui mènent au texte intégral.
• Blocs d'attribution et de mention là où les licences MIT, Apache, BSD, GPL ou personnalisées les exigent.
• Un étiquetage clair si la page est un exemple, une bêta ou une version de production, le cas échéant.

La conformité des licences commence par l'inventaire : chaque composant de votre page de conformité doit correspondre au build actuellement livré, pas à une branche de développement, pas à un environnement de test, pas à une gamme de produits que vous ne vendez pas encore.

Les équipes oublient souvent les polices, les packs d'icônes, les SDK d'analytique, le JavaScript embarqué sur les sites vitrines, et les dépendances transitives entraînées par un seul import direct. La conformité échoue silencieusement quand l'inventaire est incomplet. Le rapport OSSRA 2025 de Black Duck indique que les dépendances transitives ont causé près de 30 % des conflits de licence détectés, si bien qu'une checklist qui s'arrête aux imports directs passe à côté d'une grande partie du risque.

• Chaque composant de la page correspond au build que reçoivent les clients aujourd'hui.
• Les dépendances transitives npm, pnpm, yarn, Go, Rust, Python, Java, .NET, PHP ou Ruby sont incluses selon votre politique.
• Les polices, icônes, images sous conditions de licence et SDK commerciaux ne sont pas oubliés.
• Les couches de base des conteneurs et les bibliothèques natives embarquées entrent dans le périmètre si vous les distribuez.
• Les éléments marqués inconnu ou en attente de révision sont résolus, ou explicitement exclus avec une raison documentée.
• La source de l'inventaire (lockfile, SBOM CycloneDX, saisie manuelle) est traçable jusqu'à la version.

Elle nécessite que les réviseurs puissent lire la licence réelle, pas un résumé : la divulgation de licences tierces implique le texte intégral par composant. Les achats et le juridique comparent votre page aux obligations des accords GPL, LGPL, Apache, MIT et des SDK propriétaires.

L'attribution est distincte de la mention, et distincte du texte intégral de la licence. Une page qui indique « MIT » sans le texte de la licence MIT ni la mention de copyright requise est incomplète pour la plupart des revues en environnement grand compte.

• Chaque composant a une licence identifiée, révisée par un humain, pas simplement recopiée des métadonnées du paquet.
• Le texte intégral de la licence est présent sur la page ou lié sans mur de connexion ni URL expirante.
• Les composants copyleft (GPL, AGPL, LGPL, etc.) ont franchi vos verrous de révision internes.
• Le texte d'attribution correspond à ce qu'exige chaque licence, pas un pied de page générique « licences open source ».
• Les composants sous double licence ou licence personnalisée ont une décision explicite enregistrée.
• Aucun composant n'est publié comme approuvé tant que le texte de licence n'est pas joint ou lié.

Une page de conformité des licences est un dossier vivant. L'URL que les achats ont enregistrée dans leur dossier fournisseur doit rester exacte après votre prochaine version. La conformité se rompt quand la page dérive de ce qui est livré.

Les verrous de publication (révision avant publication) empêchent les équipes de revendiquer une conformité qu'elles n'ont pas vérifiée. Les exports (JSON, fichiers d'attribution, lots de divulgation) doivent correspondre au même inventaire révisé que l'URL publique.

• Un responsable nommé a approuvé la publication pour ce produit et cette version.
• L'URL de la page de conformité est stable, publique, et accessible sans authentification.
• Les exports et les lots de version correspondent à l'inventaire publié.
• Les contrôles de dérive ou de pipeline signalent les nouveaux paquets avant le prochain audit client.
• Vous disposez d'un processus documenté pour mettre à jour la page de licences quand les dépendances changent.
• Vous ne laissez pas entendre une validation juridique, sauf si un juriste a effectivement révisé. La page est un dossier opérationnel.

Ouvrez la page de conformité des licences dans une fenêtre de navigation privée. Vérifiez qu'elle se charge, identifiez le produit, et contrôlez au hasard cinq composants par rapport à votre inventaire interne. Si les achats demandent une preuve, c'est exactement ce qu'ils feront.

Une fois la checklist validée, envoyez le format demandé (URL, export ou pièce jointe) à partir du même instantané de publication révisé. Nommez le produit et la version ou la date qu'il reflète. Le type de fichier compte moins que le fait que l'inventaire ait été révisé et approuvé avant l'envoi.

Non. Une checklist SBOM confirme l'identité des composants dans un format lisible par machine. Une checklist de conformité des licences confirme des licences révisées, le texte complet, l'attribution, et un état de publication que vous êtes prêt à partager. Vous avez souvent besoin des deux, dans cet ordre.

Relancez-la avant tout partage externe, et à nouveau lorsque les dépendances changent sur une branche de release surveillée. La dérive entre la dernière publication approuvée et le lockfile actuel est le mode de défaillance habituel.

Désignez un propriétaire responsable par produit, en général l'engineering avec une revue juridique sur les licences à haut risque. Une propriété partagée sans gate de publication est la façon dont des URL obsolètes finissent dans les dossiers fournisseurs.