Flathub vs. QEMU: The Open Source Community Can't Agree on AI-Generated Code

The policy does include a narrow exception for "mature, well-maintained projects," but the documentation makes clear this is not a guarantee . Submissions can be rejected at any stage or even recalled after merging if found non-compliant . Existing apps with AI-generated code remain on Flathub — the ban is not retroactive — but new AI-assisted submissions are effectively blocked from now on .

Flathub didn't try to draw nuanced lines between acceptable and unacceptable AI use. It chose prohibition because triage itself had become the unsustainable cost. The platform was protecting reviewer attention and mental health rather than trying to fix a legal system still catching up to the technology.

QEMU's reversal: testing a disclosure middle ground

QEMU had adopted one of open source's strictest AI policies in mid-2025. Its formal code provenance rules stated that any contribution believed to include or derive from AI-generated content — from ChatGPT, Claude, Copilot, Llama, and similar tools — would be declined . The stated rationale was that AI code cannot satisfy the Developer's Certificate of Origin (DCO) because there is no human author to make the required attestations .

But by late May 2026, the project was moving in the opposite direction. Paolo Bonzini, a distinguished engineer at Red Hat and KVM maintainer, proposed permitting AI-assisted patches in limited, low-risk areas — specifically where the ramifications of copyright violations are easy to revert and unlikely to spread. Core code would remain off-limits without prior maintainer agreement .

Bonzini's rationale was pragmatic. Projects that accept AI-assisted contributions have not yet faced serious legal trouble, and Red Hat's own legal team assessed the risk as acceptable for defined categories of changes . The proposal adds a mandatory disclosure requirement, asking contributors to flag AI-generated portions explicitly rather than hiding them .

QEMU is effectively betting that a transparency-based middle path can work where a blanket ban creates friction without proportional legal benefit — especially for mechanical contributions like test cases, documentation fixes, and small patches.

Why the DCO is the fault line

Both Flathub's hard ban and QEMU's cautious relaxation orbit the same unresolved legal question: what happens when AI-generated code meets the Developer's Certificate of Origin?

The DCO requires contributors to certify that they created the contribution or have the right to submit it under the project's license. But AI-generated code has no identifiable human author under current law. The US Copyright Office ruled in January 2025 that AI outputs can only be copyrighted where a human has contributed sufficient expressive elements — and prompting alone is not enough . In Thaler v. Perlmutter, the D.C. Circuit affirmed in March 2025 that the Copyright Act requires human authorship in the first instance, and as of March 2026 the Supreme Court had declined to hear further challenges .

This creates an uncomfortable bind. A developer who submits AI-generated code may be unable to truthfully sign the DCO. The Linux kernel's response — formalized in April 2026 with its first-ever AI coding assistants policy — was to require that only humans add Signed-off-by tags and that the human takes full legal responsibility for all AI-generated lines . But QEMU's original ban reasoned that asserting DCO compliance with AI code is "not considered credible" given the licensing ambiguity .

No court has definitively settled whether AI-generated code can be copyrighted, who holds those rights if so, or what downstream license obligations attach. Projects are making their own risk calculations because the legal system hasn't given them a clear one yet.

The human cost beyond copyright

The legal debate is important, but maintainer burnout is what actually pushed Flathub over the edge. Maintainers across multiple projects report the same pattern: AI-generated submissions are often voluminous but shallow — large diffs with little genuine understanding — producing a review burden disproportionate to their value .

GNOME Shell extensions faced a similar flood. In late 2025, reviewers reported receiving over 15,000 lines of AI-generated extension code in some days, along with AI-generated responses to review questions . Flathub maintainer Piotrowski summarized the breaking point bluntly, stating the policy was necessary because some submitters "simply do not know how to communicate properly" .

The human cost is inseparable from the legal one. The DCO question matters because maintainers face real liability for code they accept. The burnout question matters because maintainers are volunteers operating on thin margins of time and goodwill. AI-generated submissions strain both at once.

Three camps, no consensus

A February 2026 RedMonk analysis surveyed 32 open source organizations and found no emerging consensus . Projects have divided into three rough camps:

• Total bans: Flathub, Gentoo (unanimous council vote in 2024), NetBSD (calling AI code "presumed to be tainted"), and GNOME's EGO review system all prohibit AI-generated contributions outright .
• Conditional acceptance with disclosure: QEMU's proposal would join Apache, Fedora, the Linux Foundation, and the EFF, all of which allow AI use with mandatory labeling and maintainer discretion .
• Permissive with human accountability: The Linux kernel and Red Hat permit AI use if the human developer takes full responsibility, signs the DCO, and tags the tool used — but the Signed-off-by remains reserved exclusively for humans .

These camps don't just disagree on policy. They disagree on whether AI code is a tool to be managed or a threat to be excluded — and on whether the cost of managing it falls on maintainers or on a legal system that isn't ready.

What happens next

Flathub and QEMU are not outliers. They are data points on a spectrum that will continue to widen as AI coding tools improve and the volume of generated submissions increases. Some observers note that detecting AI-generated code will become functionally impossible within a year or two, which would render bans unenforceable regardless of their intent .

The EFF has already concluded that a blanket ban is impractical to enforce given how pervasive LLM use has become . But practical unenforceability doesn't solve the burnout problem that drove Flathub's decision in the first place.

Until court rulings or legislation establish clear rules for AI-generated code authorship and liability, every open source project is essentially picking its own gamble. Flathub chose to protect its reviewers now, at the cost of closing the door to AI tooling. QEMU is choosing to open the door narrowly, with a transparency requirement and a bet that the legal risk is manageable for low-stakes contributions. Both moves are rational given the available information. They just reflect different answers to the same unsettling question: in a community built on human authorship and volunteer labor, what do you do when the code arrives without either?