Debian Allows Generative AI in Code: What the 2026 Vote Changes in Open Source
Hello HaWkers, Debian spent two weeks voting and closed General Resolution 2026-002, "LLM usage in Debian", on August 28, 2026. There were eight proposals on the ballot, ranging from banning LLMs through the Social Contract to accepting assisted contributions with no ceremony at all. Option 5 won, "Responsible Use of Generative AI". The project that packages a good chunk of the internet's infrastructure decided that it neither endorses nor prohibits generative AI.
Do you contribute to an open source project, or plan to, and have you ever wondered whether you can open a PR with code that Claude or Copilot helped write? That question left the realm of etiquette and became written policy, with different rules in each project. In this article I break down what Debian approved, compare it with the projects that ban it, and show you how to automate compliance in your own repository with git hooks and CI.
What Debian Actually Decided
Voting was open from August 15 to 28, 2026, with 1,045 developers eligible to vote and a required quorum of 48.49 votes. The ballot had nine lines: eight proposals plus the classic "None of the above". Debian uses Condorcet with the Schulze method, so there is no such thing as a "tactical vote": each participant ranks the options by preference and the system resolves every pairwise matchup.
The eight proposals covered the entire spectrum:
- Ban LLM contributions from Debian via Social Contract, by Matthias Geiger
- Allow AI-Assisted Contributions with conditions, by Lucas Nussbaum
- Reject LLMs as far as practical, update Code of Conduct, by Ian Jackson
- Accept AI contributions for Debian specific work, by Pierre-Elliott Becue
- Responsible Use of Generative AI, by Marc Haber
- A cautious approach to generative AI, by Tobias Frost
- Debian is created by humans, by Gard Spreemann
- Avoid the use of LLM: climate destruction is a deal breaker, by Holger Levsen
Marc Haber's proposal won every matchup. It beat Lucas Nussbaum's 203 to 148, Tobias Frost's 210 to 130 and Pierre-Elliott Becue's 232 to 115. The most revealing detail of the tally is not who won, but who lost: the two hard ban proposals, from Matthias Geiger and Ian Jackson, were defeated even by "None of the above". Debian's base did not reject only their wording, it rejected the idea of prohibiting.
Why "Neither Endorses Nor Prohibits" Is the Important Part
The approved text is short and fits into five commitments. It is worth reading each one carefully, because the wording was picked deliberately:
- Debian neither endorses nor prohibits the use of generative AI tools in the development, maintenance or documentation of software, packaging and other media published by the project.
- Every contribution meets the same standard, regardless of how and with which tool it was produced: quality, correctness, maintainability and legal compliance.
- The tool does not dilute responsibility. Whoever submits remains accountable for the contribution. The expectation is explicit: understand, review, test and, when it makes sense, modify the AI output before merging it in.
- Every automated process needs human supervision, and that human answers for the behavior of the process.
- Disclosure is encouraged, but not required. The text treats transparency as a courtesy toward other contributors, not as an acceptance requirement.
Notice what item 5 avoids. A mandatory disclosure requirement only works if someone can verify it, and nobody can prove that a thirty-line function came out of a model or out of the head of the person who wrote it. The pro-AI camp argued exactly that during the debate: an unenforceable rule does not produce compliance, it produces witch hunts against whoever looks suspicious. The opposing camp answered with the question that still has no good answer, about how a contributor certifies the legal status of a snippet they did not write.
Debian resolved the tension by pushing the entire problem to the only place it has always lived: the person who signs off. It is not a policy about AI, it is a policy about responsibility that happens to mention AI.
The Policy Map: Who Bans, Who Allows, Who Has Not Decided Yet
Debian did not define a consensus, it defined its own position. The ecosystem is still split, and if you contribute to more than one project you need to know where you are stepping.
Who bans it:
- Gentoo is the most direct. It expressly forbids contributing any content created with the help of natural language processing AI tools. The reasons cited are copyright, quality and ethics.
- NetBSD treats LLM-generated code as tainted code by presumption. It cannot be committed without prior written approval.
- QEMU refuses contributions it believes contain or derive from AI-generated content. The argument is legal and elegant: since the copyright status of the output is still unresolved and the training data may include code under an incompatible license, the contributor cannot honestly certify the Developer Certificate of Origin.
Who allows it with rules:
- The Linux kernel went down a path similar to Debian's, but with more mechanics. It permits AI-assisted contributions and created a dedicated trailer for it, which is the subject of the next section.
Who has not settled it yet:
- Fedora, Rust, FreeBSD, GCC, Blender, NixOS and Jupyter have live discussions and no consolidated policy.
The whole fight, notice, is almost never about code quality. It is about provenance. QEMU does not say the model's code is bad, it says nobody knows whose it is. And it is worth separating that legal discussion from the quality discussion, which also exists and has data of its own. I already talked about that when the study on the impact of vibe coding on open source came out, and the two conversations run on different tracks.
The Assisted-by Trailer: The Rule You Will Hit First
If you are going to contribute to the kernel, this is the practical part. The official documentation at docs.kernel.org/process/coding-assistants.html establishes two non-negotiable rules.
The first is a prohibition: AI agents cannot add a Signed-off-by. Only a human can legally certify the Developer Certificate of Origin. The second is a new trailer format to credit the assistance:
# Format defined by the kernel documentation
# Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
git commit -s -m "net: fix reference leak in the error path
The error path of xyz_probe() did not release the device reference
when the buffer allocation failed.
Assisted-by: Claude:claude-3-opus coccinelle sparse"Two subtleties make a difference. The -s flag of git commit adds your Signed-off-by, and it is still mandatory: Assisted-by credits, it does not replace. And the tool list in brackets is for specialized analyzers, such as coccinelle, sparse, smatch and clang-tidy. Basic development tooling does not belong there. Do not list git, gcc, make or your editor.
The rest of the process does not change: the code must be compatible with GPL-2.0-only, it cannot introduce build warnings and it has to pass checkpatch.pl.
Automating the Policy in Your Repository
A policy that depends on human memory fails in the third week. If you maintain a project and adopted a rule similar to Debian's or the kernel's, put it in a hook. The commit-msg hook runs before the commit exists and can stop the problem at the source:
#!/usr/bin/env bash
# .git/hooks/commit-msg
# Ensures that an AI agent does not sign the DCO and that the
# Assisted-by trailer follows the AGENT:MODEL format.
set -euo pipefail
MSG_FILE="$1"
# List of agent identifiers that can never sign the DCO
AGENTS="Claude|Copilot|Codex|Cursor|Gemini|GPT"
if grep -qiE "^Signed-off-by:.*($AGENTS)" "$MSG_FILE"; then
echo "ERROR: an AI agent cannot sign the Developer Certificate of Origin." >&2
echo "Use the Assisted-by trailer and sign it yourself with git commit -s." >&2
exit 1
fi
# If Assisted-by exists, validate the AGENT:MODEL format
if grep -q "^Assisted-by:" "$MSG_FILE"; then
if ! grep -qE "^Assisted-by: [A-Za-z0-9._-]+:[A-Za-z0-9._-]+" "$MSG_FILE"; then
echo "ERROR: invalid Assisted-by format." >&2
echo "Expected: Assisted-by: AGENT:MODEL [tool1] [tool2]" >&2
exit 1
fi
# An assistance trailer requires a human Signed-off-by in the same commit
if ! grep -q "^Signed-off-by:" "$MSG_FILE"; then
echo "ERROR: a commit with Assisted-by needs a human Signed-off-by." >&2
exit 1
fi
fi
exit 0A local hook, however, only protects whoever installed the hook. It solves your case and the case of anyone who cloned with core.hooksPath configured, and it does not solve the PR that arrives from outside.
Taking the Check to CI
The check that counts is the one running on the server, across every commit in the PR. This action scans the pull request range and fails when it finds a DCO signed by an agent:
# .github/workflows/ai-policy.yml
name: Assisted contribution policy
on:
pull_request:
jobs:
trailers:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
# Needs the full history to scan the PR range
fetch-depth: 0
- name: Check trailers of every commit in the PR
env:
BASE: ${{ github.event.pull_request.base.sha }}
HEAD: ${{ github.event.pull_request.head.sha }}
run: |
failed=0
for sha in $(git rev-list "$BASE".."$HEAD"); do
body=$(git log -1 --format=%B "$sha")
if echo "$body" | grep -qiE "^Signed-off-by:.*(Claude|Copilot|Codex|Cursor|Gemini|GPT)"; then
echo "::error::$sha has a Signed-off-by from an AI agent"
failed=1
fi
if echo "$body" | grep -q "^Assisted-by:" \
&& ! echo "$body" | grep -q "^Signed-off-by:"; then
echo "::error::$sha declares Assisted-by without a human Signed-off-by"
failed=1
fi
done
exit $failedAn honest warning about how far this goes: nothing here detects AI-generated code. It detects a malformed trailer and an improper signature, which is what can actually be verified. It was by acknowledging that limit that Debian left disclosure as a courtesy instead of a requirement.
Writing Your Project's Policy
If you maintain a project and have not written anything about this yet, CONTRIBUTING.md is the place. The template below follows Debian's line, which in practice is the easiest to sustain because it does not promise enforcement you cannot deliver:
## AI-assisted contributions
This project neither endorses nor prohibits the use of generative AI tools.
Every contribution goes through the same criteria, whatever the tool:
quality, correctness, maintainability and license compliance.
Using a tool does not transfer responsibility. By opening a PR you
declare that you understood, reviewed and tested the code you are
submitting, and that you will answer for it in review.
Disclosing the use of assistance is encouraged as a courtesy toward the
review team, and it is not mandatory. If you want to declare it, use the
trailer:
Assisted-by: AGENT:MODEL
Automated agents do not sign the DCO. The Signed-off-by always belongs to
a person.Adapt the last line to your context: if the project does not use a DCO, swap it for whoever answers for the review. What matters is the structure, which separates three things usually mixed into the same sentence: what is allowed, what the quality standard is and who carries the responsibility.
What Changes in Your Contributor Routine
In practice, four things.
Read the policy before your first PR. That stopped being optional. A perfectly good patch gets rejected in NetBSD and in Gentoo over a criterion Debian does not apply. Look for CONTRIBUTING.md, for the Code of Conduct and for some policy page before investing hours.
Assume you will have to defend the code. Debian's and the kernel's standard forces you to understand what you submitted. If you cannot explain why a line is there during review, the problem is not that the tool wrote it, it is that you did not review it.
Treat provenance as part of the delivery. Code with a questionable license is your problem, not the model's. If the output looks like a known implementation from some project, check it before submitting.
Declare it when it helps. It is not mandatory almost anywhere, but it helps reviewers calibrate their attention, and you lose nothing by doing it.
Outlook: What Comes After the Vote
Debian's weight makes "Responsible Use" a reference text. Smaller projects will likely copy the structure, the same way they copied Debian's Social Contract and Free Software Guidelines. The distance between Debian's position and the Linux kernel's is also smaller than it looks, and both converge on the same point: a human signs, a human answers.
What remains open is the legal question QEMU raises and nobody has answered, about the copyright status of the output of a model trained on code under an incompatible license. Until that is settled in court, each project will calibrate its own risk. Fedora, Rust and FreeBSD have the discussion open right now, and Debian's result will weigh on those debates.
For you, the immediate effect is simple and worth more than any forecast: the question stopped being "can I use AI?" and became "do I understand what I am submitting?". That second question is harder, and it has always been the only one that mattered.
Let's go! 🦅
📚 Want to Keep Up With What Is Coming?
This article covered Debian's vote on generative AI, but the ecosystem changes every week and not everything turns into an article here.
On X I share what I am testing, the behind the scenes of my projects and the news that shows up before it becomes a post.
Follow Me There
💡 Daily content about development, career and the tools I actually use