Le logiciel open source est intégré dans pratiquement chaque produit d'entreprise, mais peu en connaissent les risques de licence. De l'effet copyleft de la GPL aux obligations SBOM du Cyber Resilience Act européen en passant par la due diligence M&A, nous expliquons les enjeux de la conformité OSS.
La dépendance invisible
Plus de 90 pour cent de tous les produits logiciels modernes contiennent des composants open source. Ce qui semble à première vue être une solution rentable et innovante comporte des risques juridiques considérables. En effet, le logiciel open source (OSS) n'est en aucun cas « libre » au sens de « sans conditions ». Chaque composant OSS est régi par une licence qui définit des obligations précises -- et dont la violation peut avoir des conséquences graves.
Pour les entreprises qui développent, intègrent ou distribuent des logiciels, la connaissance et le respect des licences open source ne sont pas une bonne pratique optionnelle, mais une nécessité juridique impérative. Les risques vont des actions en cessation aux demandes de dommages-intérêts, en passant par la perte de droits de propriété intellectuelle.
Le paysage des licences : du permissif au copyleft
Les licences open source se divisent fondamentalement en deux catégories, dont la distinction est déterminante pour l'évaluation des risques.
Licences permissives
Les licences comme la licence MIT ou la licence Apache 2.0 sont relativement simples. Elles autorisent l'utilisation, la modification et la redistribution libres du logiciel -- y compris dans des produits propriétaires. Les obligations essentielles se limitent au maintien de l'avis de copyright et du texte de la licence. La licence Apache 2.0 contient en outre une licence de brevet expresse qui protège l'utilisateur contre les revendications de brevets du concédant.
Licences copyleft : l'effet « viral »
Les licences copyleft sont nettement plus complexes, en premier lieu la GNU General Public License (GPL). La caractéristique centrale de la GPL est ce que l'on appelle l'effet copyleft : quiconque intègre du code sous licence GPL dans son propre programme et le distribue doit publier l'ensemble de l'œuvre résultante également sous GPL -- y compris le code source complet.
Cette obligation est fréquemment qualifiée d'« effet viral » car la licence se propage en quelque sorte à toutes les parties du code connectées. Pour les entreprises dont le modèle économique repose sur des logiciels propriétaires, cela peut être existentiellement menaçant : l'intégration involontaire d'un composant GPL peut contraindre à la divulgation de l'intégralité du code source propriétaire.
La LGPL (Lesser General Public License) atténue cet effet. Elle permet l'incorporation de bibliothèques LGPL dans des logiciels propriétaires, à condition que la bibliothèque soit liée dynamiquement et que l'utilisateur puisse la remplacer. Des pièges subsistent toutefois avec la liaison statique ou la modification de la bibliothèque elle-même.
Hellwig contre VMware : un signal d'alarme pour l'industrie
L'importance de la conformité GPL a été illustrée de manière saisissante par l'affaire Hellwig contre VMware. Christoph Hellwig, l'un des développeurs les plus prolifiques du noyau Linux, a poursuivi VMware en 2015 devant le tribunal régional de Hambourg pour violation de la GPLv2.
L'accusation portait sur le fait que VMware avait intégré du code du noyau Linux dans son hyperviseur ESXi sans divulguer le code source de l'ensemble de l'œuvre dérivée sous GPL. Bien que la plainte ait finalement été rejetée pour des raisons probatoires -- Hellwig n'avait pas pu démontrer suffisamment quelles lignes de code spécifiques provenaient de lui -- l'affaire a secoué l'industrie.
La question juridique centrale, non résolue à ce jour, concerne la notion d'œuvre dérivée au sens de la GPL : à partir de quand la combinaison de code propriétaire et de code sous licence GPL devient-elle une œuvre unitaire soumise dans son intégralité à la GPL ? Cette incertitude contraint les entreprises à une prudence particulière dans l'architecture de leurs logiciels.
Le Cyber Resilience Act européen et l'obligation SBOM
Avec le règlement (UE) 2024/2847 -- le Cyber Resilience Act (CRA), le législateur européen a créé une nouvelle dimension des obligations de transparence. Le CRA, entré en vigueur le 10 décembre 2024 et pleinement applicable à partir du 11 décembre 2027, oblige les fabricants de produits comportant des éléments numériques à créer et à maintenir un Software Bill of Materials (SBOM).
Qu'est-ce qu'un SBOM ?
Un SBOM est un inventaire lisible par machine de tous les composants logiciels d'un produit -- comparable à une liste d'ingrédients pour les produits alimentaires. Il documente toutes les bibliothèques, frameworks et modules utilisés, y compris leurs versions et licences.
La NTIA a défini dès 2021 des exigences minimales pour les SBOM, depuis mises à jour par la CISA dans une version révisée de 2025.
Exigences du CRA pour le SBOM
Le CRA exige que le SBOM :
- soit créé dans un format courant et lisible par machine
- liste au minimum les dépendances de premier niveau du produit
- soit conservé dans le cadre de la documentation technique
- soit mis à la disposition des autorités de surveillance du marché sur demande
Bien que le SBOM n'ait pas besoin d'être accessible au public, l'obligation de le créer et de le maintenir impose un recensement systématique de tous les composants OSS -- et donc de leurs licences.
Types de licences courants et leurs implications
Une compréhension claire des types de licences les plus fréquents est indispensable pour la pratique des affaires :
Licence MIT
- Obligations : conserver l'avis de copyright et le texte de la licence
- Risque : faible
- Pratique : utilisable sans problème dans les logiciels propriétaires
Licence Apache 2.0
- Obligations : conserver l'avis de copyright, le texte de la licence et le fichier NOTICE ; licence de brevet expresse
- Risque : faible à moyen
- Particularité : clause de rétorsion en matière de brevets
GPL v2 / v3
- Obligations : placer l'ensemble de l'œuvre dérivée sous GPL ; divulguer le code source
- Risque : élevé
- Pratique : utilisable uniquement dans des modules clairement séparés ou comme outil purement backend
LGPL
- Obligations : divulguer sous LGPL les modifications apportées à la bibliothèque elle-même ; liaison dynamique requise
- Risque : moyen
- Pratique : utilisable dans les logiciels propriétaires en respectant les exigences de liaison
AGPL (Affero GPL)
- Obligations : comme la GPL, mais l'obligation de divulgation est déclenchée par la simple mise à disposition via un réseau (SaaS)
- Risque : très élevé
- Pratique : particulièrement critique pour les applications SaaS commerciales
Due diligence M&A pour les logiciels open source
Dans les transactions d'entreprise, la conformité OSS devient de plus en plus un critère éliminatoire. Les acquéreurs doivent s'assurer que l'entreprise cible ne commet pas de violations de licence susceptibles d'engendrer des risques de responsabilité après la clôture de la transaction.
Points de contrôle essentiels
Une due diligence OSS doit couvrir au minimum les aspects suivants :
- Inventaire : identification complète de tous les composants OSS utilisés et de leurs licences
- Compatibilité des licences : vérification que la combinaison de différentes licences est admissible
- Contamination copyleft : identification de composants GPL ou AGPL dans les produits propriétaires
- Respect des conditions de licence : les avis de copyright, textes de licence et, le cas échéant, le code source sont-ils correctement fournis ?
- Conformité organisationnelle : des processus internes et des responsabilités pour la gestion OSS existent-ils ?
Impact sur la valorisation
Les risques OSS identifiés peuvent avoir un impact considérable sur le prix de la transaction. Dans les cas graves -- par exemple lorsqu'un produit principal est contaminé par la GPL -- cela peut signifier l'abandon de la transaction. Des garanties contractuelles sous forme de déclarations (representations), garanties (warranties) et indemnisations (indemnities) sont donc essentielles.
Programmes de conformité organisationnels
Un programme de conformité OSS efficace repose sur plusieurs piliers :
Structure de gouvernance
- Mise en place d'un Open Source Program Office (OSPO) ou au minimum d'un responsable de la conformité dédié
- Politiques claires pour l'utilisation de l'OSS (liste blanche/liste noire par type de licence)
- Processus d'approbation définis avant l'intégration de nouveaux composants OSS
Outillage technique
Les outils modernes permettent la détection et la gestion automatisées des composants OSS :
- FOSSA : détection automatisée des licences, génération de SBOM et application des politiques
- Snyk Open Source : analyse combinée de sécurité et de conformité des licences
- Black Duck (Synopsys) : analyse complète de la composition logicielle avec inspection binaire approfondie
ISO/IEC 5230 -- Le standard OpenChain
Le standard OpenChain de la Linux Foundation, standard international sous ISO/IEC 5230 depuis 2020, définit les exigences fondamentales pour des programmes de conformité open source de qualité. La certification OpenChain crée la confiance dans la chaîne d'approvisionnement et réduit la charge d'audit auprès des partenaires commerciaux et dans les processus de due diligence.
Recommandations pratiques
Pour les dirigeants
- Sensibiliser : mettre les risques OSS à l'ordre du jour de la direction
- Allouer un budget : les outils et le personnel de conformité sont un investissement, pas un coût
- Définir les responsabilités : établir des attributions claires pour la conformité OSS
Pour les équipes de développement
- Vérifier avant d'intégrer : contrôler la compatibilité de licence de chaque nouveau composant OSS
- Documenter les dépendances : maintenir et mettre à jour continuellement les SBOM
- Intégrer dans le pipeline de build : intégrer des scans de licences automatisés dans le pipeline CI/CD
Pour les services juridiques
- Créer une politique de licences : directives claires sur les licences acceptées et sous quelles conditions
- Protection contractuelle : inclure des garanties de licence dans les contrats développeurs et fournisseurs
- Organiser des formations : sensibiliser régulièrement toutes les parties prenantes aux questions juridiques OSS
Conclusion
Le logiciel open source est devenu un élément indispensable du développement logiciel moderne -- et c'est une bonne chose. Toutefois, les risques de licence associés exigent une gestion professionnelle. Le Cyber Resilience Act européen avec son obligation SBOM renforce encore la pression d'agir. Les entreprises qui négligent leur conformité OSS risquent non seulement des sanctions juridiques, mais aussi des dommages économiques considérables -- des transactions M&A avortées à la divulgation forcée de code source propriétaire.
Chez compleneo, nous vous accompagnons dans l'évaluation juridique de votre utilisation de l'open source, la mise en œuvre de programmes de conformité et la due diligence OSS lors de transactions d'entreprise. Contactez-nous.
