Last updated: August 16, 2026 · By Vishal Swami, Founder & Lead AI Reviewer, AISagely
Debian's General Resolution on LLM usage opened for voting on August 15, 2026, and closes August 28. Debian Developers are ranking eight competing proposals, ranging from a full ban on AI-assisted contributions to permissive rules with disclosure requirements, using the project's Condorcet ballot system.
Short answer: Debian voting on AI and LLM contributions runs August 15–28, 2026. Debian Developers rank eight proposals plus "None of the above," from Matthias Geiger's outright ban (needs a 3:1 supermajority) to Lucas Nussbaum's disclosure-based permission (simple majority). The scope covers only Debian's own packaging, docs, and infrastructure, not upstream projects.
In my testing of AI coding assistants across real commits and pull requests, I've seen exactly the failure mode Debian's stricter proposals are trying to head off: a patch that compiles and looks tidy, but that nobody, including the person who submitted it, can fully explain line by line. That's the tension driving this vote. Debian isn't asking whether AI tools work. It's asking who's accountable when one gets it wrong in a package that ends up on millions of servers.
What Debian is actually voting on
This is a General Resolution (GR), the mechanism Debian uses to settle project-wide policy questions that can't be resolved by a single team or maintainer. The discussion period began July 24, 2026, according to Phoronix’s initial coverage, and ran the required two weeks before ballots were finalized. What started as five draft proposals during discussion grew to eight formal options by the time voting opened, plus a standard "None of the above" line.
Only Debian Developers, people who've gone through Debian's formal membership process, can vote. They don't pick one option; they rank as many as they're willing to accept, and Debian's Condorcet-style counting method finds the option that would beat every other option head-to-head. One wrinkle matters here: Proposal A, because it amends the Social Contract, needs a 3:1 supermajority to win outright. Every other proposal needs only a simple majority, per the official ballot text.
This isn't Debian's first attempt at settling this. A 2025 GR on the same question was withdrawn by its own initiator before it reached a vote, and a 2024 mailing-list thread had already raised Gentoo's stricter AI-contribution policy as a reference point. In between, Debian handled AI-assisted submissions case by case, team by team. That inconsistency is a big part of why this vote is happening now.
What you'll need to follow the vote
You don't need to be a Debian Developer to understand what's at stake, just a sense of the vocabulary. A "Social Contract amendment" is Debian's highest bar for change, which is why the ban proposal needs 3:1 support instead of a plain majority. A "Git trailer" is a structured line at the bottom of a commit message, similar to the "Signed-off-by:" line Debian already requires; several proposals would add something like "Generated-By:" for AI-assisted work. And "DFSG" refers to the Debian Free Software Guidelines, the licensing bar every package already has to clear, AI-generated or not.
The eight proposals on the ballot
1. Proposal A: full ban (Matthias Geiger)
The strictest option. It would amend the Social Contract to forbid LLM-assisted source code, packaging, documentation, translations, and official communications across the project. The stated reasoning centers on Debian's stability mandate clashing with the faster, less predictable pace of AI-assisted work, plus concerns about hallucinated code, outdated methods baked into training data, copyright uncertainty, and fewer learning opportunities for new contributors. Because it changes a Foundation Document, it needs the 3:1 supermajority.
2. Proposal B: permit with conditions (Lucas Nussbaum)
From Debian's former Project Leader, this option allows AI-assisted contributions under six conditions: legal compatibility with Debian's licensing, clear attribution of any third-party code an AI tool reproduces, full contributor responsibility for quality and security, mandatory disclosure, and a "Generated-By:" trailer in the commit itself. It doesn't touch the Social Contract, so it only needs a simple majority.
3. Proposal C: minimal use (Ian Jackson)
This option asks contributors to reject LLMs "as much as practical," citing environmental cost, exploitation of the human writers whose work trained these models, and misinformation risk. Direct human communication, bug reports, mailing-list posts, would have to stay AI-free, though non-English speakers could still use AI for translation.
4. Proposal D: pragmatic guidelines
This option treats widespread AI use as already irreversible. It would accept AI-assisted contributions that comply with the DFSG and pass normal review, while barring cloud-based AI services for anything security-sensitive, where pasting private code into a third-party API is the actual risk, not the AI output itself.
5–8. The remaining four options
The rest of the ballot fills out the middle and edges: one option encourages responsible AI use without new restrictions; another discourages AI while stopping short of a ban, preferring human authorship where practical; a "humans create Debian" option would allow AI for research and exploration but bar submitting AI output directly as a contribution; and one option opposes LLM use mainly on environmental grounds, tied to the energy cost of running these models at scale.
Example prompts you can copy
If you're a contributor trying to get ahead of whatever passes, these are the kinds of checks the disclosure-based proposals (B and D especially) would effectively require:
- Explain-it-back check: "Walk through this patch line by line and explain what each change does and why. Flag anything you can't justify without re-reading the original AI output."
- Disclosure trailer: "Rewrite this commit message to add a Generated-By trailer disclosing AI assistance, formatted the same way as a Signed-off-by line."
- License risk scan: "Review this AI-generated documentation change for wording that looks copied from a specific external source rather than written fresh, so I can check it against DFSG licensing requirements before I submit it."
Common mistakes to avoid
The mistake I keep seeing in the mailing-list threads is treating this as a project-wide AI ban vote. It isn't. Every proposal, even Geiger's, is scoped to Debian's own packaging, documentation, and infrastructure. Upstream projects that Debian merely packages are out of reach here, even if those upstreams use AI internally. Second mistake: assuming "no policy yet" meant anything goes. Debian has been reviewing AI-assisted submissions case by case since the 2025 attempt fell through, and maintainers have already rejected patches on exactly these grounds. Third, don't assume a ban wins just because it's the most-discussed option. Proposal A needs 3:1 support specifically because it's a constitutional change; a plurality of first-choice votes won't be enough on its own. Fourth, if you're a Debian Developer voting, rank every option you'd find acceptable in order rather than only marking your favorite. Debian's Condorcet method is built to use that full ranking, and an incomplete ballot throws away your say in how the middle-ground options stack up against each other.
Where the eight proposals land
| Proposal | Sponsor | Core stance | Majority needed |
|---|---|---|---|
| A | Matthias Geiger | Full ban via Social Contract amendment | 3:1 supermajority |
| B | Lucas Nussbaum | Permit with disclosure, attribution, six conditions | Simple majority |
| C | Ian Jackson | Reject LLMs "as much as practical"; human-only communications | Simple majority |
| D | (project discussion) | Accept AI work meeting DFSG; ban cloud AI for sensitive code | Simple majority |
| E–H | Various | Responsible use, cautious discouragement, research-only, environmental concern | Simple majority |
| NOTA | — | None of the above | — |
Tools that make this easier
Whichever proposal wins, disclosure and verification habits are worth building now, not after a policy forces them. If you're already using an AI assistant for packaging or code review work, my best AI tool for code roundup compares the options on exactly the accountability and output-quality axes this vote is arguing about. My GitHub Copilot vs. ChatGPT and Cursor vs. Copilot comparisons cover how each tool handles suggestions you still have to review and own. If you're weighing alternatives for open-source work specifically, see ChatGPT alternatives for programmers. And before trusting any AI coding tool with real contributions, my AI tool ratings guide and AI coding assistant overview walk through what to check beyond a vendor's marketing claims.
My take
I'd bet against an outright ban clearing the 3:1 bar. Debian's own maintainers already lean on AI tools day to day, and a supermajority requirement exists precisely to stop a passionate minority from forcing a constitutional change the broader membership isn't fully behind. My read is that a disclosure-and-accountability option, something closer to Nussbaum's Proposal B or the DFSG-compliance framing in Proposal D, is better positioned once the Condorcet count works through the full rankings. But Debian's ranked voting is designed to surprise people who assume the loudest mailing-list thread reflects where the membership actually lands, so treat that as a read, not a prediction.
Frequently Asked Questions
What is Debian's General Resolution on LLM usage?
It's a formal, project-wide vote Debian Developers use to settle a policy question, in this case, whether and how AI or LLM tools can be used to write Debian packages, documentation, translations, and official communications. Voting on Debian voting on AI and LLM contributions runs from August 15 to August 28, 2026.
Will Debian ban AI-generated code entirely?
Only if Proposal A wins, and it needs a 3:1 supermajority because it amends the Social Contract. Seven other proposals offer softer approaches, from disclosure requirements to guidance without a formal ban, so an outright, project-wide ban is one possible outcome among several, not the default.
Who gets to vote on this Debian resolution?
Only Debian Developers, contributors who've completed Debian's formal membership process. They rank the options they find acceptable using Debian's Condorcet-style ballot rather than picking a single favorite.
Does this vote affect projects that Debian just packages?
No. Every proposal on the ballot is scoped to Debian's own work: its packaging, documentation, translations, infrastructure, and official communications. Upstream projects that Debian repackages are outside this resolution's reach, even if those upstream maintainers use AI tools themselves.
When will the result be known?
Voting closes August 28, 2026, at 23:59 UTC. After that, Debian's vote-counting process applies the Condorcet method to the ranked ballots to determine which proposal, if any, has enough support to pass.