System76 prohíbe IA en COSMIC y reabre el debate en GNOME

El veto de System76: qué dice exactamente la nueva política

El escritorio COSMIC, la apuesta de System76 por un entorno Linux propio escrito en Rust sobre el toolkit Iced y exclusivamente Wayland, acaba de blindar sus reglas de contribución. System76 empezó a desarrollar COSMIC a finales de 2021 — un año antes del debut de ChatGPT a fines de 2022, según el registro de The Register — y la primera versión estable llegó con Pop!_OS 24.04 a finales de 2025.

La nueva plantilla de Pull Request exige a cualquier contribuidor declarar expresamente que no incluyó "ningún contenido generado por LLM (también conocido como IA) en este PR, incluyendo código, comentarios y descripciones". La regla deja una puerta entreabierta: aprender con IA, encontrar bugs con IA e incluso usar autocompletado sigue permitido. Lo que se prohíbe es entregar ese código, su documentación o los mensajes del PR ya redactados por un modelo.

La apuesta ya tiene tracción. Fedora, openSUSE, Arch Linux y NixOS ofrecen COSMIC como opción; Fedora incluso publicó una edición oficial llamada Fedora COSMIC Spin, y distros como Origami Linux y AstrOS nacieron específicamente para aprovecharlo, según recogió XDA Developers.

¿Por qué GNOME debate aceptar reportes de bugs con IA?

El contraste lo pone Michael Catanzaro, desarrollador veterano de GNOME, que acaba de publicar un post titulado "The Era of Software Quality, or the Era of Ostriches?" en el que argumenta exactamente lo opuesto: GNOME debe aceptar reportes de bugs generados por IA. La razón es de peso. Gran parte de GNOME sigue escrita en C — un lenguaje sin garantías automáticas de seguridad de memoria — y, como él mismo resume en su blog, "por mucho que lo intentemos, los desarrolladores de GNOME no lograrán escribir código seguro con lenguajes inseguros como C, C++ o Vala; es demasiado difícil incluso para desarrolladores experimentados hacerlo correctamente".

Catanzaro no es nuevo en esta pelea. Ya en junio había pedido "Please Do Not Ban AI-Assisted Issue Reports", y en julio anunció que recortaba de 90 a 30 días el plazo de divulgación de vulnerabilidades reportadas a GNOME Security, vigente desde el 1 de agosto. GNOME Calendar ya prohíbe contribuciones de modelos generativos en sus guías; GNOME Extensions, según recoge The Register, va más lejos con una regla directa: "Extensions must not be AI-generated".

La posición de Catanzaro encaja con el hecho de que Red Hat, el principal empleador de muchos maintainers de GNOME, ya integró IA en su flujo de desarrollo. The Register describe la situación como "el filo delgado de una cuña con el peso de Red Hat detrás": primero los reportes con IA; luego el triaje; luego los parches; eventualmente, el escritorio mismo.

El open source ya se fracturó: quién permite IA y quién la prohíbe

El debate de COSMIC y GNOME no ocurre en el vacío. El ecosistema ya se partió en bloques bien definidos, según el relevamiento de TechTimes:

• Veto total: GCC prohibió contribuciones derivadas de LLMs el 29 de julio de 2026, tras un fallo de la Oficina de Copyright de EE.UU. de enero de 2025 (que la Corte Suprema no revisó en marzo de 2026) según el cual el código generado por IA no tiene titular de copyright. Sin dueño, la cadena de licencias GPLv3 se rompe, y GCC decidió proteger su eslabón legal. Flathub hizo lo propio el 29 de mayo de 2026, cubriendo código, build scripts, manifests, metadata, documentación y texto de PRs. Codeberg, la alternativa europea sin fines de lucro a GitHub, votó el 22 de julio de 2026 a favor del veto (358 votos a favor, 144 en contra, alrededor del 50% de participación), con un argumento económico: el coste de almacenamiento para esa organización sin fines de lucro se disparó por el crawling indiscriminado de bots de IA.
• Veto con excepciones: GNOME Extensions prohíbe el código IA pero admite autocompletado. COSMIC sigue esa misma lógica.
• Aceptación con disclosure: el kernel de Linux permite código asistido por IA con disclosure obligatorio, según la política que Linus Torvalds explicitó en la lista de correo en julio de 2026: "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it." Debian, que acaba de cerrar una votación con ocho propuestas en juego — y cuyo ban total exigía una supermayoría 3:1 según las reglas de su Contrato Social — está definiendo su política en estos días. LLVM (licencia Apache 2.0) adoptó en enero de 2026 una política de supervisión humana, porque sus términos permisivos no descansan sobre el copyright para defenderse.

¿Por qué importa si estás construyendo sobre software open source?

Para un founder que monta su stack sobre Linux, Rust, GCC, LLVM o cualquier distro downstream de Debian, esta fragmentación ya tiene consecuencias prácticas:

• Riesgo legal distinto según la licencia. Si tu código depende de GCC, la cadena de licencias GPLv3 está ahora blindada contra derivadas de IA. Si depende de Apache 2.0 (como LLVM), el cálculo cambia. El litigio GitHub Copilot Intellectual Property Litigation, todavía abierto, podría alterar todo el panorama si finalmente se resuelve a favor de los demandantes.
• Riesgo operativo en el ruido. Torvalds documentó que el canal privado de seguridad del kernel se hizo "casi enteramente inmanejable" por reportes duplicados generados con IA. Si tu startup depende de reportar vulnerabilidades a un proyecto upstream, la cola está saturada.
• Riesgo de mantenedor. Varios proyectos mencionan explícitamente el burnout de los revisores: una IA produce parches plausibles mucho más rápido de lo que cualquier humano los verifica. El modelo se rompe cuando los maintainers son voluntarios.

¿Qué significa esto para tu startup?

La pregunta ya no es si tu equipo va a usar IA para escribir código — eso está pasando — sino bajo qué reglas upstream tu producto va a poder seguir recibiendo parches, reportando bugs y distribuyendo binarios.

Acciones concretas que puedes tomar esta semana:

• Audita qué proyectos críticos usas y dónde se posicionaron. GCC, COSMIC, Flathub, GNOME Extensions y Codeberg vetan IA. Kernel de Linux, LLVM y (probablemente) Debian la admiten con disclosure. Si tu stack pasa por el primer grupo, documenta internamente qué partes fueron escritas con ayuda de IA y conserva esa trazabilidad: si la licencia de un componente entra en revisión, vas a necesitarla.
• Define tu propia política interna de disclosure. No esperes a que tu proveedor de open source te la imponga. Decide hoy si tu equipo declara las contribuciones asistidas por IA en cada PR a tus repos privados y en cada paquete que publiques. La trazabilidad hoy es un costo operativo; mañana puede ser un requisito legal.
• Mide el costo de revisión, no solo el de generación. Si tu equipo adoptó Copilot o Claude Code, el ahorro está en escribir más rápido, pero el cuello de botella real pasó a la code review. Reserva horas explícitas de revisión y considera pairing con un segundo modelo para validar el output del primero antes de mandarlo a un maintainer upstream.

La decisión de COSMIC de cerrar la puerta y la de GNOME de abrir una rendija son el mismo síntoma: el software libre está escribiendo, en tiempo real, las reglas que tu stack va a heredar.

Fuentes

• The Register - COSMIC shuts the door on AI code as GNOME debates letting bug reports in (fuente original)
• XDA Developers - Every major Linux distro wants COSMIC, and it hasn't even finished its first year
• TechTimes - Debian Votes on Eight AI Proposals: Ballot Math Makes Outright Ban Unlikely
• TechTarget - Does AI-generated code violate open source licenses?