31 AUG 2026 — Debian has published the result of its general resolution on generative AI, and the coverage reads as a permission being granted. The resolution grants nothing. It declines to require disclosure, and it adds two restrictions that did not exist before.
What was actually decided
Eight options went to the developer body. The winner, proposed by Marc Haber and titled Responsible Use of Generative AI, opens by stating that Debian neither endorses nor prohibits the use of generative AI tools in the development, maintenance or documentation of software, packaging, documentation and other media published within the project.
The phrase neither endorses nor prohibits is not an approval. It is a refusal to take a position. The three operative clauses that follow are where the resolution does work.
The three clauses that matter
Disclosure is encouraged and not required. Contributors are encouraged to say whether a contribution was made with AI assistance, and no one has to. This is the clause the headlines are describing as permission, and it is better read as the project declining to build an enforcement mechanism it would have had to staff.
Responsibility is unchanged. The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit, and contributors are expected to understand, review, test and where appropriate modify the output before it goes in. Every contribution, however produced, meets the same standards of quality, correctness, maintainability and legal compliance.
The clause is not new, though its appearance in a document about AI makes it read that way. It restates what already applied to a maintainer pasting code from a mailing list in 2003. What the resolution adds is that a contributor cannot cite the tool as a defence.
The two restrictions nobody is reporting
Confidential project information must never be transmitted to third-party AI services. This is an unqualified prohibition, and it did not exist before the vote. In practice it covers security-embargo material, private discussion of unreleased advisories and anything else the project holds in confidence, and it means that pasting an embargoed patch into a hosted assistant is now a policy violation rather than a judgment call.
The restriction with the most operational weight is the second one: large-scale automated contributions require prior discussion. Debian is not guarding against a maintainer using a completion tool. The threat is an agent running across the archive and opening several hundred patches for human review. Reviewers are the project's scarcest resource, so a rule that bulk runs must be discussed first rate-limits the one thing that could exhaust them.
The outcome is a project that permits individual use without policing it, while drawing a hard line around confidentiality and bulk automation.
The vote was closer than the result suggests
The winning option beat the runner-up by 55 votes in their pairwise comparison, out of 401 ballots. Its margins over the other options were wider, running from 80 to 117.
Reporting has put the split at roughly 64 per cent for allowing assisted contributions against 36 per cent preferring a ban or strong discouragement. Read that as a description of sentiment rather than a tally. Debian votes by Condorcet method over ranked ballots, so there is no single yes-or-no figure to extract, and any percentage split has to be reconstructed from rankings.
One reported figure does not reconcile. Secondary coverage says just under 600 people voted with many ballots rejected, leaving almost 450 to count. Debian's own result page records 401 ballots received, and we have used the project's figure.
Where this sits against other projects
The distributions have landed in different places, which is unusual for a procedural question.
Gentoo has banned AI-generated contributions outright. NetBSD and OpenBSD reject AI-generated code submissions. Debian has taken the position that the tool is not the project's business as long as the contributor answers for the result.
These projects are not arguing about code quality, because each one already rejects code that fails its standard. The argument is about provenance and legal exposure. The question is whether a project can accept a patch whose licensing history the contributor cannot fully account for. Debian's answer is the one it has always given: the project relies on the contributor's own assurance, and that does not change because the drafting tool did.
Why the employment question follows from this
A policy that puts responsibility on the individual works as long as contributors are individuals.
The pressure point arrives when a maintainer is employed to work on packages, and the employer supplies the assistant, sets the throughput expectation and owns the output under a contract the project never sees. The responsibility clause still binds the person, and the person's leverage over how the work gets produced may be small.
Debian has not addressed that and did not need to for this vote. It is the shape of the next argument, and it is the same one AWS buying DuckDB's maintainers rather than DuckDB made concrete: a licence stays open while the people who decide what gets written move onto a payroll.
View author profile → · Editorial policy
