AlpineBSD: un SO con kernel de NetBSD donde cualquier código de IA se considera «comprometido»

El debate sobre si permitir código generado por IA en el software de código abierto ha pasado de las discusiones en listas de correo a sistemas operativos enteros. El proyecto AlpineBSD, anunciado por Drew DeVault (conocido como sircmpwn), convierte el rechazo a la IA generativa no en un deseo, sino en un principio fundamental.

Qué hay dentro

AlpineBSD se construye con piezas conocidas. El kernel, la biblioteca estándar libc y utilidades de bajo nivel como mount provienen de NetBSD. Sobre ellos funciona un entorno de usuario inspirado en Alpine Linux: un conjunto básico de utilidades en BusyBox, el gestor de paquetes apk y el sistema de inicialización s6. Las aplicaciones se toman de los repositorios de Alpine siempre que es posible.

Todavía no hay imágenes de instalación listas, pero el sistema se puede instalar manualmente. El código y el repositorio de ports están alojados en Sourcehut.

Esta combinación no es casual. Las herramientas de Alpine se portan con facilidad: apk ya lo usan Chimera Linux, que no tiene componentes de GNU pero sí mucho de FreeBSD, y Adélie Linux. AlpineBSD prueba el mismo enfoque con un kernel del mundo BSD.

Qué significa «comprometido»

La formulación clave del proyecto: cualquier software, ya sean códigos fuente, documentación o archivos binarios, que contenga, aunque sea en parte, el resultado del trabajo de un modelo generativo se considera comprometido. No hay un umbral de «proporción aceptable». Basta con que un fragmento lo haya escrito un LLM.

Es una continuación de la línea de NetBSD. Ya en 2024, el proyecto estableció en sus normas para aportar cambios que el código creado por un gran modelo de lenguaje se considera comprometido. En esencia, AlpineBSD hereda la política del upstream y la extiende a toda la distribución.

Conviene fijarse en el contexto. En julio, Linus Torvalds declaró que Linux no es un proyecto contrario a la IA. Después de eso, según la fuente, NetBSD registró un notable aumento del interés y del volumen de donaciones. Es decir, la postura de «sin IA» se ha convertido para una parte de la comunidad en un valor en sí mismo, que está dispuesta a respaldar con dinero.

Para tener una referencia: recientemente se publicó NetBSD 11.1. El proyecto es compatible con 15 familias de CPU, 8 ports primarios (amd64, i386, evbarm, evbmips, evbppc, hpcarm, sparc64 y xen) y 49 secundarios, entre ellos alpha, hppa, m68k, sh3, sparc y vax.

Limitaciones y conclusión práctica

La pregunta principal es cómo verificarlo. El anuncio no describe ningún mecanismo con el que el proyecto distinguirá el código humano del generado. Lo más probable es que se base en la buena fe de los autores y en el origen de las dependencias. Los paquetes de Alpine se toman «siempre que es posible», lo que significa que el límite de la pureza será en la práctica difuso: nadie garantiza que los programas del upstream no contengan fragmentos de asistentes.

Además, el proyecto es muy joven: sin imágenes, sin versión estable, con instalación manual. Es pronto para usarlo en producción.

Qué significa esto en la práctica:

• Si mantienes software de código abierto, conviene definir de antemano una política sobre código de IA. Los requisitos para los colaboradores ya se están convirtiendo en motivo de elección para usuarios y patrocinadores.
• Si vendes un producto basado en componentes abiertos, revisa los riesgos de licencias y de reputación: parte de la comunidad considera el código de IA un problema.
• Si creas herramientas de programación con IA, ten en cuenta que en algunos ecosistemas tus resultados simplemente no se aceptarán. Etiquetar el origen del código puede convertirse en una función útil.

Es poco probable que AlpineBSD se convierta en un sistema masivo. Pero como señal es importante: «sin IA» se está convirtiendo en un nicho propio con su audiencia, y la actitud hacia el código generado determina cada vez más adónde dirige la comunidad su atención y su dinero.