The Debian project is polling its developers over AI usage: use it, impose limits, or ban it outright.
The second Debian vote of the year, General Resolution: LLM usage in Debian is underway. More saliently, it is still underway – Debian Project Lead Sruthi Chandran extended the voting deadline by an extra week. (She was elected in March, in the first project poll of 2026.)
Debian is a large and complicated project: the release announcement for version 13 says it has 69,830 packages, which take a total of 403 GB of disk, and contain 1,463,291,186 lines of code. So, suitably, it is a large and complex poll.
The poll is more than 5,000 words long, and contains eight different proposals, which are both numbered and lettered. Each of them is seconded by between six and 17 developers. They are as follows:
No LLM contributions to Debian via Social Contract.
Allow AI-Assisted Contributions with conditions.
Reject LLMs as far as practical, update Code of Conduct.
Accept AI contributions for Debian specific work.
Responsible Use of Generative AI.
A cautious approach to generative AI.
Debian is created by humans.
Avoid the use of LLM: climate destruction is a deal breaker.
The poll also notes:
“Proposal A needs a 3:1 majority, the other proposals need a simple majority.”
This aside, there’s a lot of variation under each proposal. Some are structured, some contain explanations and lists of what they would or would not apply to, some contain summaries, and so on. Only recognized Debian developers are eligible to vote, but we hope that they’re not put off by the wall of text and take the time to work out which of the fairly subtle variations best represents their views.
Proposal A is one of the longest. The closest thing it has to a summary is its “preamble,” which says:
“This proposal aims to expressly forbid any contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools.”
Proposal B would permit LLM-based contributions, so long as they meet six requirements. These cover “legal compatibility,” “licensing and attribution,” “accountability,” “disclosure,” “prior discussion of bulk or automated changes,” and “confidentiality and privacy.”
Proposal C calls for a total ban, and its summary is simple: “Reject LLMs (generative”AI”) as far as practical.” It’s backed by “Debian grandee Ian Jackson”, who wrote dpkg and runs Chiark.
Proposal D attempts a pragmatic compromise, saying it “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 and therefore defines the following guidelines.” It continues with a reasonable enough set of restrictions – the work must be clearly described, comply with the Debian Free Software Guidelines, and so on.
Proposal E is similar, and ends by saying that “responsibility for every contribution rests with the contributor who submits it, who remains accountable for its technical quality, legal acceptability, and suitability for inclusion in Debian.”
Proposal F urges caution and “encourages contributors to avoid the use of generative AI where practical”.
Proposal G “aims to ensure that contributions directly to Debian are created by humans” – in other words, code should be written by hand, but it’s permissible to use LLM tools in other ways while creating it. It ends by saying “we disallow the output of generative AI as direct contributions to Debian.”
Finally, Proposal H focuses on just one of the many ethical concerns – but overall, the single most important one, as it affects everyone. “LLM usage accelerates the destruction of our ecosystem (planet Earth) and that is a deal-breaker.”
If Proposal H has a weakness, it's that it does not distinguish between local and cloud-based LLMs, although there’s an argument that the environmental impact of the training process is the predominant aspect here and whether the end result is local (and relatively resource efficient), or remote (and extremely inefficient) is nowhere near as significant. In the humble opinion of this vulture, there are too many propositions, with too much overlap between them. We suspect this makes a three-to-one majority for the first very unlikely. To make it easier to arrive at a decision, we would have wanted to see the positions consolidated to fewer, clearer, mutually exclusive positions. But then, we’re not Debian contributors and have no skin in this game.
The vote still has a few days to go, although the votes so far are climbing, at the time of writing under 350 ballots have been received.
Some other projects and distributions have already chosen a position in this dispute. Back in April 2024, Gentoo chose to forbid it – as NetBSD did too soon afterwards. As we covered looking at the latest OpenBSD release, the project says that since AI code can’t be copyrighted, it can’t be committed to OpenBSD – but the project grandfathers in code from the Tmux project, which allows LLM-assisted contributions, so the barrier is somewhat permeable. Other such projects may yet follow.
As we reported in September 2025, FreeBSD didn’t want AI code, but it has yet to update its official guidance with an explicit position. From some social media posts, we believe that an active debate is happening right now, possibly including a ballot similar to Debian’s – but the information is not public.
The Register approached the project leadership at FreeBSD for comment, but at the time of writing, had received no response.
Some distributions may forbid LLM code, but how much that changes things is a difficult question. The Linux kernel itself is now officially not an anti-AI project, and of course, Red Hat is all-in – and the IBM subsidiary does create a lot of the code used in most distros. These things being so, arguably what individual distros choose to do becomes something of a moot point. ®