Mars 2026 — Un projet Python massivement utilisé vient de changer de licence en quelques jours grâce à l’IA. Son auteur original, disparu d’Internet depuis 2011, a refait surface pour contester. Ce cas pose une question fondamentale pour l’avenir du droit d’auteur logiciel.
I. Les faits : quelques jours, un LLM, et une licence effacée
Le 4 mars 2026, chardet 7.0.0 est publié sur PyPI et présenté comme une « ground-up, MIT-licensed rewrite » de la bibliothèque chardet, jusque-là diffusée sous LGPL depuis sa création en 2006 (la documentation du projet mentionne toutefois la date du 2 mars 2026 pour le changelog 7.0.0 ; les deux dates circulent dans les sources publiques). Le projet conserve le même nom de paquet et la même API publique. La bibliothèque est largement diffusée dans l’écosystème Python et bénéficie d’une forte visibilité sur PyPI.
La réécriture a été réalisée avec Claude Code d’Anthropic, et le mainteneur, Dan Blanchard, a soutenu publiquement qu’elle constituait une œuvre indépendante plutôt qu’une simple modification du code antérieur. Les benchmarks publiés dans le dépôt et sur PyPI mettent en avant un gain de performance d’environ 40 à 44 fois par rapport à chardet 6.0.0 selon les configurations testées. La similarité structurelle avec les versions antérieures, telle que mesurée par JPlag, serait — selon les déclarations publiques de Blanchard rapportées par Simon Willison — inférieure à 1,29 % au maximum avec la version précédente.
Le même jour, Mark Pilgrim — auteur originel de chardet, créateur de « Dive Into Python », qui avait volontairement quitté la vie publique en ligne en 2011 dans ce que la communauté désigne informellement comme son « infosuicide » — ouvre le ticket GitHub n°327 : « No right to relicense this project ».
« J’insiste respectueusement pour que le projet soit rétabli sous sa licence originale. L’utilisation d’un générateur de code fantaisiste ne leur confère aucun droit supplémentaire. »
Mark Pilgrim, Issue #327, 4 mars 2026
II. La question juridique centrale : la « clean room implementation » à l’ère de l’IA
Le concept de « clean room implementation » est bien établi en droit de la propriété intellectuelle : pour réécrire légalement un logiciel protégé sans reproduire son expression, il faut organiser une séparation stricte entre l’équipe qui analyse le code original et l’équipe de développement, qui n’a jamais eu accès au code source. L’exemple canonique est la réécriture du BIOS d’IBM par Compaq dans les années 1980, qui a permis la création des PC compatibles sans accès direct au code propriétaire d’IBM.
La jurisprudence Oracle v. Google (US Supreme Court, 2021) a confirmé que, dans les circonstances de cette affaire, la réimplémentation de l’API Java par Google pouvait relever du fair use — sans pour autant poser une règle générale d’immunité pour toute réimplémentation d’API.
La défense de Blanchard :
- Départ dans un dépôt vide, sans copier de fichiers ;
- Instruction explicite à Claude de ne pas référencer de code LGPL ou GPL ;
- Similarité structurelle très faible selon JPlag ;
- Seuls des patterns Python courants (argparse, blocs d’import, dict literals) sont similaires — non protégeables en tant que tels.
Pilgrim et ses soutiens répondent :
- Douze ans d’immersion dans le code original excluent toute prétention à une clean room classique ;
- Claude a vraisemblablement été entraîné sur des corpus publics susceptibles d’inclure le code source de chardet, sans que cela puisse être établi avec certitude — ce qui complique fortement la démonstration d’une séparation étanche ;
- Simon Willison relève qu’un artefact public du dépôt montre une consultation de
metadata/charsets.pypendant la réécriture ; - Même nom de paquet PyPI, même API — ce qui renforce la qualification d’œuvre dérivée.
Peut-on « blanchir » une licence copyleft via un LLM ? Si oui, l’ensemble de l’écosystème open source protégé par la GPL est potentiellement fragilisé.
III. Analyse juridique
A. Le régime LGPL et la notion d’œuvre dérivée
La LGPL impose que toute modification soit redistribuée sous les mêmes termes. Si chardet 7.0.0 est qualifiée d’œuvre dérivée, une relicence en MIT sans accord des titulaires serait juridiquement très contestable — mais tout le litige porte précisément sur cette qualification.
La jurisprudence a établi que les idées et algorithmes ne sont pas protégés en tant que tels — seule la mise en forme expressive l’est. Le test abstraction-filtration-comparaison (Computer Associates v. Altai, 2d Cir. 1992) permet d’isoler les éléments protégeables.
B. Le rôle de l’IA dans l’appréciation de la clean room
- Si Claude a été entraîné sur des données incluant le code de chardet — vraisemblable mais non démontré —, il n’existe pas de mécanisme simple permettant d’attester qu’aucune trace pertinente issue de cet entraînement n’influence la génération ;
- La barrière étanche de la clean room classique est beaucoup plus difficile à garantir et à démontrer avec un LLM entraîné sur des corpus publics qu’avec deux équipes humaines cloisonnées ;
- Blanchard reconnaît lui-même qu’il n’a pas suivi une clean room « traditionnelle ».
Simon Willison (co-créateur de Django) : « Les arguments des deux côtés sont entièrement crédibles. » Bruce Perens au Register : « L’ensemble de l’économie du développement logiciel est morte, terminée, kaput. » Zoë Kooyman (FSF) au Register : « Refuser d’accorder aux autres les droits que vous avez vous-même reçus est hautement antisocial, quelle que soit la méthode. » La FSF n’a pas publié de position formelle spécifique sur ce cas à ce stade.
IV. Cinq implications pratiques
1. La contamination de provenance
Paradoxe documenté : le MIT est devenu, dans ce contexte, moins utilisable que la LGPL. L’incertitude sur la provenance est juridiquement plus problématique que la contrainte copyleft. Une licence LGPL claire vaut mieux qu’un MIT contesté.
2. La menace systémique sur le copyleft
Si la technique est reconnue légalement valide, n’importe quel mainteneur d’un projet GPL pourrait commander à un LLM une réécriture fonctionnellement équivalente et relicencier en MIT. Ce scénario affaiblirait profondément le copyleft comme mécanisme de protection du commun numérique.
3. Le statut auteur du code généré par IA
La Cour suprême des États-Unis a refusé le 2 mars 2026 d’examiner Thaler v. Perlmutter, laissant en place l’exigence d’un auteur humain pour le copyright. Si le code produit par Claude n’est pas protégeable, qui en est propriétaire ?
4. La responsabilité des fournisseurs de LLM
L’utilisation de Claude Code comme outil principal de réécriture pose la question de la chaîne de responsabilité entre l’utilisateur du modèle et son concepteur. Aucune réponse n’est établie à ce stade.
5. L’AI Act comme outil de preuve futur
L’article 53 de l’AI Act (art. 53(1)(c) et (d)) impose aux fournisseurs de modèles GPAI une politique de conformité au droit d’auteur et un résumé public du contenu d’entraînement. Ces obligations pourraient, à terme, permettre de vérifier si un LLM a incorporé une œuvre donnée — transformant radicalement l’analyse de ces litiges.
V. Conclusion
L’affaire chardet révèle une lacune structurelle : la clean room implementation, conçue pour des développeurs humains cloisonnés, ne peut pas être directement transposée à des modèles de langage entraînés sur le patrimoine numérique commun.
Légal et légitime sont deux choses distinctes. Même si la loi venait un jour à valider la réécriture, cela ne signifierait pas que l’acte était légitime vis-à-vis des contributeurs ayant participé à un projet historiquement diffusé sous copyleft.
La vraie question : les LLM, en abaissant drastiquement le coût de réimplémentation, vont-ils modifier durablement l’équilibre entre copyleft et licences permissives — et le droit existant est-il équipé pour répondre à cette transformation ?