Conformité open source : SBOM, audit et violation de licence

Droit du numérique & propriété intellectuelle · Master 2

Conformité open source : SBOM, due diligence M&A et sanctions civiles et pénales de la LDA.

Introduction

Les logiciels modernes sont composés en grande partie de briques open source. Une application commerciale peut dépendre de centaines de bibliothèques, elles-mêmes dotées de dépendances transitives, sous des licences variées. Sans inventaire ni politique, une entreprise s'expose à des risques de non-respect des conditions de licence, à la divulgation involontaire de code propriétaire et à des difficultés lors d'une levée de fonds ou d'une vente.

Un programme de conformité open source repose sur quelques instruments : un inventaire des composants et de leurs licences (la nomenclature logicielle ou SBOM, software bill of materials), une politique interne précisant les licences admises, interdites ou soumises à validation, des outils d'analyse automatisée du code, des procédures d'approbation avant intégration et des règles pour les contributions de salariés à des projets externes. La responsabilité de ces processus implique les équipes techniques, juridiques et de gouvernance.

La violation d'une licence open source peut déboucher sur des actions civiles en vertu de la loi sur le droit d'auteur (interdiction, suppression, dommages-intérêts, remise du gain) et sur une répression pénale sur plainte. En pratique, les différends se règlent le plus souvent par la mise en conformité, la publication du code ou la conclusion d'une licence commerciale. Lors d'une opération de fusion-acquisition, l'acquéreur exige généralement un audit open source dont les résultats nourrissent les garanties contractuelles.

Objectifs d'apprentissage

Décrire les composantes d'un programme de conformité open source
Expliquer le rôle et le contenu d'une nomenclature logicielle (SBOM)
Identifier les risques de contamination copyleft et les stratégies d'atténuation
Préparer l'audit open source d'une opération de fusion-acquisition
Énumérer les sanctions civiles et pénales d'une violation de licence en droit suisse

Concepts clés

Inventaire et SBOM: La nomenclature logicielle recense les composants, leur version, leur origine et leur licence, y compris les dépendances transitives. Elle sert de base à la gestion du risque juridique, mais aussi à la cybersécurité.
Politique d'usage: Une politique classe les licences en catégories : admises sans approbation, admises sous conditions, interdites ou à valider cas par cas. Elle précise le traitement des licences à copyleft fort et réseau pour les produits distribués ou hébergés.
Risque de contamination: L'intégration de code à copyleft fort dans un produit propriétaire distribué peut obliger à publier le code source de l'ensemble. Les mesures d'atténuation incluent l'isolation architecturale, le remplacement du composant, la négociation d'une licence commerciale ou le respect intégral des conditions.
Due diligence M&A: L'acquéreur fait auditer le code cible pour identifier les licences et les écarts de conformité. Les résultats conduisent à des garanties spécifiques, des prix ajustés ou des mesures correctives avant la clôture.
Sanctions: La LDA ouvre des actions civiles en interdiction, en suppression de l'état de fait illicite, en dommages-intérêts et en remise du gain (art. 62 LDA) et prévoit des infractions poursuivies sur plainte (art. 67 LDA). La mise en conformité amiable est fréquente.

Conclusion

La conformité open source est un processus continu qui combine inventaire (SBOM), politique, outils et gouvernance. Elle réduit le risque de contamination copyleft, facilite les opérations d'investissement et de cession et évite des litiges coûteux.

Les sanctions civiles et pénales de la LDA existent mais se règlent le plus souvent par la mise en conformité. L'investissement le plus rentable est donc préventif : connaître ses composants avant qu'un tiers ne les connaisse à sa place.

Cartes

Qu'est-ce qu'un SBOM ?: Une nomenclature logicielle (software bill of materials) listant les composants d'un logiciel, leurs versions, origines et licences.
Pourquoi inclure les dépendances transitives dans l'inventaire ?: Parce que les licences de ces composants s'appliquent aussi et peuvent imposer des obligations ou des incompatibilités.
Que contient une politique open source d'entreprise ?: La liste des licences admises, soumises à validation ou interdites, les procédures d'approbation et les règles de contribution.
Qu'est-ce que le risque de contamination ?: Le risque qu'un composant à copyleft fort oblige à publier le code source d'un produit propriétaire qui le combine.
Comment atténuer un risque de contamination ?: Isoler le composant, le remplacer, négocier une licence commerciale ou respecter intégralement les obligations de la licence.
Pourquoi un acquéreur demande-t-il un audit open source ?: Pour identifier les licences utilisées, apprécier les écarts de conformité et négocier des garanties ou un ajustement de prix.
Quelles garanties contractuelles accompagnent souvent la cession ?: Une déclaration sur l'usage de composants open source, la conformité aux licences et l'absence d'obligation de divulguer le code, avec indemnisation en cas de violation.
Quelle disposition de la LDA ouvre des actions civiles ?: L'art. 62 LDA (interdiction, suppression, dommages-intérêts, remise du gain).
Comment la violation d'une licence est-elle poursuivie pénalement ?: Sur plainte, selon les dispositions pénales de la LDA (art. 67 LDA).
Une entreprise peut-elle contribuer à un projet open source avec du code de ses salariés ?: Oui, si l'entreprise détient les droits et valide la contribution selon sa politique ; sinon elle viole ses droits ou ceux de tiers.
Qu'est-ce qu'un accord de contribution (CLA) ?: Un contrat par lequel un contributeur concède ou cède au projet les droits nécessaires sur sa contribution.
Les différends sur l'open source se règlent-ils surtout au tribunal ?: Non, la plupart se règlent par la mise en conformité, la publication du code ou une licence commerciale.

Glossaire

SBOM: Software Bill of Materials, inventaire structuré des composants d'un logiciel.
Dépendance transitive: Composant requis non directement mais par une autre dépendance du projet.
Contamination: Extension du copyleft à un ouvrage combiné avec du code sous licence à copyleft fort.
Due diligence: Audit juridique et technique réalisé avant une acquisition ou un investissement.
CLA: Contributor License Agreement, accord par lequel un contributeur accorde au projet les droits nécessaires sur sa contribution.
Remise du gain: Prétention du lésé de réclamer le gain réalisé par l'auteur de l'atteinte selon les règles de la gestion d'affaires.
Mise en conformité: Régularisation spontanée ou négociée d'une violation de licence (publication du code, mentions, retrait).