Debian has opened a General Resolution discussion on LLM use, and the proposals show how hard it is to turn “AI assistance” into enforceable project policy. Proposal A would forbid Debian contributions written with the use or assistance of LLMs or other generative AI tools. Proposal B would allow AI-assisted contributions if contributors handle legal compatibility, licensing and attribution checks, accountability, and disclosure. Proposal C strongly asks contributors to avoid LLMs, while recognizing that a complete ban may be impractical; it also adds disclosure requirements and human-only drafting for messages to humans.

The stakes are broader than code generation. Debian’s trust model covers source packages, official project software, web resources, documentation, translations, bug discussions, and public project communication. Once LLM output enters that chain, the project has to decide who verifies copyright status, who accepts security responsibility, and whether users or maintainers deserve explicit disclosure.

The HN discussion immediately corrected a common misread: the page is not a final decision, but competing proposals still under debate. From there, commenters focused on edge cases. Is it “assistance” if a model suggests a bug fix but a human writes and tests the patch? What about copyediting a mailing-list message? How should Debian treat upstream projects that already used LLMs before a patch reaches the distribution?

That ambiguity is why the vote matters beyond Debian. A hard ban is clear but difficult to police. Conditional acceptance fits modern workflows but depends on contributors understanding and disclosing what happened. Strong discouragement preserves norms, but may leave maintainers making case-by-case judgments. Debian is effectively drafting one of the more visible open-source answers to AI-era maintainer responsibility.

Sources: Debian vote page and HN discussion.

#debian

Debian weighs LLM rules: ban, conditional use, or strong discouragement