IT Sécurité IA Open Source

Comment les IA viennent changer les règles du jeu du droit d'auteur et de l'Open Source ?

Un développeur réécrit une bibliothèque Python en cinq jours avec Claude Code et change sa licence : qu'en est-il du droit d'auteur sur le code Open Source à l'ère des agents IA ?

Le mainteneur de chardet, une bibliothèque Python utilisée pour détecter automatiquement l'encodage de caractères dans un fichier texte, présente dans des millions de projets à travers le monde, a publié la version 7.0.0 avec une note dans les release notes qui a mis le feu aux poudres : réécriture complète, nouvelle licence et considérée comme plus rapide. Sauf que chardet était jusqu'ici publié sous licence LGPL et que la réécriture a été réalisée en cinq jours avec Claude Code 😮

Mark Pilgrim, l'auteur original du projet, a réagi publiquement sur GitHub en des termes sans ambiguïté : les mainteneurs n'avaient pas le droit de procéder à ce changement de licence. Le fil de discussion a été verrouillé. Le débat, lui, ne l'est pas.

GPL, MIT : deux licences Open Source aux logiques opposées

Quand un logiciel est publié en open source, "libre" ne signifie pas "sans règles". Il existe des licences précisément pour encadrer ce que les utilisateurs ont le droit de faire avec le code et ce qu'ils ont l'obligation de faire en retour. Deux familles dominent les débats depuis des décennies : la famille GPL et la licence MIT.

La licence MIT est dite permissive. Elle accorde à quiconque le droit d'utiliser, de modifier et de redistribuer le code, y compris dans des produits commerciaux entièrement propriétaires, sans aucune obligation de reverser quoi que ce soit à la communauté. On prend, on adapte, on intègre à un produit commercial sans rien rendre. C'est la raison pour laquelle les grands éditeurs logiciels ont une préférence marquée pour les composants publiés sous MIT : cela ne coûte rien et n'engage à rien.

La GPL, General Public License et sa variante LGPL, légèrement moins contraignante, fonctionnent selon une logique radicalement différente. Elles sont dites copyleft : si l'on construit un produit qui s'appuie sur du code publié sous GPL, ce produit doit lui aussi être publié sous GPL. La licence se propage à l'ensemble de l'œuvre dérivée. Pour un éditeur commercial, cela peut représenter une contrainte sérieuse, voire rédhibitoire : être contraint d'ouvrir son propre code source est souvent incompatible avec un modèle économique fondé sur la propriété intellectuelle.

C'est précisément pour cette raison que Linus Torvalds a choisi la GPL pour le noyau Linux. Cette décision n'est pas anodine : elle a forcé les industriels qui développaient des pilotes matériels à publier leur code source dès lors qu'ils voulaient que leur matériel fonctionne avec Linux. Au fil des années, un socle technique commun s'est ainsi constitué, composé de millions de lignes de code contribuées par des fabricants de puces, de serveurs, de téléphones, de voitures et de satellites, parce que la licence les y contraignait. Le noyau Linux anime aujourd'hui la grande majorité des appareils connectés sur la planète. La GPL n'est pas étrangère à ce résultat.

Relicencier un projet Open Source est normalement quasi impossible

Dans l'écosystème open source, la licence d'un projet n'est pas un détail administratif modifiable à la marge. Elle engage juridiquement tous ceux qui ont contribué au code. Pour relicencier un projet, il faut théoriquement recueillir l'accord explicite de chaque contributeur ayant écrit la moindre ligne, un exercice titanesque qui devient rapidement impraticable sur un projet de plusieurs années, avec des dizaines ou des centaines de participants dont certains sont injoignables, inactifs ou disparus.

L'alternative légale reconnue est l'implémentation en chambre noire, que les anglophones appellent clean room : repartir entièrement de zéro, réimplémenter les fonctionnalités du logiciel sans jamais consulter le code source original, en travaillant uniquement à partir des spécifications publiques ou des interfaces. Cette démarche est actuelellement légale, les interfaces logicielles ne sont pas protégées par le droit d'auteur, mais elle exige du temps, des ressources et une discipline rigoureuse pour ne pas reproduire involontairement des structures issues de l'original.

C'est dans ce contexte que l'affaire chardet a éclaté.

Une réécriture par IA présentée comme une œuvre nouvelle

Dan Blanchard, mainteneur de chardet depuis plusieurs années, a utilisé Claude Code pour réécrire l'intégralité du projet en cinq jours, dans un dépôt vide, en instruisant explicitement le modèle de ne s'appuyer sur aucun code publié sous licence LGPL ou GPL. Il a ensuite publié le résultat sous licence MIT en faisant valoir que cette réécriture constituait une œuvre nouvelle, indépendante de l'originale et donc affranchie de toute obligation envers la licence précédente.

L'argument de Mark Pilgrim est simple et direct : Dan Blanchard avait une connaissance approfondie du code source original, auquel il avait lui-même contribué pendant des années . Une réécriture réalisée dans ces conditions n'est pas une implémentation en chambre noire, quels que soient les outils utilisés. C'est une [œuvre dérivée] (https://www.gnu.org/licenses/gpl-faq.fr.html) qui reste soumise à la LGPL. Le fait d'avoir intercalé un modèle de langage dans le processus ne modifie pas la filiation juridique de l'œuvre.

Blanchard a répondu en publiant une analyse de similarité entre les versions 6 et 7 du projet : moins de 1,3 % de tokens communs, aucun fichier structurellement similaire. Il en conclut que la version 7 est objectivement une œuvre distincte de son prédécesseur.

La Free Software Foundation a refusé de se prononcer sur la légalité spécifique du cas tout en rappelant que rien n'est propre dans un modèle de langage qui a ingéré le code qu'on lui demande de réimplémenter. Richard Fontana, l'un des auteurs de la GPLv3, a pour sa part estimé qu'il ne voyait pas de base solide pour conclure que chardet 7.0.0 est juridiquement contraint par la LGPL, sans pour autant trancher définitivement. Le fil GitHub a été verrouillé. La question reste entière.

Une brèche dans trente ans de protection copyleft

Ce qui rend l'affaire chardet importante, c'est ce qu'elle révèle comme possibilité à grande échelle.

➡️ Si un modèle de langage peut réécrire fonctionnellement n'importe quel composant open source en quelques jours et si cette réécriture peut être considérée comme une œuvre nouvelle affranchie de la licence originale, alors le mécanisme de protection du copyleft sur lequel repose l'ensemble de l'écosystème GPL depuis trente ans devient contournable par quiconque dispose d'un accès à un agent de codage. Les mainteneurs du noyau Linux ont déjà soulevé cette question sur leur liste de diffusion.

➡️ Il y a une ironie dans tout cela. Le modèle qui a réécrit chardet a presque certainement été entraîné sur chardet, dont le code était public, indexé et librement accessible. Peut-on démontrer que le modèle s'en est servi d'une manière déterminante dans sa génération ? Probablement pas avec les outils juridiques actuels. Mais l'idée qu' une œuvre peut être blanchie de ses obligations de licence en passant par un intermédiaire algorithmique qui en a absorbé le contenu pendant son entraînement est profondément problématique, indépendamment de ce que les tribunaux finiront par décider.

➡️ Armin Ronacher, créateur du framework Flask et développeur open source de longue date, l'a formulé directement : le copyleft repose sur le droit d'auteur et sur la friction. Or, parce que le code est fondamentalement ouvert, il est désormais possible de le réécrire trivialement. Les conséquences de cette réalité restent à mesurer.

Implications pratiques pour les équipes techniques et les décideurs

Pour les équipes techniques et les décideurs, cette affaire appelle une vigilance renforcée sur deux points pratiques.

1. Le premier est la traçabilité des licences dans les bases de code. Savoir qu'un composant est open source ne suffit plus : il faut savoir sous quelle licence il est publié et surveiller les changements de licence lors des mises à jour. Un composant qui passe de LGPL à MIT sans explication peut signaler une relicensation contestée, avec des implications juridiques pour les projets qui l'intègrent en aval.

2. Le second concerne l'usage de l'intelligence artificielle dans le développement logiciel interne. Si les équipes utilisent des agents de codage pour générer ou réécrire des composants et que ces agents ont été entraînés sur du code GPL, la question de la filiation juridique du code produit n'est pas tranchée. Ce n'est pas une raison de ne pas utiliser ces outils mais c'est une raison de documenter les processus, de choisir les licences de sortie avec soin et de ne pas naviguer à vue dans un vide juridique qui sera tôt ou tard comblé par des décisions de justice.

Pour aller plus loin sur les licences open source et leurs implications organisationnelles, la Free Software Foundation publie une documentation de référence accessible sur son site, et la CISA a produit des recommandations sur la gouvernance des composants logiciels tiers dans les chaînes d'approvisionnement.

L'équipe Sigilence est disponible pour vous accompagner dans l'audit des licences de vos dépendances open source.

Sources : Phoronix / Korben