OpenJDK Will Not Take AI-Generated Code. Five Projects, Five Different Lines

OpenJDK's governing board has approved an interim policy that reads: "Contributions in the OpenJDK Community 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 in Git repositories, pull requests, email, wiki pages and issue tracker entries. You may still use the tools privately to comprehend, debug and review code. Four other well-known projects have drawn the line in four different places, and the practical consequence for you is a single question to answer before your next upstream pull request: can you certify where every line came from?

Five policies, read from the source

Each row below comes from the project's own published policy page, read on 30 July 2026. Where a project has a dated vote, the date is the project's, not ours. Nothing here is drawn from secondary coverage.

Four bans and one permission, and the four bans are not the same ban. Gentoo's is the broadest: content created "with the assistance of" these tools, which on a literal reading catches a commit message you asked a model to tighten. QEMU's turns on belief and derivation. NetBSD's is a presumption that a named human can rebut. OpenJDK's is the most explicit about surfaces, and it is the only one that names your issue tracker comments and mailing list posts alongside your code.

The reason is provenance, not code quality

The tempting reading is that maintainers think generated code is bad. The policies say something narrower. QEMU's page walks through it: the project requires contributors to certify submissions under the Developer's Certificate of Origin, which means the contributor "has to fully understand the copyright and license status of content they are contributing". For generated output, "the copyright and license status of the output is ill-defined with no generally accepted, settled legal foundation", so how a contributor could comply with DCO clauses (b) or (c) "is unclear". The project states plainly that it "is not willing or able to accept the legal risks of non-compliance".

OpenJDK reaches the same conclusion by a different instrument. The Oracle Contributor Agreement requires a contributor to own the intellectual property rights in each contribution and to grant them without restriction. Since most tools are trained on copyrighted and licensed content and their output can include infringing content, contributing it would violate the agreement, and whether the user of a tool has rights in its output "is the subject of active litigation".

Apache lands somewhere else from the same starting point. Its guidance notes that content generated by a non-human is generally not copyrightable, cites the US Copyright Office registration guidance of 16 March 2023 on human authorship, and concludes that the existing disclosure duty is the right mechanism: you were already responsible for flagging material that is not your original creation and naming its licence, and a model's output is one more source of such material.

Quality is cited too, and specifically as a load on other people. OpenJDK's stated reviewer-burden risk is that these tools "make it easy to create large quantities of plausible-looking code, with plausible-looking tests, which is nonetheless incorrect", and that reviewing it "can easily become a drain on the already limited time of human reviewers". Gentoo's council listed the same concern alongside copyright and ethics.

Three questions before you open the pull request

1. Have you read this specific project's policy, this month? Not open source policy in general, and not the policy of the last project you contributed to. Four of the five above are on the project's own site, at a stable URL, and take two minutes to read.
2. Does the rule cover what you actually did? Every ban above carves out reading, debugging and research. If you asked a model to explain an unfamiliar subsystem and then wrote the patch yourself, you are inside the line under OpenJDK, QEMU and NetBSD. If it produced a function you kept, you are not.
3. Can you honestly sign off? A Signed-off-by line is a statement, and QEMU spells out what it means: the author "takes responsibility for the entire contents of the patch, including any parts that were generated or assisted by AI tools or other tools". If you cannot say where a block of code came from, you cannot certify it, and that is true whether the project has an AI policy or not.

If your employer mandates an assistant

This is the live tension for a lot of people: an internal policy that pushes an assistant into every editor, and a weekend project whose maintainers refuse its output. Two habits keep those apart. Keep a separate clone for contributions to projects that ban generated content, with your editor's assistant switched off for that workspace, so that acceptance is a deliberate act rather than a keystroke you did not notice. And keep a note of which branches an agent touched while the work is fresh, because reconstructing provenance a week later is guesswork, and guesswork is exactly what a sign-off is not.

Where the rules do permit generated content, treat disclosure as the price. Apache's model is the most portable one: say what came from where, name the licence if you know it, and let the reviewer decide. That habit costs nothing and works under every policy above, including the ones that forbid the contribution outright, since a disclosure that gets a patch rejected is a far cheaper outcome than a silent one that gets a project sued.

If you maintain a project

Write the rule so it can be checked. "No AI-generated code" is unenforceable and you will not detect violations reliably; what you can do is state the certification you require and the surfaces it covers, as OpenJDK does by naming pull requests, email, wiki pages and issues. Give people a permitted use, since every project above except Gentoo explicitly allows tools for comprehension and debugging, which keeps the policy credible with contributors who use them daily. Say what happens on suspicion, as QEMU does by declining rather than investigating. And date the policy, as Gentoo did, so contributors know which version they read.

Whatever you decide will be provisional. OpenJDK calls its own policy interim and says a full one is being drafted for the Governing Board, QEMU invites exception proposals on its mailing list, and Gentoo's motion says it "can be revisited". The projects most exposed to the licensing question are the ones treating this as a moving problem rather than a settled position, which is a reasonable posture for your own repository too.

The provenance discipline here is the same one that applies to what you pull in as well as what you push out, which we worked through in pinning every model your build downloads, and it sits next to the practical review limits in the agent writes faster than anyone can read and the question of where your code goes in the code privacy switches.