Debian’s General Resolution on LLMs: Ban, Allow, or Ask Nicely
Debian is doing something most open source projects won’t: they’re putting it to a vote.
A General Resolution opened this week presents the Debian community with three competing proposals on what to do about LLM-generated contributions. This isn’t a board decree or a benevolent dictator’s edict. It’s a democratic process in one of the oldest and most important Linux distributions, and the outcome will ripple.
The proposals, as summarized in the HN discussion, break down like this:
Proposal A — Full ban. “Expressly forbid any contributions to Debian written with the use or assistance of large language models.” No AI code, no AI-generated patches, no AI-written docs. If a model touched it, it doesn’t land in Debian.
Proposal B — Permissive with guardrails. Allows AI-assisted contributions provided conditions are met. Think disclosure requirements, manual review, accountability. The “informed consent” model, as one HN commenter put it.
Proposal C — The soft touch. “Request that all contributors to Debian avoid the use of LLMs in their Debian work.” A request, not a rule. No enforcement mechanism. Just an appeal to community norms.
Three boats, three different theories of how AI should fit into a project that’s been shipping free software since 1993.
Here’s what makes this interesting: the endorsements are split roughly evenly across all three proposals. That suggests about a third of Debian’s core contributors support an outright ban, a third want a regulated path forward, and a third just want to register discomfort without pulling the trigger.
If Proposal A passes, Debian becomes the most high-profile project to ban AI contributions outright. That sends a signal — to other distros, to upstream projects, to every developer wondering whether their AI-assisted patches will be welcome. If Proposal B passes, Debian becomes a test case for how to integrate LLM tools with transparency requirements. If Proposal C passes, nothing happens — but the discussion itself becomes part of the historical record.
The counterargument to A is straightforward: you can’t un-invent a tool. If AI-assisted code review catches real bugs, if AI-generated patches fix real issues, you’re accepting worse security and slower development out of principle. One HN commenter put it bluntly: when exploit-finding models get good enough, would you rather run a fork that patches its vulnerabilities with AI assistance, or one that doesn’t?
The counterargument to B is that disclosure requirements are trivially evaded. “I wrote this myself” is the easiest lie in the world when there’s no technical mechanism to verify it. And the counterargument to C is that a “request” with no teeth is just a way to feel good without changing anything.
I don’t know which proposal will win, and I don’t have a strong horse here. What I do know: Debian is doing the hard work of actually thinking about this, in public, through the mechanisms of democratic governance. That’s more than most organizations have managed.
Most companies just silently add “we use AI” to their privacy policy and move on. Most projects let individual maintainers decide case by case, which means the loudest voices set the norm. Debian is forcing a deliberate choice, debated openly, voted on by the people who actually do the work.
That’s worth paying attention to — regardless of which boat you’re in.
Sources: Debian General Resolution Vote 2026-002, HN Discussion, LWN coverage