Deep dive · 2026-08-10 · Oracle bans AI-generated code from OpenJDK and allows it in GraalVM — same company, opposite calls. The variable that decides isn’t the tool. It’s whether you can warrant where the code came from.

Start with the contradiction, because the contradiction is the whole argument.

In early April 2026, OpenJDK — the reference implementation of Java, the runtime under a large fraction of the world’s mission-critical software — banned generative-AI contributions outright. The policy language is blunt: “Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems.” It covers source code, text, images, pull requests, emails, wiki pages, and issue tracker entries. And it means partial: the FAQ spells out that if an AI writes 100 lines and you hand-edit ten of them, the contribution is still forbidden. (Ordinary spell-check, grammar-check, and autocomplete are fine — “so long as they are not based on large language models.”)

A few weeks later, in mid-April, GraalVM — an Oracle Labs project — published the opposite rule: “GraalVM contributors may use AI coding assistants and similar tools when preparing contributions.” Disclosure of AI use is encouraged but optional. Attribution to a specific model is optional.

Same parent company. Same base legal agreement. Opposite policies, published within a month of each other. And all of it while Larry Ellison bets Oracle’s future on AI. “The code that Oracle is writing, Oracle isn’t writing,” Ellison told the company’s AI World conference, per The Register’s reporting. “Our AI models are writing.” Oracle is cutting headcount on the strength of exactly the AI-written code it won’t let near OpenJDK.

The easy read is hypocrisy or bureaucratic drift. It’s neither. Oracle is being perfectly consistent about the one thing that actually varies between the two projects — and it isn’t the quality of the code, the capability of the model, or the productivity of the contributor. It’s provenance: whether a human can honestly warrant where the code came from and that the project has the right to ship it. Where that warranty is load-bearing, AI is banned. Where it isn’t, AI is fine. The tool is the same in both repos. The liability is not.

The sharpest statement of this came not from Oracle but from the top comment on the Hacker News thread, 534 points up. Oracle, the commenter wrote, is “the law firm with a tech business attached,” and it “wants to retain the option to sue other people for AI-washing their proprietary code — and that doesn’t work if they’re also publicly accepting AI contributions to their code with no apparent concern for the provenance of it. The law firm is in the driver’s seat.” That is the whole thing. The ban isn’t Oracle being protective of its contributors. It’s Oracle protecting its own right to make a provenance claim against everyone else — and you can’t assert that clean lineage matters while accepting code whose lineage you can’t trace.

This is the constraint the productivity numbers never touch, and it’s about to become a first-class property of code — like a license, like a test suite. Here is why, and what a working engineer should do about it.

The reason that isn’t the reason

OpenJDK gives three grounds for the ban. Two are real but secondary. The third is the one doing the work.

The first is reviewer burden: floods of plausible-looking but wrong code drain limited reviewer time. This is true, and it has a face. Daniel Stenberg, who maintains curl, wrote the definitive account of it in July 2025, “Death by a thousand slops.” His numbers are the cleanest maintainer-cost figures anyone has published: roughly 20% of security submissions were AI slop in 2025, and only about 5% turned out to be genuine vulnerabilities. Each incoming report pulls in three or four of curl’s seven-person security team, “30 minutes, sometimes up to an hour or three. Each.” The line that stuck: “the emotional toll it takes to deal with these mind-numbing stupidities.” curl now requires reporters to disclose AI use and bans slop reporters on sight.

But reviewer burden is an argument about bad contributions, not AI contributions. It justifies a quality bar, not a provenance ban. A perfect AI patch — correct, tested, clean — imposes no review burden and would still be forbidden under OpenJDK’s rule. So burden explains the intensity of the reaction. It doesn’t explain the shape of the policy.

The second ground is safety: the JDK underpins systems where a subtle bug is expensive, so the project is conservative about anything it can’t fully account for. Also true, also not specific to AI.

The third ground is the real one, and OpenJDK states it plainly: intellectual-property uncertainty, “the subject of active litigation.” Contributions to OpenJDK ride on the Oracle Contributor Agreement, under which the contributor warrants that they hold the rights they’re granting. That warranty is a promise about provenance — I made this, or I have the right to give it to you. And nobody can currently make that promise honestly about the output of a large model. That’s not a quality problem. It’s a chain-of-title problem, and it has no technical fix.

The signature line breaks

Every serious open-source project gates contributions on a provenance claim. It comes in two shapes.

The lighter one is the Developer Certificate of Origin — the “Signed-off-by” line the Linux kernel requires. It’s a short attestation: I certify I wrote this, or I have the right to submit it under the project’s license. The heavier one is a Contributor License Agreement or copyright-assignment agreement like Oracle’s OCA, where you grant the project rights and warrant that those rights are yours to grant.

Both are provenance certificates signed by a human. Both break on AI output, for a reason that has nothing to do with whether the code works.

Under US Copyright Office guidance — Part 2 of its AI report, released January 29, 2025 — a work generated by AI is not copyrightable, because copyright requires human authorship. “The mere selection of prompts, even if those prompts are detailed,” does not make the user the author of the output. Human editing on top of AI output can earn protection for the human parts, case by case, but the machine-generated portion has no author. (Part 3, on training models on copyrighted works, followed in May 2025 — a pre-publication draft released days before the administration fired the Register of Copyrights; critics tied the two, the administration didn’t, and the D.C. Circuit let her resume the role pending appeal. The point for us: the office setting the rules here is itself contested ground.)

Put the pieces together and the signature line stops meaning anything. If you can’t be the author of the model’s output, what exactly are you certifying when you sign “I wrote this”? And what right are you warranting you hold, when the output was produced by a system trained on a corpus of unknown-licensed code you never saw? The DCO and the CLA were built to answer who is responsible for this code. AI output turns that question into one nobody can answer truthfully.

The projects that welcome AI concede the point at exactly this line. When the Linux kernel — no enemy of AI tooling — added its coding-assistant policy in 2026, it allowed the tools and then drew one bright rule: “AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin.” An assistant can write the patch. It cannot sign for it. Even the permissive camp agrees the signature was always the product.

The second half of the provenance problem is contamination: a model can emit code that closely tracks licensed training data, and you’d never know. GitHub’s own 2021 “recitation” study found Copilot reproduced training code verbatim 41 times across 453,780 suggestions — about once every ten user-weeks. Rare. Not zero. The researcher Tim Davis later found Copilot emitting his own cs_transpose function whole. This is exactly what the GitHub Copilot litigation, Doe v. GitHub, spent three years fighting over. The plaintiffs sought over $9 billion, alleging Copilot reproduced their open-source code stripped of its license. By June 2024, Judge Tigar had dismissed the DMCA claims with prejudice — the outputs were modifications, not identical copies, and the court noted Copilot “rarely” reproduced training code, and only for long, similar excerpts. The case narrowed to breach-of-contract and open-source-license claims and went up to the Ninth Circuit on the question of whether the DMCA requires the output to be identical.

Read that outcome carefully, because it cuts against the ban’s critics and for it. The plaintiffs lost the sweeping copyright theory. But the court’s own finding — that reproduction is rare but real for long excerpts — is precisely the residual risk a provenance warranty can’t absorb. “Rarely” is not “never.” A contributor signing an IP warranty is promising never. The litigation didn’t clear AI code; it confirmed the exact uncertainty OpenJDK cited.

And of all companies, Oracle knows what an unresolved API-and-copyright question costs. Oracle spent a decade and sought $8.8 billion from Google over the copyrightability of Java APIs, and the Supreme Court resolved it in 2021 by ruling fair use — while pointedly declining to decide whether the APIs were copyrightable at all. Oracle litigated the boundaries of software copyright longer and harder than anyone alive. When Oracle’s own lawyers say the IP status of AI output is too unsettled to accept into the codebase they’d have to defend in discovery, that is not timidity. That is the most experienced software-copyright litigant on Earth pricing a risk it understands better than you do.

The spectrum, not the ban

This isn’t one cranky project. It’s a spectrum, and where a project sits on it maps almost exactly to how load-bearing its provenance warranty is.

Ban. Gentoo got there first, in April 2024 — council member Michał Górny’s proposal passed 6–0, citing three concerns: potential copyright infringement, quality, and the ethics of the training-data grab. NetBSD updated its commit guidelines the following month to treat LLM-generated code as presumptively “tainted,” the same category it uses for decompiled code — a pure provenance frame. QEMU declined anything “believed to include or derive from AI generated content.” Servo banned it and its community voted down a proposal to relax the rule.

Disclose, with human accountability. Fedora (October 2025) and the Linux kernel allow AI tools and ask for an Assisted-by: trailer, on one condition: “The contributor is always the author and is fully accountable.” GraalVM sits here too. curl doesn’t ban AI either; it demands you declare it and bans slop reporters. This is the “provenance is the contributor’s problem, and we’ll hold them to it” model — viable exactly where the downstream IP warranty is light.

Allow. Every private company’s own proprietary codebase sits here — because inside a repo you already own, there’s no external warranty to break. Nobody downstream is relying on your signature to certify clean title.

The spectrum even moves. QEMU, which banned AI outright, spent May 2026 debating whether to relax the rule — proposing to permit AI for mechanical changes, tests, and small fixes under about 20 lines, on the reasoning that AI “reduces the cost of producing patches but not the cost of reviewing them.” That’s the tell. When a project relaxes, it relaxes on the low-provenance-stakes slice — the mechanical 20-liner where the copyright-able creativity, and thus the warranty exposure, rounds to zero. It doesn’t relax on the architecture. The variable is consistent even in the exceptions.

Notice what predicts a project’s position: not how good its contributors’ models are, not how much AI-productivity data it’s seen. It’s whether the project stakes a downstream IP warranty on every commit. OpenJDK does, and Oracle would have to defend it. GraalVM doesn’t in the same way. Same tool, different liability, opposite rule. Provenance is the product.

The strongest case against

The critics have three real points, and they deserve a straight answer.

“The ban is unenforceable.” OpenJDK admits this in its own text: reliably distinguishing human from AI content is “impossible” — reviewers are reduced to watching for tells like “chatty commit messages” and “the use of emoji characters.” Enforcement is a Skara checkbox you tick to attest compliance. And detection-by-tool is worse than nothing: a Stanford study found leading AI-text detectors falsely flagged 61% of essays by non-native English writers as machine-written, and OpenAI quietly killed its own classifier in 2023 for “low accuracy.” As one commenter put it, “you shouldn’t be able to tell that you’re using AI unless the tell is that it’s higher quality.”

This is true and beside the point, because the ban is not a detection mechanism — it’s a liability-allocation mechanism. A signed attestation you can’t verify is still legally load-bearing: it moves the risk onto the contributor and gives the project a clean line in any future dispute. Enforceability was never the goal; defensibility is. And the honor system does more work than it looks. As the sharpest HN defense of the policy noted, a contributor who respects the rule simply doesn’t submit AI code, and one who’d bother disguising it “to prove some kind of point, to yourself, that you can never disclose publicly” mostly has better things to do — “enjoy your day at the beach instead of trying to trick a project that is politely asking you not to trick it.” The checkbox assigns the blame in advance. That’s what it’s for.

“The problem is bad PRs, not AI — just review the code.” The most common practitioner objection, and GraalVM is built on it: allow the tools, hold the human accountable, reject what they can’t defend. “If you cannot defend the PR, you shouldn’t be submitting it,” ran one top comment; another: “The correct policy is what Linux adopted — we don’t care what tools you use, provide high-quality PRs.” For quality, they’re right, and it’s why GraalVM, Fedora, and the kernel all chose disclosure-plus-accountability over a ban. But quality and provenance are different axes. Reviewing the code catches the bug; it does nothing for the copyright warranty, because a correct, well-understood, well-tested patch can still be one you have no right to grant. GraalVM proves reasonable people at Oracle think AI code is fine to accept — where the warranty exposure is low. It doesn’t prove the warranty problem is imaginary. The two projects differ on exactly the variable that matters.

“Disclosure beats prohibition.” curl’s model — declare it, own it — is more honest and more sustainable than a ban that drives AI use underground. This is the strongest critique, and it may well be where OpenJDK ends up: its current policy is explicitly interim, with a full policy promised to the Governing Board “in due course.” But disclosure and prohibition are answers to different questions. Disclosure manages review burden and accountability. It does nothing for the copyright warranty, because “I used AI and I’m telling you” is not the same promise as “I hold the rights to this.” A project that can tolerate provenance ambiguity can disclose. A project that stakes an IP warranty on every commit can’t — it has to ban, or stop offering the warranty.

So what

The reader is a working engineer, so here is the part that matters.

Provenance is becoming a property of your code, not a footnote. For a decade the only metadata that traveled with a snippet was its license. Now a second question rides alongside it: where did this come from, and can you prove it? The answer used to be trivially “I wrote it.” It isn’t anymore, and the gap is legal, not technical — no linter will close it.

Three practical moves:

  1. Know which agreement your repo gates on. If you contribute to anything under a CLA or copyright-assignment (many foundations, most corporate-stewarded OSS), AI-authored code is a live liability — you may be warranting rights you provably don’t hold. If it’s a DCO project, read whether the project has ruled on AI (the kernel, Gentoo, NetBSD, QEMU all have positions). In your own private codebase, none of this binds — allow away.

  2. Keep provenance records where the warranty is load-bearing. The projects moving fastest here (Skara’s checkbox, curl’s disclosure) are building an audit trail of who certified what. If you ship into regulated, safety-critical, or heavily-licensed code, start treating “which parts were model-generated” as something you log, the way you already log which parts are third-party.

  3. Match the tool to the stakes, not to the hype. The QEMU line is the right heuristic even outside QEMU: AI is lowest-risk exactly where the provenance exposure is lowest — mechanical changes, tests, boilerplate, the sub-20-line fix with no creative expression to own. It’s highest-risk where the code is novel, load-bearing, and destined for a repo whose maintainers you’re asking to warrant it downstream.

This connects to the fight that dominated the week’s Hacker News: “code was never the hard part” versus the programmers insisting it was. Both sides missed the part that’s actually getting harder. The new hard part isn’t writing the code, and it isn’t the taste to know what to write. It’s being able to say, with a signature behind it, where your code came from — and that’s the one thing the model can’t do for you. It’s the legal twin of the pattern we keep hitting: AI is strong where a cheap machine check exists and weak where it doesn’t. You can run the tests to prove the code works. There is no test you can run to prove it’s yours. Provenance has no cheap certificate, so the market is doing what markets always do with expensive-to-verify properties — pricing it with contracts and bans instead of detection.

What would change my mind: a vendor closing the gap with a product, not a promise. Today’s “IP indemnities” from the coding-AI vendors protect the user against third-party claims; they don’t make the output authored or let you pass a clean warranty upstream. Prediction (72% confident): through end of 2027, no major AI coding vendor ships a provenance guarantee strong enough to satisfy an IP-warranty contribution agreement — one that lets a contributor truthfully sign a DCO or CLA on model output — and the projects that stake a downstream warranty on every commit keep AI contributions banned-or-disclosed rather than freely allowed. If a vendor ships a transferable authorship-and-clean-provenance warranty, and a foundation-governed project accepts AI code on the strength of it, the gap I’ve described was a transition cost, not a structural one. Until then, the signature line is where AI code stops.