OpenJDK banned AI generated contributions to the JDK while GraalVM permits them, and the Oracle Contributor Agreement both projects share is what makes the split a working framework rather than a contradiction.
The IP question is the load-bearing one. In early April 2026, Oracle's OpenJDK Governing Board approved an interim policy broadly banning AI-generated contributions to the JDK, citing three reasons: reviewer burden from plausible-but-incorrect submissions, the safety stakes of a mission-critical runtime, and uncertainty over who owns the intellectual property in AI output. The board called that last concern, in the policy's own language, "the subject of active litigation" (OpenJDK AI policy, interim).
Two months later, GraalVM, an Oracle Labs project that sits outside the OpenJDK Governing Board's authority, published a Coding Assistants policy that permits AI-assisted contributions, requires human reviewers to understand and defend the change, and weakens the explicit "Assisted-by" tag the Linux kernel requires. On June 3, 2026, the project added an AGENTS.md style guide for AI coding assistants to its documentation workflow. The two projects share the same Oracle Contributor Agreement, which is what makes the divergence informative rather than arbitrary: a single corporate IP framework is producing opposite policy outputs because the governance bodies differ on what they are willing to tolerate.
The OpenJDK policy is explicitly interim. It covers code, text, and images submitted through Git, GitHub, JBS, the wiki, and mailing lists. The FAQ spells out two precision points that lazy coverage tends to miss. First, the ban is on contributed content, not on the tool: contributors may still use generative AI to read, understand, debug, and research OpenJDK code. Second, editing 10 of 100 AI-generated lines does not satisfy the policy, because the contribution is still partly AI-generated. Spell-checker-style tools, by contrast, are allowed. OpenJDK will also add a checkbox to the Skara pull-request system so submitters attest compliance, while noting that reliably distinguishing human- from AI-authored content is "generally impossible" (OpenJDK AI policy and FAQ).
GraalVM's policy, adapted from the Linux kernel's coding-assistants model, takes a different bet. Explicit attribution is "optional" rather than required, AI-assistance disclosure is "encouraged" only when it helps reviewers, and the load-bearing rule is human accountability: a contributor who cannot explain, defend, or maintain an AI-assisted change may have the contribution rejected. The new AGENTS.md gives AI tools a documentation style guide so the prose the model produces matches what reviewers expect, a small but concrete move that treats the model as a contributor with onboarding needs rather than a threat to police at the door.
What the split actually shows is a working decision framework. The OCA, the contract that every Oracle open-source contributor signs, requires the contributor to grant Oracle unrestricted IP rights in what they submit. If a contributor does not legally own the IP in AI-generated output, the OCA grant is broken at the foundation, regardless of how thoroughly the contributor reviewed the patch. The OpenJDK Governing Board concluded that the litigation risk made that foundation too unstable to build on for the JDK. GraalVM's governance, answering to Oracle Labs rather than the JDK board, decided the same risk was acceptable in exchange for the productivity upside and a stronger human-reviewer norm. Neither project is wrong on the merits; they are pricing the same uncertainty differently based on what their code does, who runs it, and what their governance is willing to defend in court.
The framework has three reusable parts for any engineering organization writing its own AI-contribution policy. The first is the IP-litigation gate: if your contributor agreement assumes clean IP assignment and your jurisdiction has not resolved whether AI output is assignable, you have a structural exposure that no reviewer process can fix. The second is the private-use carve-out: banning contributed content is not the same as banning the tool, and the difference matters to the engineers you want to keep. The third is the accountability hinge: who is on the hook when the change breaks in production, and is that person able to defend it without the model. GraalVM's explicit "cannot explain, defend, or maintain" rule is the cleanest version of that hinge so far.
What to watch next. Oracle has signaled that a full OpenJDK AI policy, replacing the interim ban, will be proposed "in due course" (InfoQ coverage of the interim policy). The Skara checkbox will surface how often contributors self-attest under any future relaxation. GraalVM's AGENTS.md is a small but modelable experiment: if documentation-style guidance for AI assistants becomes routine, it changes the shape of the reviewer conversation from "is this AI" to "does this read like us." And the underlying IP question, the one OpenJDK called "the subject of active litigation," is still open. The two Oracle policies are not the end of the story. They are the first legible draft of the framework other projects will have to either adopt or argue with.