Your Dependencies Now Have AI Code Policies. Do You?

In April 2026 two open-source projects governed by the same company published opposite rules about AI-generated code. OpenJDK banned it from contributions outright. GraalVM, an Oracle Labs project, allowed it with conditions. Both sit under Oracle and both require the same contributor agreement. If your application depends on either, you have just learned that an AI code provenance policy is now a property of your supply chain rather than an internal preference.

Two Projects, One Vendor, Opposite Rules

The OpenJDK policy is blunt. Contributions must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems. That covers source code, text, and images across the repository, pull requests, mailing lists, wiki pages, and issue tracker.

What it does not cover is private use. Developers may still use these tools to understand, debug, review, and research code. Spell-checkers, grammar tools, auto-completion, and refactoring that does not run on a language model remain permitted. The line is drawn at what enters the project, not at what a developer may open on their own machine.

GraalVM went the other way in the same window and clarified its position in June. It permits AI-assisted contributions and puts the weight on human accountability: contributors must review, understand, and defend their work. Its policy states that use of AI assistance does not create any presumption that a change is correct, review-ready, or exempt from normal scrutiny.

Two reasonable positions, same corporate parent, same month. Any organization maintaining a dependency graph of meaningful size should assume the rest of that graph is about to diverge the same way.

Why the Ban Is About Ownership, Not Code Quality

It would be easy to read the OpenJDK decision as a judgement on whether generated code is any good. Its three stated reasons say otherwise, and only one of them is about quality.

The first is reviewer burden: plausible-looking but flawed contributions consume scarce review capacity. The second is safety, because the JDK sits underneath mission-critical systems. The third is the one that should interest a general counsel more than an engineering lead. The contributor agreement requires that contributors own the intellectual property they grant, without restriction, and whether a person owns the output of a generative model is still being litigated.

That third reason does not depend on the code being wrong. A perfectly correct, well-tested contribution fails the test if nobody can warrant who owns it. Provenance, meaning a defensible record of where a piece of code came from and who holds rights to it, is a separate property from correctness. Your existing code review process almost certainly checks the second and not the first.

The AI Code Provenance Policy Your App Team Needs

An application organization is exposed in three directions at once, and most have written a position for none of them.

Outbound. When your engineers contribute upstream, to a dependency, a client repository, or a partner integration, whose rules apply and do your engineers know them? A contribution made in good faith to a project with an OpenJDK-style ban is a problem for the maintainer and an embarrassment for you.

Inbound. Your dependencies are adopting divergent policies, which means the assurance you inherit from them now varies by project. This is not a reason to avoid a dependency. It is a reason to know which of them can tell you where their code came from.

Internal. Your own coding agents are producing code that lands in your product. If a customer, an acquirer, or a regulator asks which parts of your application were machine-generated and under what terms, the answer has to exist before the question does.

What to Write Down First

This does not require a policy document with a version number. It requires four answers that a senior engineer can give without hedging.

1. Where generated code is allowed to land. Name the parts of the codebase where it is fine, and the parts where it is not. Most teams will draw the line at anything touching authentication, payments, or data handling, which is roughly where the JDK reasoning points.
2. What gets recorded at the moment of authorship. A commit trailer or pull request field marking machine-assisted work costs nothing to add now and is close to unrecoverable later. Reconstructing provenance after the fact means reading history and guessing.
3. Who checks upstream rules before contributing. Assign it. The policies are short, public, and easy to read once someone is responsible for reading them.
4. What you would hand over in diligence. Work backwards from the request. If the honest answer today is a shrug, the gap is the record, not the code.

None of this slows a team down in any material way. It is cheap while the work is being done and expensive to reconstruct once it is not, which is the usual shape of an assurance problem.

Sources

1. InfoQ, "Oracle's OpenJDK Bans Generative AI Contributions While Oracle's GraalVM Allows Them," 2026. Link.
2. The Register, "As Larry Ellison bets the farm, Oracle says it loves AI-written code, just not in OpenJDK," 2026. Link.

Next Steps

If you cannot currently say which parts of your application were machine-generated, the exposure is the missing record rather than the code itself. Stable Solutions builds the provenance trail into the delivery process, so the answer is a by-product of shipping rather than an archaeology project. Explore our App and Web Development or contact our team to scope a provenance review of your codebase.