« 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.jsonLe 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
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.
