QGIS introduce una prohibición de contribuciones con IA: 289 puntos y 299 comentarios en HN

El proyecto QGIS, el sistema de información geográfica (SIG) de código abierto más conocido, ha sometido a debate una prohibición de las contribuciones creadas con ayuda de IA. La propuesta se presentó como pull request n.º 387 en el repositorio QGIS-Enhancement-Proposals, donde el equipo analiza los cambios importantes en las reglas y la arquitectura. A fecha de 12 de octubre de 2026, el enlace al PR había reunido en Hacker News 289 puntos y 299 comentarios. Para un tema tan especializado como los SIG, es una cifra alta.

Una salvedad importante: el material de origen solo incluye el enlace al PR y las métricas de HN, sin el texto de la política. Las formulaciones exactas (qué se considera ayuda de IA, cómo se comprueba, qué sanciones se prevén) y el estado final de la propuesta deben consultarse en el propio pull request. El titular en HN habla de una prohibición, pero el proceso de toma de decisiones en el repositorio de QEP puede incluir votación y cambios.

Por qué estas decisiones aparecen ahora

QGIS se desarrolla en GitHub, está escrito sobre todo en C++ y Python y se distribuye con licencia GPL. El proyecto depende de un número limitado de mantenedores, que revisan a mano los parches de cientos de personas. Cualquier herramienta que abarate la producción de código pero no su revisión golpea el cuello de botella: el tiempo del revisor.

Además de la carga de trabajo, hay dos problemas, uno jurídico y otro técnico. El primero es el origen del código. Los modelos se entrenaron con enormes volúmenes de repositorios, y los mantenedores no tienen forma de asegurarse de que un fragmento generado no reproduzca código ajeno con una licencia incompatible. Para un proyecto GPL, es una cuestión de pureza de licencias. El segundo es la responsabilidad. El autor de un parche debe entender qué envía y saber defender su solución en la revisión. Si no escribió el código él mismo y no lo comprende del todo, el diálogo se convierte en un reenvío de mensajes entre el revisor y un chatbot.

No es el primer proyecto con este rumbo

QGIS se suma a un grupo ya notable. Gentoo prohibió en 2024 aceptar código escrito con modelos generativos. NetBSD declaró ese mismo año que el código de LLM está potencialmente «contaminado» desde el punto de vista de las licencias y exigió aprobación previa. QEMU también rechazó en 2025 esos parches, con el argumento de los derechos de autor y del certificado de origen del desarrollador (DCO). Otros proyectos siguen un camino más suave: permiten la ayuda de IA, pero exigen declararla y hacen responsable al autor.

Qué dicen las métricas

• Objeto de la discusión: pull request n.º 387 en qgis/QGIS-Enhancement-Proposals.
• Plataforma de debate: Hacker News, 289 puntos.
• Actividad: 299 comentarios, es decir, aproximadamente uno por punto. El tema es polémico y en el hilo no hay consenso.
• Licencia del proyecto: GPL, lo que hace especialmente delicada la cuestión del origen del código.
• Fecha de publicación en el agregador: 12 de octubre de 2026.

Conclusiones prácticas para contribuyentes y equipos

Si contribuyes a QGIS o a sus plugins, lee el texto final de la política antes de enviar tu próximo parche. Averigua si la prohibición alcanza al autocompletado en el editor, la generación de tests y documentación, la traducción y la corrección de erratas, o solo al código sustancial. En este tipo de documentos el límite suele ser difuso, y los casos dudosos conviene consultarlos antes con los mantenedores.

A los mantenedores de otros proyectos de código abierto les puede servir el propio formato: la norma se ha llevado a un proceso público de propuestas, en lugar de adoptarse por decisión cerrada del equipo core. Eso reduce el número de conflictos posteriores. Los equipos que usan QGIS en su empresa y envían parches al upstream deberían fijar una regla propia sobre qué código interno creado con ayuda de IA se puede enviar al exterior. Lo más sencillo es mantener esos cambios en un fork o plugin propio.

El veredicto final llegará solo después del debate en el propio PR. Pero los 299 comentarios en HN muestran que la pregunta de si se debe admitir código de IA en proyectos abiertos hace tiempo que trascendió las discusiones en torno a un solo repositorio.