Conformité des licences open source

Cette page fournit des informations générales, pas un conseil juridique. Pour toute décision concernant un produit précis, adressez-vous à un avocat.

Types de licences open source

Type	Exemples	Ce qu'elle exige généralement
Permissive	MIT, BSD, Apache-2.0	Conserver les mentions de copyright et de licence. Apache-2.0 comporte aussi des clauses sur les brevets.
Copyleft faible	LGPL, MPL-2.0	Partager les modifications apportées au composant sous licence lui-même
Copyleft fort	GPL-2.0, GPL-3.0	Le logiciel distribué avec ce composant doit être proposé aux mêmes conditions, avec son code source
Copyleft réseau	AGPL-3.0	Comme le copyleft fort, et s'applique aussi lorsque des utilisateurs interagissent avec le logiciel via un réseau
Source-available	BUSL, SSPL	Pas open source : le code source est visible, mais son utilisation est restreinte

Qu'est-ce qu'une licence copyleft ?

Une licence copyleft vous permet d'utiliser, de modifier et de partager un logiciel, à condition que ce que vous distribuez reste soumis aux mêmes conditions. Elle garde l'open source ouvert. Le risque pour un produit commercial est qu'un composant en copyleft fort lié à votre code peut soulever la question de savoir si votre propre code doit lui aussi être publié.

Cela dépend de la façon dont le composant est utilisé et dont le produit est fourni. Un logiciel que vous distribuez à des clients est plus exposé qu'un outil interne, et un produit SaaS échappe généralement aux conditions de distribution de la GPL, mais pas à celles de l'AGPL.

Risques de conformité courants

• Licences transitives. Un paquet permissif peut dépendre d'un paquet copyleft. Vérifier uniquement les dépendances directes passe à côté.
• Mentions manquantes. La plupart des licences vous demandent de conserver l'attribution, et un fichier de mentions oublié est le manquement le plus courant.
• Licences modifiées. Un projet peut changer de licence dans une nouvelle version : une mise à niveau peut donc changer vos conditions.
• Déclaré vs réel. Les métadonnées d'un paquet peuvent être erronées ou incomplètes, et le code vendoré peut avoir sa propre licence.
• Due diligence. Les acquéreurs et les grands clients demandent un inventaire des licences, généralement dans des délais courts.

Comment rester conforme

1. Rédigez une politique. Décidez quelles licences sont autorisées, lesquelles nécessitent une revue et lesquelles sont interdites, par type de produit.
2. Établissez un inventaire. Une SBOM liste chaque composant avec sa licence, y compris les dépendances transitives.
3. Vérifiez automatiquement. Appliquez la politique en CI, afin qu'une nouvelle dépendance soit rejetée au moment où elle est ajoutée plutôt que lors d'un audit.
4. Respectez les obligations. Générez les fichiers de mentions et fournissez le code source lorsqu'une licence l'exige.
5. Conservez les enregistrements. Stockez l'inventaire par release, car la question porte généralement sur une version déjà livrée.

Ce que font les logiciels de conformité des licences

La conformité des licences est un volet standard de l'analyse de la composition logicielle. Les outils identifient les composants, indiquent leurs licences et signalent les infractions à votre politique. Ils diffèrent par leur profondeur :

• Licences déclarées : la plupart des outils lisent ce que chaque paquet déclare dans ses métadonnées. C'est rapide et cela couvre le cas courant.
• Scan approfondi des licences : FOSSA et Black Duck analysent aussi le texte des licences dans le code, et aident pour les rapports d'attribution et la revue juridique. Consultez CRACI vs FOSSA et CRACI vs Black Duck.
• Outils gratuits : de nombreux générateurs de SBOM et scanners SCA indiquent gratuitement les licences déclarées. Consultez les meilleurs outils SCA.

La place de CRACI

CRACI gère les licences déclarées dans le build. En tant que runner GitHub Actions, il enregistre chaque paquet récupéré par un job, et chacun porte sa licence déclarée : les licences copyleft sont donc repérées avant de se retrouver dans le produit. Les règles de politique de licence peuvent bloquer un build en fonction d'une licence, et les exports de SBOM en CycloneDX et SPDX incluent la licence déclarée de chaque composant. CRACI s'appuie sur ce que les paquets déclarent : si vous avez besoin de workflows de revue juridique ou d'une analyse du texte des licences, utilisez donc un outil spécialisé à côté.

Conformité des licences open source : questions fréquentes

Qu'est-ce que la conformité des licences open source ?

Elle consiste à savoir quelles licences open source s'appliquent aux logiciels que vous utilisez et à respecter leurs conditions, comme conserver les mentions ou partager le code source.

Qu'est-ce qu'une licence copyleft ?

Une licence qui vous permet d'utiliser et de modifier un logiciel à condition que ce que vous distribuez reste soumis aux mêmes conditions. La GPL en est l'exemple le plus connu.

Peut-on utiliser du code GPL dans un logiciel commercial ?

Oui, mais si vous distribuez un logiciel qui en contient, vous devrez peut-être proposer le code source de ce logiciel sous GPL. La façon dont le code est combiné compte : demandez donc un avis juridique pour votre cas.

Le copyleft s'applique-t-il au SaaS ?

Les conditions de la GPL sont généralement déclenchées par la distribution, ce que le SaaS évite le plus souvent. L'AGPL comble cette lacune en étendant les conditions aux utilisateurs qui interagissent avec le logiciel via un réseau.

Quelle est la licence open source la plus sûre pour un usage commercial ?

Les licences permissives telles que MIT, BSD et Apache-2.0 sont les moins exigeantes. Vous devez tout de même conserver leurs mentions.

Comment vérifier les licences de vos dépendances ?

Générez une SBOM qui inclut les dépendances transitives et les licences déclarées, ou utilisez un outil SCA. Appliquez votre politique en CI, afin que les nouvelles infractions fassent échouer le build.