Debian Voted to Allow AI in Its Code by 55 Votes. The Rule It Chose Is the Right One.

On 28 August, Debian finished a vote on whether its developers may use generative AI. Everywhere the headline was "Debian allows AI." The text that won says something narrower and more useful. You can use the tool, and it doesn't reduce your responsibility for a single line you send.

That's the policy I'd want at any company. The numbers also show that plenty of careful people still don't agree with it, and that part is worth a look too.

What Debian voted on

This was General Resolution 2026-002, "LLM usage in Debian." The discussion ran from 23 July to 13 August and the vote from 15 to 28 August, with 1,045 developers eligible. Eight options made the ballot, which tells you how far apart people were before a single vote.

Option 1 would have changed the Social Contract, so it needed a three-to-one majority. It didn't even get a simple majority. Option 5 won.

The text that won

Here are the two paragraphs that matter, from the resolution itself:

Debian neither endorses nor prohibits the use of generative AI tools in the development, maintenance, or documentation of software, packaging, documentation, and other media published within the Debian Project. We recognize that such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration.The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance. The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian.

It also asks contributors to say when they used AI, but doesn't require it.

Read that second paragraph twice. It never names a model, a vendor, or a year. It will still be right when the tools have changed completely, which is more than you can say for most AI policies written this year.

How close it was

Debian uses a ranked-ballot method (Condorcet, resolved with Schulze). In plain terms: you rank every option, and the winner is the one that beats each other option head to head. If nobody beats everyone, the method picks from the strongest chain of wins.

Option 5 beat every other option one on one, so it won cleanly under those rules. But the margins are the story. Against option 2, allow with conditions, it won 203 to 148. Against option 7, "Debian is created by humans," it won 251 to 139. Against "none of the above" it won 281 to 126. A 55-vote gap over the runner-up, in a project with a thousand developers, is not a landslide.

Options 2, 6, and 7 all drew real support, and option 2 came closest. A real share of Debian's developers ranked a careful or skeptical option above the winner. That's not a project at peace with the tools. It's a project that picked a rule it can enforce.

Why "responsibility doesn't transfer" is the right rule

Other projects went other ways. Gentoo banned AI use. NetBSD and OpenBSD reject AI-written code. Linus Torvalds welcomes it in the kernel and has used it to fix a bug himself.

Bans have one problem: you can't tell. A reviewer can't reliably separate a model's patch from a person's, so a ban either goes unenforced or turns into accusations. One commenter on LWN said the outcome stopped the "witch hunts" that "would have ruined Debian." That's the failure a ban invites.

Debian's rule steps around it. It doesn't ask how the patch was made. It asks whether the person sending it understands it, tested it, and will stand behind it. You can check that in review, which is where quality was always enforced anyway. I made the same point from the other side a couple of months ago: "the AI wrote it" has never survived an incident review, and now it won't survive a Debian upload either.

The honest counter

The people who ranked the no-AI options first weren't being silly, and the winning text doesn't answer all of them.

Licensing is the hard one. Debian's rules care where code came from, and "I reviewed it" doesn't tell you whether a generated function is a near-copy of something under a license that doesn't fit. The resolution asks for legal compliance but gives reviewers no way to check it.

Optional disclosure is the second gap. If I don't know a patch was generated, I can't choose to read it more slowly. Asking for disclosure is polite. Requiring it would have been useful.

And the climate option got votes for a reason. Training and running these models costs real energy, and "use responsibly" says nothing about it. The project decided that wasn't a deal breaker. Some of its members disagree, and the vote records that.

What I'd copy into a team's CONTRIBUTING.md

## AI-assisted contributions

- Any tool is fine. The bar for what you submit does not change.
- You must understand, test, and be able to explain every line you submit.
- "The model wrote it" is not a review response.
- Say in the PR if you used AI assistance. Reviewers read those differently.

Four lines, and all of them come from Debian's rule. The first makes the policy work for any tool, so you never have to update it. The second is the responsibility line. The third closes the excuse before anyone reaches for it. The fourth is where I'd go further than Debian and make disclosure a rule, because it costs the writer one sentence and saves the reviewer the guessing.

The vote page with the full count is on debian.org, and LWN's writeup has the developer discussion. If you want this argument for people who aren't packaging an operating system, it's in an earlier post.