Oracle's CEO Says AI Writes the Code. Oracle's OpenJDK Says AI Code Isn't Welcome.

When one company sends two opposite messages, it’s usually because the left hand doesn’t know what the right is doing — or because both hands are sincere and they’re working in different rooms. Oracle and OpenJDK are a textbook case of the second. One side says humans will stop writing code. The other side just told contributors that AI-written code won’t be accepted.

One caveat before we dig in: this hasn’t blown up. There’s no viral Hacker News thread, no Reddit pile-on from the last month. That’s actually the more interesting version of the story — it means we get to look at the structural problem, open source contribution policy colliding with AI code provenance, without the noise of a discourse cycle.

Ellison’s Pitch Isn’t Wrong

Larry Ellison has been telling roughly the same story for a while now: AI builds the application, humans review the output and steer. Oracle has backed it with product, wiring code generation into its cloud and database stack.

This isn’t pure marketing. Whether it’s internal development or a customer’s enterprise rollout, the pattern of AI drafts, human polish is already the default in a lot of shops. The question isn’t whether it works. The question is whether it works the same way across every codebase.

Why OpenJDK Shut the Door

OpenJDK is the reference implementation of Java. Millions of production services sit on top of it. Core banking systems. Big chunks of the Android ecosystem. The backend of basically every large enterprise you can name.

To contribute to that codebase, you sign the Oracle Contributor Agreement. The clause that matters says, in effect: the code I’m submitting is my own original work, and it doesn’t infringe anyone else’s rights.

That’s where AI-generated code hits a wall. Large language models trained on enormous piles of source — GPL, AGPL, proprietary code that leaked into scrapes, all of it blended together. When the model emits a function, the contributor genuinely does not know where it came from. So they can’t honestly sign the attestation. Sign it anyway and you’ve made a false statement. Don’t sign it and you can’t contribute.

The Real Issue Is Accountability, Not Copyright

Purely as a legal risk calculation, the odds are low. A ten-line utility function generated by a model is unlikely to be a byte-for-byte match with some specific GPL project.

But for a project like OpenJDK, the number that matters isn’t probability — it’s traceability. If a dispute erupts a decade from now over the origin of some code, the project needs to be able to say who added it, when, and on what basis. “A contributor asked a model and this is what it said” is not an answer anyone can defend.

Oracle has particular reason to care. Java has been in court repeatedly. The API copyright fight with Google ran for a decade and went all the way to the Supreme Court, where Oracle ultimately lost on fair use in 2021 — after years of legal exposure over what were, in the end, 11,500 lines of declaring code. An organization that has lived through that becomes conservative about code provenance for entirely rational reasons.

Not a Contradiction. A Split in the Rules.

So I’d read this less as corporate incoherence and more as the first visible sign that the rules are forking by domain.

An internal application running on your own servers? Let AI generate as much of it as you want. If something breaks, the company that shipped it owns the problem. Shared global infrastructure with a license lineage that has to hold up under scrutiny is a different animal. There, provenance gets audited before quality does.

The same logic applies to the Linux kernel, to major cryptographic libraries, to payment infrastructure. Several open source projects have already started working through the same question — the Gentoo project banned AI-generated contributions outright in 2024, and NetBSD adopted a similar policy. QEMU followed. The list keeps growing.

What This Actually Means for Your Next Commit

The practical version of this question is simple: which room is this code going into?

Internal project? Use the tools aggressively. That’s what they’re for. Sending a PR to an open source project? Read the contribution guidelines first, because a growing number of them now include an explicit line about AI-assisted code. An autocomplete suggestion you accepted without thinking can drag an entire project into legal gray territory, and maintainers are the ones who’ll be cleaning it up.

Adoption speed and legal safety have never been easy to optimize at the same time. Oracle’s answer was to stop trying — and to split them across different org charts and different documents.

The conversation around AI coding tools is quietly shifting from productivity to licensing and liability. Producing code fast is becoming the easy part; explaining where it came from is becoming the hard one. Could you account for the origin of the code you committed yesterday if someone asked you five years from now?