Pas le droit de relicencier ce projet
(github.com/chardet)- Mark Pilgrim, auteur original de
chardet, affirme que le projet enfreint la licence LGPL et demande l’annulation du récent passage à la licence MIT dans la version 7.0.0 - Il précise que, même si les mainteneurs parlent d’une « réécriture complète », il s’agit d’un travail dérivé rédigé avec exposition directe au code d’origine, et qu’il doit donc rester sous LGPL
- Plusieurs développeurs débattent de savoir si une réécriture assistée par IA constitue réellement une « clean room implementation », et si le LLM a été entraîné sur le code source d’origine
- Certains évoquent la compatibilité API et le fair use, mais la majorité s’inquiète du risque de violation du droit d’auteur et de l’incertitude juridique autour de la génération de code par IA
- Cette discussion est considérée comme un précédent important concernant la responsabilité liée au copyright du code généré par IA, les procédures de changement de licence dans l’open source et les limites de l’autorité des mainteneurs
Contestation soulevée par Mark Pilgrim
- Mark Pilgrim indique être l’auteur original de
chardetet rappelle que le projet a été distribué sous licence LGPL- Il souligne que l’affirmation des mainteneurs selon laquelle ils auraient, dans la version 7.0.0, « le droit de relicencier », est erronée
- Même modifié, le code sous LGPL doit être publié sous la même licence, et l’argument de la « réécriture complète » est, selon lui, sans fondement juridique
- Il précise que « l’ajout d’un générateur de code » ne confère aucun nouveau droit
- Pilgrim demande que le projet soit rétabli sous sa licence LGPL d’origine
Premières réactions de la communauté
- Un utilisateur demande s’il existe un fork d’une version antérieure à la réécriture assistée par IA ; un autre partage un lien vers la version 6.0.0
- Certains estiment que « juridiquement, Mark a raison » et reconnaissent un risque de violation de la LGPL
- D’autres évoquent une vision pragmatique, considérant qu’une « réécriture via l’IA est un compromis inévitable »
Débat juridique : API, droit d’auteur, fair use
- Un utilisateur cite l’affaire Google LLC v. Oracle America, Inc. pour rappeler que les API peuvent aussi relever de la protection du droit d’auteur
- Il explique qu’une réécriture motivée par la compatibilité API peut être illégale si elle ne satisfait pas aux conditions du fair use
- Un autre répond que, dans le cas de Google, le fair use a justement été reconnu
- Le débat s’élargit alors à la légalité des réécritures compatibles API et au statut en droit d’auteur du code généré par IA
Génération de code par IA et controverse sur la clean room implementation
- Certains soulignent que si l’IA a pu apprendre à partir du code source d’origine, on ne peut plus parler de clean room implementation
- La question de savoir si le LLM a été entraîné sur le code de
chardetpourrait devenir centrale dans l’appréciation juridique
- La question de savoir si le LLM a été entraîné sur le code de
- D’autres avancent qu’une telle approche pourrait être recevable si l’IA n’a généré le code qu’à partir des entrées et sorties
- Mais cette idée suscite une objection : dans ce cas, la licence elle-même perdrait tout son sens
- Le flou sur la responsabilité en matière de copyright du code IA et la difficulté de vérifier la conformité aux licences émergent comme points majeurs
Compatibilité des licences et débat autour de la GPL
- Certains affirment que la licence MIT n’est pas compatible avec la GPL, mais un autre utilisateur cite la documentation officielle de la FSF pour expliquer que la MIT (Expat) est compatible GPL
- En revanche, beaucoup s’accordent sur le fait que relicencier du code LGPL en MIT reste une violation
- Un autre utilisateur souligne qu’on ne peut pas conserver la notoriété et le dépôt construits sur du code LGPL tout en abandonnant les obligations associées
Données d’entraînement de l’IA et problème de confiance
- Plusieurs utilisateurs demandent s’il est crédible de croire que Claude n’a pas été entraîné sur du code LGPL
- L’impossibilité de retracer précisément les données d’entraînement des modèles d’IA est citée comme risque juridique
- Certains estiment que si le code IA comporte un risque de plagiat, il faudrait éviter de l’utiliser
- Une statistique issue d’une étude est mentionnée : 2 à 5 % du code généré par IA pourraient être des copies de code existant
Identité du projet et autorité des mainteneurs
- Certains avancent que si tout le code des anciens contributeurs a réellement été supprimé, la nouvelle version pourrait être indépendante
- Mais d’autres répondent que conserver le même nom et la même réputation reste problématique
- L’idée est aussi avancée que le droit d’auteur protège l’expression, pas le nom
- Quelques intervenants considèrent qu’il pourrait ne pas y avoir de violation juridique si le mainteneur a effectivement retiré tout le code préexistant, mais aucune preuve claire n’est apportée
Vision d’ensemble de la communauté
- Plusieurs utilisateurs disent respecter les contributions de Mark Pilgrim comme de Dan Blanchard, tout en soulignant la complexité des enjeux liés à l’IA, au droit d’auteur et à la gouvernance open source
- La discussion s’étend à la responsabilité juridique du code généré par IA, à la légitimité des changements de licence de projet et aux limites du pouvoir des mainteneurs open source
- Certains proposent aussi de forker la v7.0.0 pour la remettre sous LGPL
Résumé des points clés
- Légalité du passage de LGPL à MIT : pour beaucoup, impossible sans l’accord de l’auteur original
- Statut en droit d’auteur d’une réécriture par IA : elle pourrait être considérée comme dérivée selon son exposition aux données d’entraînement
- Caractère clean room ou non : il faudrait démontrer que l’IA n’a pas référencé le code source original
- Usage du nom et de la réputation du projet : une redistribution sous le même nom soulève des controverses juridiques et éthiques
- Fiabilité du code IA : inquiétudes autour du risque de plagiat et de la stabilité de la supply chain
Cette affaire apparaît comme un cas emblématique autour du copyright du code généré par IA et du respect des licences open source, avec un possible impact futur sur la structure de responsabilité juridique des outils de développement IA.
1 commentaires
Avis sur Hacker News
Certains estiment que Pilgrim comprend mal la notion de clean room en droit d’auteur
L’affirmation d’une « réécriture complète » n’est pas déterminante. Juridiquement, une implémentation indépendante peut exister.
Le clean room n’est qu’un mécanisme procédural destiné à simplifier un litige, pas une exigence légale imposant de n’avoir jamais été exposé au code source.
En pratique, Linux connaissait aussi la structure interne d’Unix tout en ayant été implémenté indépendamment
La faible similarité relevée par JPlag semble constituer une preuve convaincante de l’absence de plagiat
L’affirmation selon laquelle « si l’on connaît la base de code, toute réécriture constitue aussi une violation du droit d’auteur » n’est pas totalement valable
La connaissance interne relève du domaine des brevets, pas du droit d’auteur.
En revanche, garder le code original sous les yeux et en modifier simplement la formulation constitue bien une violation.
Si une IA regarde le code source et génère un code similaire, cela pourra très probablement être considéré comme une copie parallèle.
Mais si le nouveau code est écrit entièrement de zéro sans consulter l’original, c’est possible. Cela reste toutefois difficile à défendre juridiquement, donc une entreprise doit y voir un facteur de risque
Un brevet peut être enfreint même en cas d’invention indépendante, alors qu’en droit d’auteur, l’indépendance de la création est centrale.
Cela dit, si l’on produit un résultat identique à une œuvre déjà vue, il sera difficile de convaincre un jury
En fin de compte, s’il y a similarité, il est probable qu’une violation soit retenue selon le critère de la prépondérance des preuves
À l’inverse, si l’on ne connaît absolument pas l’œuvre originale, cela sera reconnu comme une création indépendante
Les idées en elles-mêmes ne sont pas protégées, mais leur expression l’est.
Si un LLM a vu le code original pendant son entraînement, on est dans une zone grise juridique
Le point clé est de savoir s’il y a violation de la LGPL.
Si le nouveau code est fondé sur l’original, il doit être considéré comme une œuvre dérivée et rester sous LGPL.
Même en invoquant une « réécriture complète », une exposition au code original peut constituer une violation de licence
Le clean room n’est qu’une procédure de défense en cas de litige, et la charge de la preuve incombe au demandeur.
Linux comme les outils GNU connaissaient Unix, tout en restant légaux
Un cas intéressant est apparu en mission de conseil
Un ingénieur d’une entreprise SaaS a rétroconçu l’application de sa propre société avec Claude Code et créé en une semaine un backend compatible API.
La question posée était : « si un concurrent fait la même chose, comment se protéger ? »
Si le code lui-même est au cœur du business, le risque existe déjà.
Mieux vaut construire un meilleur produit que s’inquiéter de la concurrence
Nous vivons désormais à une époque où dire « réimplémentons Slack ou Drive » n’est plus irréaliste
Une API est une interface publique, donc elle n’est pas protégée
Comme dans les cas historiques de reverse engineering du BIOS d’IBM ou de DOS, une implémentation indépendante est légale
Un mainteneur est un fiduciaire (trustee), pas un propriétaire.
Il ne devrait pas changer arbitrairement la licence choisie par l’auteur original.
Si le code est entièrement nouveau, il faut lancer un projet sous un autre nom.
Dire en substance « fixez simplement l’ancienne version » va à l’encontre de l’esprit communautaire
Un commentaire de 2021 indiquait déjà que « chardet est sous LGPL et ne peut donc pas être relicencié ».
Si la réécriture a été faite en le sachant, c’était une décision imprudente et un manque de respect envers l’auteur original
Si l’IA a écrit le code après avoir vu l’original, ce n’est pas une implémentation en clean room.
Si l’on mettait en place deux équipes d’IA, l’une pour produire une spécification et l’autre pour implémenter, cela serait-il acceptable ?
Cela reprend le précédent de l’époque IBM, mais si le modèle a déjà été entraîné sur l’original, le problème demeure
Il faut néanmoins vérifier que la spécification n’inclut pas d’éléments d’expression
Lorsque l’original figure dans les données d’entraînement, la comparaison elle-même perd son sens
Comme dans la plaisanterie « si je copie-colle Wikipédia et que je ne change que quelques mots, est-ce acceptable ? »,
en fin de compte, l’évitement intentionnel ne fonctionne pas.
Nous sommes à une époque où il devient difficile de faire confiance au point de devoir figer les versions des dépendances
Mais le droit privilégie une appréciation d’ensemble.
Les tribunaux raisonnent selon la prépondérance des preuves, et remplacer simplement quelques mots ne crée pas une nouvelle œuvre.
Si l’original était indispensable, il est probable qu’il soit qualifié d’œuvre dérivée.
Si l’original se trouve dans les données d’entraînement, certains prédisent qu’un contentieux pour violation du droit d’auteur deviendra inévitable
Par ailleurs, le retour de Mark Pilgrim intrigue
Sa page Wikipédia mentionne son épisode de « disparition d’Internet ».
Ses livres sur Python restent recommandables
Certains s’étonnent : « si une IA a été entraînée sur du code GPL, tout le code généré par IA n’est-il pas contaminé GPL (taint) ? »
Aux États-Unis, la procédure de clean room n’est qu’une stratégie pour écourter un litige