How an LLM Ban Travelled from Ruma to AerynOS

Category: Case Study Date: January 23, 2026 Sector: Linux Distribution / Rust Libraries Sources last verified 17 October 2026

The Same Policy, Twice

In January 2026, AerynOS — an independent Linux distribution, formerly Serpent OS — adopted a policy refusing LLM-generated contributions. It was picked up by Phoronix and Linuxiac as another distro banning AI.

It is more specific than that. AerynOS's policy is Ruma's policy — a set of Rust crates for the Matrix protocol, a project with no technical relationship to a Linux distribution whatsoever. Comparing the two documents, the LLM sections run to 25 lines each and differ in exactly three places: two heading levels, and the sentence naming which project's documentation you should read instead of asking a chatbot.

Everything else — the prohibition, the four justifications, the scope, the exemptions, the section on support requests — is the same text.

The Text

"Contributions must not include content generated by large language models or other probabilistic tools like ChatGPT, Claude, and Copilot."

The stated reasons are four:

ethical concerns about the data gathering for training these models
the disproportionate use of electricity and water of building / running them
the potential negative influence of LLM-generated content on quality
potential copyright violations

The ban "applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks." Two carve-outs follow, and they are the part the news coverage left out.

What the Coverage Missed

An accessibility exemption

"An exception applies for purely translating texts for issues and comments to English. We may make more exceptions for other accessibility-related uses."

This is worth pausing on. A blanket prohibition on LLM output falls hardest on contributors who do not write English fluently and on those who use assistive tooling. Of the project policies documented on this site — Gentoo, NetBSD, QEMU, libvirt — none carries a comparable provision, and all four come from projects far larger than AerynOS.

A support-burden clause

"Support requests referencing misleading or false LLM output relating to the project may be ignored, since it is a waste of time for us to 'debug' where things went wrong based on this output before human support was sought."

This is a separate argument from the copyright and ethics case, and a more concrete one: maintainer attention is finite, and plausible-looking wrong answers consume it. The clause was published in January 2026. At the end of that same month curl shut down its bug bounty after roughly 20% of reports proved AI-generated and 20 submissions in 21 days produced no real vulnerabilities. A project with eight members and a project with curl's profile reached the same conclusion about review load within weeks of each other.

How It Travelled

The commit record makes the transmission path unusually legible.

Date	Where	Event
Aug 30, 2025	Ruma	Jonas Platte commits "Ban LLM contributions"
Sep 2, 2025	AerynOS	Jonas Platte adds the project's first `CONTRIBUTING.md`
Jan 20–23, 2026	AerynOS	NomadicCore opens PR #8 porting the LLM section, crediting Ruma; Jonas Platte approves; merged
Jan 31, 2026	AerynOS	Announced in the monthly project update

Jonas Platte is Ruma's principal contributor by a wide margin. He wrote the policy in one project, seeded the contributing guide in the other three days later, and approved the port five months after that. The policy did not spread through news coverage or advocacy. It spread because one person worked on both projects.

The pull request drew one approving review, one requested reviewer who did not respond, and three emoji reactions. There is no recorded disagreement. The commit message notes the language was inserted "whilst making an allowance that exceptions may be made, for example due to accessibility-related reasons" — the carve-out was deliberate, and it was inherited.

The Second Documented Copy

This site has covered one other case of an AI policy propagating by duplication: libvirt adopting QEMU's ban in a single day. The two cases spread by different mechanisms.

libvirt ← QEMU travelled along a technical relationship. The projects share a domain, an ecosystem and several maintainers' employer, and the copy was explicit and immediate.
AerynOS ← Ruma travelled along a personal one. A Rust Matrix library and a Linux distribution have nothing in common except a contributor.

The second mechanism is harder to see and probably more common. Policy text is short, quotable, and sitting in a public CONTRIBUTING.md; anyone who liked the version they helped write elsewhere can carry it over. Counting projects with AI bans, as most coverage does, treats each as an independent decision. Some fraction of them are the same decision, made once and re-published.

Scale, and What It Does Not Tell You

AerynOS is small. The GitHub organisation lists eight public members. The distribution is still Alpha: the January 2026 release is described by the project as "our newest Alpha ISO," shipping an Alpha installer. The current team describes itself as having had "stewardship of the project" for about a year, the distribution having been renamed from Serpent OS.

It would be easy to make the size the story — a small project issuing sweeping declarations about an industry-wide question. That reading does not survive contact with the document. The policy AerynOS adopted contains an accessibility exemption and a support-burden rationale that Gentoo's council, NetBSD's core team, the QEMU mailing list and libvirt's maintainers all omitted, over deliberations that in QEMU's case ran roughly eighteen months.

The more accurate observation is that thoroughness of policy and size of project are not the same axis, and neither is process length. AerynOS did not deliberate at length; it borrowed carefully from someone who had. The result is a better-drafted document than several produced by projects with orders of magnitude more contributors.

🧬 How an LLM Ban Travelled from Ruma to AerynOS