Código IA vacía el Open Source: ¿qué está pasando?

El código generado por IA está siendo integrado en proyectos open source sin suficiente revisión, y como la US Copyright Office consideró que el código generado exclusivamente por IA es dominio público, las licencias copyleft pierden su poder: ese código IA puede ser reutilizado sin restricción, incluso en proyectos cerrados, vaciando de valor los proyectos abiertos que durante décadas construyeron la economía del software libre.

En 30 segundos

La US Copyright Office clasificó el código generado por IA como dominio público (sin copyright)
Las licencias copyleft (GPL, MPL) no protegen código de dominio público, perdiendo su restricción
Proyectos como curl, Ghostty y Jazzband reportan explosión de PRs con código IA de baja calidad
Los modelos de IA fueron entrenados con código de repositorios GPL públicos
Los maintainers integran código IA sin revisar suficientemente las implicaciones legales

Qué es el “hollowing out” del open source

El “hollowing out” es exactamente lo que suena: el vaciamiento gradual de valor de los proyectos open source mediante la integración de código generado por IA sin las protecciones que proporciona el copyright. No es que el código IA sea malo técnicamente (bueno, tampoco que sea bueno). El tema es que destroza la economía que mantuvo vivo al open source durante treinta años.

Ponele que contribuís a un proyecto GPL. El acuerdo implícito es: vos das tu código, pero si alguien lo copia, debe darte crédito y mantener la licencia. Eso hace que el código sea valioso porque está protegido. Ahora alguien mete código IA (totalmente legítimo en términos de la plataforma, GitHub no te lo bloquea), eso se mezcla con el resto, y de repente ese código IA puede ser copiado por cualquiera, sin atribución, sin GPL, sin nada. (¿El riesgo es real? Absolutamente.)

Big tech AI se aprovechó del open source para entrenar sus modelos. Los LLMs de Anthropic, OpenAI, Google aprendieron leyendo millones de repositorios públicos, la mayoría bajo licencias restrictivas. Luego esos modelos generan código que termina de vuelta en esos mismos proyectos, pero esta vez sin deuda con la comunidad. Es un loop que cierra perfecto, excepto para los maintainers.

El problema del copyright: Por qué el código IA es dominio público

En octubre de 2023, la US Copyright Office dictaminó algo que cambió el juego: el código generado exclusivamente por IA sin intervención humana creativa no es protegible por copyright. Es dominio público.

Esto viene de un precedente más viejo. En 2016 hubo un juicio bizarro sobre una selfie de un mono (en serio). Un fotógrafo dejó una cámara al alcance de un macaco en Indonesia, el mono apretó el botón, y después discutieron si el copyright de esa foto era del mono, del fotógrafo o de nadie. La corte dijo que para copyright necesitás intención humana creativa. Un mono no la tiene. Un LLM tampoco, según ese criterio.

El argumento es débil, la verdad sea dicha.

Claude, ChatGPT y Copilot generan código complejo que requiere decenas de inputs de usuarios, refinamiento, context humano. Pero técnicamente hablando, si ejecutás un prompt y el LLM genera código sin editar, ese código es dominio público según el Office. Si vos lo editás un poco, sigue siendo cuestionable. Y acá empieza el problema real para el open source.

Cómo el código IA socava licencias copyleft

Las licencias copyleft —GPL, AGPL, MPL— tienen un mecanismo: si usás código protegido, cualquier derivado también debe estar bajo la misma licencia. Es “viral” en el buen sentido (si no te interesa el activismo, es molesto). El punto es que garantiza que el código siga siendo libre. Más contexto en ejecutar agentes de IA localmente.

Pero si el código es dominio público, copyleft no aplica. Dominio público significa: sin copyright, sin restricciones. Vos podés copiar código dominio público a un proyecto closed source y nadie puede decirte nada.

Imaginemos que curl (un proyecto GPL famoso) integra un fix de seguridad generado por IA. Ese fix es dominio público. Ahora Microsoft lo copia, lo mete en Visual Studio sin GPL. Legalmente limpio (si es que eso cuenta como limpio). Curl se queda con su fix GPL, Microsoft se queda con el fix sin obligación.

Pero acá está lo verdaderamente injusto: curl pasó años construyendo su reputación de seguridad, ese fix probablemente derivó de conocimiento comunitario, discusiones, auditorías. Y de repente Microsoft se beneficia gratis, sin GPL, sin reconocimiento. El valor se filtra hacia afuera.

Contaminación GPL: La amenaza invisible

Hay otro riesgo, quizás peor. Los LLMs fueron entrenados con código de Github que estaba bajo licencias GPL. Cuando generan código nuevo, ¿ese código derivó de la información GPL? ¿Es “contaminado” legalmente? Nadie sabe.

OpenBSD es paranoica al respecto (con razón). No usa GitHub Copilot. No integra código generado por IA sin inspección minuciosa. Porque si el código derivó accidentalmente de código GPL en el set de entrenamiento, podrías estar violando GPL sin saberlo. Tema relacionado: cómo proteger tu código abierto.

Es una bomba de tiempo que nadie quiere desactivar porque nadie está seguro de cómo hacerlo.

Casos reales: La explosión de PRs de baja calidad

Curl es el caso más documentado. Hace años, el proyecto recibía 2-3 bugs reports por semana. Gente seria, investigada, detallada. Luego llegó la IA. De repente fueron cientos de reportes por semana. Copilot generaba un análisis, lo pegaba como issue, sin pensar. Curl tuvo que cerrar su bug bounty program porque se volvió insostenible.

Ghostty, un terminal emulator joven y bien mantido, declaró públicamente: no aceptamos código generado por asistentes de programación IA. Movió a contribución por invitación solamente. Jazzband reportó “flood de AI-generated spam PRs.” En GitHub, hay una epidemia de low-quality contributions que el equipo de GitHub ya reconoció como “Eternal September”.

Tabla: Proyectos afectados y su respuesta

Proyecto	Problema reportado	Respuesta
Curl	Explosión de bugs reports automatizados (cientos/semana vs 2-3 antes)	Cerrar bug bounty program
Ghostty	PRs de código IA de baja calidad	Contribución por invitación, rechazo explícito de código IA
Jazzband	Flood de spam PRs generado por IA	Mayor revisión, políticas de no-IA
OpenBSD	Riesgo de contaminación GPL en código entrenado con GPL	No usa Copilot, inspección manual rigurosa
Linux kernel	Cuestionable integración de patches IA sin disclosure	Propuesto: exigir disclosure de origen IA

código IA open source diagrama explicativo

El rol cómplice de los maintainers

Acá viene la parte incómoda: muchos maintainers están integrando código IA porque simplemente no quieren pensar en las consecuencias.

Estás desbordado de issues, de PRs, de bugs sin arreglar. GitHub Copilot te sugiere una solución en dos segundos, se ve razonable, y la mergeás. (¿Y si después genera deuda técnica? Problema de mañana.) O alguien contribuye con un fix bonito pero generado por Claude, y vos asumís que si llegó a tu inbox, alguien ya revisó. Spoiler: nadie revisó nada.

No es mala fe. Es negligencia colectiva bajo presión. Los maintainers son voluntarios la mayoría de las veces, sin recursos, sin tiempo. Si una IA te puede ahorrar una hora de review, la tentación es enorme. El problema es que esa hora ahorrada es deuda que pagan todos después. En herramientas de IA para desarrollo profundizamos sobre esto.

Estrategias defensivas: Cómo proteger open source

¿Qué pueden hacer los maintainers? Opciones:

Política explícita de no-IA o revisión estricta: Exigir que los contribuidores declaren si usaron IA. Si la respuesta es sí, revisar línea por línea como si fuera untrusted. Ghostty hace esto.
Exigir atribución: Si tu licencia es GPL y el código derivó de GPL, lo mínimo es que quede documentado. No como para hacer cumplir (es prácticamente imposible), pero sí para mantener transparencia.
Cambios de licencia: Algunos proyectos estudian migrar a licencias que sean explícitas sobre IA o dominio público. No es trivial, pero es opción.
Educación comunitaria: Documentar públicamente los riesgos. Si los contribuidores entienden por qué importa, el problema baja de temperatura.
Herramientas de detección: Existen (en desarrollo) herramientas que analizan código y predicen si fue generado por IA. No son perfectas, pero ayudan.

Anthropic lanzó “Claude for Open Source”, un programa que da acceso gratis a Claude para maintainers. La idea es que si los maintainers usan IA transparentemente, bajo control, el riesgo baja. No resuelve el problema de fondo (dominio público sigue siendo dominio público), pero es un reconocimiento de que el sistema está roto.

Errores comunes de los maintainers

1. Asumir que “IA-generated” no significa baja calidad

Código IA puede ser técnicamente correcto y legalmente tóxico al mismo tiempo. Un fix que resuelve el bug no es suficiente si socava la licencia del proyecto. Los maintainers revisan por funcionalidad, no por implicaciones legales.

2. No documentar el origen del código

Si integrás código IA, anotá eso en el commit, en los comentarios, en algún lado. Después, cuando alguien pregunte “¿de dónde vino este fix?” tenés un registro. Sin documentación, es imposible rastrear.

3. Confundir “fast” con “good”

IA es rápida. Pero rápido no es lo opuesto de malo; es lo opuesto de lento. Los mejores proyectos open source fueron lentos, deliberados, curados. La presión por velocidad (y IA hace que parezca posible) es exactamente lo que quiebra a los proyectos a largo plazo.

Preguntas Frecuentes

¿Por qué el código generado por IA es dominio público?

Según la US Copyright Office, el copyright requiere “intención humana creativa”. Un LLM que ejecuta un prompt sin edición posterior no muestra esa intención a ojos de la ley, así que el output es dominio público. El criterio es cuestionable, pero así están las cosas hasta que alguien apele y pierda.

¿Cómo afecta esto a GPL y copyleft?

GPL obliga a compartir derivados bajo la misma licencia. Pero eso aplica a código con copyright. Código dominio público no tiene copyright, así que GPL no tiene poder sobre él. Si alguien lo copia a un proyecto cerrado, legalmente está permitido. Te puede servir nuestra cobertura de modelar amenazas de seguridad.

¿Todos los proyectos están rechazando código IA?

No. Algunos (Ghostty, OpenBSD) son muy estrictos. Otros la ignoran o la integran sin pensar. Muchos requieren disclosure: si lo usaste, decilo. El problema es que no hay estándar; cada proyecto hace su movida.

¿Podría cambiar la ley al respecto?

Posiblemente. Hay presión legislativa (especialmente en Europa) para establecer claridad sobre copyright en código IA. Si la ley dice “código IA tiene copyright”, el problema desaparece. Pero eso podría traer otros quilombos legales. Por ahora es nebuloso.

¿Puede un project protegerse cambiando de licencia?

Parcialmente. Algunas licencias nuevas incluyen cláusulas anti-IA o pro-transparencia. Pero cambiar de licencia es traumático (todos los contribuidores históricos tienen que estar de acuerdo), así que pocos proyectos lo hacen. Es más fácil una política editorial clara.

Conclusión

El “hollowing out” del open source no es un bug de la IA; es una consecuencia directa de decisiones legales y técnicas que nadie pensó a fondo. La US Copyright Office dijo “código IA = dominio público.” Los LLMs fueron entrenados con repositorios GPL públicos. Y los maintainers, bajo presión, integran código IA porque es más rápido. Es un tormenta perfecta.

Lo que te lleva a donde estamos: proyectos legendarios como curl teniendo que cerrar programas de contribución porque no dan más. Ghostty diciendo “no aceptamos código IA.” Linux kernel replanteándose políticas que existían desde hace dos décadas.

¿Cuál es la salida? Educación, transparencia, y cambio legal. Los maintainers necesitan herramientas (y dinero) para revisar código con rigor. Los legisladores necesitan aclarar si código IA tiene copyright o no. Y la comunidad necesita entender que “más rápido” no siempre es “mejor.”

El open source no se quiebra de repente. Se quiebra poco a poco, cuando dejas que el valor se filtre hacia afuera y nadie vigila quién lo lleva.