Debian developers are casting ballots on whether large language models have any place in one of the oldest and most widely deployed free software projects. The general resolution went to a vote on August 15 and closes on August 28, with a ballot that stretches to nine choices — a spread that says as much about the project's internal disagreement as any single proposal does.
The strictest option, attributed to Matthias Geiger, would write the prohibition into Debian's social contract. Its argument leans on the distribution's reputation for stability, framing widespread LLM use as an import from a move-fast-and-break-things culture that the proposal calls inappropriate for Debian contributors. Under it, the project would not accept direct contributions written with the assistance of LLMs or other generative tools.
Seven Ways to Disagree
The counterproposals map the middle ground in considerable detail. They include permitting AI-assisted contributions under conditions; rejecting LLMs as far as practical while updating the code of conduct; accepting AI contributions specifically for Debian-native work; publishing responsible-use guidelines; a cautious-approach option; a statement built on the pledge that Debian is created by humans; and a final entry arguing the case on environmental grounds, on the reasoning that the planet is burning. A ninth slot covers none of the above.
Only Debian Developers may vote, using the project's ranked ballot to order their preferences. The procedural detail that matters most: the outright ban requires a 3:1 supermajority because it amends the social contract, while the remaining proposals clear on a simple majority.
What a Ban Would and Would Not Cover
Should the prohibition pass, it would reach Debian source packages and Debian-developed software, official web resources, direct contributions such as packaging, native tooling like the lintian package checker, and documentation and translations written by contributors.
It would stop well short of a blanket rule. Upstream projects that use generative AI would remain fair game, and patches or security fixes arriving from upstream would not be rejected on those grounds. Maintainers could keep packaging third-party AI-written tools — they simply could not use those tools for new work of their own.
The Critique From Outside
Observers watching the debate are largely unconvinced that a prohibition addresses the underlying issue. Joe Phillips, author of the Hybrid Workforce Standard, told The New Stack that the project already agrees provenance must be declared, and that a nine-way ballot is therefore an argument over how large the disclosure label should be rather than a fight over principle. He points to the deskilling argument buried in the community section — that contributors who lean on a model never learn packaging, and so can never replace the maintainer who burns out — as the one harm that compounds. His prescribed fix is apprenticeship rather than prohibition: shadow mode for newcomers, junior-level review, earned authority.
Justin Beals, CEO of Strike Graph, reads the proposal as an admission that no one has built a reliable way to verify what an AI agent produced before it lands in a codebase this many systems depend on. He argues a ban treats the symptom while leaving the trust model untouched.
Matt Brown, principal AI architect at Endor Labs, raises the enforcement problem directly, noting that banning AI-assisted code does not eliminate it so much as make its use harder to disclose. Nothing stops a contributor from retyping generated output by hand.
Debian's answer, whichever way it lands, will be the most consequential position any major distribution has taken on the question.
