# Un audit de licences open source avant de livrer un projet à un client public

> Certaines licences imposent des obligations d'attribution ou de partage du code que peu d'agences vérifient avant livraison. Une méthode d'audit rapide des dépendances Composer et npm.

- Auteur : Clément Hadrot
- Publié le : 2024-07-05
- Mis à jour le : 2024-07-05
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/audit-licences-open-source-livraison/

## L’essentiel

- Les licences des dépendances varient d'un projet à l'autre sans contrôle systématique
- composer licenses et license-checker listent l'ensemble en une commande
- Une licence copyleft imposant le partage du code mérite une décision explicite, pas un oubli

« GPL-2.0-or-later », « MIT », « BSD-3-Clause », « AGPL-3.0 » : la liste des licences associées aux dépendances d'un projet WordPress moyen dépasse rapidement la dizaine de valeurs distinctes, chacune avec ses propres obligations, sans qu'aucun contrôle systématique ne soit généralement effectué avant la livraison d'un projet à un client.

Ce contrôle prend une importance particulière lorsque le client est un organisme public soumis à des obligations propres en matière de logiciels libres, ou lorsque le projet lui-même sera republié en tant qu'extension ou thème distribué. WordPress lui-même est distribué sous licence GPL, ce qui impose que tout code dérivé — thèmes et extensions inclus — respecte les mêmes termes de licence, une contrainte qui se propage en théorie à chaque dépendance intégrée au projet.

## Extraire l'inventaire des licences Composer

Composer fournit une commande native pour lister les licences de l'ensemble des dépendances installées, sans outil supplémentaire à installer :

```
composer licenses --format=json > licences-composer.json
```

Le résultat liste, pour chaque paquet, son nom, sa version et sa ou ses licences déclarées dans son fichier `composer.json`. Cette commande ne vérifie pas la cohérence réelle du code avec la licence déclarée, elle se contente de rapporter l'information telle que fournie par chaque mainteneur de paquet, ce qui reste néanmoins suffisant pour un premier passage d'audit.

## Extraire l'inventaire côté npm

Côté JavaScript, l'outil `license-checker`, disponible en tant que paquet npm, remplit un rôle équivalent :

```
npx license-checker --json --out licences-npm.json
```

> L'essentiel à retenir : Les licences des dépendances varient d'un projet à l'autre sans contrôle systématique ; composer licenses et license-checker listent l'ensemble en une commande ; Une licence copyleft imposant le partage du code mérite une décision explicite, pas un oubli

Sur un projet comportant à la fois des dépendances Composer côté PHP et des dépendances npm côté outillage de build front-end, les deux commandes doivent être exécutées séparément, chacune produisant son propre inventaire à analyser.

## Ce qui a été trouvé sur le projet audité

L'audit mené sur un projet destiné à un organisme public a révélé six dépendances sous licence `AGPL-3.0`, une licence copyleft dite forte qui impose de rendre disponible le code source complet de tout logiciel qui l'utilise, y compris lorsqu'il est exploité uniquement via un réseau plutôt que distribué directement. Cette obligation entrait en tension avec les conditions contractuelles du projet, qui ne prévoyaient pas la publication du code source complet développé pour ce client.

Après analyse, ces six dépendances correspondaient toutes à un unique outil de génération de rapports PDF, utilisé pour une fonctionnalité secondaire du projet. Le remplacement par une bibliothèque équivalente sous licence `MIT`, moins contraignante, a résolu le point sans affecter les fonctionnalités livrées au client.

## Une grille de lecture des licences les plus courantes

| Licence | Type | Obligation principale |
| --- | --- | --- |
| MIT, BSD, ISC | Permissive | Conserver la mention de copyright, rien d'autre |
| GPL-2.0, GPL-3.0 | Copyleft | Le logiciel dérivé distribué doit rester sous la même licence |
| AGPL-3.0 | Copyleft renforcé | Obligation étendue à l'usage en réseau, pas seulement à la distribution |
| LGPL | Copyleft limité | S'applique à la bibliothèque elle-même, pas au logiciel qui l'utilise en liaison dynamique |

## Automatiser le contrôle plutôt que le répéter manuellement

Une fois la méthode établie, son intégration à la chaîne d'intégration continue évite qu'une nouvelle dépendance problématique ne passe inaperçue lors d'une mise à jour ultérieure. Une étape dédiée, exécutée à chaque modification du fichier de verrouillage des dépendances, peut comparer la liste des licences détectées à une liste blanche définie pour le projet et signaler tout écart avant fusion de la modification.

- Liste blanche de licences acceptées, définie une fois par type de projet
- Contrôle automatisé déclenché à chaque modification du fichier de verrouillage
- Décision explicite documentée pour toute exception acceptée malgré tout

## Ce que cet audit ne couvre pas

Cet audit porte sur les licences déclarées par chaque paquet, pas sur une vérification juridique complète de leur compatibilité mutuelle dans un cas d'usage précis, qui reste du ressort d'un conseil juridique spécialisé pour les situations les plus sensibles. Il ne couvre pas non plus les vulnérabilités de sécurité des dépendances, sujet distinct traité par d'autres outils dédiés.

## En résumé

Un audit de licences open source, réalisé en deux commandes simples sur les écosystèmes Composer et npm, révèle des obligations contractuelles parfois incompatibles avec les engagements pris envers un client, en particulier un organisme public. Le coût de cette vérification reste minime comparé au risque juridique qu'elle permet d'éviter, surtout lorsque la licence de WordPress lui-même impose déjà un cadre à respecter par construction.