Debian opened a general resolution on 24 July on whether its developers may use large language models. Four proposals are on the ballot, running from a ban written into the Social Contract to a permissive framework with disclosure rules. The vote page still reads "In Discussion" — nothing has been decided.

Read all four and the striking thing is not the disagreement. It is what they agree on.

Every option says the technology is a problem

Proposal A, from Matthias Geiger, would forbid LLM-assisted contributions to Debian itself — though expressly not upstream projects, AI-related software, or upstream patches and security fixes — arguing that "widespread LLM usage comes from the 'move fast, and break things' attitude that, while common in many parts of this industry, is contrary to what makes Debian Debian."

Proposal C, from Ian Jackson, is blunter still, listing "undermining the mechanisms of free software community building; environmental damage; exploitation of authors; disruption to open web hosting by aggressive scraping; generation and promulgation of bullshit; polluting the information commons" among the problems, and concluding that "ethical and safe use of this technology is almost impossible."

Proposal D, from Pierre-Elliott Bécue, is one of the two permissive options — and it opens: "Debian as a project does not endorse or recommend the use of generative AI assistants for software development, as it raises multiple concerns about ethics, legality, copyright, etc."

Even Proposal B, the most accommodating of the four, from Lucas Nussbaum, opens by conceding the case against. The project "recognizes that AI-assisted contributions raise many concerns, e.g. about the technical quality and maintainability of such contributions, and their legal status." It then goes further, about the technology rather than the contributions: "AI itself also raises additional concerns, about its impact on society at large, on the IT industry and on Free Software; about its environmental impact; and the aggressive or non-compliant practices of AI scrapers." B does not stop there, and in fairness to it the next sentence is the case for: "Nevertheless, many Debian contributors find AI tools helpful when contributing to Debian, and ultimately for improving Debian."

There is no option on this ballot that treats the technology as unproblematic. Every one concedes it raises real concerns — including the option titled "Allow AI-Assisted Contributions". What they disagree about is whether a rule can do anything about it.

The actual fault line is enforceability

Proposal A meets the objection head-on and answers it with trust:

Other projects exploring similar decisions have elicited a common reply: "How will you enforce a ban on LLM contributions?" While enforcement could be a challenge, this is a statement of intent by the Debian community, and we trust this community to adhere to it in good faith.

Proposal C concedes more ground. Jackson writes that ideally "LLM output should not form any part of software that we rely on" — but that because "some of the wider software world, including many of our upstreams," takes a different view, "a complete ban on LLM output as part of Debian is currently impractical." His text therefore frames most of its clauses as requests rather than prohibitions, reserving hard requirements for a narrower set: messages to humans "must be drafted solely by humans without LLM assistance", any LLM use "must be disclosed", and individual "projects and maintainers" may ban LLM contributions completely, with such bans to be respected. Even his enforcement clause is written in the softer register, though: violations "should be treated as violations of the Code of Conduct and should result in swift but proportionate disciplinary action."

Proposal D reaches the opposite conclusion from the same premise — that a ban cannot be policed: Debian "acknowledges that these practices are already in use and here to stay. Rather than banning their use, which seems counter-productive and unenforceable, the project chooses to place responsibility on contributors."

Proposal B builds that out into procedure — and the modality is worth reading closely. Contributors should ensure the tool's terms do not conflict with Debian's use of the output; should verify they have the right to submit third-party material in it; should "fully understand the proposed changes and be prepared to justify them"; should disclose significant AI assistance, for which Nussbaum suggests a Git trailer such as Generated-By: or Assisted-By:; and should discuss bulk or automated changes in advance. Contributors also, flatly, "assume full responsibility" for their contributions and "remain solely accountable" for them. But exactly one condition is written as a prohibition: contributors "must not" put non-public or sensitive project data — embargoed security reports, private communication — through tools that transmit to untrusted providers.

That distinction is not incidental. Debian's constitution defines the word for its own text: "Should means that it would be considered a good thing if the sentence were obeyed, but it is not binding." B's only outright prohibition is the one about secrets; almost everything else is expectation.

So the ballot is not ban-versus-allow. It is a disagreement about what a rule is for when compliance cannot be verified: a declaration of values people will mostly honour, or a set of expectations placed on whoever presses send — with, in B's case, a single binding line drawn around confidential data.

The two camps are not facing the same bar

There is a structural asymmetry in how these proposals are built, and it matters more than the rhetoric.

Proposal A does not merely set policy. It adds a new sixth clause to the Social Contract. Under Debian's constitution, the Social Contract is a Foundation Document, and "a Foundation Document requires a 3:1 majority for its supersession", where options without an explicit supermajority requirement carry a 1:1 majority. Proposals B, C and D are position statements and guidelines, not amendments to a foundation document.

Debian has twice treated a change to the Social Contract as exactly that kind of supersession — including for a pure addition. In the 2022 non-free firmware vote, the winning option's own text declared that it "supersedes the Debian Social Contract (a foundation document) under point 4.1.5 of the constitution and thus requires a 3:1 majority", for a Social Contract change that did nothing but add "the following sentence to the end of point 5". The Secretary recorded that "Proposal 5 and 6 need a 3:1 super majority"; it carried at 4.587. The 2004 editorial amendments went the same way.

But the difference here matters, and cuts against reading the outcome early: in both of those ballots the option's own text declared the supermajority. Proposal A's text declares nothing, and no majority requirement has yet been published for this resolution — the vote page carries no quorum or majority section at all. That determination rests with the Project Secretary, who "shall decide on matters of procedure" in cases of doubt. So the fair statement is not that the strictest option has chosen the highest bar; it is that precedent points squarely at 3:1 and nobody has ruled yet.

If it does land at 3:1, a ban written into the Social Contract would be correspondingly hard to reverse — which is presumably the point, and an argument in its favour rather than against it.

Sponsorship counts do not settle anything either, and are easy to over-read. Under the constitution a ballot option "is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee". Proposal A has 8 sponsors, B has 9, C has 8 and D has 6.

Two developers sponsored across the divide. Pierre-Elliott Bécue proposed the permissive Proposal D and then seconded the ban; Johannes Schauer Marin Rodrigues sponsored both A and D. Rather than infer what that means, it is worth taking Bécue at his word. His second of Proposal A, posted to the debian-vote list, says only "Seconded", followed by a parenthesis: "(this GR needs a representative set of options)." Getting the alternatives onto the ballot is the stated motive.

Two details worth keeping

Proposal A's rationale runs through copyright, quality, community and ethics, and its quality argument is specific to distribution work rather than general hand-wringing: because packaging syntax and practice have changed over the archive's life, "a LLM-produced package will have a mixture of contents spanning the age of the archive, with watch files that do not work, overrides out of context, imaginary copyright, and will generally be unfit for upload." The claim is not simply that the output is wrong: "a seasoned Debian contributor with packaging expertise may find some limited usefulness here, but a new contributor cannot, and would not know how to fix it."

The document closes with a line that is its own argument: "This document was written by Matthias Geiger and Jesse Rhodes with input from Sledge and josch, organically and without language model assistance."

And Jackson's proposal, the harshest on the technology, carries the gentlest clause on the ballot. Any contributor who feels they cannot write English without assistance "may write in their native language, and expect readers to use translation tools of their choice" — a human-written English summary "would be very welcome but is not required" — and "in any case we promise not to shame anyone for any linguistic mistakes." It is a direct answer to the most common objection to LLM bans in international projects, and it comes from the strictest proposal rather than the permissive ones.

What happens next

Under the standard resolution procedure the discussion period runs a minimum of two weeks and a maximum of three from the point a draft is proposed and sponsored. Counting from 24 July, that puts the earliest ordinary opening of a vote at around 7 August — though the Project Leader may increase or decrease the minimum and maximum by up to a week, and further amendments extend the clock: Proposal B has already been amended twice, and the three-week ceiling falls around 14 August. The Secretary then has up to seven days to call the vote. Voting itself runs two weeks, again variable by up to one week at the Project Leader's discretion. Developers rank the options; the default option is "None of the above", and the Project Leader holds a casting vote.

Which means Debian may yet decide that none of these four is the answer — an outcome the ballot explicitly provides for, and one that would leave the project exactly where the four proposals agree it already is: convinced there is a problem, and unconvinced that anyone has written the rule for it.

For the wider argument about what these models do and do not do to working developers, see Microsoft's study of its own AI coding agents, and the twenty-five companies backing open weights while the closed frontier labs stayed away.