Debian votes on whether to ban generative AI in its code or regulate it with transparency rules

By Zendoric · July 25, 2026.

Debian, one of the most veteran Linux distributions and the basis of Ubuntu, has opened a discussion period, begun on July 24, on two General Resolutions (GRs, the constitutional mechanism with which the project settles its most delicate decisions) competing to define its policy on the use of language models (LLMs) in contributions to the project. The vote, managed by the Debian Secretary, pits a total ban against a framework of regulated use, and both start from a shared diagnosis: generative AI is already entering Debian's code, documentation and translations, and the project needs an explicit stance.

Proposal A, put forward by developer Matthias Geiger and backed by seven other Debian Developers, seeks to amend Debian's Social Contract to expressly prohibit any contribution "written with the use or assistance" of LLMs or other generative AI tools: source packages, official tools such as lintian, documentation, translations and official project communication. Software from upstream projects that use AI in their development and third-party security patches would be excluded. The arguments, according to the text itself, are four: the legal status of copyright over an LLM's output is ambiguous and clashes with the licensing-clarity requirement of the Debian Free Software Guidelines (DFSG); the quality of generated code is erratic because an LLM "can never know" whether its output is correct, and in packaging, where each package is idiosyncratic, that translates into broken watch files or made-up copyrights; the review burden on human maintainers, already scarce, would soar with low-quality contributions; and, as the document itself denounces, massive crawling of Debian's websites by AI companies to train their models has gone so far as to overload its infrastructure, forcing the project to set up JavaScript-based checks to protect its servers.

Proposal B, driven by developer Lucas Nussbaum and seven other signatories, opts to allow AI-assisted contributions under specific conditions: legal compatibility of the terms of the tool used, verification that no third-party code with an incompatible license slips in, full responsibility of the contributor for what they submit, explicit disclosure of AI use (for example via a Generated-By: label in Git commits), prior discussion for mass or automated changes —as Debian already requires for mass bug-filing— and a ban on using tools that send confidential information, such as still-embargoed security reports, to untrusted third parties.

It is, at bottom, the same tension that other projects cited as precedent in Proposal A itself have already experienced: GNOME vetoed generative-AI contributions in its image viewer Loupe, and both Gentoo and Codeberg have already adopted their own policies. The pattern repeats because the problem is not technical but institutional: who assumes the legal and quality risk when code is no longer (solely) written by an identifiable person.

Our reading is that this debate matters far beyond Debian. The project has an unusually formalized governance culture —a written constitution, Condorcet voting, general resolutions with public seconds— that makes it a useful laboratory for observing, more clearly than in most companies, how a community collectively decides the limits of a technology that a good part of its own members already use. Proposal A is right on one point that is not ideological but operational: code review is a scarce human resource, and dumping mass-generated patches onto it with no quality guarantee shifts the cost of AI onto those who benefit least from its speed, the maintainer. It is the same pattern we have already pointed out in labor disruption: AI's immediate problem is rarely that it replaces someone all at once, but that it quietly erodes the conditions of those who remain.

At the same time, a total ban clashes with the reality that a good part of Debian's own signatories and developers already use coding assistants daily, and that distinguishing in practice an "assisted" commit from one that is not is, as Proposal A itself acknowledges, almost impossible to enforce. Proposal B, with its requirement of traceability (disclosure, named responsibility, advance notice of mass changes), more closely resembles the response most mature institutions end up adopting toward a disruptive tool: not banning it, but imposing frictions of transparency and accountability until the technology itself —and the culture around it— matures enough that those frictions cease to be necessary.

In the long run, we remain convinced that this is the way forward: the better models become at documenting the provenance of their output, verifying licenses and sticking to each project's style and conventions, the less sense a categorical ban will make and the closer AI-assisted contribution will come to being just another tool of the trade, as happened with automatic spell-checkers or linters. But that moment is not today, and the fact that a project as long-lived and cautious as Debian has to legislate explicitly on it is the clearest proof that the transition, in free software too, is going to be uncomfortable before it is productive.