
TL;DR
Debian is voting on four proposals to regulate LLM-generated contributions - from an outright ban to full acceptance. The HN discussion reveals the fault lines in open source's biggest AI policy debate yet.
The Debian project is formally debating how - or whether - to accept contributions generated by large language models. The discussion period opened July 24, and the project will eventually vote on four competing proposals that range from an outright ban to full acceptance with disclosure requirements. This is the first major Linux distribution to put LLM policy to a formal general resolution, and the outcome will shape norms across open source.
Debian is one of the oldest and most influential Linux distributions. It is the foundation for Ubuntu, Kali, and countless servers. Its Social Contract has guided free software governance for decades. How it resolves this question matters beyond Debian itself.
Proposed by Matthias Geiger, Proposal A would amend the Debian Social Contract to add a new clause: "We will not allow direct contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools."
The scope covers Debian source packages, official project software (lintian, etc.), web resources, documentation and translations, and official communication. It explicitly exempts upstream projects, AI-related software in the archive, and upstream patches.
The rationale makes four arguments. Copyright: "LLM output has very unclear legal status" and Debian Policy requires absolute clarity. Quality: an LLM "can never know if its output is correct since it merely produces syntactically likely combinations of the training data." Community: new contributors submitting LLM output for review strains reviewers and creates dependency without learning. Ethics: LLM companies "scraping the whole web for training data without any regard for license, copyright, or even established conventions such as robots.txt," some of which has impacted Debian's own infrastructure.
Proposed by Lucas Nussbaum, Proposal B takes an informed-consent approach. AI-assisted contributions are allowed provided the contributor meets six conditions: tooling legal compatibility, licensing and attribution verification, full accountability (the contributor must "fully understand the proposed changes and be prepared to justify them"), disclosure (recommending Generated-By: or Assisted-By: Git trailers), prior discussion for bulk changes, and no use of cloud-based AI tools on sensitive or confidential project data.
Proposed by Ian Jackson, Proposal C acknowledges that "a complete ban on LLM output as part of Debian is currently impractical" given how many upstreams use them. It requests that contributors avoid LLMs for Debian work, asks decisionmakers to discourage use, and mandates that messages to humans (bug reports, mailing list posts, blog posts on Planet Debian) be drafted solely by humans. Individual projects and maintainers may ban LLM contributions entirely, and such bans must be respected. Violations would be treated as Code of Conduct violations.
Proposed by Pierre-Elliott Becue as the most permissive option. Contributors must evaluate and understand their submissions and mark AI-assisted work. No cloud-based AI may be used on sensitive data. It is the only proposal that frames AI contributions as something to accept and manage rather than discourage or ban.
Newsletter
Get the weekly deep dive
Tutorials on Claude Code, AI agents, and dev tools, delivered free every week.
From the archive
Jul 25, 2026 • 7 min read
Jul 25, 2026 • 12 min read
Jul 25, 2026 • 10 min read
Jul 25, 2026 • 8 min read
The Hacker News discussion (141 comments, 158 points) surfaced the real tensions that policy language cannot paper over.
The most-upvoted framing came from simonw, who clarified that the page represents competing proposals, not a final decision. "Don't misinterpret this link as representing a final decision," they wrote. "It's actually three separate proposals which will be debated and then voted on."
The enforceability debate dominated. Multiple commenters noted that Gentoo already banned LLM contributions two years ago. "Gentoo chose to ban LLMs two years ago. They seem to be doing well," wrote Meneth. Others pushed back hard. "Proposals like these are arrogant and obnoxious," wrote baggy_trough. "You aren't going to tell me what tools I can use."
tulio_ribeiro was the most pointed critic: "The whole anti-LLM crusade feels like developers trying to gatekeep their own relevance. They know the tool can automate parts if not all of what gave them status, so instead of adapting, they want to declare its use illegitimate." They warned: "If Proposal A passes and is somehow enforceable, every distro that embraces AI while Debian moralizes about it will lap them within a few years."
The security angle got real traction. simonw raised a critical edge case about Proposal A: "as written, excludes contributions where the LLM assisted in discovering the vulnerability. That's clearly a bad policy, and they should update their wording."
1saadcodes reframed the whole debate: "I suspect the debate shouldn't be LLMs or no LLMs, but rather what level of human accountability is required. We've accepted compilers, static analyzers, and code generators because the maintainer is still responsible for the final result."
A subtler concern came from alightsoul, who argued Proposal A "is the end of Debian for non-English speakers," because LLMs have become vital for accessing English-dominated technical information. Barrin92 pushed back: "nobody, by definition, can stop you from consuming documentation using machine translation."
This vote is a fork-in-the-road moment for open source governance. Five dynamics make it significant:
The upstream boundary problem. Proposal A exempts upstream LLM-generated code. But if the kernel and major packages increasingly accept AI contributions, Debian ends up shipping AI code in everything except its own packaging layer. That creates an awkward philosophical position: AI code is fine for the kernel but not for debian/rules.
The enforceability question. As the proposal text itself acknowledges: "How will you enforce a ban on LLM contributions?" The answer: "We trust this community to adhere to it in good faith." In a project with thousands of contributors, trust-based enforcement is porous at best.
The contributor drain. If a third of Debian contributors find LLMs useful for their workflow and the project bans them, those contributors may shift energy elsewhere. HN commenters noted this is already happening: "I would not have considered Gentoo for my work laptop but LLMs have unlocked my ability to do so," wrote hparadiz.
The security paradox. LLMs are increasingly used for vulnerability discovery. A policy that discourages or bans their use for finding and patching bugs could leave Debian systematically less secure than distributions that embrace them. This is not a hypothetical - attackers will use LLMs regardless.
The community identity question. Debian's stability mandate has always been its superpower. But that same conservatism, applied to tooling rather than output, could create an opening for distributions like Fedora (which allows LLM use with disclosure) or Nix to attract contributors who see AI tools as essential to modern development.
Proposal B is the most pragmatic path forward. It neither bans nor endorses LLMs - it sets a responsibility framework that mirrors what many corporations are adopting. Contributors must disclose, verify, and remain accountable. The Gen-By trailer is a lightweight norm that could work in practice.
But Proposal B also has a problem: it requires contributors to decide when disclosure is necessary. "Some lightweight generative tools, such as tab-completion in Copilot, may be used without the contributor realising they rely on generative AI models," the text acknowledges. That line is getting blurrier every month.
The outcome of this vote will signal whether the open source community's largest institutions see LLMs as just another tool or as something qualitatively different. There is no neutral option - whichever way Debian votes, it will shape how other projects set their own policies.
Read next
A new distributed inference system pools GPU resources across multiple machines and exposes them through a single OpenAI-compatible API. No RDMA, no NVLink - just QUIC and your existing hardware.
6 min readA new multi-model orchestration system routes requests across open-weight models to match frontier performance at reduced inference cost. Here is what we know.
7 min readA developer got Google's Gemma 4 26B running on 2013 Xeon hardware for under $300. The fix for a silent MoE bug is now upstream - here's what it means for local inference.
6 min readTechnical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.

A developer got Google's Gemma 4 26B running on 2013 Xeon hardware for under $300. The fix for a silent MoE bug is now u...

A new distributed inference system pools GPU resources across multiple machines and exposes them through a single OpenAI...

A new multi-model orchestration system routes requests across open-weight models to match frontier performance at reduce...

The Gleam programming language has migrated to Tangled, a new ATProto-based code hosting platform. Here's what this mean...

A developer built a complete X11 server in 20,000 lines of assembly language using Claude as a compiler, running Firefox...

LM Studio launches Bionic, a standalone agent harness for open models with local inference, voice input, and zero data r...

New tutorials, open-source projects, and deep dives on coding agents - delivered weekly.