QEMU define una política de "prohibido usar generadores de código con IA"

• La comunidad de QEMU actualizó recientemente su política. Se prohíbe el uso de generadores de código con IA (por ejemplo, Copilot, ChatGPT, etc.) y el envío de código producido mediante esas herramientas

define policy forbidding use of AI code generators

• Recientemente ha aumentado de forma acelerada el interés por el uso de generadores de código con IA, pero la interpretación de licencias de los resultados producidos por esas herramientas aún no es ampliamente aceptada en la industria
• Los principales proveedores sostienen que no hay problema y que se puede elegir libremente la licencia, pero existe un conflicto de interés por su parte
• Como los generadores de código con IA se crean a partir de datos de entrenamiento bajo diversas licencias, todavía no existe consenso en la industria sobre los problemas de licencia de sus resultados
• QEMU exige en el DCO (Developer Certificate of Origin) que quien contribuye tenga claramente el derecho de aportar código bajo la licencia del proyecto
  • Se menciona explícitamente que, en el caso de código hecho con generadores de código con IA, es difícil demostrar el cumplimiento de las cláusulas b/c del DCO
  • Por ello, se introdujo una política que no permite contribuciones de código al proyecto QEMU cuando el uso de generadores de código con IA sea evidente o exista sospecha clara

Flexibilidad de la política y manejo de excepciones

• El desarrollo de software asistido por IA aún está en una etapa inicial, por lo que es muy probable que las cuestiones legales se resuelvan en el futuro
• Se prevé que, a medida que las herramientas evolucionen, algunas puedan llegar a usarse de forma segura en proyectos de código abierto
• Por ahora se aplica primero una política estricta y segura, con posibilidad de flexibilizarla más adelante si hace falta
• Las solicitudes de excepción se revisarán caso por caso para decidir si se permiten

[GN⁺]

Comentarios en Hacker News

• El software de código abierto y el software libre se sienten especialmente vulnerables si el código generado por IA llega a considerarse obra infractora o se determina que pertenece al dominio público. Si llegara el momento de tener que distinguir entre ediciones hechas por IA y ediciones humanas, los proyectos podrían quedar atados durante años por problemas legales, y además no tendrían cómo costear litigios. Si en adelante el código hecho por IA es modificado por humanos o integrado en código existente, también queda la discusión de si esas ediciones humanas posteriores podrían verse como obras derivadas fuera del uso justo. Si se determina que el código generado por IA es de dominio público, los proyectos en los que solo parte del código fuente está cubierto por licencias de código abierto/software libre perderían muy rápidamente herramientas fuertes para actuar contra empresas que abusan de las licencias. Habría una carga enorme de probar incluso que el infractor usó código hecho por humanos, es decir, código con una licencia definida. En cambio, el software propietario recibiría un golpe relativamente menor en ese escenario. Porque para alegar que el código generado por IA es una cita no autorizada, al final alguien tendría que desensamblar su binario y compararlo con el código original, y ya es común que en el software propietario también haya código de dominio público mezclado
  • Creo que para la licencia MIT esto más bien sería una situación beneficiosa
  • Como desarrollador con experiencia, entiendo que mucha gente no quiera que "desarrolladores" sin conocimiento contribuyan código de IA al azar. Revisar línea por línea código hecho por IA, incluso dejando de lado los problemas legales, sería algo que consumiría personal durante años. Primero, parece que en adelante casi no habrá una forma práctica de verificar si un código fue generado con IA. Segundo, está claro que el software desarrollado 100% por humanos perderá competitividad frente a proyectos asistidos o escritos por IA. La única objeción posible sería un colapso de nivel apocalíptico en el que los humanos ya ni puedan producir semiconductores o electricidad en masa. Tercero, incluso si un proyecto lograra excluir por completo las contribuciones de código hechas con IA, (aunque no está claro cómo sería posible, incluso si solo contribuyera una minoría opuesta a la IA) al final alguien copiaría ese código, quitaría solo las partes legalmente riesgosas y migraría a un proyecto nuevo. Si la licencia permite forks, podría hacerse un fork directo, pero también podría preferirse copiar y depurar. Al código abierto todavía le queda camino, y el software del futuro crecerá explosivamente en cantidad; aunque 99% sea mediocre, también da la impresión de que habrá mucho software realmente valioso
  • Compartiendo un artículo reciente de news.artnet.com sobre la postura de la Oficina de Copyright de EE. UU. respecto al arte con IA, y el wiki del fallo del selfie del mono, se menciona que esta discusión ya entró en un camino sin retorno
  • Si un software es verdaderamente de código abierto total, en el sentido de "haz lo que quieras con este código, no nos importa", entonces no hay absolutamente nada que preocupe por causa de la IA
• Me da la impresión de que es una postura claramente más dura que la política de LLVM. Se puede ver en detalle en la política para desarrolladores de LLVM. Como desarrollador veterano, nunca querría estar en la situación de revisar código que ni el autor entiende ni yo entiendo
  • Es realmente desagradable tener que revisar algo cuando el autor ni siquiera entiende su propio código. De hecho, alguien me pide a veces que haga cierto trabajo y me transmite la explicación que recibió de una IA diciendo “según esto se hace así”, pero sinceramente sería mucho mejor que solo dijera “haz esto, por favor”. Hasta se siente insultante
  • Empecé a agregar DCO (Developer Certificate of Origin) a todos los proyectos open source que mantengo, y planeo incluir en CONTRIBUTING.md la siguiente política sobre contribuciones de código con LLM

  ---

  Política de contribuciones generadas con LLM
  La biblioteca Color es una biblioteca llena de matemáticas complejas y decisiones sutiles. Todo issue o PR debe estar redactado bajo el entendimiento profundo del propio remitente, y en particular, en el caso de PR, el desarrollador debe certificar el DCO de cada commit. Si se usó ayuda de un LLM para redactar un PR, debe indicarse explícitamente en el mensaje del commit y en el PR. Si se detecta ayuda de LLM sin evidencia declarada, el PR será rechazado. Todo contenido generado por LLM enviado sin revisión será rechazado automáticamente

  También planeo poner en SECURITY.md una LLM-Generated Security Report Policy, según la cual no aceptaré en ningún caso reportes de seguridad generados por LLM

  Desde la posición de alguien que lleva un proyecto por su cuenta, trato de mantener un equilibrio, pero personalmente no prefiero contribuciones de código con LLM
  • En proyectos personales sí uso GitHub Copilot. Pero no lo uso de otra forma que no sea como “autocompletado inteligente”. Solo acepto una sugerencia si es suficientemente parecida al código que yo iba a escribir. Gracias a eso, entiendo mi código al 100% y también evito bugs accidentales o controversias de copyright. Usar Copilot de esa manera sí acelera el desarrollo. De hecho, no porque teclee lento, sino porque muchas veces me distraigo con pensamientos sueltos o me aburro. Copilot me ayuda a pasar rápido a la siguiente fase de pensamiento o depuración.
    Me cuesta muchísimo imaginar que alguien pueda enviar un PR sin entender siquiera su propio código. Sí me molesta un poco que, por culpa de esa gente, las Policies terminen limitando incluso cuando yo uso LLM solo a nivel de autocompletado.
    Me gustaría poder encargarle a Copilot tareas de refactorización automática, pero cuando lo pruebo casi siempre rompe todo, y como tiende a regenerar bloques completos, al final me hace más lento que hacerlo a mano.
    Algo curioso es que si estoy escribiendo un bug, muchas veces Copilot completa ese bug tal cual. Incluso autocompleta errores obvios de contexto, como variables con nombres mal escritos
  • Cuando uso LLM para tareas de programación, por ejemplo le pido algo como “convierte este contenido YAML en structs y extrae los patrones repetidos a variables”. Eso también podría hacerse con una herramienta determinista, pero la IA lo deja limpio en 30 segundos, y además es fácil probar que el resultado es equivalente a la entrada
    El trabajo de alto nivel que hago jamás podría delegárselo a una IA, pero las tareas repetitivas y de poca importancia sí las está absorbiendo para acelerar el ritmo. Por ejemplo, si le paso a Claude Code un archivo CSV con resultados de benchmarks de base de datos y le pido que conecte distintos gráficos con análisis de outliers, termina rápido algo conceptualmente fácil pero que consume mucho tiempo en buscar librerías o hacer setup
  • Entiendo perfectamente la idea de no querer revisar código si el autor no entiende su propio código. Pero si una persona experimentada guía correctamente a la IA, las herramientas también pueden producir código bastante avanzado. Además, cada pocos meses parecen volverse más potentes, y muchas veces ya generan resultados solo con instrucciones en lenguaje natural
    He estado pensando qué significa realmente “entender” código. Uno de mis proyectos consiste en meter un backend de almacenamiento completamente nuevo en un sistema existente de orquestación de VM. Como no conozco el código existente y tampoco me sobra el tiempo para implementarlo yo directamente, he estado armando un clúster de pruebas y corriendo varios escenarios, así que sí tengo bien claro el panorama general desde el diseño y las pruebas
    Yo también, como mantenedor de open source, puedo imaginar lo estresante que es recibir PR de “slop” de LLM de baja calidad. Al final, el mantenedor tiene que revisar el código sí o sí, lo entienda o no el autor.
    Creo que en adelante habrá que encontrar formas de aprovechar bien estas herramientas y, al mismo tiempo, de dar señales a otros desarrolladores sobre el nivel de calidad del código que se está enviando. Algo que aprendí de bugs sutiles encontrados en el port inicial de ZFS para Linux es que las pruebas exhaustivas son tremendamente importantes, tanto como la revisión y autoría línea por línea por parte de humanos
• Se está volviendo realidad lo que predije en mi blog “yes i will judge you for using AI”. El open source tradicionalmente ha dependido mucho de señales ocultas de competencia de los contribuidores, pero los LLM hacen que incluso gente sin experiencia alguna pueda presentar código que parece hecho por alguien competente. Para quienes tienen experiencia, esto es un golpe muy confuso. De aquí en adelante, para entrar a proyectos grandes va a hacer falta cada vez más prueba social ajena al PR real, como reuniones virtuales o presenciales
  • En la empresa también estamos viendo este fenómeno. Mis colegas generan comentarios de code review con LLM y como suenan demasiado sofisticados, por un momento me engañan. Entonces termino gastando muchísimo tiempo verificando si el comentario era correcto, y en la práctica yo consumo mucha más energía que la que invirtió la persona que solo copió y pegó
  • Piden el enlace del blog
• La política parece estar firmada sobre todo por gente del entorno de RedHat. RedHat es bastante serio y orientado a empresas. Probablemente la preocupación de RedHat no sea tanto “quién puede tener copyright sobre un resultado generado por IA”, sino que termine saliendo sin querer código de otros proyectos que la IA tomó durante el entrenamiento. La mayoría de los hipervisores son closed source, y abundan las empresas litigiosas
  • Si el riesgo es que la IA “escupa” directamente código de otros proyectos desde sus datos de entrenamiento, creo que ese problema aplica en realidad a casi todo el código que genera la IA
  • Los modelos de lenguaje muchas veces tienen mayor riesgo de introducir errores lógicos sutiles, e incluso podrían atravesar los límites de seguridad del hipervisor. Quien depende mucho de ayuda de IA suele estar menos preparado para detectar ese tipo de errores, así que me parece todavía más peligroso
• Me llama la atención que quienes más firmaron esta política son personas de RedHat, empresa que fue adquirida por IBM. IBM hizo Watson y ganó Jeopardy en 2011. Me pregunto si este discurso de que el desarrollo de software con IA “apenas está empezando” es real, o si es otra escena más del clásico patrón de adquisiciones destructivas al estilo IBM.
  Dotnet Runtime está adoptando la IA de forma activa. Desde fuera quizá algunos se burlen, pero hay que notar que lo apoyan ingenieros excelentes como Stephen Toub y David Fowler.
  A las empresas les recomendaría que, cuando IBM llegue la próxima vez a venderles servicios de IA, busquen un socio realmente orientado al futuro.
  Como alguien de North Carolina, deseo que IBM y RedHat encuentren el rumbo correcto
• Me pregunto si la motivación es realmente legal. Algunos proyectos también parecen simplemente cansados de revisar código basura hecho por IA
  • QEMU es software sumamente crítico en la industria. Se usa en VM de escritorio, nube, servidores de build, sandboxes de seguridad, entornos multiplataforma y muchísimos otros lugares. Incluso un riesgo legal muy pequeño puede tener efectos graves en la industria
  • La política es clara y acotada. Parece enfatizar que no se puede asegurar de forma segura la titularidad del copyright de código generado algorítmicamente. El uso deliberado de “algorítmicamente” también llama la atención. La política actual parece ir por esa línea, y frases como “empezamos hoy con la postura más estricta y segura, y más adelante relajamos” hacen que suene razonable desde el principio. También es cierto que rechaza la llamada “gran cantidad de slop”, pero la estrategia parece arrancar por ordenar el riesgo legal y la atribución. Me parece mucho mejor que la política de curl
  • Mencionan el caso de Monsanto haciendo valer de forma obsesiva sus derechos sobre semillas como advertencia
  • Sinceramente no sé cómo la IA cambiará la calidad del código de nivel medio, pero los humanos también producen sobre todo código inútil. Si hay demasiados commits y resulta difícil gestionarlos, quizá haga falta un equipo de triage por proyecto. Creo que la mayoría de las contribuciones se hacen de buena fe.
    Entiendo a quien evita la IA por riesgo legal, pero también me pregunto si no se está exagerando. Quien crea haber reducido una posibilidad a cero probablemente todavía no lo ha pensado lo suficiente
  • Si esta tendencia sigue así, el open source podría romperse. Sacar código por copy-paste se está volviendo demasiado fácil, y toma demasiado tiempo revisarlo y rechazarlo. Parece probable que más proyectos se muevan hacia un modelo tipo Android, donde cualquiera puede descargar el código fuente, pero para externos es casi imposible contribuir de verdad
• Espero que se haga una distinción entre usar un LLM en el IDE como herramienta de autocompletado inteligente y darle instrucciones de alto nivel para que genere grandes bloques de código. Admito que hay una zona gris, pero me gustaría que al menos algo como el autocompletado de Copilot pudiera usarse sin riesgo de copyright. Por ejemplo, cuando escribes una serie de case, Copilot detecta el patrón y reduce muchísimo la cantidad de entrada manual
  • Incluso sueño con un futuro en el que la IA sea como unos lentes inteligentes, una extensión de mi pensamiento y de mi cuerpo. Así como los lentes normales corrigen la vista, unos smart glasses podrían algún día asistir incluso el pensamiento.
    Mi cerebro también ha sido entrenado con muchísimo código closed source, así que señalo que la discusión de copyright sobre IA tiene algo de NIMBY occidental. Me preocupa que, si seguimos rechazando tecnología increíble por estos “qué tal si” legales, la civilización occidental misma pueda terminar debilitándose
• Entiendo por qué aparecen estas políticas, pero creo que son un error. Me parece que el panorama legal sobre IA y copyright sigue siendo ambiguo, y casi no ha habido legislación.
  Separado de la política de prohibir contribuciones con IA, incluso haría falta delimitar con claridad “en estas partes sí se puede usar IA”. Por ejemplo, el setup de CI de QEMU no es un área central de seguridad. Para contribuciones de casos de prueba o entornos nuevos e interesantes, perfectamente podría permitirse IA bajo ciertas condiciones
  • Me pregunto qué riesgo habría en no aplicar esta política. Quizá el código salga un poco más lento, pero sería mejor, y aunque haya que sacrificar velocidad, en un proyecto tan importante como QEMU ese nivel de riesgo sí vale la pena asumirlo. No parece que los autores sean anti-GenAI en sí, sino que están siendo cautelosos ante una situación que, una vez que arranca, ya no se puede revertir
  • La solución más simple es sencillamente “esperar hasta que la situación legal se aclare”. QEMU es casi por completo GPL 2.0; si se introduce mal código de GenAI y después aparece jurisprudencia diciendo que “debe respetarse obligatoriamente la licencia del código original”, eso implicaría rollback del código afectado y una carga para todo el ecosistema downstream. Incluso si desde el principio se etiquetara una parte como “esto es IA, no reutilizar”, seguiría existiendo luego el problema de una reescritura total.
    En definitiva, “por ahora no lo aceptamos” es la opción menos compleja y menos dramática para todos
    Como material relacionado, se adjuntan enlaces a la licencia de QEMU y a la lista de licencias no libres
  • Esto no será una discusión legal de décadas; ya hay decenas de demandas relacionadas en los tribunales, así que en pocos años habrá precedentes. QEMU ha crecido muy bien durante 22 años sin IA, así que esperar unos años más no tiene absolutamente nada de malo
  • Recomiendan leer bien tanto la superficie como el trasfondo de esta política. Todas las acciones tienen riesgo legal, pero las empresas globales grandes suelen asumir incluso esos riesgos. La lectura aquí no es que QEMU sea particularmente especial, sino que en realidad simplemente no quiere usar código de LLM. La lógica sería: “consultamos a abogados → hay riesgo legal → no se puede usar”, y con eso se busca cerrar la discusión por completo. Es el mismo patrón que ocurre en las empresas
  • En la industria de la computación existe desde hace mucho la práctica de “no plagiar código”. Incluso si el fragmento es muy corto o legalmente pudiera caer bajo uso justo, la cultura ha sido no copiar el código original
• La idea de “empezar de forma estricta y segura, e ir relajando después” realmente suena razonable
  Pero me pregunto si hay alguna forma práctica de distinguir entre código generado por IA y código que un humano copió de alguna parte. En el open source cualquiera puede contribuir, y del mismo modo los humanos también pueden verse influidos por otras fuentes al escribir código
  Desde la perspectiva actual, me parece que el código generado por IA no tiene tanto una identidad independiente como que se parece más a una herramienta en manos de humanos
  • La analogía es que “el código generado por IA es como una motosierra poderosa empuñada por un humano”. Es una herramienta muy potente y, después del humano, también puede volverse peligrosa.
    Ya hasta siento que esta analogía se alargó demasiado como para seguir usándola
• Este tipo de políticas parece completamente imposible de aplicar en la práctica. Zed, Cursor y VS Code ofrecen autocompletado basado en IA, y es imposible distinguir entre el código que tecleé yo y el código sugerido por IA.
  Es como si yo dibujara un muñequito de palitos y alguien dijera: “quizá copiaste ese dibujo de palitos de otra persona, así que no tienes derecho a enviarlo”
  El objetivo real de la política es, al final, construir una justificación para poder decir “no había nada que hacer” cuando inevitablemente alguien termine enviando algo mezclado con código de IA. No creo que quienes redactaron la política ignoren que en el fondo es inútil
  • Este tipo de políticas sirven para asegurarse una excusa de evasión de responsabilidad del tipo “si se envió código sospechoso según la política, nosotros tampoco podíamos hacer nada”. En los mensajes de commit o en los parches también entra esa postura de que “los problemas de licencia de los generadores de código aún no están establecidos legalmente”.
    Además de los temas legales, claramente hay muchos otros problemas al usar código de IA
  • Neovim no fuerza IA. Solo funciona si uno lo configura manualmente. Si un editor no permite desactivar la IA, entonces me parece que ese editor tiene un problema grave en sí mismo