SQLite won't accept AI-written code, but QEMU just opened the door to it

Two of open source’s most careful C projects just answered the same question in opposite ways. SQLite drew a hard line against AI-written contributions. QEMU, which had banned them outright, decided to let some back in. Same month, same dilemma, and the gap between them shows that open source has no shared rule for AI-generated code.

This matters far beyond databases and emulators. Every maintainer who runs a public repo is about to make the same call, and the projects you depend on are already splitting into camps. The fault line isn’t whether AI code is good or bad. It’s who can legally promise they own the copyright on a patch, and what happens to a project’s license if nobody can.

What each project actually decided

SQLite’s stance lives in a file called AGENTS.md in the source tree. The wording is blunt: “SQLite does not accept agentic code.” The project will still take “agentic bug reports that include a reproducible test case,” and a proof-of-concept patch for documentation purposes is welcome, but generated code itself is out. A recent commit deleted the word “(currently)” from that statement, with the message that it was meant to strengthen the position. Translation: this isn’t a temporary hold. It’s the policy.

D. Richard Hipp’s project has a structural reason to be strict. SQLite is famously in the public domain, with contributors signing legal paperwork to keep it that way. Code of murky origin is exactly the kind of thing that can poison a public-domain claim. So the door is shut, and the project even spun up a separate bug forum to absorb the wave of machine-generated reports without drowning the main one.

QEMU went the other way, and it’s the more surprising move because QEMU got there first on banning. Back in mid-2025, Daniel P. Berrangé and Markus Armbruster landed a policy that, in QEMU’s own code-provenance docs, declared the project would “DECLINE any contributions which are believed to include or derive from AI generated content.” The reason was the DCO: given “the fuzziness over the legal position of generated code,” Berrangé wrote, he didn’t consider it “credible (today) for a contributor to assert compliance with the DCO terms.”

Why QEMU reversed itself

In May 2026, Red Hat’s Paolo Bonzini posted a patch to walk that ban back, and Phoronix reported on May 28 that other QEMU developers seemed on board. The new shape is narrow on purpose. AI assistance is allowed “where the ramifications of copyright violations are at least easy to revert and unlikely to spread”: tests, documentation, mechanical changes, and small bug fixes. “Core code that other things depend on, and that cannot simply be thrown away once a problem is noticed long after the fact, stays off-limits without prior agreement from a maintainer.”

There’s a disclosure hook too. Contributors using AI have to add an “AI-used-for:” tag explaining where and how they used it. That’s the same instinct the Linux kernel codified: name the tool, keep a human on the hook.

What changed Bonzini’s risk math? Time. The original ban bet that the legal uncertainty would clear up “perhaps a few years down the line.” A year in, projects accepting AI-assisted content hadn’t hit serious legal trouble, which nudged the perceived probability of disaster down. QEMU didn’t decide AI code is safe. It decided the blast radius is survivable if you confine it to the parts you can rip out later.

The real fight is provenance, not quality

Strip away the headlines and both projects are arguing about the same three letters: the DCO. When you sign off on a kernel or QEMU patch, you’re certifying you have the right to submit that code under the project’s license. If an LLM trained on a billion lines of unknown-license code wrote your patch, that certification gets shaky fast. You can’t promise provenance you don’t have.

Gentoo named this first and loudest. When its council banned AI contributions in April 2024, the motion listed copyright as the lead concern: generated material “could pose a danger of copyright violations, but it could also weaken Gentoo claims to copyright and void the guarantees given by copyleft licensing.” That second clause is the scary one for any GPL or AGPL project. A copyleft license only works if the project owns the copyright it’s enforcing. Untraceable code chips at that foundation.

Quality is the other half, and it’s where the burden lands on humans. Gentoo’s motion warned that LLMs are “really great at generating plausibly looking, but meaningless content,” which forces “an unfair human effort from developers” to catch the mistakes. That’s the slop-PR problem in one sentence. A maintainer’s scarcest resource is review attention, and a flood of confident-looking, subtly-wrong patches burns it faster than honest human bugs do.

Nobody has felt that burn harder than curl’s Daniel Stenberg. After roughly 20% of his bug-bounty submissions turned into AI slop and volume spiked to eight times normal, curl shut down its HackerOne bug bounty entirely on January 31, 2026. Stenberg had even tried instant bans for AI-generated reports. It didn’t stem the tide. When a project as battle-hardened as curl folds a 7-figure-impact program because the noise floor got too high, the cost of AI slop stops being theoretical.

Where everyone else landed

The middle path is winning, and the Linux kernel drew the map. Its AI coding assistants policy allows AI-written code but bans AI from adding the legally binding “Signed-off-by” line. Only a human can certify the DCO. Instead, AI use gets an “Assisted-by:” tag, and every bug or security hole in that code lands on the human who sent it. The trigger was an Nvidia engineer whose LLM-written patch reached Linux 6.15 before its AI origin was disclosed.

So here’s the spread as of now:

• Hard no: SQLite refuses agentic code; Gentoo bans AI-assisted contributions outright. The PS3 emulator RPCS3 took a similar line, banning contributors who hide AI use in their pull requests.
• Conditional yes: QEMU (low-risk areas plus an “AI-used-for:” tag), the Linux kernel (allowed with an “Assisted-by:” tag and full human responsibility).
• Adjacent pressure: the licensing fights underneath all of this, from the FSF clarifying how AGPLv3 terms work to projects like Warp going AGPL on open-sourcing, are the same copyright machinery that AI provenance now stress-tests.

The pattern isn’t random. Public-domain and strict-copyleft projects skew toward no, because they have the most to lose if provenance breaks. Projects with maintainer-heavy review cultures lean toward conditional yes, because they trust a tagged disclosure plus a human signature to hold the line.

What this means for you

Don’t assume anything. The single takeaway from the SQLite-versus-QEMU split is that there’s no portable rule for AI-assisted contributions anymore, and guessing wrong gets your patch closed or gets you banned. Before you send code to any project, read its policy. Look for an AGENTS.md, a CONTRIBUTING file, or a code-provenance doc. If the project bans AI code, respect it, and don’t try to launder a generated patch through manual edits. If it allows AI in limited areas, use the exact tag it asks for (“AI-used-for:”, “Assisted-by:”, whatever it specifies) and confine your AI use to the zones it names.

And whatever the policy, own your patch. Every conditional-yes project agrees on one thing: a human signs the DCO and a human eats the consequences. If you can’t read a generated diff line by line and defend it in review, you’re not ready to submit it. The maintainers absorbing the slop wave can tell the difference, and their patience is the resource you’re spending.