Audit des licences open source pour dépôts hérités : un plan pratique

Pourquoi les dépôts hérités créent un risque de licence

Quand un dépôt change de mains, vous héritez de plus que du code. Vous héritez de chaque choix de licence, de chaque dépendance et de chaque avis manquant que l'équipe précédente a omis. Si le projet a commencé comme un prototype rapide (ou a été généré par un outil d'IA), la licence est souvent considérée comme "pour plus tard" jusqu'à ce que quelqu'un extérieur pose les bonnes questions.

Les modes de défaillance sont généralement simples, mais coûteux :

• Une dépendance est sous une licence que le client n'acceptera pas.
• Les textes de licence requis ou les avis de droit d'auteur ne sont pas inclus dans ce que vous livrez.
• Le build intègre des paquets transitoires que personne n'a examinés.
• Un extrait copié, une police, une icône ou un actif a des conditions qui ne correspondent pas à votre usage prévu.

Les clients et partenaires demandent des preuves parce qu'ils se protègent. S'ils embarquent votre logiciel, intègrent votre SDK ou revendent votre produit, ils peuvent devenir responsables de la conformité aussi. Les équipes d'achats d'entreprise demandent souvent un Software Bill of Materials (SBOM), un fichier de third-party notices et une déclaration claire de la manière dont vous respectez les obligations de licence. Si vous ne pouvez pas produire ces éléments, les accords ralentissent, les revues deviennent plus strictes et les équipes juridiques peuvent bloquer le déploiement.

Une idée reçue courante est de considérer la propriété du repo comme des droits de licence. Posséder l'organisation GitHub (ou recevoir le code d'un contractant) n'accorde pas automatiquement la permission d'utiliser, modifier ou distribuer tout ce qu'il contient. Les licences open source sont des permissions avec des conditions. Vous voulez savoir quelles conditions s'appliquent avant de livrer, surtout si vous distribuez des binaires, vendez un SaaS payant ou donnez une copie à des partenaires.

L'objectif pratique d'un audit est simple : trouver ce qui est réellement inclus, repérer les lacunes tôt et produire des artefacts de conformité clairs. Cela ne remplace pas un avis juridique et ne résoudra pas tous les cas limites, mais ça peut faire remonter des problèmes tant qu'ils restent peu coûteux à corriger.

Notions rapides sur les licences (sans le jargon juridique)

Une licence est le règlement sur la façon dont vous pouvez utiliser le code d'un autre. Quand vous héritez d'un dépôt, vous héritez aussi de ses règles et de sa paperasse. Une première passe utile consiste à séparer les « licences à faible friction » des « licences à partage », puis à confirmer que vous avez rempli les obligations de base.

Licences permissives (comme MIT et Apache-2.0) permettent en général l'utilisation dans presque n'importe quel produit, y compris commercial. Le compromis est administratif : conservez les avis de droit d'auteur, incluez le texte de la licence lorsqu'il est requis et ne prétendez pas être l'auteur de l'œuvre originale.

Licences copyleft (comme GPL) permettent aussi l'utilisation, mais peuvent exiger que si vous distribuez un produit qui inclut le code, vous partagiez également le code source de l'œuvre combinée sous les mêmes termes. AGPL est similaire, mais peut étendre le déclencheur du partage du code aux services offerts sur un réseau, ce que les équipes SaaS évitent souvent.

En pratique, “les obligations de licence” signifie souvent du travail peu glamour :

• Inclure les textes de licence et avis de droit d'auteur requis avec votre distribution
• Fournir l'attribution dans un fichier THIRD-PARTY-NOTICES (ou équivalent)
• Suivre les modifications quand la licence l'attend
• Pour le copyleft, être prêt à partager le source quand c'est requis
• Éviter d'utiliser des marques ou des noms d'une manière interdite par la licence

Les doubles licences surprennent souvent les équipes car le même projet peut être offert sous deux jeux de règles différents. Une librairie peut être « GPL pour les projets open source » et « licence commerciale pour les produits propriétaires », ou contenir des fichiers sous différentes licences. Si quelqu'un a copié du code depuis la mauvaise source, vous pouvez vous retrouver avec des termes plus contraignants que prévu.

Vous n'avez pas besoin de mémoriser chaque détail de licence. Vous devez savoir quelles licences sont faciles à respecter, lesquelles changent vos obligations de distribution et lesquelles peuvent bloquer un accord quand l'équipe conformité du client les repère.

Où les licences se cachent dans un dépôt moderne

La plupart des problèmes de licence dans le code hérité ne se trouvent pas dans la dépendance dont vous vous souvenez. Ils apparaissent dans des endroits que l'on n'examine pas tant qu'un client ne demande pas de preuves.

Commencez par les dépendances directes (paquets listés dans des fichiers comme package.json, requirements.txt, go.mod, Gemfile). La grosse surprise est les dépendances transitives : des paquets que vos paquets tirent. Une dépendance directe peut apporter des dizaines de licences transitives, et celles-ci peuvent changer après une petite mise à jour de version.

Les repos frontend ajoutent un autre endroit où se cacher : les assets bundlés. Les outils de build regroupent souvent le code dans un fichier minifié, et ce processus peut supprimer les en-têtes ou avis qui auraient normalement accompagné le code source. Les extraits copiés fonctionnent de la même façon. Une fonction d'aide collée depuis un article de blog, un gist ou une réponse Stack Overflow peut toujours comporter des exigences de licence.

Vérifiez aussi ce qui est livré autour de votre application, pas seulement votre application. Les conteneurs et images de base peuvent inclure des paquets OS (et leurs licences) qui se retrouvent en production. Si vous avez hérité d'un Dockerfile, vous avez aussi hérité de son bagage de licences.

Endroits courants où les licences se cachent :

• Manifestes de dépendances et lockfiles (directs et transitifs)
• Dossiers vendor, bibliothèques copiées et répertoires “utils”
• Bundles frontend construits et polices/icônes embarquées
• Images de base de conteneurs et paquets OS installés
• “Code mystère” ajouté vite fait, y compris du code généré par IA qui peut refléter des sources sous licence

Signaux d'alerte repérables en 10 minutes

Vous n'avez pas besoin d'un audit complet pour repérer des problèmes probables. Une passe rapide peut indiquer si un dépôt risque d'échouer à une revue client ou partenaire.

Regardez d'abord les manifestes de dépendances et les lockfiles. Des centaines de dépendances sans lockfile (ou plusieurs lockfiles incohérents) signalent que vous ne pourrez pas prouver ce qui a été livré. Surveillez les registres privés ou les dépendances basées sur Git tirées directement de dépôts. Elles manquent souvent de métadonnées de licence claires.

Ensuite, vérifiez la présence d'artefacts de build committés dans le repo. Des dossiers comme dist, build, vendor, third_party ou des bundles minifiés copiés sont des sources courantes d'avis manquants. Si du code est copié plutôt qu'installé via un gestionnaire de paquets, vous n'aurez peut-être aucun moyen automatique de rassembler les textes de licence.

Si le repo est un monorepo (par exemple packages/* ou libs/*), ouvrez quelques packages internes. L'absence de fichiers LICENSE ou des notes de propriété floues peuvent devenir un cauchemar quand les packages sont publiés séparément.

Enfin, vérifiez ce qui est effectivement livré. S'il n'y a pas de fichier de third-party notices (souvent THIRD_PARTY_NOTICES ou NOTICE) dans les releases, installateurs ou images conteneur, c'est un écart de conformité courant.

Une triangulation rapide :

• Lockfiles manquants ou incohérents avec le build
• Dépendances Git-based ou licence “inconnue”
• Code fournisseur ou bundles tiers committés
• Aucun fichier de notices dans le processus de release

Si plus d'un de ces signes apparaît, prévoyez une revue approfondie avant que quelqu'un d'autre ne la découvre.

Étape par étape : mener un audit de licences open source

Les audits de licences se passent mieux quand vous les traitez comme un inventaire d'abord, de la paperasse ensuite. Commencez par identifier ce que vous livrez réellement, car les obligations dépendent souvent de la distribution.

1) Construire un inventaire propre de ce qui est livré

Listez chaque livrable qui sort de votre contrôle : un bundle web, une application mobile, un installateur desktop, une image conteneur, un package on‑prem, même un ZIP envoyé à un partenaire.

Puis collectez les fichiers qui définissent votre graphe de dépendances. Les versions comptent.

• Manifestes de build comme package.json, pyproject.toml, requirements.txt, Gemfile, go.mod
• Lockfiles comme package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, Gemfile.lock, go.sum, Cargo.lock, composer.lock
• Fichiers conteneur et déploiement (Dockerfiles, Helm charts, pipelines de build)
• Dossiers vendor ou code copié (vendor/, third_party/, parfois libs/)
• Métadonnées d'app store ou écrans “À propos” (endroits communs pour afficher des notices)

2) Scanner, confirmer et enregistrer les obligations

Un flux de travail pratique que la plupart des équipes peuvent suivre :

1. Générez une liste de dépendances (directes et transitives) à partir des lockfiles et de la sortie de build.
2. Identifiez la licence pour chaque version de dépendance. Signalez tout ce qui est “inconnu” ou “personnalisé”.
3. Vérifiez les données de licence à travers différentes sources (métadonnées du registre, LICENSE du repo, en-têtes de fichier).
4. Enregistrez les obligations que vous devez satisfaire (attribution, inclusion du texte de licence, emplacement des notices, déclencheurs de partage du source).
5. Décidez de ce qui est acceptable selon votre mode de livraison (SaaS uniquement vs distribution de binaires ou packages on‑prem).

Une application desktop a généralement besoin des third-party notices incluses dans l'installateur. La distribution SaaS peut être différente, mais clients et partenaires attendent tout de même des dossiers propres.

Les dépôts hérités ont souvent des lockfiles manquants et du code copié. Si vous ne pouvez pas reproduire l'ensemble des dépendances, corrigez cela d'abord. Sinon chaque décision de licence sera fragile.

Erreurs courantes qui déclenchent des problèmes de conformité

La plupart des problèmes de conformité ne sont pas dus à une mauvaise intention. Ils surviennent parce que des équipes héritent d'un dépôt, livrent vite et ne vérifient jamais ce qui se trouve à l'intérieur.

Problèmes récurrents :

• Les métadonnées ne correspondent pas à la réalité. Un README affirme “MIT”, mais les métadonnées du package sont erronées ou manquent d'un identifiant SPDX.
• Extraits copiés sans attribution. “Juste une fonction utilitaire” peut quand même imposer des conditions.
• Copyleft fort au mauvais endroit. Des dépendances GPL/AGPL peuvent créer des obligations incompatibles avec votre modèle commercial.
• Les actifs non-code sont ignorés. Polices, icônes, images et UI kits ont souvent des licences séparées.
• On s'est fié à des rumeurs. Un article de blog ou un commentaire n'est pas une licence. C'est le texte de la licence et les métadonnées du paquet qui comptent.

Même si votre dépendance directe est permissive, une dépendance transitive ajoutée discrètement peut ne pas l'être. Ne vérifier que les paquets de premier niveau manque les problèmes que les clients tendent à trouver.

Un scénario courant : vous héritez d'un prototype, voyez un seul fichier LICENSE et supposez que tout le dépôt est couvert. Plus tard, un client entreprise demande des third-party notices et vous découvrez des assets bundlés avec leurs propres termes et aucune attribution.

Comment corriger les constats : notices, remplacements et documentation

Après un audit, l'objectif n'est pas la perfection. C'est la clarté : ce que vous utilisez, ce que vous devez livrer avec, et ce que vous ne devez pas faire.

Commencez par créer (ou mettre à jour) un fichier THIRD-PARTY-NOTICES. Restez ennuyeux et complet. Pour chaque dépendance, indiquez le nom, la version, la licence et où elle apparaît (web app, serveur, mobile, image conteneur). C'est souvent la première chose que recherchent les partenaires.

Ensuite, ajoutez les textes de licence requis. Si une licence exige que le texte ou l'avis de droit d'auteur soit inclus à la distribution, rassemblez ces textes dans un dossier licenses/ et référez-vous à eux depuis THIRD-PARTY-NOTICES.

Si vous trouvez une licence à haut risque pour votre modèle (par exemple un copyleft fort dans une librairie liée à un produit propriétaire), vous avez en général trois voies : la remplacer, l'isoler derrière une frontière de service, ou obtenir une licence commerciale. Le bon choix dépend de l'utilisation du composant, pas seulement du libellé de la licence.

Pour rendre cela répétable, ajoutez un court COMPLIANCE.md qui explique comment vous générez l'inventaire et où se trouve la paperasse. Restez pratique : quels lockfiles sont dans le périmètre, ce que vous excluez (outils dev-only, frameworks de test) et pourquoi, et quelles commandes reproduisent le scan.

Enfin, définissez une règle d'entrée légère pour les nouvelles dépendances : ne pas merger un nouveau package tant que sa licence n'est pas connue (avec un identifiant SPDX réel si possible) et que les mises à jour des notices sont gérées si nécessaire.

Ce que les partenaires souhaitent généralement voir dans un paquet de conformité

La plupart des partenaires ne demandent pas un essai juridique. Ils veulent la preuve que vous savez quel logiciel tiers est dans votre produit, quelles règles s'appliquent et qui le tient à jour.

Un bon paquet commence par un résumé court : quelles familles de licences apparaissent dans ce que vous livrez (permissives comme MIT/Apache, copyleft faible comme LGPL, copyleft fort comme GPL/AGPL), plus le périmètre du scan et la date.

Puis viennent les preuves : un inventaire de dépendances que quelqu'un d'autre peut vérifier, avec noms, versions exactes, licences détectées et où chaque élément a été trouvé (lockfile, répertoire vendor, couche conteneur, sortie de build).

Vous aurez presque toujours besoin des textes et attributions réels, pas seulement des étiquettes.

Minimum pratique à inclure

• Un court résumé des licences pour le produit livré
• Une liste de dépendances avec noms, versions et licences
• Des third-party notices (attributions requises et textes de licence complets si demandés)
• Notes sur les exceptions (licences commerciales, approbations écrites)
• Un propriétaire nommé et un rythme de revue simple

Un détail qui réduit les allers-retours : signalez d'emblée les zones grises. Exemples : “Le package X n'avait pas de fichier de licence, nous l'avons remplacé”, ou “Un outil GPL de dev a été retiré de l'image de production et est exclu du SBOM.”

Scénario d'exemple : prototype hérité, revue par un client entreprise

Une startup achète un prototype fonctionnel à un contractant et le met rapidement en production. Les démos fonctionnent, l'équipe se concentre donc sur les fonctionnalités et les ventes. Trois mois plus tard, un client entreprise lance une revue sécurité et achats et demande une question simple : “Pouvez-vous fournir la liste de tous les logiciels tiers et leurs licences ?”

L'équipe lance un audit et trouve une dépendance copyleft (GPL/AGPL) dans le flux de travail central. Elle a fait gagner du temps au départ, mais les termes ne correspondent pas à la façon dont la startup prévoit de vendre et distribuer le produit.

Ils mettent le deal en pause et font trois choses en parallèle : confirmer la dépendance/version exacte et où elle est utilisée, la remplacer par une alternative permissive et refactorer l'intégration, et nettoyer la paperasse pour que le client voie une histoire complète et cohérente.

Ce qu'ils renvoient est court et précis :

• Une liste de dépendances avec noms, versions et licences
• Un fichier de third-party notices correspondant à ce qui est livré
• Une note documentant la dépendance retirée et son remplacement
• Un enregistrement de la date du scan et des paramètres de l'outil

Après la conclusion du deal, ils ajoutent une vérification de licence en CI, exigent la mise à jour des notices avant les releases et maintiennent une liste de “licences autorisées” qui correspond à leur modèle économique.

Checklist rapide et prochaines étapes

Traitez le travail sur les licences comme une exigence de release, pas comme une panique ponctuelle. Avant des conversations clients sérieuses, vous devriez pouvoir répondre : « Que livrons‑nous exactement, et sous quelles licences ? »

Une base pré-release :

• Inventaire complet de ce que vous livrez (y compris dépendances transitives et assets bundlés)
• Versions épinglées et licences connues (aucun “inconnu”, “personnalisé” ou “voir README” non résolu)
• Notices prêtes à être livrées (third-party notices, avis de droit d'auteur requis, textes de licence requis)
• Builds reproductibles (lockfiles committés et réellement utilisés)
• Un propriétaire clair pour les mises à jour continues

Si vous avez une release dans les 1 à 2 semaines, priorisez d'abord les notices et les builds reproductibles. C'est ce que les partenaires peuvent vérifier rapidement. Si vous avez plus de temps, ajoutez une règle d'entrée de dépendance pour que les questions de licence ne soient pas redécouvertes lors des processus d'achats.

Si le dépôt est hérité ou généré par IA, attendez‑vous à des lacunes : lockfiles manquants, paquets inutilisés, code copié sans en‑têtes et artefacts de build qui bundlent des fichiers tiers. Quand la base de code est déjà instable, il est souvent plus rapide de réparer le build et l'inventaire d'abord, puis faire la paperasse.

Obtenir de l'aide quand le dépôt est en désordre ou généré par IA

Quand un dépôt est hérité et à moitié fonctionnel, le travail de licence peut sembler conjectural. C'est plus difficile quand le code a été produit rapidement par des outils IA, parce que des dépendances peuvent avoir été ajoutées sans revue, des extraits peuvent manquer d'en‑têtes et des artefacts livrés peuvent inclure des fichiers tiers dont personne ne se souvient.

Il aide de scinder le travail en deux axes :

• Décisions juridiques : interprétation des obligations (par exemple, si votre distribution déclenche des termes copyleft, ou comment traiter des releases passées qui ont omis des notices).
• Nettoyage d'ingénierie : inventaire, automatisation et correction du dépôt pour que vous puissiez répéter le processus à chaque release.

Un schéma pratique consiste à ce que les ingénieurs produisent les faits (liste de dépendances, licences, notices) et que le conseil juridique révise les cas limites et approuve la formulation.

Si vous avez besoin d'aide opérationnelle pour transformer un prototype hérité et cassé en quelque chose que vous pouvez livrer et défendre lors de revues, FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation des bases de code générées par IA ou héritées, y compris le refactoring, le durcissement sécurité et la préparation au déploiement. Un build propre et stable est souvent le chemin le plus rapide vers un inventaire de dépendances digne de confiance et un paquet de notices que les partenaires accepteront.

Avant de demander de l'aide, rassemblez quelques éléments de base pour que le travail reste précis : accès au repo (ou export sanitizé), vos étapes actuelles de build et de release, un artifact livré d'exemple (image/zip/installateur/bundle) et tout questionnaire client déjà reçu.