AlpineBSD: um SO com kernel do NetBSD em que qualquer código de IA é considerado «comprometido»

A discussão sobre permitir ou não código gerado por IA no software de código aberto saiu das listas de e-mail e chegou a sistemas operacionais inteiros. O projeto AlpineBSD, anunciado por Drew DeVault (conhecido como sircmpwn), faz da rejeição à IA generativa não um desejo, mas um princípio básico.

O que há por dentro

O AlpineBSD é montado a partir de peças conhecidas. O kernel, a biblioteca padrão libc e utilitários de baixo nível, como o mount, vêm do NetBSD. Por cima deles roda um ambiente de usuário inspirado no Alpine Linux: um conjunto básico de utilitários no BusyBox, o gerenciador de pacotes apk e o sistema de inicialização s6. Os aplicativos são obtidos dos repositórios do Alpine sempre que possível.

Ainda não há imagens de instalação prontas, mas o sistema pode ser instalado manualmente. O código e o repositório de ports estão hospedados no Sourcehut.

Essa combinação não é por acaso. As ferramentas do Alpine são fáceis de portar: o apk já é usado pelo Chimera Linux, que não tem componentes do GNU, mas tem muito do FreeBSD, e pelo Adélie Linux. O AlpineBSD testa a mesma abordagem com um kernel do mundo BSD.

O que significa «comprometido»

A formulação central do projeto: qualquer software, sejam códigos-fonte, documentação ou arquivos binários, que contenha, ainda que em parte, o resultado do trabalho de um modelo generativo é considerado comprometido. Não há um limite de «proporção aceitável». Basta que um trecho tenha sido escrito por um LLM.

Isso dá continuidade à linha do NetBSD. Já em 2024, o projeto incluiu em suas regras de contribuição que o código criado por um grande modelo de linguagem é considerado comprometido. Na prática, o AlpineBSD herda a política do upstream e a estende a toda a distribuição.

Vale observar o contexto. Em julho, Linus Torvalds afirmou que o Linux não é um projeto contrário à IA. Depois disso, segundo a fonte, o NetBSD registrou um aumento notável de interesse e do volume de doações. Ou seja, a posição «sem IA» passou a ser, para parte da comunidade, um valor em si, que ela está disposta a apoiar com dinheiro.

Para referência: o NetBSD 11.1 foi lançado recentemente. O projeto oferece suporte a 15 famílias de CPU, 8 ports primários (amd64, i386, evbarm, evbmips, evbppc, hpcarm, sparc64 e xen) e 49 secundários, incluindo alpha, hppa, m68k, sh3, sparc e vax.

Limitações e conclusão prática

A principal questão é como verificar isso. O anúncio não descreve nenhum mecanismo pelo qual o projeto vai distinguir código humano de código gerado. Provavelmente, dependerá da boa-fé dos autores e da origem das dependências. Os pacotes do Alpine são obtidos «sempre que possível», o que significa que a fronteira da pureza será, na prática, difusa: ninguém garante que os programas do upstream não tenham trechos inseridos por assistentes.

Além disso, o projeto é muito novo: sem imagens, sem versão estável, com instalação manual. É cedo para usá-lo em produção.

O que isso significa na prática:

• Se você mantém software de código aberto, vale definir antecipadamente uma política sobre código de IA. Os requisitos para contribuidores já estão se tornando um critério de escolha de usuários e patrocinadores.
• Se você vende um produto baseado em componentes abertos, verifique os riscos de licenciamento e de reputação: parte da comunidade considera o código de IA um problema.
• Se você cria ferramentas de programação com IA, considere que, em alguns ecossistemas, seus resultados simplesmente não serão aceitos. Marcar a origem do código pode se tornar um recurso útil.

É improvável que o AlpineBSD se torne um sistema de massa. Mas, como sinal, é importante: o «sem IA» está virando um nicho próprio, com seu público, e a atitude em relação ao código gerado determina cada vez mais para onde a comunidade direciona sua atenção e seu dinheiro.