Conformité des licences Open Source : un guide pratique pour les éditeurs de logiciels

L'application commerciale moyenne contient 77 % de code open source, réparti sur plus de 500 dépendances. Chaque dépendance possède sa propre licence avec des obligations spécifiques. La violation de ces obligations expose votre entreprise à des poursuites judiciaires, à la divulgation forcée du code et à des atteintes à sa réputation. Pourtant, la plupart des entreprises ne disposent d’aucun processus de suivi ou de conformité aux licences open source.

Ce guide fournit un cadre pratique pour la conformité des licences open source, de la catégorisation des licences à l'analyse automatisée et à la génération SBOM.

Points clés à retenir

• Toutes les licences open source ne sont pas identiques : les licences permissives autorisent presque tout, les licences copyleft nécessitent que vous partagiez les modifications
• Une nomenclature logicielle (SBOM) devient une exigence légale dans les marchés publics (US Executive Order 14028)
• L'analyse automatisée des licences dans CI/CD empêche les dépendances non conformes d'entrer dans votre base de code
• Le risque « d'infection » par le copyleft est réel : une dépendance à la GPL peut vous obliger à open-source l'intégralité de votre application

---

Catégories de licences

Licences permissives (faible risque)

Sans danger pour un usage commercial. Incluez le texte de la licence et l'avis de droit d'auteur dans votre distribution. Apache 2.0 nécessite en outre de noter toute modification apportée au code d'origine et inclut une licence de brevet.

Copyleft faible (risque moyen)

À utiliser avec prudence. Conservez les bibliothèques LGPL en tant que bibliothèques partagées (dynamiques), non liées statiquement. Conservez le code sous licence MPL dans des fichiers distincts de votre code propriétaire.

Copyleft fort (risque élevé)

Risque le plus élevé pour les logiciels commerciaux. L'utilisation du code GPL dans votre application peut vous obliger à publier l'intégralité de votre application sous GPL. AGPL étend cela aux logiciels côté serveur --- même si vous ne distribuez jamais de binaires, fournir le logiciel en tant que service Web déclenche l'obligation de copyleft.

---

Flux de travail de conformité

Étape 1 : Générer un SBOM

# For Node.js projects (using CycloneDX)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json --spec-version 1.5

# For Python projects
pip install cyclonedx-bom
cyclonedx-py environment --output sbom.json

# For multi-language projects (using Syft)
syft . -o cyclonedx-json > sbom.json

Étape 2 : Rechercher la conformité des licences

# Using license-checker for Node.js
npx license-checker --production --json --out licenses.json

# Using scancode-toolkit (comprehensive, all languages)
scancode --license --copyright --output-json scan-results.json .

Étape 3 : Catégoriser et approuver

Créez une liste de licences approuvées :

{
  "approved": [
    "MIT", "BSD-2-Clause", "BSD-3-Clause", "Apache-2.0",
    "ISC", "0BSD", "Unlicense", "CC0-1.0"
  ],
  "conditional": [
    "LGPL-2.1", "LGPL-3.0", "MPL-2.0", "EPL-2.0"
  ],
  "prohibited": [
    "GPL-2.0", "GPL-3.0", "AGPL-3.0", "SSPL-1.0",
    "EUPL-1.2", "OSL-3.0"
  ]
}

Étape 4 : Intégration CI/CD

# .github/workflows/license-check.yml
name: License Compliance
on: [pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: pnpm install --frozen-lockfile

      - name: Check licenses
        run: |
          npx license-checker --production --excludePackages "" \
            --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
            --summary

---

SBOM (nomenclature logicielle)

Pourquoi les SBOM sont importants

• Le US Executive Order 14028 exige des SBOM pour les logiciels vendus au gouvernement américain.
• La loi européenne sur la cyber-résilience exigera des SBOM pour les logiciels vendus dans l'UE.
• Sécurité de la chaîne d'approvisionnement : les SBOM permettent une réponse rapide aux vulnérabilités (lorsque log4j se produit, vous savez si vous êtes affecté)
• Confiance des clients : les acheteurs d'entreprise demandent de plus en plus de SBOM lors de l'approvisionnement

Normes SBOM

Recommandation : CycloneDX pour la plupart des éditeurs de logiciels. Il est plus simple, dispose d’un meilleur support d’outils et devient la norme par défaut de l’industrie.

---

Scénarios de conformité courants

Scénario 1 : Application Web Node.js

Le répertoire node_modules typique contient 500 à 2 000 packages. La grande majorité utilise des licences MIT ou ISC. Problèmes courants :

• Dépendances transitives sous GPL (vous ne les avez pas ajoutées directement)
• Champs de licence UNKNOWN nécessitant une enquête manuelle
• Plusieurs licences sur un seul package (par exemple, "MIT OR Apache-2.0")

Action : Exécutez npx license-checker --production chaque semaine. Enquêtez sur toutes les licences non permissives. Remplacez les dépendances GPL par des alternatives permissives.

Scénario 2 : Développement du module Odoo

Odoo Community Edition est LGPL v3. Odoo Enterprise est propriétaire. Vos modules personnalisés :

• Modules communautaires : doivent être LGPL v3 ou compatible (si distribué)
• Modules internes privés : Non distribué, donc LGPL ne s'applique pas
• Modules complémentaires Entreprise : doivent être conformes aux conditions de licence Odoo Entreprise

Scénario 3 : SaaS avec dépendances AGPL

Si votre application SaaS utilise du code sous licence AGPL (par exemple, MongoDB avant de passer à SSPL), vous devez soit :

1. Libérez l'intégralité du code source de votre application sous AGPL
2. Supprimez la dépendance AGPL et utilisez une alternative
3. Obtenir une licence commerciale du projet AGPL (si disponible)

L'utilisation du code AGPL côté serveur déclenche l'obligation de copyleft même si vous ne « distribuez » jamais de binaires.

---

Questions fréquemment posées

L'utilisation d'une bibliothèque GPL dans notre API nous oblige-t-elle à rendre notre API open source ?

Cela dépend de la façon dont vous l'utilisez. Si la bibliothèque GPL est liée à votre application (statiquement ou dynamiquement), la position de la FSF est que votre application est une « œuvre dérivée » et doit être sous licence GPL. Si vous communiquez avec le logiciel GPL via une API réseau (par exemple, en utilisant un serveur de base de données sous licence GPL), cela n'est généralement pas considéré comme une œuvre dérivée. Consultez un avocat pour votre cas spécifique.

Que se passe-t-il si une dépendance modifie sa licence ?

Vous êtes lié par la licence sous laquelle vous avez obtenu le code, et non par les modifications futures de la licence. Toutefois, si vous effectuez une mise à jour vers une nouvelle version avec une nouvelle licence, la nouvelle licence s'applique à cette version. C'est pourquoi les SBOM avec épinglage de version sont importants : ils documentent exactement la version (et la licence) que vous utilisez.

Comment gérer les dépendances avec les licences « INCONNU » ?

Vérifiez le référentiel du package pour un fichier LICENSE. Si aucune licence n'est spécifiée, le code est techniquement entièrement protégé par le droit d'auteur : vous n'avez aucun droit de l'utiliser, de le modifier ou de le distribuer. Soit recherchez la licence (elle peut se trouver dans un emplacement non standard), demandez à l'auteur d'en ajouter une ou remplacez la dépendance par une alternative clairement sous licence.

Devons-nous fournir une attribution pour les packages sous licence MIT ?

Oui. Le MIT et la plupart des licences permissives exigent que vous incluiez l'avis de droit d'auteur et le texte de la licence lors de la distribution du logiciel. Pour les applications Web, cela signifie généralement inclure un fichier TIERS-PARTY-NOTICES ou une page répertoriant tous les composants open source et leurs licences.

---

Créer un programme de conformité

Examen de conformité trimestriel

1. Régénérer SBOM pour tous les projets
2. Rechercher de nouvelles dépendances ajoutées depuis le dernier examen
3. Vérifiez les modifications de licence dans les packages mis à jour
4. Examinez toutes les licences « INCONNUES » apparues
5. Mettre à jour la liste des licences approuvées si de nouvelles licences sont rencontrées
6. Archiver les instantanés SBOM pour la piste d'audit

Rôles de conformité

Un programme de conformité léger prend 2 à 4 heures par trimestre pour une petite équipe et évite le coût beaucoup plus élevé lié à la découverte d'un problème de conformité après le lancement d'un produit ou lors d'une vérification préalable.

---

Ce qui vient ensuite

La conformité des licences est un aspect de la gouvernance logicielle. Combinez-le avec la protection IP pour votre propre code, les essentiels de l'accord SaaS pour les logiciels du fournisseur et les exigences réglementaires en matière de cybersécurité pour la conformité en matière de sécurité.

Contactez ECOSIRE pour les services d'audit de conformité open source et de génération SBOM.

---

Publié par ECOSIRE – aider les entreprises à utiliser l'open source de manière responsable.