MagicTools
Back to Articles
Developer ToolsBy CooconAugust 16, 202614 views9 min read

Debian's Vote on AI Code: All 8 Ballot Options Explained

The ongoing vote in Debian may be the most formal "AI code ballot" the open-source world has seen yet: General Resolution 2026-002 "LLM usage in Debian", with a voting period from 00:00 UTC on August 15, 2026 to 23:59:59 UTC on August 28, 2026 (the vote had just begun when this article was published, with no results yet). Only Debian Developers have voting rights; votes are cast via GPG-signed email, using Condorcet preference ranking, with secret ballot.

The ballot contains a total of 9 items: 8 proposals plus "None of the Above". This is not a binary "ban or don't ban" choice, but rather laying out all the stances from over two years of community discussion for ranking. Below, we explain each option from strictest to most lenient, along with one crucial procedural detail.

8 Options: From a Ban Written into the Social Contract to Neither Banning nor Endorsing

Choice 1: Ban all contributions via the Social Contract (proposed by Matthias Geiger). Adds a line to the Debian Social Contract: "We will not allow direct contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools." Covers source packages, official tools, websites, documentation translations, and official communications. Enforcement relies on "good faith compliance"—the proposal itself admits there is no detection mechanism. The proposal text also explicitly states it was "written organically, without LLM assistance."

Key procedural detail: This is the only option requiring a 3:1 supermajority, because it modifies a foundational document (the Social Contract). All other options only require a simple majority. This threshold is extremely high and is key to understanding the dynamics of this vote.

Choice 3: Reject as much as possible, codify in Code of Conduct (Ian Jackson). Acknowledges that a total ban is "currently impractical", but draws a clear daily red line: Person-to-person messages—bug reports, mailing list discussions, Salsa discussions—must be written by humans; any use of an LLM in Debian work must be declared; violations are handled under the Code of Conduct.

Choice 7: Ban AI output, but not AI tools (Gard Spreemann, slogan "humans create Debian"). The most nuanced centrist position: LLM output cannot directly become a contribution, but does not restrict using LLMs to explore, analyze, or review code. This "output vs. analysis" distinction emerged as cross-camp consensus during the discussion period, and GCC's new policy follows this same line of thinking.

Choice 2: Allow, but with six conditions (former DPL Lucas Nussbaum). Conditions include tool license compatibility, license verification, full contributor responsibility, mandatory disclosure (Git trailers like Generated-By: / Assisted-By:), prior discussion for bulk automated changes, and confidential information must not be fed to untrusted services.

Choice 4: Accept + Responsibility Model (Pierre-Elliott Bécue, co-signed by Russ Allbery among others). Rationale is straightforward: "Rather than banning their use, which seems counter-productive and unenforceable, the project chooses to place responsibility on contributors." Disclosure is "should" rather than "must", because tools like tab completion might be used without explicit awareness.

Choice 5: Neither ban nor endorse (Marc Haber, co-signed by 11 others). "Debian neither endorses nor prohibits"—a statement that only encourages, does not mandate, and is the closest to maintaining the status quo.

Choice 6: Encourage avoidance (Tobias Frost). A softer form of discouragement: encourages avoiding use where feasible, framing disclosure as "courtesy to fellow contributors."

Choice 8: Climate-based discouragement (Holger Levensen, co-signed by 17 others, the most of any option). A statement of position rather than an enforceable policy: "we condemn LLM (resource) usage but not LLM users."

What the Two Sides Are Arguing About: Core Arguments Distilled

Against (Pro-Restriction) Four Main Lines of Argument:

  • Copyright and DFSG: The legal status of LLM output is unclear, while "Debian Policy and the DFSG require absolute clarity on licensing and copyright." Why grant a special exception for LLM output?
  • Packaging Quality: Proposal A states this concretely—LLM-generated packaging files mix syntax from various eras, resulting in "watch files that don't work, overrides disconnected from context, and imagined copyright fields."
  • New Contributor Pipeline: The worst-case scenario is "new contributors merely acting as messengers between the AI and the maintainers" (Simon Richter's "onboarding problem").
  • Crawler Resentment: Proposal A directly labels AI crawlers as "a massive and perpetual denial-of-service attack" on Debian infrastructure. There is on-site evidence—lists.debian.org now uses proof-of-work challenges against crawlers, and the original emails quoted in this article required solving a SHA-256 hash to retrieve.

For (Anti-Ban) Counterarguments Are Equally Sharp:

  • Unenforceable: Russ Allbery said two years ago when commenting on Gentoo's ban: "it (as they themselves admit) is unenforceable," and "we never legislate what tools people use locally."
  • Quality Argument Doesn't Hold Up: Again from Allbery, a 2026 quotable line: "Writing meaningless slop requires no creativity; writing really bad code requires human ingenuity."
  • Guarding the Gate Harms the Gatekeeper: Ted Ts'o: "You're now saying we should turn away contributors who might be using AI? I call that more self-destructive."
  • The "Preferred Form for Modification" Problem: Bdale Garbee asks, for code generated by a chat prompt, what is its preferred form of modification? Nussbaum answers "the tool's input", but LWN points out that LLM outputs are non-reproducible and models retire, making this answer incomplete—this may be the deepest legal pitfall in the entire discussion.

A detail perfectly encapsulates the methodological clash between the two sides: Proposal A declares itself "written organically", while the option comparison table Nussbaum provided to all developers was openly marked "generated with AI assistance."

How This Vote Came to Be

  • 2024-05: Inspired by Gentoo's ban, the Debian community first formally discussed an AI contribution policy; it ended without conclusion.
  • 2025-04: Mo Zhou proposed a GR stating "AI models without training data are not DFSG compliant"; it was withdrawn after discussion.
  • 2026-02: Lucas Nussbaum drafted a "Allow + Conditions" GR—stating his motivation was to respond to "various attacks against people using AI in the Debian context"—but ultimately did not formally submit it. LWN's headline was precise: "Debian decides not to decide".
  • 2026-06/07: The external environment changed abruptly—Godot banned vibe coding (June 30), Codeberg community voted 358:144 to ban hosting repositories "primarily generated by AI" (vote closed July 22), GCC AI policy took effect (announced July 30).
  • 2026-07-22: Matthias Geiger directly proposed the ban: "It is time for Debian to make a statement." Within two weeks, 8 options emerged, and voting began on August 15.

Cross-Community Policy Comparison Table

Debian is not voting in a vacuum. Current policies in major communities:

Community Policy Effective Time
Gentoo Full ban (reasons: copyright, quality, ethics) 2024-04
NetBSD LLM code is tainted by default; requires core team written approval 2024
Asahi Linux Most severe: labels all as "Slop Generators", use is a violation, warning then permanent ban Current
QEMU Rejects AI-generated contributions by default (legal basis: DCO cannot be satisfied); exceptions can be applied for Current
GCC Rejects "legally significant" LLM contributions; test cases are exempt; small contributions must be marked Assisted-by 2026-07
Godot Bans autonomous agents / vibe coding; AI limited to menial tasks with mandatory disclosure 2026-06
Codeberg Community vote 358:144 bans hosting repositories "primarily generated by AI" 2026-07
Fedora Allowed + mandatory disclosure (Assisted-by tag); full contributor responsibility; AI may assist review but not final approval 2025-10
Linux Kernel Allowed + Assisted-by: tag; only humans can sign Signed-off-by (DCO) Merged into docs 2025-12
curl Not banned but mandatory disclosure; slop leads to immediate ban; ~20% of 2025 submissions were slop, issue mitigated after bug bounty was shut down at end of Jan 2026 From 2024
FreeBSD No official policy; core team avoids AI-generated code due to license concerns; policy under development —

As seen, both ends of the spectrum have supporters, and disclosure obligations are currently the biggest common denominator—5 of the 8 options on Debian's ballot include some form of disclosure requirement.

Practical Impact for Ordinary Developers

  • Upstream is unaffected. All 8 options unanimously exclude upstream: how you use AI in your own project is Debian's concern, and Debian will continue packaging upstream software containing AI code. Even the strictest Choice 1 specifies "does not include upstream projects using LLMs in development."
  • If an "Allow + Disclosure" type option wins (currently most likely based on procedural thresholds): Submitting a patch to Debian will require adding a Generated-By: / Assisted-By: style Git trailer; bulk automated contributions must be discussed on the mailing list first.
  • If Choice 3 wins: The most day-to-day impact—one of its rules—reporting bugs or sending emails to Debian cannot be drafted by AI.
  • Universal Red Line (shared by nearly all options): Embargoed security information and debian-private content must not be fed to third-party AI services; contributors are fully responsible for their submissions and must be able to explain them.

Results will be known after August 28. Whichever option wins, the texts of these 8 proposals themselves have already become the most complete reference material for other open-source communities formulating their own AI policies.

Frequently Asked Questions (FAQ)

When will the vote results be released?

The voting period is August 15 to 28, 2026 (UTC). Results will be announced by the Debian Project Secretary on the official voting page (vote_002) after the period ends. It uses Condorcet preference ranking, where developers rank their preferences for the 9 options.

Is there a high chance the strictest ban option passes?

The procedural threshold is extremely high: Choice 1 requires modifying the Social Contract, needing a 3:1 supermajority, while all other options only need a simple majority. Historically, few GRs modifying foundational documents have passed; moreover, during the discussion period, the "Allow + Disclosure" camp gathered endorsements from multiple former DPLs. However, the ranking effect of Condorcet voting is unpredictable, and everything is subject to the official results after August 28.

Will this affect how I use AI for my own open-source projects?

No. All options only govern "contributions directly to Debian" (packaging, official tools, documentation translation, official communications) and explicitly exclude upstream projects. However, if your project is packaged by Debian, or if you submit patches to Debian, disclosure obligations may fall on you.

Why are so many communities establishing rules simultaneously in 2024–2026?

Two direct pressure points: First, the unclear legal status of LLM output at the copyright/DFSG level, which the DCO signature system cannot cover (the core legal rationale of QEMU's policy); second, the operational cost of AI slop—curl's data shows ~20% of 2025 submissions were AI-generated garbage reports, requiring the 7-person security team to spend 0.5-3 hours per report from 3-4 people to process, ultimately leading to the shutdown of the bug bounty program in January 2026.

References

Related Articles

Codex 232x GPU Kernel Speedup: The Real Story and Method

The viral '232x kernel speedup with Codex' was a GPU Mode competition entry: 14 days, 1,500+ submissions, 12th place out of 183, measured against a torch.geqrf baseline. We break down the replicable harness—AGENTS.md evidence rules, /goal loops, beam of candidates, a strong advisor model—plus three caveats: overfitting, numerical stability, and reward hacking.

ai-tutorialsAug 16, 20269 min
14

Fine-Tune 8B Models on 4GB VRAM: Soup's Layer Streaming

GitHub project Soup claims a single YAML file can fine-tune Llama-3.1-8B on a 4GB laptop GPU. We read the code, benchmarks, and HN thread: the claim holds—3.32GB peak VRAM and 119.6 tok/s on an RTX 3050 Laptop, versus the 6.6–8GB QLoRA floor. Here is how layer streaming works, how to configure it, and the trade-offs: 1.43x slower training, a 16GB system RAM minimum, an architecture whitelist, and two silent bugs it already fixed.

ai-tutorialsAug 16, 20267 min
11

A 232x speedup and a 99.9% watermark landed on the same day

The same day, a developer used Codex to make a kernel 232x faster, while Anthropic announced a 99.9%-detectable watermark on Claude's output. One story is about capability, the other about rules. Don't envy the 232x ceiling — the reproducible profiling→patch→verify loop is what's actually worth building. On the watermark side, both content platforms and API developers should reassess what traceable AI text means for them.

developerAug 16, 20264 min
23

Claude's Text Watermark: A Signature Hidden in the Dice Rolls

Anthropic published the full mechanics of Claude's text watermark — nothing added to the text, no hidden characters, no extra tokens, no price change. What's more interesting is the other half of the document: the long list of cases where the watermark barely works at all.

claudellm+5
ai-tutorialsAug 16, 202613 min
9

Try these free online tools

JSON FormatterFormat, minify, validate, escape and unescape JSON with syntax highlighting, code folding, in-editor search, and precise error locations.Regex TesterTest regular expressions in real time with match highlighting, group details, and flag controls.JWT DecoderDecode JWT tokens and inspect Header, Payload, Signature, and expiry status. 100% local — nothing transmitted.Hash GeneratorGenerate MD5, SHA-1, SHA-256, and SHA-512 hashes from any text. All processing is local — nothing sent to servers.Base64 Encode/DecodeBase64 encoding and decoding with UTF-8 support. One-click copy and download.SQL FormatterFormat and beautify SQL with keyword casing, custom indentation, and syntax highlighting. Also minify SQL to one line.

Published by MagicTools