Summary: OpenJDK posted an interim policy barring contributions that contain content generated in whole or in part by large language models, diffusion models, or comparable deep-learning systems, extending beyond code to text and images across repositories, PRs, email, wiki, and JBS. The policy allows private AI use for understanding, debugging, and review, while Oracle drafts a full policy and Skara adds a GitHub PR compliance checkbox. Reviewer burden, security, and unsettled IP rights are the stated risks, and Rust chose narrower, use-case-specific controls that week.
OpenJDK, the main open source implementation of the Java platform, has posted an “Interim Policy on Generative AI” on its official legal page. Until a full policy is settled, anything the community contributes must not carry content generated, in whole or in part, by large language models, diffusion models, or comparable deep-learning systems. The Register had the story first, on August 3. Code is not the only thing in scope: source code, text, and images in OpenJDK Git repositories, GitHub pull requests, e-mail messages, wiki pages, and JBS issues all fall under the rules.
Where the Interim Policy Draws the Line
The boundary is drawn precisely: generated output may not become a contribution, while the tools themselves are fine. Nothing stops a contributor from using generative AI privately to comprehend, debug, and review OpenJDK code, or to do related research — the policy even cites anecdotal evidence from other communities that on large established codebases, this is where the tools shine: reading the existing code, not turning out new code. Oracle is drafting a full policy for proposal to the OpenJDK Governing Board. In the meantime Skara, the toolchain that handles pull requests, will add a checkbox to the body of every GitHub PR, so contributors must affirm there that their submission complies.
Three Risks: Reviewer Burden, Security, and IP
The policy’s FAQ does not soften the risks. Reviewer burden comes first: generative AI turns out plausible-looking code and tests in bulk, and such output — incorrect, or correct yet poorly designed and hard to keep up — drains time human reviewers barely have. Safety and security comes second: the JDK sits underneath mission-critical systems in businesses and governments worldwide, and code that reads as plausible while being wrong undermines that foundation. Intellectual property comes third: under the Oracle Contributor Agreement, a contributor must hold the rights in every contribution and pass them to Oracle without restriction, yet generative AI tools learn from copyrighted content and can emit infringing output — and whether a user holds any rights at all in AI-generated content is being fought over in active litigation.
The sharpest entry in the FAQ: a generative AI tool writes 100 lines of code and you edit ten of them yourself — may you contribute the result? No. Your contribution would still include, in part, AI-generated code.
All In on AI Code Internally, a Red Line for Open Source
Oracle’s own leadership supplies the contrast. Larry Ellison told Oracle AI World 2025: “The code that Oracle is writing, Oracle isn’t writing.” The Register’s headline spelled out the tension: as Ellison bets the farm on AI, Oracle says it loves AI-written code — just not in OpenJDK. This is not simple hypocrisy: risk from internal code stays internal, while an open source contribution needs a clean chain of title, every commit backed by signed legal agreements. Taken side by side, the quote and the policy say something plain — the loudest AI advocates in the industry still want code at their foundations that a human wrote and whose legal footing is clean. One company, two risk ledgers.
Rust Went Another Way
That same week, on August 5, the Rust project announced on the Inside Rust blog that five of its teams had adopted a policy, written by Jynn Nelson, governing how LLMs may be used in the rust-lang/rust monorepo. Its reach is far narrower: it lands on people who review or moderate PRs, on those who write PRs using LLM-generated code, on those who file an issue after an LLM turned up the problem, and on those who quote LLM output in a comment — and the post stresses it is not an official stance on LLMs, nor does it apply everywhere in the Rust project. Here one project forbids generated content outright; there the other handles use case by use case. Between them, they mark out both ends of the spectrum open source is now picking from.
What Contributors Should Take Away
Three things. One: before an agent opens a pull request on your behalf, look up the target project’s policy — maintainer trust is the scarcest resource open source has, and once it is burned, getting it back is hard. Two: compliance is being built into the toolchain, through checkboxes, review workflows, and eventually detection mechanisms, which turns disclosure from etiquette into procedure. Skara’s checkbox is the first concrete instance — compliance left the wiki page and landed in the exact form every contributor fills out anyway. Three: until the IP litigation is settled, any answer to “who owns AI output” can flip — projects protecting themselves first is rational, not reactionary.