· 8 min read

Debian Just Voted on How Contributors Can Use AI. If You Maintain Any Open Source Project Alone, Steal Their Policy.

Debian just voted on how contributors can use AI. If you maintain any open source project alone, steal their policy

On August 28, 2026, Debian closed a two-week General Resolution that asked its roughly 1,045 eligible developers to pick a position on generative AI from eight competing proposals, ranging from an outright ban to open encouragement. Only 438 of the 575 ballots submitted actually got counted after the project's election team validated signatures and developer status. The winner, Proposal E, "Responsible Use of Generative AI," boils down to one paragraph: use whatever tool you want, but you own everything you submit, no exceptions and no special pass for the tool. If you maintain an npm package, a WordPress plugin, or any small library by yourself, that one paragraph is worth more to you than the entire eight-proposal fight that produced it.

What was actually on the ballot

Debian didn't debate a single yes-or-no question. Developers ranked eight full proposals against each other, plus a standing "none of the above" default option. Proposal A wanted an outright ban written into the Social Contract itself, which needed a 3:1 supermajority and didn't come close (144 votes for it against 257 preferring the default). Proposal C wanted contributors to avoid LLMs "as far as practical" and let individual maintainers enforce hard bans. Proposal G, "Debian is created by humans," would have barred AI output from direct contributions while still letting people use AI to research and think. Proposal H tied the objection to climate impact specifically. On the permissive end, Proposal D would have accepted AI contributions for Debian-specific work under a short list of conditions, and Proposal F asked contributors to prefer human authorship without requiring it.

For comparison, Gentoo has banned AI-assisted contributions outright, and NetBSD and OpenBSD have taken a similarly hard line. Linus Torvalds sits at the other end, having said in July that "Linux is not one of those anti-AI projects" and later using AI himself to track down a bug. Debian's vote landed almost exactly between those two poles, which is probably why the option that won wasn't the strictest or the loosest one on the ballot.

How Debian decided, and why it wasn't close once you look at the mechanism

Debian uses a Condorcet method (specifically Cloneproof Schwartz Sequential Dropping, spelled out in Constitution section A.5) rather than simple plurality voting. Every proposal is compared against every other proposal head to head, and the winner has to be the one option that isn't beaten by anything else once cycles are resolved. Proposal E was the only option that ended up alone in the "Schwartz set," meaning it beat every single other proposal in its direct pairwise matchup: it beat the outright ban 287 to 115, beat "allow with conditions" 203 to 148, beat the human-only proposal 251 to 139, and so on down the beat matrix. That's a more decisive result than a simple headline of "450 people voted" suggests. It didn't just get the most first-place votes, it was preferred over every single alternative when voters compared it directly.

The one paragraph that actually matters

Strip out the constitutional framing and Proposal E says this: Debian "neither endorses nor prohibits the use of generative AI tools" in packaging, documentation, or code. But every contribution, regardless of how it was produced, has to meet "the same standards of quality, correctness, maintainability, and legal compliance" as anything else. The contributor, not the tool, remains accountable. Blindly uploading AI output without review is explicitly called out as inconsistent with how the project already works. Disclosure is encouraged, not required. And large, automated, or bulk changes still need the same prior discussion and human oversight Debian already expects for mass bug filing, so a contributor can't hide behind "the agent did it at scale" any more than they could hide behind "I wrote a script to do it at scale." The resolution's own closing line makes the intent explicit: generative AI is "neither exempt from nor subject to special rules beyond the standards already expected of Debian contributors."

Why you need this before your own repo forces the question

Debian could afford an eight-proposal, two-week debate with a formal constitution behind it because Debian has 1,045 people who get a vote. You don't. If you maintain a solo project, you're the entire governance structure, and right now that structure probably has no answer at all for the AI-assisted-contribution question. Most solo maintainers I talk to haven't written anything down because nothing has forced them to yet. Then a PR shows up that's clearly LLM-generated, technically plausible, subtly wrong in three places, and the person who submitted it can't explain why it works when you ask. Or worse, it's fine on the surface and you merge it, and six months later you're the maintainer explaining what happened, the same position the XZ Utils maintainer landed in after years of being the sole gatekeeper on a project everyone assumed someone else was watching. You don't need Debian's bureaucracy to avoid that. You need their one governing sentence, adapted, in your CONTRIBUTING.md before the problem shows up in your repo instead of someone else's.

The honest take

Here's what I'd actually paste into a CONTRIBUTING.md today, adapted from Debian's language down to two sentences:

## AI-assisted contributions

You're welcome to use AI tools to help write a pull request; we don't ban them and won't ask. But the bar doesn't move: your PR is held to the same standard for correctness, tests, and licensing as anything written by hand, and if you can't explain why your code works or haven't run it yourself, don't submit it. Undisclosed AI output that breaks in review gets closed, not debugged by the maintainer.

That's the whole policy. It doesn't ban a tool you can't actually detect anyway, and it doesn't require you to become a licensing lawyer. It puts the accountability where Debian's 425 developers voted to put it: on the human who hit submit.

Where I could be wrong: a written policy with no enforcement mechanism is mostly a statement of intent, and Debian admits as much when a competing proposal on the same ballot noted that a ban "could be a challenge" to enforce and rests on trusting the community to comply in good faith. Nobody can reliably prove a PR was AI-written, so this clause won't stop a bad-faith contributor. What it does is give you, the maintainer, a citable reason to close a bad PR without an argument, and it sets the expectation before the first bad PR arrives instead of after. For a project with one maintainer and no time to debate eight proposals, that's the whole point.

Author

Sources

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts