Le risque lié aux licences open source est le risque juridique et commercial découlant de logiciels qui intègrent des composants open source sous des licences dont les termes (obligations de copyleft, exigences de mention de l’auteur, clauses de résiliation liées aux brevets, restrictions d’usage commercial) peuvent être incompatibles avec la manière dont l’entreprise déploie le logiciel, ou imposer au code propriétaire du fournisseur des obligations que celui-ci n’a pas divulguées. L’adoption de la SBOM a amélioré la visibilité sur les composants open source inclus dans les logiciels des fournisseurs. La gestion du risque lié aux licences exige de comprendre non seulement quels composants sont présents, mais aussi quelles obligations leurs licences imposent dans le contexte de déploiement concerné.
Le spectre du copyleft constitue le cadre conceptuel. Les licences open source vont des licences permissives (MIT, Apache 2.0, BSD), qui imposent des obligations minimales (en général une simple mention de l’auteur), aux licences à copyleft fort (GPL-3.0, AGPL-3.0), qui exigent que tout logiciel intégrant des composants sous licence copyleft soit distribué sous la même licence copyleft. La AGPL-3.0 est la variante de copyleft la plus forte, car elle étend l’obligation de copyleft aux services réseau : un logiciel utilisé via un réseau est considéré comme distribué au sens de l’AGPL, ce qui déclenche l’obligation de divulgation du code source. Pour un fournisseur dont le logiciel propriétaire intègre des composants sous licence AGPL et est fourni sous forme de service réseau, les dispositions de copyleft de l’AGPL peuvent imposer la divulgation du code source propriétaire.
Le problème de compatibilité des licences en constitue la dimension technique. Les différentes licences open source sont compatibles ou incompatibles entre elles, et cela détermine si un produit logiciel qui combine des composants sous plusieurs licences est juridiquement cohérent. Combiner dans un même binaire des composants sous licence GPL-2.0 et GPL-3.0 crée une incompatibilité ; la clause « ou version ultérieure » de la GPL-2.0 la résout, mais tous les logiciels sous licence GPL-2.0 ne la comportent pas. Combiner Apache 2.0 et GPL-2.0 crée une incompatibilité, car Apache 2.0 comporte une clause de résiliation liée aux brevets incompatible avec les exigences de la GPL-2.0. L’analyse de compatibilité des licences est une tâche juridique spécialisée que la plupart des équipes TPRM ne peuvent mener sans conseil juridique.
Pourquoi c’est important
Le risque lié aux licences open source est un enjeu pour le TPRM parce que les logiciels déployés par votre entreprise peuvent imposer des obligations juridiques que ni l’entreprise ni le fournisseur n’ont identifiées, des obligations qui peuvent apparaître après le déploiement, lorsque les conséquences juridiques d’une combinaison de licences sont évaluées. Il peut s’agir d’obligations de divulgation du code source, d’obligations de redevances et de dispositions de résiliation de licence qui affectent le droit de l’entreprise à continuer d’utiliser le logiciel.
- Risque lié aux licences non évalué en même temps que les fonctionnalités et la sécurité
- Composants AGPL et à copyleft fort non identifiés dans les logiciels des fournisseurs
- Contexte de déploiement en service réseau non pris en compte dans l’analyse du copyleft AGPL
- Compatibilité des licences non évaluée pour les combinaisons de composants
- SBOM utilisée pour la sécurité, mais pas pour l’évaluation de la conformité des licences
À quoi ressemblent les bonnes pratiques
Les programmes matures de gestion du risque lié aux licences incluent les informations de licence dans les demandes de SBOM, identifient les composants à copyleft fort et AGPL dans les logiciels des fournisseurs, évaluent la compatibilité des licences pour les combinaisons de composants et procèdent à un examen juridique des logiciels comprenant des composants AGPL déployés en tant que services réseau.
- Informations de licence dans la SBOM : licences de tous les composants identifiées
- Identification des composants copyleft, en particulier AGPL dans un contexte de service réseau
- Analyse de compatibilité des licences pour les combinaisons de composants
- Examen juridique des logiciels contenant de l’AGPL déployés en tant que service réseau
- Déclaration du fournisseur sur la conformité des licences dans le cadre de l’évaluation de la sécurité logicielle
Outils
Analyse des licences : FOSSA, Black Duck, Snyk License Compliance pour l’analyse des licences de la SBOM
Les outils d’analyse des licences open source peuvent examiner les SBOM et les dépôts de code pour en extraire les informations de licence : ils identifient les composants copyleft, signalent les problèmes de compatibilité des licences et produisent des rapports de conformité des licences. FOSSA et Black Duck proposent une analyse du risque lié aux licences de niveau entreprise. Pour les praticiens du TPRM, demander les résultats de l’analyse des licences en même temps que ceux de l’analyse des vulnérabilités de la SBOM donne une vue complète du risque open source.
Enjeux de gouvernance
La difficulté de gouvernance du risque lié aux licences open source tient au besoin d’expertise juridique. L’analyse de ce risque, en particulier celle du copyleft AGPL et de la compatibilité des licences, exige une expertise juridique dont la plupart des équipes TPRM et de sécurité ne disposent pas. La réponse de gouvernance consiste à inclure le risque lié aux licences dans l’évaluation des logiciels des fournisseurs et à transmettre les composants copyleft identifiés au conseil juridique pour qu’il en évalue les conséquences.
- Demander les informations de licence dans la SBOM
- Identifier les composants AGPL et à copyleft fort dans les logiciels des fournisseurs
- Transmettre les constats AGPL au conseil juridique pour l’analyse des conséquences liées aux services réseau
- Inclure la conformité des licences dans le contrat fournisseur : garanties du fournisseur concernant les obligations de licence
- Mettre en place l’analyse des licences des logiciels fournis par les fournisseurs en plus de l’analyse des vulnérabilités
Si vous êtes une petite équipe
La prochaine fois que vous recevrez une SBOM d’un fournisseur, passez-la dans l’offre gratuite de FOSSA ou dans un outil équivalent d’analyse des licences. L’analyse prend quelques minutes et classe tous les composants listés par licence, en identifiant les éventuels composants AGPL, GPL ou à copyleft fort. Signalez tout composant AGPL pour examen juridique si le logiciel est déployé en tant que service réseau. Cette analyse de quinze minutes évite l’examen juridique de six mois qu’a subi l’organisation du scénario d’ouverture.
- Passer la SBOM du fournisseur dans un outil d’analyse des licences
- Identifier les composants AGPL et à copyleft fort
- Signaler les composants AGPL pour examen juridique dans les déploiements en service réseau
- Inclure une garantie de conformité des licences dans les contrats fournisseurs
Ce qu’il faut exiger
Demandez directement :
« Votre logiciel comprend-il des composants sous licence AGPL-3.0 ou sous d’autres licences à copyleft fort, et avez-vous procédé à un examen juridique de vos obligations de conformité aux licences, en particulier au regard de la disposition de l’AGPL relative aux services réseau si votre logiciel est fourni en tant que service ? »
Preuves attendues
- SBOM comportant les informations de licence de tous les composants
- Résultats d’analyse des licences identifiant les composants copyleft
- Évaluation de la conformité juridique des composants AGPL et à copyleft fort
- Garantie de conformité des licences dans le contrat fournisseur
Il convient de demander à un fournisseur qui fournit une SBOM les informations de licence en plus des données de vulnérabilité. Les analyses de vulnérabilités de la SBOM traitent le risque de sécurité. Les informations de licence traitent le risque juridique. Les deux sont nécessaires à une gestion complète du risque open source.
Comment le prouver
- Registres d’analyse des licences des logiciels des fournisseurs
- Identification des composants copyleft
- Registres d’examen juridique des composants AGPL
- Documentation de la garantie de conformité des licences
À retenir
Plateforme d’analyse déployée. Composant AGPL : non divulgué, aucune question posée. Découvert : 18 mois plus tard, par le service juridique. Obligation AGPL potentielle : divulgation du code source propriétaire en cas de déploiement en service réseau. Examen juridique : 6 mois. Le risque lié aux licences est un risque juridique qui existe dès le premier jour du déploiement. Les composants AGPL dans un logiciel fourni en tant que service réseau peuvent déclencher des obligations de divulgation du code source qui s’appliquent au code propriétaire du fournisseur. L’analyse des licences les repère en quelques minutes. L’examen juridique en évalue les conséquences. Les deux ont lieu avant le déploiement, pas dix-huit mois après. Une SBOM sans informations de licence offre une visibilité sur la sécurité sans visibilité sur le risque juridique.