Two Oracle Projects, One Contributor Agreement, Opposite Answers on AI-Generated Code

Two projects that Oracle stewards, that share the same legal foundation for intellectual property, have landed on opposite policies for code written with large language models. OpenJDK says no. GraalVM says yes, with conditions. The interesting part is not that the policies differ. It is that both sit on top of the identical Oracle Contributor Agreement, and they reach contradictory conclusions from the same starting point.

What OpenJDK decided

In early April 2026 the OpenJDK Governing Board approved an interim policy with a flat prohibition. Contributions must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems. The definition of "content" is deliberately wide: source code, text, and images in OpenJDK Git repositories, GitHub pull requests, email messages, wiki pages, and JBS issues all fall under it.

The policy gives three reasons, and each one maps onto a concrete failure mode rather than a vague principle.

The first is reviewer burden. A maintainer's time is the scarce resource in any large open-source project, and a flood of plausible-looking but subtly wrong code consumes that time faster than honest human submissions do. The cost of reviewing a contribution that looks correct but carries hidden defects is higher than reviewing one that is visibly rough, because the reviewer has to work harder to find the problem.

The second is safety and security. The JDK underpins systems where a regression is not a cosmetic bug but a production incident across a large installed base. When the cost of a defect is high, the bar for accepting new code rises with it, and code whose provenance and reasoning the submitter cannot fully account for sits below that bar.

The third is intellectual property, and this is the one doing the real work. The OCA requires a contributor to own the IP rights they grant to Oracle, and to grant them without restriction. Whether a person actually owns the rights to output produced by a generative model is, in the policy's own words, "the subject of active litigation." If you cannot be sure you own something, you cannot cleanly assign it.

The prohibition is narrower than it first appears. Private use is explicitly carved out. A contributor may use generative AI to understand, debug, and review OpenJDK code, and for research. The line is drawn at the contribution itself, not at the tools a developer keeps on their own machine. The policy FAQ closes the obvious loophole: editing ten of one hundred AI-generated lines is still not allowed, because the contribution is still partly AI-generated. Spell-checking, grammar-checking, auto-completion, and IDE refactoring stay permitted, but only if those features "are not based on large language models or similar deep-learning systems."

Enforcement runs through Skara, OpenJDK's automated pull request review system. Contributors will soon check a box confirming their work complies. The board is candid about the limits of this: "in general, reliably distinguishing human-generated content from AI-generated content is impossible." The checkbox is an attestation, not a detector. Reviewers are asked to watch for tell-tale signs anyway, which is an honest admission that the policy leans on good faith more than on technical enforcement.

What GraalVM decided

In mid-April 2026, GraalVM, an Oracle Labs project that is not governed by the OpenJDK Governing Board, went the other way. Contributors may use AI coding assistants when preparing contributions. The policy defines "coding assistants" broadly: AI-based tools that help draft, transform, explain, review, or summarize code, tests, documentation, or commit text. It covers pull requests and issues filed with the project.

GraalVM's policy is, by its own statement, informed by the Linux kernel's AI coding assistants policy, but it adapts rather than copies. The Linux policy asks that contributions include an Assisted-by tag. GraalVM takes a softer line: explicit attribution to a specific model or tool is optional, and disclosure of AI assistance is merely "encouraged when it helps reviewers understand how a change was produced."

The weight of the policy rests on accountability. The human submitter is responsible for the entire contribution, including any part an AI produced. They must review and understand it, verify its correctness, and answer a reviewer's questions without deferring to the tool. The sharpest sentence in the policy is the consequence: "If a contributor cannot explain, defend, or maintain an AI-assisted change, the contribution may be rejected." That reframes the question. The project does not ask where the code came from. It asks whether the person submitting it can stand behind every line, which is a test a human author has always had to pass.

Maintainer review does not soften to accommodate the tooling. "Use of AI assistance does not create any presumption that a change is correct, review-ready, or exempt from normal scrutiny." Maintainers may probe provenance, design intent, licensing, testing, and contributor understanding. On June 3, 2026 the project added a Documentation Terminology and Style Guide aimed at AI coding assistants, which signals that GraalVM expects these tools in the workflow and wants to shape their output rather than exclude it.

Where the two policies actually diverge

Both projects require the same OCA. Both demand unrestricted IP rights. From that shared base, OpenJDK treats the unsettled legal status of AI-generated output as grounds for outright prohibition, while GraalVM treats contributor accountability as sufficient grounds for permission.

The disagreement is not really about whether AI produces good code. It is about which risk each project considers unmanageable. OpenJDK identifies the IP question as the one it cannot resolve internally, because no amount of careful review changes whether a court eventually decides that model output is ownable. If the grant at the heart of the OCA might be void, no review process repairs it. GraalVM looks at the same uncertainty and concludes that placing full responsibility on the human submitter, plus unchanged maintainer scrutiny, contains the practical risk well enough to proceed.

There is a structural reason the two could split. GraalVM is an Oracle Labs project, not one under the OpenJDK Governing Board, so they were never obligated to align. That independence let two groups inside the same company run what amounts to a natural experiment on the same legal substrate.

The situation is explicitly provisional on the OpenJDK side. The current ban is interim, and Oracle is working on a full AI contribution policy for OpenJDK to propose "in due course." GraalVM has published no roadmap for revising its own stance. For now, a developer who wants to submit AI-assisted code to an Oracle-stewarded Java project has to know which project they are contributing to, because the same patch is forbidden in one repository and acceptable in the other. That is an unusual state for two projects under one corporate roof, and it is a reasonable preview of the choices many open-source communities will face as they each decide whether the line belongs at the tool or at the person holding it.