No tienen derecho a relicenciar este proyecto

• Mark Pilgrim, autor original de chardet, señaló una violación de la licencia LGPL del proyecto y exigió revertir el reciente cambio a licencia MIT en la versión 7.0.0
• Indicó que, aunque los mantenedores afirmen que fue una “reescritura completa”, sigue siendo un derivado escrito con exposición directa al código original, por lo que debe mantenerse bajo LGPL
• Varios desarrolladores debatieron si una reescritura asistida por IA realmente constituye una “implementación clean room” y si el LLM fue entrenado con el código original
• Algunos mencionaron la compatibilidad de API y la posible aplicación del fair use, pero la mayoría expresó preocupación por una posible infracción de copyright y la incertidumbre legal del código generado por IA
• Esta discusión está siendo observada como un precedente importante sobre la responsabilidad de copyright del código generado por IA, los procedimientos para cambiar licencias en proyectos open source y los límites de la autoridad de los mantenedores

---

El planteamiento de Mark Pilgrim

• Mark Pilgrim afirmó que es el autor original de chardet y que el proyecto se había distribuido bajo licencia LGPL
  • Señaló que la afirmación del mantenedor de que tenía derecho a relicenciar en la versión 7.0.0 es incorrecta
  • Subrayó que el código bajo LGPL, aunque sea modificado, debe publicarse bajo la misma licencia, y que la afirmación de una “reescritura completa” no tiene base legal
  • También indicó que “agregar un generador de código” no otorga nuevos derechos
• Pilgrim exigió que el proyecto volviera a su licencia LGPL original

Reacción inicial de la comunidad

• Un usuario preguntó si existía un fork de una versión anterior a la reescritura asistida por IA; otro compartió un enlace a la versión 6.0.0
• Algunos coincidieron en que “legalmente Mark tiene razón” y reconocieron una posible violación de la LGPL
• Otros señalaron desde una perspectiva práctica que “reescribir con IA es un trade-off inevitable”

Debate legal: API, copyright y fair use

• Un usuario citó el caso Google LLC v. Oracle America, Inc. para señalar que las API también están protegidas por copyright
  • Explicó que una reescritura motivada por compatibilidad de API podría ser ilegal si no cumple con los requisitos de fair use
• Otro usuario respondió que en el caso de Google sí se reconoció el fair use
• La discusión se amplió a la legalidad de las reescrituras compatibles con API y al estatus de copyright del código generado por IA

Debate sobre código generado por IA e implementación clean room

• Algunos señalaron que, si existe la posibilidad de que la IA haya sido entrenada con el código original, entonces no se puede considerar una implementación clean room
  • Si el LLM fue entrenado con código de chardet podría ser un factor clave en la evaluación legal
• Otros argumentaron que, si la IA generó código basándose solo en entradas y salidas, tal vez sí podría ser válido
  • Sin embargo, surgió la réplica de que, en ese caso, la licencia misma perdería sentido
• La falta de claridad sobre la responsabilidad de copyright del código de IA y la dificultad para verificar el cumplimiento de licencias surgieron como temas centrales

Compatibilidad de licencias y debate sobre GPL

• Algunos afirmaron que la licencia MIT no es compatible con GPL, pero otros citaron la documentación oficial de la FSF para explicar que MIT (Expat) sí es compatible con GPL
• Aun así, hubo amplio acuerdo en que relicenciar código LGPL como MIT sigue siendo una infracción
• Otro usuario señaló que no se puede conservar la reputación y el repositorio construidos sobre código LGPL y al mismo tiempo desechar ese compromiso

Datos de entrenamiento de IA y problema de confianza

• Varios usuarios plantearon la duda de si realmente puede creerse que Claude no fue entrenado con código LGPL
  • La imposibilidad de rastrear los datos de entrenamiento de los modelos de IA fue mencionada como un riesgo legal
• Algunos sostuvieron que, si el código generado por IA implica riesgo de plagio, debería evitarse su uso por completo
  • Se citó investigación según la cual entre 2% y 5% del código generado por IA podría ser copia de código existente

Identidad del proyecto y autoridad del mantenedor

• Algunos argumentaron que, si se eliminó todo el código de contribuyentes anteriores, la nueva versión podría ser independiente
  • Pero también hubo respuestas señalando que seguir usando el mismo nombre y reputación sería inapropiado
• También se expresó la opinión de que el copyright protege la expresión, no el nombre
• Hubo quien sostuvo que, si el mantenedor realmente eliminó todo el código previo, quizá no habría infracción legal, aunque no se presentó evidencia clara

Visión general de la comunidad

• Varios usuarios dijeron que deben respetarse las contribuciones tanto de Mark Pilgrim como de Dan Blanchard, y reconocieron la complejidad de los temas de IA, copyright y gobernanza open source
• La discusión se amplió hacia la responsabilidad legal del código generado por IA, la legitimidad de cambiar la licencia de un proyecto y los límites de la autoridad de los mantenedores en open source
• Algunos incluso propusieron hacer un fork de la v7.0.0 y devolverla a LGPL

Resumen de los puntos clave

• Legalidad del cambio LGPL → MIT: la opinión mayoritaria es que no es posible sin el consentimiento del autor original
• Estatus de copyright de la reescritura con IA: podría considerarse una obra derivada según la exposición a los datos de entrenamiento
• Condición de implementación clean room: habría que demostrar que la IA no consultó el código original
• Uso del nombre y la reputación del proyecto: redistribuir con el mismo nombre genera controversia legal y ética
• Confiabilidad del código de IA: persisten preocupaciones por riesgo de plagio y estabilidad de la cadena de suministro

Este caso está siendo visto como un ejemplo representativo de los problemas de copyright del código generado por IA y de cumplimiento de licencias open source, y podría influir en la futura estructura de responsabilidad legal de las herramientas de desarrollo con IA

[GN⁺]

Opiniones en Hacker News

• Creo que Pilgrim está entendiendo mal el concepto de copyright (clean room)
  La afirmación de una “reescritura completa” no es lo importante. Legalmente, una implementación independiente sí es posible.
  El clean room es solo un mecanismo procedimental para simplificar un litigio, no un requisito legal de no haber estado expuesto al código original.
  De hecho, Linux también conocía la estructura interna de Unix, pero se implementó de forma independiente

  • Más allá de la interpretación legal, preocupa que si la IA puede reescribir automáticamente código GPL y así esquivar la licencia, la comunidad open source perdería una de sus armas
  • También es incorrecto afirmar que una prueba de similitud estructural puede determinar si algo es una obra derivada. Y también es errado asumir que solo por haber usado Claude ya se trata de una obra derivada. El criterio legal real sigue siendo una zona gris
  • Hay que pensarlo en tres casos.
    1. Si el código es similar, hay que demostrar una reimplementación clean room
    2. Si es completamente distinto, da igual si fue clean room o no
    3. En la mayoría de los casos hay una mezcla de partes similares y no similares, así que hace falta analizar cada parte por separado. Si aunque sea una parte fue copiada, esa parte debe reescribirse
  • La funcionalidad de chardet (detección de codificación Unicode) está esencialmente fijada. Por eso es natural que una implementación nueva pase las mismas pruebas.
    La baja similitud en JPlag parece una prueba convincente de que no hubo plagio
  • Sorprende pensar que el código reescrito generado por IA esté protegido por copyright

• La afirmación de que “si conoces el codebase, cualquier reescritura también infringe copyright” no es del todo válida
  El conocimiento interno pertenece al ámbito de las patentes, no al copyright.
  Eso sí, tener el código original al lado y solo cambiar la redacción sí sería una infracción.
  Si la IA ve el código original y genera código parecido, eso probablemente se consideraría en la práctica una copia en paralelo.
  Pero si se escribe algo totalmente nuevo sin mirar el original, es posible. Aun así, como es difícil defenderlo legalmente, desde la perspectiva de una empresa debe tratarse como un riesgo

  • Hay que dejar clara la diferencia entre patentes y copyright.
    Con las patentes se puede infringir independientemente de que la invención haya sido independiente o no, pero en copyright la independencia creativa es lo central.
    Aun así, si produces el mismo resultado que una obra que ya viste, será difícil convencer a un jurado
    Al final, si hay similitud, es probable que se considere infracción bajo el criterio de preponderancia de la evidencia
  • Si lees The Godfather de Mario Puzo y luego escribes una novela con la misma estructura, se consideraría una obra derivada.
    En cambio, si no conoces en absoluto la obra original, se reconocerá como creación independiente
  • Si existe un archivo Claude.md, es muy probable que el nuevo mantenedor haya usado Claude como generador de código, y ese modelo probablemente haya sido entrenado con el código original de chardet
  • Surgió la pregunta: “¿qué tan distinto tiene que ser para que se considere código nuevo?”
  • Una reescritura es similar a una traducción. Y una traducción también infringe copyright.
    La idea en sí no está protegida, pero la expresión sí.
    Si el LLM vio el código original durante el entrenamiento, eso queda en una zona legal gris

• El punto clave es si hubo una infracción de la LGPL.
  Si el código nuevo se basó en el original, se consideraría una obra derivada y tendría que seguir bajo LGPL.
  Aunque se afirme que fue una “reescritura completa”, si hubo exposición al código original podría constituir una violación de licencia

  • Haber estado expuesto no convierte automáticamente algo en obra derivada.
    El clean room es solo un procedimiento de defensa ante litigios, y la carga de la prueba recae en el demandante.
    Linux y las herramientas GNU también conocían Unix, pero eran legales
  • Si Claude aprendió del código original, de esa interpretación sale una conclusión interesante: la IA solo podría generar derivados LGPL
  • El punto central es el copyright. Si el código nuevo es una obra derivada del original, debe seguir la LGPL; si no lo es, el nuevo titular del copyright puede elegir libremente la licencia
  • Si solo subes la versión manteniendo el mismo nombre, en la práctica podría parecer el mismo proyecto

• Vi un caso interesante durante una consultoría.
  Un ingeniero de una empresa SaaS hizo ingeniería inversa de la app de su propia compañía con Claude Code y construyó un backend compatible con la API en una semana.
  Le preguntaron: “si un competidor hace esto, ¿cómo nos protegemos?”

  • Eso es simplemente avance tecnológico.
    Si el código en sí es el núcleo del negocio, ya estás en riesgo.
    Más que preocuparse por la competencia, lo importante es hacer un mejor producto
  • Como en el caso de StrongDM Factory, ya se está volviendo real copiar servicios externos para usarlos en pruebas.
    Ya vivimos en una época en la que decir “reimplementemos Slack o Drive” ya no suena irreal
  • Si la IA reimplementó el backend viendo solo el frontend, eso sería legal.
    La API es una interfaz pública, así que no está protegida
  • Las patentes no pueden registrarse retroactivamente, y el copyright no protege ideas.
    Como en los casos de ingeniería inversa del BIOS de IBM o de DOS, una implementación independiente es legal

• El mantenedor es un fiduciario (trustee), no el propietario.
  No puede cambiar arbitrariamente la licencia del autor original.
  Si el código fue hecho completamente desde cero, debería iniciar el proyecto con otro nombre.
  Decir algo como “congelen la versión anterior” va contra el espíritu de la comunidad

• Ya en un comentario de 2021 se mencionaba que “chardet está basado en LGPL, así que no se puede relicenciar”.
  Si aun sabiéndolo lo reescribieron, fue una decisión temeraria y una falta de respeto hacia el autor original

  • Por otro lado, también hay quien opina que fue la decisión correcta para maximizar la utilidad del proyecto

• Si la IA escribió el código habiendo visto el original, entonces no es una implementación clean room.
  ¿Y si se usan dos equipos de IA, uno para hacer la especificación y otro para implementar?
  Eso seguiría el precedente de la época de IBM, pero si el modelo ya fue entrenado con el original, el problema sigue ahí

  • Si chardet está incluido en los datos de entrenamiento, entonces de cualquier forma no puede haber clean room
  • Si se extrae una especificación y otro modelo separado escribe el código a partir de ella, en teoría sí podría haber clean room.
    Pero habría que verificar que la especificación no incluya elementos expresivos
  • Si el original está en los datos de entrenamiento, la posibilidad de infracción sigue siendo alta
  • También hubo quien sostuvo que la estructura de la API es parte del copyright, aunque luego fue corregido
  • El caso IBM/Compaq solo se parece en la superficie.
    Si el original está en los datos de entrenamiento, la comparación en sí pierde sentido

• Como en la broma de “¿está bien copiar y pegar Wikipedia y cambiar unas pocas palabras?”,
  al final no se puede evadir deliberadamente el problema.
  Vivimos en una época en la que cuesta tanto confiar que hasta hay que fijar versiones de dependencias

  • Los técnicos a menudo malinterpretan el derecho como si fuera una regla técnica.
    Pero el derecho se enfoca en una evaluación integral.
    Los tribunales juzgan con el criterio de “preponderancia de la evidencia”, y cambiar unas cuantas palabras no convierte algo en una obra nueva.
    Si el original fue indispensable, es muy probable que se considere una obra derivada.
    Se predice que si el original estaba en los datos de entrenamiento, una demanda por infracción de copyright será inevitable

• Por otro lado, resulta interesante ver de nuevo a Mark Pilgrim
  En su página de Wikipedia aparece la historia de su “desaparición” de Internet.
  Sus libros de Python siguen siendo recomendables

  • Quizá pronto la cuenta de GitHub “a2mark” también aparezca mencionada en Wikipedia

• También sorprende la idea de que “si la IA fue entrenada con código GPL, entonces ¿no queda todo el código generado por IA contaminado (tainted) por GPL?”

  • Hay proyectos como ReactOS que exigen un clean room completo, pero eso es solo una garantía legal adicional, no un requisito indispensable
  • Para demostrar “contaminación”, primero habría que probar una relación de derivación real.
    En EE. UU., el procedimiento clean room es solo una estrategia para acortar litigios
  • Como el sistema de copyright originalmente fue una herramienta para proteger capital, se considera poco probable que esto se haga cumplir con tanta dureza en la práctica
  • Ya había gente advirtiendo sobre estos problemas desde el inicio del boom de los LLMs