Debian’s debian-vote list opened a general-resolution proposal on July 22 to prohibit direct contributions written with the use or assistance of large language models. The proposed scope covers Debian source packages, project software such as lintian, web resources, documentation, translations, and official communications. Upstream projects that used LLMs would stay outside the initial boundary.
The proposal has already produced the better counterproposal: allow AI-assisted contributions under rules for legal compatibility, licensing, accountability, disclosure, bulk-change discussion, mailing-list labels, and confidentiality. That split is the story. Debian is using its governance machinery to decide whether generated work enters the archive as suspect material or as admissible material with a chain of custody.
The ban proposal treats generated text as contaminated provenance
Matthias Geiger’s proposal says LLM output has unclear legal status, may be entangled with training-data licenses, and should not receive a special exception from Debian’s normal copyright discipline. That is a very Debian argument. The archive already rejects conventionally written work with unclear licensing. Generated output does not become clean because the uncertainty is fashionable or because a chatbot dressed the diff in confident syntax.
The proposal’s quality section is sharper than the usual hallucination complaint. It names Debian packaging as a local, historical, high-context craft. A generated source package can mix old archive habits with current syntax, invent copyright files, produce unusable watch files, and look plausible enough to waste reviewer time. The danger is not that every generated patch explodes. The danger is that plausibility shifts review from judging a known contributor’s work to auditing an unknown synthesis machine.
That is how AI assistance becomes supply-chain material. Debian source carries authorship, licensing, maintainer judgment, review history, and upload authority alongside the tarball and rules file. Once generated content enters that record, the project needs a story about whose responsibility travels with it.
Reviewer labor is the control surface
The proposal’s community argument lands because Debian depends on finite human attention. New contributors learn by packaging, debugging, explaining, and fixing. If a newcomer submits generated output they cannot explain, the review burden moves onto the maintainer while the learning loop collapses. The maintainer becomes both teacher and decompiler for someone else’s prompt residue. Lovely system if your goal is volunteer burnout with extra paperwork.
Lucas Nussbaum’s reply adds the complication that keeps this from becoming a bumper sticker. He wrote that much of his recent Debian infrastructure work was AI-assisted, including debaudit.debian.net and changes around UDD importers, dashboards, Salsa data, reproducibility dashboards, and trends.debian.net. He also described successful experiments using AI to analyze bugs and build better reports. A clean ban would reach productive internal work unless the project draws a careful boundary around infrastructure software, bug reports, and developer communications.
That reply matters because it turns the debate from morality theater into policy design. Debian has to distinguish generated sludge from assisted maintenance. The same tool class can produce junk packaging, accelerate dull infrastructure changes, summarize bug context, or leak private data into a provider. A ban is legible. A permission regime is operationally harder. Policy gets stupid fast when a community pretends the boundary is obvious.
The counterproposal turns AI into contribution metadata
Nussbaum’s ballot option is basically an intake protocol. Contributors remain responsible for technical merit, security, license compliance, and utility. Significant unmodified tool output should be disclosed, possibly with Generated-By: or Assisted-By: trailers. Bulk or autonomous changes should be discussed in advance. AI-generated mailing-list or bug content should be labeled for people who do not want to process it. Sensitive project information should stay out of untrusted providers.
That policy shape treats AI assistance like a new provenance field. It does not trust the tool. It trusts the Debian contributor only if the contributor can understand, justify, label, and stand behind the result. In theory, that is the sane middle. In practice, it depends on culture. Git trailers do not inspect code. Labels do not prove comprehension. Bulk-change discussion does not stop a well-meaning maintainer from rubber-stamping machine-shaped busywork because the diff appears harmless.
Still, the counterproposal has one serious advantage: it admits that assisted work is already happening. Debian can ban the category and rely on good faith, or it can define the duties attached to the category and rely on good faith. Neither path has magic enforcement. The useful question is which rule produces better behavior under volunteer scarcity.
Other projects already drew their lines
The Debian proposal cites GNOME, Gentoo, and Codeberg as source material. GNOME’s Loupe maintainers stopped allowing generative-AI contributions. Gentoo’s Council policy forbids using AI to create contributions unless the contributor can verify copyright and quality, and it bans feeding private Gentoo information to third-party services. Codeberg’s policy discussion similarly treats AI as a licensing, labor, and community-boundary problem rather than a productivity demo.
That pattern matters more than the wording. Free-software projects are realizing that AI-generated contribution policy belongs beside licensing, conduct, review, and infrastructure rules. The patch carries a claim: this work can be distributed, maintained, explained, and trusted by the people who inherit it.
Debian is deciding what a maintainer vouches for
Every software distribution already has a human accountability model. Maintainers upload packages. Reviewers ask questions. Bug reporters provide evidence. Release teams decide whether a change is worth the risk. Security teams handle embargoed details. The archive persists because people can point at decisions and say who made them.
LLM assistance stresses that model because it inserts a non-accountable producer into the workflow. The model cannot own a regression. It cannot answer a license challenge. It cannot maintain the package next year. It cannot care when a stable update breaks some cursed enterprise appliance running under a desk in a municipal office. The contributor has to absorb all of that responsibility or the project absorbs it for them.
Debian’s ban proposal is one answer: keep generated work out of direct contribution paths because the accountability debt is too high. The allow proposal is another: permit assistance only when the human contributor accepts the debt explicitly and leaves enough metadata for the project to reason about it.
I prefer the second shape if the rules have teeth. A blanket ban sounds clean, then immediately runs into local scripts, assisted refactors, bug summarization, translation tooling, and contributors who use models privately while pretending otherwise. But a permission regime without real norms is worse than a ban because it launders machine output through a checkbox. Assisted-By: cannot become the new “LGTM” for patches nobody actually understood.
The line worth defending is comprehension. If a contributor cannot explain the patch, license, build behavior, regression risk, and maintenance path, Debian should treat the submission as junk regardless of whether a model touched it. AI policy should make that older standard explicit again, with disclosure as evidence and reviewer time as the scarce resource being protected.