📋 libvirt Copies QEMU Ban Without Thinking

The Decision

On July 10, 2025, the libvirt project — the widely-used virtualization API library that powers tools like virt-manager, oVirt, and OpenStack — adopted a policy banning all AI-generated code contributions.

"Current libvirt 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."

What makes this case study particularly interesting isn't just the ban itself — it's how it happened. The libvirt maintainers didn't deliberate. They didn't consult experts. They didn't even write their own policy. They simply copied QEMU's ban, changed the project name, and called it done.

The "Process": Copy, Paste, Ship

Pavel Hrdina (Red Hat) proposed the ban with disarming honesty about the lack of independent analysis:

"This policy is a copy of what QEMU project is using as there is no reason to use different policy, only modification is changing the project name and link to DCO."

That's it. No independent legal review. No consultation with AI researchers. No community survey. No consideration of whether libvirt's situation might differ from QEMU's. Just: "QEMU did it, so we'll do it too."

The Timeline

The entire "deliberation" took place in a single day. Hrdina mentioned he was "planning to wait a week or two to give most maintainers enough time for comments" — but the approvals came within hours.

The Participants

Three maintainers. Two from Red Hat. One from SUSE. Zero AI experts. Zero lawyers. Zero public debate.

Jim Fehlig's Revealing Comment

Jim Fehlig's approval is particularly telling:

"I read the policy when proposed on the QEMU list and thought it would be relevant for other projects in the opensource virt ecosystem."

This is follow-the-leader governance stated explicitly. Fehlig didn't independently evaluate whether an AI ban made sense for libvirt. He saw QEMU do it and thought "we should too." The policy spread through the virtualization ecosystem not through deliberation, but through imitation.

The Berrangé Connection

Daniel Berrangé — the Red Hat engineer who proposed QEMU's ban — signaled just weeks before that libvirt should follow suit:

"The QEMU proposal isn't merged yet, but we should keep an eye on it, as the position would apply equally to libvirt as QEMU."

So the same person who drove QEMU's ban also signaled that libvirt should follow suit. When QEMU's ban was finalized, libvirt's adoption was essentially predetermined.

The Real-World Consequence: Cole Robinson's Dilemma

The absurdity of copy-paste policy became apparent when Cole Robinson — a Principal Software Engineer at Red Hat, the maintainer of virt-manager, and a libvirt co-maintainer — ran into an awkward situation.

Robinson used Claude Code to generate patches for adding sound model capabilities to libvirt's domain capabilities system. The code was entirely boilerplate — standard plumbing that any experienced developer would write identically. As Robinson noted:

"There does not appear to be a single novel line in the whole series."

But here's the problem: he'd already looked at the AI-generated code. So he asked the mailing list a pointed question:

"But in a copyright sense am I tainted by looking at the generated code? If I wanted to write the patches by hand they likely will end up looking identical, down to the character. Creates a weird scenario IMO."

Robinson shared the "forbidden" patches with a darkly humorous warning:

"The patches are here, gaze not upon them lest ye too be corrupted."

The Absurdity Exposed

Think about what this policy created:

• A senior Red Hat engineer, libvirt co-maintainer, used AI to write boilerplate code
• The code contains "not a single novel line" — any human would write it identically
• Now he questions whether he's legally "tainted" and can't contribute manually-written identical code
• Other developers who merely looked at his patches might also be "corrupted"

This is what happens when you copy a policy without thinking through its implications. The ban doesn't distinguish between creative code and mechanical boilerplate. It treats all AI assistance as equally dangerous, creating absurd situations where experienced maintainers wonder if they've been legally contaminated by viewing standard code patterns.

The Red Hat Irony (Again)

Just like with QEMU, there's a striking irony here. The libvirt AI ban was proposed and approved almost entirely by Red Hat employees. Yet Red Hat as a company is heavily invested in AI:

• InstructLab: Red Hat's open source LLM fine-tuning project
• Red Hat AI: Enterprise AI platform launched in 2024
• vLLM: Red Hat is a major contributor to this LLM inference engine

Red Hat officially champions AI and open source working together. But Red Hat engineers, acting in their capacity as open source maintainers, ban AI from the projects they control.

This isn't corporate policy — it's individual engineers being more restrictive than their employer. And now one of those same Red Hat engineers (Cole Robinson) is questioning whether he's been "tainted" by the policy his colleagues created.

Comparison: Governance Quality

libvirt's governance is arguably worse than NetBSD's. At least NetBSD's silent commit was an original decision, however flawed. libvirt didn't even bother to think — they just copied someone else's homework.

The Ecosystem Effect

libvirt's copy-paste approach reveals a troubling pattern in open source governance: policy contagion.

When a prominent project like QEMU adopts a policy, related projects feel pressure to follow. Not because they've independently concluded it's the right choice, but because:

• "They did it, so we probably should too"
• "It's easier to copy than to think"
• "If something goes wrong, at least we're in good company"

Jim Fehlig made this explicit: he thought the policy "would be relevant for other projects in the opensource virt ecosystem." The ban spreads not through deliberation, but through social proof.

This is how bad policy propagates. One project makes a questionable decision, and others copy it without scrutiny. The original flaws — no expert consultation, no distinction between use cases, no evidence of actual harm — are faithfully reproduced.

Editorial: The Danger of Copying

libvirt's AI ban is a case study in governance failure. Not because the maintainers are incompetent — they're clearly skilled engineers. But because they confused "following a peer project" with "making a good decision."

Good governance requires:

• Independent analysis: Does this policy make sense for our project?
• Stakeholder input: What do our contributors think?
• Expert consultation: Do we understand the technical and legal issues?
• Consequence consideration: What edge cases might this create?

libvirt did none of these. They saw QEMU's policy, thought "seems reasonable," and adopted it wholesale. Within months, one of their own senior maintainers was asking whether he'd been legally "tainted" by boilerplate code.

The lesson: copying is not governance. Every project has different circumstances, different contributors, different needs. What works (or doesn't work) for QEMU isn't automatically right for libvirt. But by copying without thinking, libvirt imported not just QEMU's policy, but all its flaws.

Cole Robinson's "gaze not upon them lest ye too be corrupted" isn't just dark humor. It's a perfect summary of what happens when policy spreads through imitation rather than deliberation.

References

• libvirt-devel: Pavel Hrdina's Policy Proposal (Primary Source)
• libvirt-devel: Pavel Hrdina on Waiting for Comments
• libvirt-devel: Jim Fehlig's Approval
• libvirt-devel: Berrangé's Earlier Discussion
• libvirt-devel: Cole Robinson's "Tainted" Question
• QEMU Code Provenance Documentation (Original Policy)
• libvirt AUTHORS File
• Cole Robinson - Fedora Project Wiki
• Hacker News Discussion