AlpineBSD: An OS on the NetBSD Kernel Where Any AI-Written Code Is Considered "Compromised"

The debate over whether to allow AI-generated code into open source has moved from mailing-list discussions to entire operating systems. The AlpineBSD project, announced by Drew DeVault (known as sircmpwn), makes rejecting generative AI not a wish but a founding principle.

What's inside

AlpineBSD is assembled from familiar parts. The kernel, the libc standard library and low-level utilities such as mount come from NetBSD. On top of them runs a userland inspired by Alpine Linux: a base set of utilities on BusyBox, the apk package manager, and the s6 init system. Applications are taken from Alpine repositories wherever possible.

There are no ready-made installation images yet, but the system can be installed manually. The code and the ports repository are hosted on Sourcehut.

This combination is no accident. Alpine's tooling is easy to port: apk is already used by Chimera Linux, which has no GNU components but a lot from FreeBSD, and by Adélie Linux. AlpineBSD tries the same approach on a kernel from the BSD world.

What "compromised" means

The project's key wording: any software, whether source code, documentation or binaries, that contains even partly the output of a generative model is considered compromised. There is no threshold for an "acceptable share." It is enough for a fragment to have been written by an LLM.

This continues NetBSD's line. Back in 2024, the project wrote into its commit guidelines that code generated by a large language model is considered tainted. In essence, AlpineBSD inherits the upstream policy and extends it to the entire distribution.

Note the context. In July, Linus Torvalds stated that Linux is not an anti-AI project. After that, according to the source, NetBSD saw a noticeable rise in interest and donations. In other words, the "no AI" stance has become, for part of the community, a value in its own right that people are ready to support with money.

For reference: NetBSD 11.1 was recently released. The project supports 15 CPU families, 8 primary ports (amd64, i386, evbarm, evbmips, evbppc, hpcarm, sparc64 and xen) and 49 secondary ones, including alpha, hppa, m68k, sh3, sparc and vax.

Limitations and practical takeaways

The main question is how to verify this. The announcement does not describe any mechanism by which the project will distinguish human-written code from generated code. Most likely it will rely on the good faith of authors and on the provenance of dependencies. Packages from Alpine are taken "where possible," which means the line of purity will in practice be blurry: nobody guarantees that upstream programs contain no assistant-written insertions.

On top of that, the project is very young: no images, no stable release, manual installation. It is too early to use it in production.

What this means in practice:

• If you maintain open source, it is worth defining an AI-code policy in advance. Contributor requirements are already becoming a factor in the choices of users and sponsors.
• If you sell a product built on open components, check the licensing and reputational risks: part of the community considers AI code a problem.
• If you build AI coding tools, keep in mind that in some ecosystems your output will simply not be accepted. Marking code provenance could become a useful feature.

AlpineBSD is unlikely to become a mainstream OS. But as a signal it matters: "no AI" is turning into a separate niche with its own audience, and attitudes toward generated code increasingly determine where the community directs its attention and money.