Oracle Bans AI-Generated Code from OpenJDK — While Using It Internally

Larry Ellison stood on stage at Oracle AI World 2025 and said something that should make every developer's skin crawl: "The code that Oracle is writing, Oracle isn't writing. Our AI models are writing."

He was proud of it. Smiling. His company had just cut 21,000 jobs in June, partly attributing the layoffs to "deployment of AI technologies." Oracle's co-CEO Mike Sicilia said AI coding tools were enabling "smaller engineering teams to deliver more complete solutions to our customers more quickly."

So Oracle loves AI-generated code. Loves it enough to bet the company on it — $70 billion in datacenter spending this year, so aggressive that S&P downgraded Oracle's credit rating to BBB-, one notch above junk.

And yet.

Oracle just banned AI-generated code from OpenJDK.

Not "discouraged." Not "please be thoughtful about." Banned. The interim policy, approved by the OpenJDK Governing Board and published at openjdk.org/legal/ai, states in no uncertain terms:

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

Source code, text, images, pull requests, emails, wiki pages, bug reports — all of it. If a language model touched it, it doesn't go in.

Rules for thee, but not for me

Let's sit with this contradiction for a second, because it's not a small one.

Oracle's own products? Built with AI-generated code, according to their CTO. Their internal engineering teams? Leaner and shipping faster thanks to AI tools, according to their CEO. Their workforce? Slashed to the tune of 21,000 people, with AI deployment cited as a contributing factor.

But the open-source project they steward — the one that runs mission-critical systems at banks, governments, and enterprises worldwide? Keep your AI slop away from it.

The Hacker News comment section, predictably, went nuclear. 442 upvotes and 307 comments in half a day. The top reactions ranged from "rules for thee, but not for me" to someone pointing out the "delicious irony" of AI-generated code running on top of a JVM that was built entirely by human hands.

One commenter cut right to it: "Why AI-generated code is suitable for Oracle's products but not for OpenJDK contributions is therefore puzzling."

The Register asked Oracle the same question. Oracle has not yet shared the secret.

The policy itself is actually... reasonable?

Here's the uncomfortable part: strip away the hypocrisy, and OpenJDK's policy makes a lot of sense.

Oracle laid out three specific concerns, and each one is legitimate.

Reviewer burden. AI tools produce vast quantities of plausible-looking code with plausible-looking tests that are nonetheless incorrect or poorly designed. For a project like OpenJDK — where reviewers are already stretched thin and every change potentially affects millions of production systems — a flood of AI-generated pull requests would be a nightmare. You'd spend more time debunking confidently wrong code than writing real features.

Safety and security. The JDK sits at the foundation of mission-critical systems worldwide. "Plausible-looking but incorrect code would put these critical properties at risk," Oracle wrote. That's not corporate paranoia. That's the reality of software that powers hospital databases, banking infrastructure, and government systems.

Intellectual property. This is the big one, and it's where Oracle's history makes this less hypocritical than it looks. The Oracle Contributor Agreement requires that contributors own the IP rights in everything they submit. But AI models are trained on copyrighted code — potentially including Oracle's own. If an LLM regurgitates a chunk of licensed code and someone submits it to OpenJDK, who owns it? Is it a derivative work? Can the original author sue?

If that scenario sounds familiar, it should. Oracle sued Google for $9 billion over Java API copyright in a case that dragged on for over a decade. They know exactly how ugly IP disputes over code can get. And they know that AI-generated code is an IP lawsuit waiting to happen.

One HN commenter put it perfectly: "Oracle is not a software company, but a litigation company. It will be hard to sue people because LLMs generated code similar to some code copyrighted by Oracle if they themselves use LLMs internally to generate code."

The line Oracle is drawing

The policy isn't a total AI ban. It's more surgical than that.

You can use AI tools to understand existing code. You can use them to debug. You can use them to review pull requests. You can ask ChatGPT to explain what a particularly gnarly piece of JVM internals does. You just can't take what it spits out and paste it into a commit.

The FAQ on the policy page is almost comically precise about this. Can you use spell-check? Yes, as long as it's not powered by a deep-learning model. Can you use AI to review draft documentation you wrote yourself? Totally fine. Can you generate 100 lines of code with an LLM, manually edit 10 of them, and submit the result? No. "Your contribution would still include, in part, AI-generated code."

That last point is where things get philosophically weird. Because at what point does AI-assisted code become AI-generated code? If Cursor autocompletes a line and you accept it, is that AI-generated? If you ask Copilot for a function signature and then fill in the body yourself? If you used an LLM to brainstorm an approach and then wrote every line manually?

Oracle's policy doesn't answer these questions. The interim document explicitly says a fuller policy is coming. But the enforcement problem is going to be brutal. Unless Oracle plans to run AI-detection tools on every contribution — which themselves are notoriously unreliable — this policy is going to rely on the honor system.

Oracle isn't alone

OpenJDK isn't the first major open-source project to draw this line. The policy page itself notes that "some open-source communities have limited, if not banned, the submission of code created by generative AI tools."

This is becoming a real fault line in the software world. On one side: companies like Oracle, internally racing to replace human developers with AI, cutting headcount by the thousands. On the other side: the open-source foundations those same companies depend on, desperately trying to keep AI-generated contributions out of their codebases.

The tension isn't just about code quality. It's about who bears the risk.

When Oracle uses AI to generate code internally, they own the risk. If something breaks, they fix it. If someone sues, they settle. But when AI-generated code enters an open-source project, the risk spreads to everyone who uses it — every bank running OpenJDK, every government agency, every enterprise. The blast radius is enormous, and nobody wants to be the one who approved the pull request that introduced a subtle security vulnerability into the Java runtime.

The $70 billion elephant

You can't talk about this story without talking about Oracle's financial situation, because it's genuinely wild.

Oracle is spending $70 billion this year on datacenter expansion — up from $55.7 billion the year before. They're borrowing heavily to do it. S&P downgraded their credit rating to BBB-, one notch above junk. The cost of insuring against an Oracle default has spiked. Credit default swap spreads are widening.

This is a company going all-in on AI infrastructure at a scale that makes Wall Street nervous. And the bet is predicated on AI being reliable enough to replace thousands of engineers, write production code, and power "agents embedded in applications that can reason, make business decisions, and act on behalf of users."

So when the same company turns around and says "actually, AI-generated code is too risky for our open-source project," it's hard not to read between the lines. Either Oracle genuinely believes AI code is good enough for their proprietary products but not good enough for Java, or they're managing legal risk in the open-source world while selling a different story to investors.

Probably both. The IP concern alone justifies the OpenJDK policy regardless of what Oracle does internally. The OCA creates a legal obligation that AI output may not satisfy. That's a real liability, not a philosophical preference.

But the optics are terrible, and Oracle doesn't seem to care.

What this means for the rest of us

If you're a developer, the OpenJDK policy is a preview of a conversation that's coming to your codebase.

Most companies haven't formalized their stance on AI-generated code yet. The tooling exists — Copilot, Cursor, Claude Code, a dozen others — and developers are using it whether their employers know it or not. But the legal questions are unresolved. Who owns AI-generated code? Can it infringe on existing copyrights? What happens when two companies both claim IP rights over code that an LLM generated after being trained on both their codebases?

OpenJDK's answer is the conservative one: don't let it in until we figure this out. That's a defensible position for a project that runs the world's banking infrastructure.

But it raises a deeper question that nobody at Oracle seems eager to answer: if AI-generated code isn't safe for OpenJDK, why is it safe for Oracle's customers?

Larry Ellison says AI models are writing Oracle's code. Oracle's products run mission-critical systems for governments and enterprises. If "plausible-looking but incorrect code" is too dangerous for an open-source Java implementation, why isn't it too dangerous for Oracle Cloud?

The answer, presumably, is that Oracle has internal review processes, testing infrastructure, and legal teams that mitigate the risks. OpenJDK has volunteer reviewers and an OCA. The risk profiles are different.

But it still feels like Oracle is telling two different stories. To investors: AI is so good we're replacing engineers and betting $70 billion on it. To the open-source community: AI code is too risky to accept.

Both can be technically true. That doesn't make the contradiction any less glaring.

---

The Oracle-OpenJDK split is going to become a template. Watch for other major open-source projects to follow suit — not because AI code is inherently bad, but because the legal infrastructure hasn't caught up to the technology. Until courts rule on AI-generated copyright, until there's a clear framework for IP attribution in LLM output, conservative projects will err on the side of caution.

That's not anti-AI. It's anti-lawsuit. And if anyone understands the cost of code copyright litigation, it's Oracle.

If you're building with AI tools — whether that's code generation, document analysis, or full agent workflows — having a local, private environment matters. CopperRiver runs open-source AI models on your Mac with no data leaving your machine. Your codebase stays yours. Your prompts stay private. No IP entanglement with cloud APIs you don't control.