Debian has opened a vote (General Resolution) with four proposals on how to regulate contributions written with LLM assistance. Proposal A bans the use of generative models entirely for source packages, official software, documentation, and project communications. Other proposals seek middle-ground positions.

The discussion period began on July 24, 2026. The community will vote using the Condorcet method, the same system used for the project’s constitutional decisions.

Why this matters to you. If you use or contribute to open source software, the rules Debian sets today will become the model other projects copy. The core issue is practical: LLM output has unclear legal status regarding copyright, and Debian’s social contract (DFSG) requires absolute certainty about licenses. A contribution whose origin cannot be verified is a concrete risk for anyone maintaining a distribution used by millions.

Open source communities are moving past debating whether AI is good or bad and are writing explicit rules. Codeberg has already passed two motions to protect its commons from indiscriminate LLM use. Debian does this with its most characteristic tool: a vote open to all project developers, where each proposal must gather signatures and pass a public discussion period before final decision.

In detail

The General Resolution (GR) is Debian’s mechanism for decisions affecting the entire project. It goes through a vote open to all active Debian Developers, who express themselves using the Condorcet method, a preferential voting system that minimizes tactical voting effects. Before reaching a vote, each proposal must be seconded by other developers and pass a public discussion period.

The four proposals. Proposal A, written by Matthias Geiger and supported by eight developers including Ian Jackson, explicitly bans any contribution written with LLM use or assistance. Its scope covers: Debian source packages, official project software (such as lintian), web resources, documentation and translations, and official communications. It explicitly excludes: upstream projects that use LLMs for their own development, AI-related software, and upstream security patches.

Proposals B, C, and D seek middle-ground positions, but their complete texts had not yet been published when the source was gathered. The precise picture of options will be defined during the discussion period.

Three concrete issues. Proposal A argues for the ban on three fronts.

1. Copyright. LLM output has uncertain legal status: it could be covered by autonomous copyright, or depend on all licenses present in training data. Debian Policy and DFSG (Debian Free Software Guidelines) require absolute clarity on licenses and copyright. A package with unclear provenance cannot enter Debian.

2. Stability. Debian has built a reputation for stability over thirty years. Proposal A associates widespread LLM use with “move fast and break things” culture, which it considers incompatible with what makes Debian what it is.

3. Maintainability. LLM-generated contributions can be hard to maintain: those who produced them might not fully understand them, and the code can contain subtle errors that only emerge in production.

What actually changes. Whether Debian approves a total ban or a middle-ground path, the fact remains that one of the world’s most structured open source communities is writing explicit rules on territory that until now was no-man’s-land. When the problem presents itself in your project, or your company, the terms of discussion will already be laid out in black and white by someone.

Limitations of what we know. Proposals B, C, and D are not yet complete. The vote is not immediate: public discussion can modify texts, generate amendments, or lead to proposals being withdrawn. The final outcome could be a compromise that none of the four original options anticipated.