QEMU Bans AI Code Despite Good Process

Category: Case Study Date: June 24, 2025 Sector: Open Source Virtualization Sources last verified 17 October 2026

The Decision

On June 24, 2025, the QEMU project — the widely-used open source machine emulator and virtualizer — formally adopted a policy banning all AI-generated code contributions.

"Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools."

Unlike Gentoo's ideological crusade or NetBSD's silent update, QEMU's ban emerged from genuine mailing list discussion with multiple revisions. This makes it a more interesting case study: even with proper process, the outcome was still a sweeping ban decided by non-experts.

The Process: Better, But Still Flawed

Credit where due: QEMU's process was more transparent than its peers.

The Timeline

November 2023: Daniel P. Berrangé (Red Hat) posts initial patches
2024: Discussion stalls; Berrangé worries policy "might go too far"
June 2025: Markus Armbruster revives and refines the proposal (v3, v4, v5)
June 24, 2025: Stefan Hajnoczi commits the policy

The Participants

Participant	Affiliation	Expertise
Daniel P. Berrangé	Red Hat	Virtualization (libvirt lead)
Markus Armbruster	Red Hat	Virtualization (QAPI/QMP)
Stefan Hajnoczi	Red Hat	Virtualization
Peter Maydell	-	Virtualization (ARM)
Michael S. Tsirkin	Red Hat	Virtualization
Kevin Wolf	Red Hat	Virtualization (block layer)
Gerd Hoffmann	Red Hat	Virtualization (graphics)

Notice a pattern? Every single participant is a virtualization engineer. Most work for Red Hat. None have demonstrated expertise in AI, machine learning, or even intellectual property law — the very domains central to the policy's rationale.

The Echo Chamber Problem

QEMU's discussion had multiple revisions and genuine back-and-forth. But it was still an echo chamber — just a well-organized one.

No AI/ML Experts

The policy makes sweeping claims about how LLMs work, how they're trained, and what their outputs represent legally. Yet no one with actual AI expertise participated. Questions that an ML engineer might have raised:

Do LLMs actually "copy" training data, or do they learn statistical patterns?
Is there meaningful difference between autocomplete suggestions and full generation?
What does the empirical research say about LLM output and training data similarity?

These questions were never asked because no one in the room knew to ask them.

No Legal Experts

The entire rationale hinges on legal risk — DCO compliance, copyright, licensing. Yet no intellectual property lawyers participated. The developers made legal judgments based on their interpretation of legal documents, not actual legal advice.

Berrangé's key argument:

"I don't consider it credible (today) for a contributor to assert compliance with the DCO terms (b) or (c) (which is a stated pre-requisite for QEMU accepting patches) when a patch includes (or is derived from) AI generated code."

This is a legal conclusion reached by a virtualization engineer. It may be correct. It may be wrong. The point is: they don't actually know, and they didn't ask anyone who would.

The Autocomplete Problem

Perhaps the most striking flaw in QEMU's policy is its failure to distinguish between fundamentally different use cases.

What's Banned

The policy explicitly names "Copilot" alongside ChatGPT and Claude. There is no carve-out for autocomplete. This means:

Accepting a 3-character variable name suggestion from Copilot — banned
Using Copilot to complete for i in range( — banned
Any code that touched an AI autocomplete — banned

Was This Discussed?

Yes, briefly. Michael S. Tsirkin asked: "Can we soften this to only apply to expressive code?" — suggesting mechanical refactoring tasks might warrant different treatment than creative code.

Daniel P. Berrangé's response was dismissive:

"Trying to detail every possible scenario is impractical and would make the document too onerous for people to read, remember & apply."

Translation: "We can't be bothered to think about nuance, so we'll ban everything and make it the contributor's problem."

The Reality of Modern Development

According to GitHub's 2024 Open Source Survey, 72% of open source developers use AI tools for coding or documentation. Copilot is integrated into VS Code, JetBrains, and most modern IDEs. For many developers, AI autocomplete is as routine as syntax highlighting.

QEMU's policy effectively tells these developers: disable your tools, or lie about using them. Given that the policy is unenforceable, the honest developers are penalized while the dishonest face no consequences.

The "Start Strict" Fallacy

Daniel P. Berrangé argued the policy is provisional:

"It's best to start strict and safe, then relax."

This sounds reasonable but inverts the burden of proof. The policy:

Assumes AI code is dangerous until proven safe
Requires contributors to seek exceptions case-by-case
Places the burden on individuals to prove compliance

Meanwhile, there's no documented incident of AI-generated code causing legal problems for QEMU. The entire policy is preemptive — addressing a theoretical risk with a concrete restriction.

"Start strict, relax later" also assumes relaxation will actually happen. While restrictive policies often become entrenched, QEMU proved to be a partial exception eleven months later — though only after a different senior maintainer stepped in to argue the blanket ban was unworkable (see 2026: The Push to Relax the Ban below).

The Red Hat Irony

Here's a curious fact: most QEMU AI policy participants work for Red Hat. And Red Hat, as a company, is heavily invested in AI.

InstructLab: Red Hat's open source project for contributing to and fine-tuning LLMs
vLLM: Red Hat is the main corporate contributor to this UC Berkeley LLM inference project
Red Hat AI: Enterprise AI platform launched in 2024

Red Hat's official position champions open source AI: "We have always believed in the power of open source development in driving innovation."

So Red Hat engineers banned AI contributions to QEMU while Red Hat the company invests millions in AI development. This wasn't corporate policy — it was individual engineers being more cautious than their employer. And when Red Hat's corporate legal assessment of AI risk matured, it was another Red Hat engineer who led the effort to unwind the blanket ban.

2026: The Push to Relax the Ban

On May 28, 2026 — eleven months after QEMU's ban was merged — Red Hat Distinguished Engineer and KVM/QEMU maintainer Paolo Bonzini posted a patch series to qemu-devel proposing to replace QEMU's blanket prohibition with a risk-tiered policy.

Bonzini's rationale directly addressed the assumptions behind the 2025 ban: while the theoretical copyright questions around LLMs had not been settled by statute, "projects accepting AI-assisted content have not run into serious legal trouble so far, which suggests the probability of the risk materializing is not high," and major corporate contributors (including Red Hat) had assessed the risk as acceptable under human review. Through September 2026, Bonzini refined the proposal into a comprehensive policy overhaul (docs/devel/llm-usage.rst and AGENTS.md; Linuxiac, freenode):

Permitted in low-risk, easily revertible areas: AI assistance is allowed for test cases, documentation, mechanical refactoring, and small bug fixes (around 20 lines or fewer) where any hypothetical provenance issue would be localized and easy to replace.
Core code requires pre-arrangement: Foundational infrastructure and large new features (such as new device models) remain off-limits to AI generation unless explicitly pre-arranged with subsystem maintainers.
Disclosure via AI-used-for: trailer: Contributors declare AI assistance by category (e.g., AI-used-for: tests, docs) ahead of their human Signed-off-by:, while commit messages, cover letters, and review replies must remain human-written.

As of October 2026, QEMU's live Code Provenance documentation still displays the June 2025 blanket ban while Bonzini's replacement series undergoes final mailing-list review. Even before merge, however, the episode validates the core critique of the 2025 ban: treating a three-line test or mechanical refactoring identically to a thousand-line subsystem was unsustainable in practice.

Comparison: Process vs. Outcome

Project	Process Quality	Expert Input	Outcome
Gentoo	Poor (author voted on own RFC)	ML engineer ignored	Full ban
NetBSD	None (silent update)	None sought	Effective ban
QEMU	Good (multiple revisions)	None (all virtualization engineers)	Full ban (2025); relaxation in review (2026)
Debian	Good (open debate + 2026 GR)	Broad DD electorate (425 voters)	No ban ("Responsible Use")
Fedora	Good (council discussion)	N/A	Allow with disclosure

QEMU demonstrates that good process doesn't guarantee good outcomes. You can have multiple revisions, mailing list discussion, and transparent decision-making — and still produce a flawed policy if everyone in the room shares the same blind spots.

What Would Better Governance Look Like?

If QEMU wanted to address AI concerns responsibly from the start, they could have:

Consulted AI researchers about how LLMs actually work and whether the "training data copying" concern is technically valid
Sought legal counsel on DCO interpretation rather than making legal conclusions as engineers
Distinguished use cases: autocomplete vs. generation, small suggestions vs. large blocks — the exact distinction Paolo Bonzini had to retrofit in 2026
Studied other approaches: Apache Foundation's disclosure-based policy, Fedora's transparency requirements, Mozilla's responsibility framework
Gathered evidence: has AI-generated code actually caused problems? For QEMU or anyone?

Instead, virtualization engineers debated among themselves about legal and AI matters they don't specialize in, reached consensus within their echo chamber, and called it a day.

Editorial: The Limits of Process

QEMU's AI ban is instructive precisely because the process was reasonable. This wasn't Gentoo's ideological crusade or NetBSD's bureaucratic fiat. Real engineers had real discussions and made real revisions.

And yet the initial outcome was still a blanket ban that:

Made no distinction between autocomplete and full generation
Was decided without AI/ML or legal expertise
Addressed theoretical risks with concrete restrictions
Punished honest contributors while being unenforceable against dishonest ones
Contradicted the AI-friendly stance of the participants' own employer

The lesson isn't that process doesn't matter — it does. NetBSD's silent update was worse, and QEMU's open mailing list culture at least made it possible for Bonzini to reopen the question a year later when the evidence didn't support the fear. But process alone isn't sufficient. Who participates matters as much as how they participate.

A room full of virtualization engineers will reach virtualization-engineer conclusions about AI policy. They'll focus on what they understand (DCO compliance, code provenance) and gloss over what they don't (how LLMs work, what modern development looks like, actual legal risk assessment).

QEMU needed voices in the room who could say: "Wait, have we actually talked to anyone who understands this technology?" Instead, they got consensus among the like-minded — the definition of an echo chamber, however well-organized.

💻 QEMU Bans AI Code Despite Good Process