Debian has put four competing rules for AI-assisted contributions on a single ballot, and they run the whole distance from an outright ban to a permissive disclosure regime. The discussion period opened on July 24, 2026 under General Resolution vote_002. Whatever wins becomes the first binding LLM policy at a distribution that Ubuntu, Raspberry Pi OS, Tails and several thousand other downstream projects inherit from.
That inheritance is the reason this vote matters outside Debian's own mailing lists. Most open-source projects have handled generative AI with a README note or a maintainer's personal preference. Debian is holding a constitutional vote with legal reasoning attached, and the result will be the most concrete precedent anyone can point to.
RelatedDebian 13.6 Ships a Fix for the Expired Secure Boot CA
What is actually on the ballot?
Four proposals cleared the seconding threshold, each sponsored by a well-known developer.
Proposal A, from Matthias Geiger with 8 seconders, is the hard stop. Its operative sentence: "We will not allow direct contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools." It covers packaging, native Debian software, documentation, translations and web resources. The rationale cites copyright uncertainty, output quality, community impact, and ethical objections to how the models were trained.
Proposal B, from Lucas Nussbaum with 9 seconders, is the permissive end. It asks contributors to verify that an AI tool's terms do not conflict with free software licensing, to confirm the legal compatibility of any copyrighted material in the output, to disclose significant AI assistance in commits or discussion, to raise bulk or automated contributions before submitting them, and to avoid tools that transmit sensitive project data.
Proposal C, from Ian Jackson with 8 seconders, reads as a middle path and functions as something stricter. It requests that contributors avoid LLMs, mandates disclosure when they are used, respects individual maintainer bans, and treats violations as Code of Conduct infractions. It also carries the sharpest single clause in the entire resolution, which we come back to below.
Proposal D, from Pierre-Elliott Bécue with 6 seconders, is the pragmatic allowance. AI-assisted work must comply with the Debian Free Software Guidelines, contributors remain solely responsible for what they submit, AI assistance gets marked in commit messages or changelogs, cloud-based AI is prohibited when handling sensitive or embargoed data, and the whole thing applies only to Debian-specific work rather than to upstream projects.
| A · Geiger | C · Jackson | D · Bécue | B · Nussbaum | |
|---|---|---|---|---|
| Stance | Absolute ban | Discourage | Allow with rules | Permissive |
| Seconders | 8 | 8 | 6 | 9 |
| Disclosure | Not applicable | Mandatory | Commit or changelog | Required if significant |
| Messages to humans | Banned with the rest | Humans only, explicitly | Allowed | Allowed |
| Enforcement | Good faith | Code of Conduct | Contributor liability | Guidelines |
| Scope | All Debian work | All Debian work | Debian-specific only | All Debian work |
Why does a packaging project care this much?
Because Debian's actual product is a legal artifact, not just a pile of software. The distribution ships only what it is confident it can redistribute, and the Debian Free Software Guidelines are the test every package passes before it enters the archive. A patch whose provenance is unclear is not a matter of taste. It is a licensing defect that propagates to every downstream rebuild.
That is what makes Proposal B's first requirement the load-bearing one. Asking a contributor to verify that a tool's terms of service do not conflict with free software licensing sounds like paperwork, but it is the only clause in any of the four that engages directly with the question Debian actually has to answer: can this code be redistributed under the licence the package claims?
What separates Proposal C from a ban?
Less than the summary suggests. Proposal C asks contributors to avoid LLMs rather than forbidding them, which sounds softer than A. Then it adds Code of Conduct enforcement, which is the strongest lever Debian has short of expulsion, and it includes this: messages to humans must be drafted solely by humans without LLM assistance.
RelatedApple Ships iOS 27 Public Beta With Agentic Siri AI
That clause is doing something the other three do not. A, B and D all regulate artifacts, meaning code, packages, docs and translations. C regulates conversation. Under it, a maintainer who runs a bug-report reply through a model to tidy the grammar has committed a Code of Conduct violation, even if the technical content is entirely their own. Whether that is principled or unenforceable is the argument the discussion period exists to have.
Who does this actually bind?
Only Proposal D draws the boundary explicitly, limiting itself to Debian-specific work and leaving upstream projects alone. The distinction is practical. A Debian maintainer packaging someone else's library has no control over how that library was written, and a policy that pretended otherwise would make most of the archive unpackageable overnight.
The other three are silent on the point, which is likely to become the first interpretive fight after the vote closes. If Proposal A passes as written, a maintainer whose upstream openly uses AI assistance is in an ambiguous position, and nothing in the text resolves it.
- Jul 24, 2026Discussion period opens four proposals seconded, amendments still possible
- Discussion closeBallot text frozen Project Secretary calls the vote once debate settles
- Voting periodDevelopers rank the options Condorcet, with Further Discussion as a live outcome
- After the resultPolicy takes effect downstreams decide whether to mirror it
- Further Discussion is a real contender. Debian ballots include it, and on a question this contested a plurality that cannot agree on which rule to adopt often defaults to adopting none.
- Watch the seconder overlap. Matthias Geiger seconded Ian Jackson's Proposal C despite authoring the outright ban, which suggests the restrictive camp is coordinating on rankings rather than splitting.
- The upstream boundary gets litigated first. Whichever option wins, the initial disputes will be about packaged software Debian did not write.
- Downstreams will not move immediately. Ubuntu and the rest inherit packages, not governance, so expect months before anyone mirrors the policy.
Our take
The interesting thing about this ballot is that it is not really split between people who like AI tools and people who do not. It is split between people who think the problem is legal and people who think the problem is social. Proposals B and D treat it as a provenance question that disclosure and licence checks can manage. Proposals A and C treat it as a question about what kind of project Debian wants to be, which no amount of commit-message tagging resolves.
Our read is that D is the most likely to survive contact with reality, because it is the only one that admits Debian does not control its upstreams. But C has the momentum of the people who care most, and in a Condorcet vote intensity of preference shows up in the rankings. A result of Further Discussion would not surprise us at all, and it would leave the largest community distribution with no policy at exactly the moment every downstream is asking for one.
- GovernanceDebian General Resolution: LLM Usage in Debian full proposal texts, proposers and seconders
- ReferenceDebian Free Software Guidelines the redistribution test Proposal D invokes
- ReferenceDebian Constitution how General Resolutions and Condorcet voting work
Original analysis by GenZTech, based on the General Resolution text published by the Debian Project. Source: debian.org/vote/2026/vote_002