Your AI Coding Policy Is Not a Provenance Record

Four major open source projects have now written down what they will accept from AI coding tools. They disagree with each other. That disagreement is the useful part, and it has almost nothing to do with code quality.

OpenJDK bans AI-generated content outright. QEMU declines it. GraalVM accepts it. The Linux kernel accepts it and asks you to label it. Four regimes, four different lines, all written between June 2025 and April 2026 by people who maintain code that runs everything.

They are not arguing about whether the code is any good. They are arguing about whether anyone can promise they own it.

The same contract produced two opposite answers

Start with the pair that should not exist.

OpenJDK and GraalVM are both Oracle projects. Both are governed by the same Oracle Contributor Agreement. Both name that agreement as the reason for their position on AI-generated code. They reached opposite conclusions.

The OpenJDK policy, approved by its Governing Board on 9 April 2026, is explicit about the mechanism. The agreement “requires that a contributor own the intellectual property rights in each contribution and be able to grant those rights to Oracle, without restriction.” Then comes the sentence that matters: “Whether a user of a generative AI tool has IP rights in content generated by the tool is the subject of active litigation.”

So OpenJDK bans the input. The policy is strict enough that if a tool writes 100 lines and you edit ten of them yourself, the answer is still no.

GraalVM starts from the same instrument and lands somewhere else. Its coding assistants policy states that the Oracle Contributor Agreement “applies to all contributions submitted for inclusion in the project, whether AI-assisted or not.” Its contributing guide puts it in one line: “Use of coding assistants does not change that requirement.”

The press read this as a company contradicting itself. That reading is available and it is the wrong one. Read it as an engineering leader instead, and it says something far more useful.

One contract, one company, two teams with access to the same lawyers, and two opposite policies. The contract language did not settle the question. It cannot. That is why OpenJDK calls its own policy interim.

You have signed the same promise

Here is why this belongs in a founder’s inbox rather than a maintainer’s.

Every one of these projects is enforcing the same basic mechanism. A human being certifies that they have the right to submit the material. OpenJDK and GraalVM do it through a contributor agreement. QEMU does it through the Developer’s Certificate of Origin, and its reasoning is worth quoting because it is the whole problem in one sentence: to satisfy the DCO, the contributor “has to fully understand the copyright and license status of content they are contributing,” and for AI content generators that status “is ill-defined with no generally accepted, settled legal foundation.”

If you run a software company, you have signed a version of that certificate. It sits in your customer contracts. It will sit in the representations and warranties of your next funding round or your exit. You are promising that the company owns what it is selling.

I am not a lawyer, and none of this is legal advice. The point is not what the law will eventually say. The point is that four projects with mature governance looked at that promise, could not agree on what it now requires, and each wrote down an answer with a mechanism attached. Most companies have done neither. They have a policy on which tools engineers may use, which is a different thing entirely, and they have no record of what those tools produced.

A tool policy governs behaviour. A provenance record governs evidence. Only one of them survives contact with diligence.

And this is only the code you wrote. Your dependency tree raises the same question one level down, where you control neither the policy nor the record.

The projects that allow AI did the harder work

The convenient assumption is that the projects saying yes are the relaxed ones. Read them and the opposite is true.

GraalVM accepts AI-assisted contributions and then makes the human carry all of it. The contributor must “review and understand the submitted code,” must “stand behind the contribution during review and maintenance,” and if they cannot “explain, defend, or maintain” an AI-assisted change, it can be rejected. Attribution is encouraged and optional.

The Linux kernel goes further and turns provenance into a machine-readable artefact. Its policy is blunt: “AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin.” Contributions prepared with assistance carry an Assisted-by: trailer, and the companion guidelines on tool-generated content ask for the tools used, and for the prompts themselves when code came from a short set of them.

That is the part worth stealing. The kernel did not write an aspiration. It added a line to the commit message. Provenance became something you can grep for, five years later, when the question is asked by someone who was not there.

Note also that GraalVM says its policy is “informed by the Linux kernel’s AI Coding Assistants policy.” The permissive regimes are converging on a shared convention. The restrictive ones are holding a line until the litigation resolves. Both are defensible. Having neither is not.

The cost nobody budgeted is review capacity

There is a second argument in these documents, and it is an operations argument rather than a legal one.

OpenJDK states that generative AI tools “make it easy to create large quantities of plausible-looking code, with plausible-looking tests, which is nonetheless incorrect or, even if it is correct, is poorly designed and therefore difficult to maintain.” The kernel’s guidelines say the same thing from the other side: “reviewer and maintainer bandwidth is a scarce resource.”

Two independent communities, with no shared governance, identified the same bottleneck.

I argued earlier this year that engineering value is moving from writing code to judging it. This is what that shift costs, and it lands on the people you can least afford to saturate.

This is a Day-2 operations problem dressed as a productivity win. Generation capacity rose and review capacity did not. Both communities say so in their own words, and neither is speculating, because they run the review queues in question. If your delivery metrics improved this year while your review queue quietly grew and your change failure rate crept up, you have not amplified throughput. You have moved the constraint downstream.

What to do before someone asks

The useful diligence question has changed. “Do your engineers use AI coding tools?” is now worthless. Everyone says yes and it proves nothing.

The question that has an answer is this one. Can you show where your code came from, and does that record match what your agreements already promise?

Four things make that answerable, and none of them is expensive:

1. Adopt a trailer. Assisted-by: is already convention in the Linux kernel. Use it. A provenance record that lives in the commit history costs almost nothing to maintain, and far more to reconstruct after the fact.
2. Map your obligations, per repository. A single company-wide AI policy does not establish compliance with anything. If your engineers contribute upstream, the obligation is set by each project, and OpenJDK and GraalVM prove that two projects at one company can differ.
3. Read your own contracts against your actual practice. The IP representations you have already signed were drafted before any of this. Find the gap now, with your counsel, not during a data room.
4. Measure review capacity as a first-class constraint. Track review latency and change failure rate alongside deployment frequency. If generation is up and review is flat, you are accumulating risk, not velocity.

None of this requires a position on whether AI-generated code is good. OpenJDK and GraalVM disagree about that and both remain credible. It requires evidence of origin across the full lifecycle, from design through to the support your team is still providing three years after the commit.

The projects that maintain the world’s most load-bearing code have all now written their answer down. Most companies have not started. That gap closes cheaply today and expensively during a transaction.

If you want a second pair of eyes on where your provenance record actually stands, get in touch. It is a short conversation and it usually ends with a list you can act on.