Debian developers began voting on August 15, 2026 on what the project will accept from large language models, and the ballot is larger than the one that went into discussion in July. Eight proposals are on it, running from a prohibition written into the Social Contract to permissive frameworks with disclosure obligations, plus one option that rejects the tooling on environmental grounds. Voting closes at the end of August 28. Only the Social Contract amendment needs a three to one supermajority; everything else needs a simple majority. Debian sits upstream of a very large amount of shipped software, so the outcome travels.
The short answer
Debian developers began voting on August 15, 2026 on the General Resolution covering large language model usage in the project, with the poll closing at the end of August 28. Eight proposals are on the ballot, from an outright prohibition written into the Social Contract to permissive frameworks built on disclosure and contributor responsibility, including one that opposes the tooling on environmental grounds. Only the Social Contract amendment requires a three to one supermajority. Counting is by Condorcet method, so pairwise results matter more than first preferences.
Most projects settle the question of generated code with a paragraph in a contributing file, written by whoever was annoyed most recently. Debian is settling it by constitutional vote, with named proposers, a fortnight of balloting and a supermajority requirement on the option that would change a foundation document. That is slower. It also produces something you can cite.
What changed since July
We covered this resolution when the discussion period opened on July 24 with four competing options. The discussion was extended from its original schedule, and by the time the ballot was issued the count had doubled.
Voting opened at the start of August 15 and closes at the end of August 28, both in coordinated universal time. Eight proposals are listed, each with a named developer behind it.
Option A, from Matthias Geiger, prohibits LLM contributions by amending the Social Contract. Option B, from Lucas Nussbaum, allows AI assisted contributions under stated conditions. Option C, from Ian Jackson, rejects LLM usage as far as practical and updates the Code of Conduct accordingly. Option D, from Pierre-Elliott Becue, accepts AI contributions for Debian specific work with compliance and disclosure expectations. Option E, from Marc Haber, sets out responsible use of generative AI. Option F, from Tobias Frost, proposes a deliberately cautious approach. Option G, from Gard Spreemann, asserts that Debian is created by humans. Option H, from Holger Levsen, opposes LLM usage on the grounds of environmental cost.
The mechanics that decide the outcome
Two procedural details will shape the result more than the text of any single proposal.
The first is the majority requirement. Option A alone needs a three to one supermajority, because amending the Social Contract means amending a foundation document and the constitution sets a higher bar for that. Options B through H need a simple majority. So a project that leans restrictive can still fail to adopt a restriction, purely because the strongest restriction was written into the document that is hardest to change. If you read the result and find something permissive at the top, check the thresholds before concluding what developers wanted.
The second is the counting method. Debian uses a Condorcet method, comparing each option against every other in pairwise contests, with a default option on every ballot that amounts to no change. Voters rank rather than pick. On a ballot this crowded that systematically favours proposals a broad range of developers find acceptable over proposals a smaller group finds ideal. It also means the headline winner tells you much less than the pairwise table underneath it.
What the options are actually arguing about
Strip the drafting and there are three genuine disagreements.
The first is provenance and licensing. Can a contributor warrant that a patch is theirs to give when a model produced part of it? Every restrictive option treats that warranty as impossible to make honestly today, and every permissive option treats it as the contributor's responsibility to assert, which is how the project already handles every other origin question.
The second is where the rule should live. A Social Contract amendment binds the project at its foundations and is difficult to revise as the technology moves. A policy or Code of Conduct change is easier to adjust and easier to ignore. That is the choice between a durable statement and a workable one, and reasonable people land on opposite sides of it.
The third is scope. Option D's distinction, between contributions to Debian specific work and code arriving from upstream, is the one with the most practical bite. Debian packages software written elsewhere. A rule that binds Debian's own contributors is enforceable. A rule that also implicated upstream would put the project in the position of auditing the provenance of the kernel and everything else it ships, which is not a policy so much as a wish.
If you maintain packages anywhere
Two things are worth doing while the vote runs, neither of which requires you to have an opinion on the outcome.
Look at what your own project currently claims. Most contribution guides say nothing about generated code, which means the answer defaults to whatever your certificate of origin already implies. Reading that document against a patch that a model helped write is a five minute exercise that usually reveals whether you have a policy or just a habit.
Then watch the pairwise results rather than the winner. However this lands, the reasoning published alongside the eight proposals is the most carefully argued material available on the question, produced by people who maintain a distribution used by Ubuntu, Linux Mint, Raspberry Pi OS and Proxmox among many others. Whatever your project eventually adopts, it will be a cheaper conversation if you start from arguments someone else already stress tested for a month.
Sources and further reading
- General Resolution: LLM usage in Debian, debian.org vote page, 2026
- Debian Developers Begin Voting Over LLM Usage Within The Project, Phoronix, August 15, 2026
- Debian's 2026 LLM Vote: Five Proposals Shape Open Source AI Policy, Linux Compatible, August 2026
- The Debian LLM Vote Is Open: Eight Ballot Options and Two Weeks to Settle It, Hardware Busters, August 2026
- General resolution: LLM usage in Debian, first call for votes, corrected ballot
Frequently asked questions
What is being voted on, and when does it close?
A General Resolution titled LLM usage in Debian, the project's second of 2026. Voting opened at the start of August 15 and closes at the end of August 28, both in coordinated universal time, giving developers two weeks. The ballot carries eight distinct proposals plus the standard default option. The discussion period that preceded it began on July 24 and was extended, which is part of why the ballot grew from four options at the start of discussion to eight at the vote.
What are the eight options?
A prohibits LLM contributions by amending the Social Contract, proposed by Matthias Geiger. B allows AI assisted contributions under conditions, from Lucas Nussbaum. C rejects LLMs as far as practical and updates the Code of Conduct, from Ian Jackson. D accepts AI contributions for Debian specific work, from Pierre-Elliott Becue. E covers responsible use of generative AI, from Marc Haber. F proposes a cautious approach, from Tobias Frost. G asserts that Debian is created by humans, from Gard Spreemann. H argues against LLM usage on climate grounds, from Holger Levsen.
Why does only one option need a supermajority?
Because of what it changes rather than what it says. Option A amends the Social Contract, which is one of Debian's foundation documents, and the constitution requires a three to one supermajority to modify those. The other seven express positions through policy, the Code of Conduct or project statements, so a simple majority carries them. That asymmetry is worth understanding before reading the result: an outcome where a majority prefers restriction can still fail if the restriction was written into the wrong document.
How does Debian actually count this?
By Condorcet method, comparing every option against every other in pairwise contests rather than counting first preferences. Voters rank options, including the default option that amounts to no change, and any proposal ranked below that default is effectively rejected. The practical consequence for a ballot this crowded is that a broadly acceptable middle option can beat a more popular but polarising one. Reading the winner without reading the pairwise results usually gives a misleading picture of what the project decided.
Why should this matter outside Debian?
Because of what sits downstream. Ubuntu, Linux Mint, Raspberry Pi OS and Proxmox all build on Debian, so a rule about contributions and packaging propagates into an enormous amount of software that other people ship. Beyond the direct inheritance, Debian's decisions on contribution norms have historically become the template other projects reach for when they face the same question. If you maintain a package anywhere, this ballot is a preview of the policy discussion arriving at your own tracker.