La Guerra Interna del Open Source por el Código con IA: Proteger a los Voluntarios o Abrazar el Futuro

El cambio va mucho más allá de una simple precaución sobre derechos de autor. El mantenedor Bart Piotrowski reconoció que los LLMs son una herramienta inevitable, pero explicó que el detonante real fue una avalancha de desarrolladores prepotentes enviando aplicaciones de bajo esfuerzo generadas por IA, lo que generó interacciones hostiles y una carga de revisión insostenible . La decisión no se tomó para arreglar el sistema legal, sino para proteger a los mantenedores voluntarios de lo que se había convertido en una dinámica abusiva.

La política incluye una excepción muy limitada para "proyectos maduros y bien mantenidos", pero la propia documentación advierte que no es una garantía . Los envíos pueden ser rechazados en cualquier fase, o incluso retirados después de ser fusionados si se detecta que no cumplen la norma . La prohibición no es retroactiva: las aplicaciones que ya están en Flathub con código de IA se quedan, pero cualquier nuevo envío asistido por IA queda, a efectos prácticos, bloqueado .

Flathub no intentó trazar líneas grises entre usos aceptables e inaceptables de la IA. Optó por la prohibición porque la propia tarea de triaje se había vuelto un costo insostenible. La plataforma puso por delante la salud mental y la atención de sus revisores voluntarios frente a un sistema legal que aún va a remolque de la tecnología.

El giro de QEMU: probar un punto medio con transparencia

La historia de QEMU no puede ser más distinta. A mediados de 2025, este proyecto había adoptado una de las políticas más estrictas del código abierto. Sus reglas formales de procedencia del código establecían que cualquier contribución que se creyera que incluía o derivaba de contenido generado por IA —de ChatGPT, Claude, Copilot, Llama y herramientas similares— sería rechazada .

¿El motivo oficial? El código de IA no puede cumplir con el Certificado de Origen del Desarrollador (DCO) porque no existe un autor humano que pueda hacer las declaraciones requeridas .

Pero a finales de mayo de 2026, el proyecto comenzó a moverse en la dirección contraria. Paolo Bonzini, ingeniero distinguido en Red Hat y mantenedor de KVM (la tecnología de virtualización del kernel de Linux), propuso permitir parches asistidos por IA en áreas limitadas y de bajo riesgo. Específicamente, donde las ramificaciones de una posible violación de derechos de autor sean fáciles de revertir y poco probables de propagarse. El código central seguiría estando vedado sin el acuerdo previo de un mantenedor .

La lógica de Bonzini fue eminentemente práctica. Los proyectos que ya aceptan contribuciones con IA no han enfrentado, por ahora, problemas legales graves. Además, el propio equipo legal de Red Hat evaluó el riesgo como aceptable para ciertas categorías de cambios . La propuesta añade un requisito de divulgación obligatoria, pidiendo a los colaboradores que señalen explícitamente las partes generadas por IA en lugar de ocultarlas .

QEMU está apostando por un camino intermedio basado en la transparencia. Un veto total genera fricción sin un beneficio legal proporcional, sobre todo para contribuciones mecánicas como casos de prueba, arreglos en la documentación o pequeños parches.

Por qué el DCO es la línea de falla

Tanto el veto radical de Flathub como la cauta relajación de QEMU orbitan alrededor de la misma pregunta legal sin resolver: ¿qué sucede cuando el código generado por IA se encuentra con el Certificado de Origen del Desarrollador (DCO, por sus siglas en inglés)?

El DCO obliga a los colaboradores a certificar que ellos crearon la contribución o que tienen el derecho a enviarla bajo la licencia del proyecto. Pero el código de IA no tiene un autor humano identificable según la ley actual. La Oficina de Derechos de Autor de EE. UU. dictaminó en enero de 2025 que los resultados generados por IA solo pueden tener derechos de autor si un humano ha contribuido con suficientes "elementos expresivos", y que el simple hecho de darle instrucciones al modelo no cuenta . En el caso Thaler v. Perlmutter, el Tribunal de Apelaciones del Circuito de D.C. afirmó en marzo de 2025 que "la Ley de Derechos de Autor exige que toda obra elegible sea creada, en primera instancia, por un ser humano". Para marzo de 2026, el Tribunal Supremo se había negado a escuchar más apelaciones .

Esto genera una trampa legal. Un desarrollador que envía código de IA podría ser incapaz de firmar el DCO con honestidad. La respuesta del kernel de Linux, formalizada en abril de 2026 con su primera política sobre asistentes de codificación con IA, fue exigir que solo los humanos añadan las etiquetas Signed-off-by y que el humano asuma toda la responsabilidad legal por las líneas generadas por IA . Pero el veto original de QEMU razonaba que afirmar el cumplimiento del DCO con código de IA "no se considera creíble" dada la ambigüedad de las licencias .

Ningún tribunal ha zanjado de forma definitiva si el código generado por IA puede tener derechos de autor, quién los posee en ese caso o qué obligaciones de licencia conlleva. Los proyectos están haciendo sus propios cálculos de riesgo porque el sistema legal aún no les ha dado una respuesta clara.

El coste humano más allá de los derechos de autor

El debate legal es importante, pero fue el agotamiento de los mantenedores lo que realmente empujó a Flathub al límite. Mantenedores de múltiples proyectos reportan el mismo patrón: los envíos generados por IA suelen ser voluminosos pero superficiales —largas listas de cambios con poca comprensión real—, lo que produce una carga de revisión desproporcionada respecto a su valor real .

Las extensiones de GNOME Shell sufrieron una avalancha similar. A finales de 2025, los revisores informaron haber recibido más de 15.000 líneas de código de extensiones generadas por IA en un solo día, junto con respuestas también generadas por IA a sus preguntas de revisión . El mantenedor de Flathub, Piotrowski, resumió el punto de quiebre sin tapujos, afirmando que la política era necesaria porque algunos desarrolladores "simplemente no saben cómo comunicarse adecuadamente" .

El coste humano es inseparable del legal. La cuestión del DCO importa porque los mantenedores se enfrentan a una responsabilidad real por el código que aceptan. La cuestión del agotamiento importa porque son voluntarios que operan con márgenes de tiempo y buena voluntad muy ajustados. Los envíos de IA generan una tensión sobre ambos recursos al mismo tiempo.

Tres bandos, ningún consenso

Un análisis de la firma RedMonk publicado en febrero de 2026, que encuestó a 32 organizaciones de código abierto, no encontró ningún consenso emergente . Los proyectos se han dividido en tres grandes bandos:

• Veto total: Flathub, Gentoo (por voto unánime de su consejo en 2024), NetBSD (que califica el código de IA como "presuntamente contaminado") y el sistema de revisión EGO de GNOME prohíben las contribuciones con IA de forma tajante .
• Aceptación condicionada con divulgación: La propuesta de QEMU se uniría a Apache, Fedora, la Linux Foundation y la EFF, que permiten el uso de IA con etiquetado obligatorio y a discreción del mantenedor .
• Modelo permisivo con responsabilidad humana: El kernel de Linux y Red Hat permiten la IA si el desarrollador humano asume toda la responsabilidad, firma el DCO y etiqueta la herramienta usada, pero la firma Signed-off-by sigue estando reservada exclusivamente para humanos .

Estos bandos no solo discrepan en la política. Discrepan sobre si el código de IA es una herramienta que hay que gestionar o una amenaza que hay que excluir. Y sobre si el costo de gestionarlo recae en los mantenedores voluntarios o en un sistema legal que aún no está listo.

¿Qué pasará ahora?

Flathub y QEMU no son casos aislados. Son puntos de datos en un espectro que seguirá ampliándose a medida que mejoren las herramientas de codificación con IA y aumente el volumen de envíos generados. Algunos observadores señalan que detectar el código generado por IA será funcionalmente imposible en un par de años, lo que haría que las prohibiciones fueran inaplicables, sin importar su intención .

La EFF ya ha concluido que una prohibición total es poco práctica de hacer cumplir, dado lo extendido que está el uso de los LLMs . Pero la inaplicabilidad práctica no resuelve el problema del agotamiento que motivó la decisión de Flathub en primer lugar.

Hasta que las sentencias judiciales o las leyes establezcan reglas claras sobre la autoría y la responsabilidad del código generado por IA, cada proyecto de código abierto está, en esencia, jugándose su propia apuesta. Flathub eligió proteger a sus revisores ahora, a costa de cerrar la puerta a las herramientas de IA. QEMU está optando por entreabrir la puerta, con un requisito de transparencia y la apuesta de que el riesgo legal es manejable para contribuciones de bajo riesgo.

Ambos movimientos son racionales con la información disponible. Simplemente reflejan respuestas distintas a la misma pregunta inquietante: en una comunidad construida sobre la autoría humana y el trabajo voluntario, ¿qué haces cuando el código llega sin ninguna de las dos cosas?