Licences open source en due diligence : le risque discret dans la base de code

Toute base de code moderne repose sur des centaines de bibliothèques open source, chacune avec sa licence. La plupart (MIT, Apache, BSD) demandent peu de choses au-delà de la mention de l’auteur. Les licences copyleft, GPL en tête, demandent davantage : si vous distribuez un logiciel qui en dérive, vous devez en publier le code source sous la même licence. Un éditeur SaaS se croit souvent à l’abri, parce que faire tourner un logiciel sur ses serveurs n’est pas le distribuer ; l’AGPL a été écrite pour fermer cette porte et étend l’obligation aux utilisateurs servis à travers le réseau.

Le risque est discret parce que rien ne casse : le produit tourne, les clients paient, et personne n’a relu les licences depuis la création de l’entreprise.

Pourquoi le sujet remonte dans les acquisitions et chez les grands comptes

Deux moments font sortir les licences de l’ombre. Une acquisition d’abord : l’acquéreur veut savoir si une partie du produit pourrait devoir être publiée, et "nous utilisons de l’open source standard" ne satisfait pas ses avocats. L’entrée chez un grand compte ensuite : les questionnaires fournisseurs des banques, des assureurs et des industriels comportent presque toujours une rubrique sur les composants tiers, et une startup sans inventaire perd des semaines à le constituer.

Dans les deux cas, le sujet tombe entre deux chaises. Les juristes lisent les licences sans voir l’arbre de dépendances ; les ingénieurs connaissent l’arbre et lisent rarement les licences. Nous produisons l’inventaire que les deux pourront lire, dans le cadre du périmètre habituel de l’audit technique.

Comment nous inventorions les dépendances

Nous partons d’un SBOM, l’inventaire des composants logiciels, généré depuis les fichiers de dépendances et les images de conteneurs. Les outils ne manquent pas (Syft, ScanCode, les fonctions intégrées de GitHub ou de Snyk) et le premier passage prend une heure : il liste les bibliothèques directes et transitives avec leur licence déclarée.

Le résultat brut ne suffit pas : une partie des composants a une licence absente ou ambiguë, et les outils se trompent sur les cas limites. Nous lisons ces cas à la main, dans le dépôt de la bibliothèque et dans le code qui l’appelle, parce que la nature du lien décide de tout. Une bibliothèque GPL compilée dans le binaire livré au client pèse autrement qu’un outil GPL utilisé pendant le build et absent du produit.

Les cas qui comptent

Une dépendance AGPL dans un service exposé vient en premier. Une base de données ou un moteur de recherche sous AGPL, appelé par le backend d’un SaaS, peut déclencher l’obligation de publication pour le code qui en dérive, selon la façon dont il est intégré. Les juristes en débattent ; l’acquéreur veut une intégration au statut net, ou un plan pour qu’il le devienne.

Le deuxième cas est propre aux produits IA. Les modèles à poids ouverts ne sont pas tous libres d’usage commercial, et certains jeux de données publics sont réservés à la recherche, comme les variantes non commerciales des licences Creative Commons. Un produit dont la fonction centrale a été affinée sur un tel jeu de données porte un risque que notre checklist de due diligence IA place à côté des droits sur les données clients. Nous demandons la licence de chaque modèle et de chaque jeu d’entraînement ; "nous ne savons plus" est un constat en soi.

Le troisième cas est le code sans origine, celui que le SBOM ne voit pas : des fichiers copiés dans le dépôt sans gestionnaire de paquets, des extraits de Stack Overflow, publiés sous une licence à partage à l’identique, du code généré par un assistant IA, qui peut reproduire du code existant. Aucun des trois ne menace un deal à lui seul, tant que l’équipe sait dire ce qu’elle fait et avec quelles règles. Un code dont personne ne connaît la provenance rejoint les signaux que nous classons par sévérité.

Ce qui se corrige en deux semaines et ce qui bloque

La plupart des constats se corrigent vite. Une bibliothèque GPL utilitaire se remplace par un équivalent permissif en quelques jours ; une liste de licences acceptées, vérifiée en CI à chaque nouvelle dépendance, se met en place en une semaine.

Ce qui bloque est rare. Un composant copyleft au cœur du produit, dont le remplacement revient à réécrire le module. Un modèle sous licence restrictive dont le produit dépend entièrement. Un jeu d’entraînement dont les droits ne peuvent plus être établis. Dans ces cas, la remédiation se compte en mois et entre dans la négociation comme n’importe quelle dette.

Comment le point se traite dans la documentation juridique

L’inventaire alimente trois pièces. La déclaration du vendeur sur la propriété intellectuelle, qui gagne à lister les composants copyleft connus plutôt qu’à affirmer qu’il n’y en a pas. Les garanties spécifiques, quand un cas limite subsiste et que le juriste préfère un engagement à une opinion. Le plan post-closing, pour les remplacements qui ne justifient pas de retarder la signature. Le traitement ressemble à celui des écarts RGPD : un constat technique vérifié, que les avocats traduisent en clause datée.

Les licences occupent rarement plus d’une page de nos rapports, et cette page évite des conversations pénibles après la signature. Elle fait partie du périmètre de notre audit technique, avec le code, l’architecture, la sécurité et l’équipe.