Debian Voted on Whether to Ban AI From Its Codebase and 130 of 1,039 Developers Showed Up

Debian just finished a General Resolution on whether to allow generative AI in its development process. Eight proposals were on the ballot, ranging from an outright ban that would have amended the Social Contract to a hands-off "do whatever you want" stance. The vote ran from August 15 to August 28, 2026, and 130 of the project's 1,039 eligible developers cast ranked ballots using the Condorcet method.

The winner was Option 5, "Responsible Use of Generative AI," proposed by Marc Haber. It beat every other option in pairwise comparison and was the sole member of the Schwartz set. The policy neither endorses nor prohibits AI tools. Instead, it holds the contributor accountable for everything they submit, regardless of how they produced it.

What was actually on the ballot

Most coverage reduced this to "ban vs. allow." The real ballot was more interesting than that. Eight options covered the full spectrum:

• Option 1 (Matthias Geiger): Amend the Social Contract to forbid "direct contributions written with the use or assistance of large language models." This needed a three-to-one supermajority. It did not come close.
• Option 3 (Ian Jackson): Ask contributors to avoid LLMs, let maintainers ban them from their packages, and require disclosure. Also failed to beat "None of the Above."
• Option 7 (Gard Spreemann): "Debian Created by Humans." Disallow AI output as direct contributions but permit assistive use. Lost in pairwise matchups.
• Option 8 (Holger Levsen): Frame AI use as a climate issue. Encourage avoidance but acknowledge detection is impractical.
• Option 5 (Marc Haber): The winner. Regulate the person, not the tool. Quality standards apply equally; contributors must review and test everything.

Options 2, 4, and 6 occupied various middle grounds with different disclosure and licensing requirements. All lost to Option 5 in head-to-head matchups. The margin was not close: Option 5 beat the nearest competitor (Option 2, from Lucas Nussbaum) by 203 to 148.

What the policy actually requires

The full text is short enough to summarize without losing anything:

• Contributors must understand, review, test, and where appropriate modify AI-assisted output before submitting it. "Blindly accepting or uploading AI-generated material without appropriate human review" violates Debian norms.
• Confidential material, embargoed security bugs, cryptographic keys, and credentials must not be shared with third-party AI services without authorization.
• Bulk automated contributions require upfront community discussion and accountability.
• Existing licensing rules apply to AI-touched code equally.

What it does not require: disclosure. Using an LLM to draft a changelog, debug a build script, or triage a bug report does not need to be declared. Disclosure is encouraged, not mandated.

The 13% turnout problem

Here is the number nobody is talking about. Of 1,039 eligible developers, 130 voted. That is 12.5%. A policy that will shape how one of the most influential Linux distributions handles AI tooling for the foreseeable future was decided by roughly one in eight people who could have voted.

This is not unusual for Debian. General Resolutions routinely see turnout in the 10% to 20% range. But it means the result reflects the preferences of engaged voters, not the community at large. The ban proposals never had the numbers, but neither does the winning option have a ringing mandate.

One developer quit, and the insults started

Antoine Le Gonidec, a Debian developer, resigned from the project the day after the results. "I can not support the current decision of Debian about LLM use, and am no longer willing to be seen as a part of Debian under these new rules," Le Gonidec wrote.

On social media, critics called the result "Linslop," "debAIn," and "Slopian." Some mentioned switching to BSD. The It's FOSS coverage described the social media response as "livid."

On Hacker News, the discussion (158 points, 141 comments) was more measured but split along a predictable line. User bfgeek identified the enforcement gap: "Patch authors don't understand submissions, shifting burden to maintainers doing unpaid mentorship work." User jayofdoom raised the deeper question: how do you distinguish between "AI-assisted developers" and "AI agents posing as humans" when the policy does not require disclosure?

The counterargument, from users like throwaway2037, was historical: IDEs, linters, and autocomplete all faced the same objections. None of them made programmers worse. User bigstrat2003 pushed back: "I personally observe skilled programmers now saying 'I don't know, Claude did that' without questioning output."

Why it matters downstream

Debian is not just Debian. Ubuntu, Linux Mint, Pop!_OS, and dozens of other distributions pull from Debian's repositories. Corporate deployments on Debian-based systems number in the millions. When Debian sets a policy on how code enters its archive, that decision ripples through every downstream project that inherits those packages.

The pragmatic read: Debian chose enforceability over aspiration. A disclosure mandate is unenforceable (LLM detection tools are unreliable, and people will not self-report). A ban that amends the Social Contract needs a three-to-one supermajority and would still be unenforceable. The winning policy sidesteps both problems by saying: we do not care what tools you use, but if the code is broken, the bug is yours.

The risk is real, though. Without disclosure, maintainers reviewing patches cannot calibrate their scrutiny. A contributor who understands the code they are submitting looks identical to one who pasted LLM output without reading it. The policy bets that Debian's existing review culture is strong enough to catch the difference. That bet may hold for core packages with active maintainers. For the long tail of packages with a single maintainer who is also the only reviewer, it is an open question.

Your turn

If you maintain a Debian package or contribute to a Debian-based distro, has the review burden actually changed since AI tools became widespread? We are curious whether the "walls of text" problem HN commenters described matches what you are seeing in practice.

For how the open-source world is handling another kind of AI-driven flood, see our piece on OpenAI agents uploading 2,000 malicious packages to RubyGems.