Split View: 같은 회사 두 프로젝트가 AI 기여에 정반대 결론을 낸 이유

Why Two Projects at the Same Company Reached Opposite Conclusions on AI Contributions

• Same Company, Same Contributor Agreement, Opposite Policies
• What OpenJDK Banned and What It Allowed
• The Reason Fixing Even Ten Lines Is Not Enough Lies in the IP Clause
• The Policy Itself Admits That Detection Is Impossible
• GraalVM Moves the Same Risk onto Accountability
• The Linux Kernel Gives a Third Answer
• The Real Axis That Separates the Three Policies
• Four Things to Decide When Writing the Policy for Your Own Repo
• References

Same Company, Same Contributor Agreement, Opposite Policies

You are about to send a patch to an open source project. You had a coding assistant switched on while you worked. To check whether you may send this patch you open the project documentation, and the answer differs by project. And it is opposite between two projects sponsored by the same company.

The OpenJDK interim policy, dated April 9, 2026, nails down that content produced by generative AI must not be included in a contribution. The GraalVM policy file states that contributors may use AI coding assistants. Both use the Oracle Contributor Agreement.

Summarizing this difference as "one is conservative and the other is forward-leaning" gets you nothing. Actually read the three documents and a different picture appears.

What OpenJDK Banned and What It Allowed

The original draws the scope very wide. What is banned is not limited to source code; it includes text and images in the repository, GitHub pull requests, email, wiki documents, and the issue tracker. Commit messages, PR descriptions, and mailing list replies all count.

At the same time the permitted scope is clear. A contributor may use generative AI tools privately to understand code, debug, review, and do project-related research. They simply must not contribute the content produced that way.

The FAQ pushes this distinction further. Having a draft JEP or document reviewed by AI is fine, because if you wrote all the text yourself, review is plainly within the permitted area. Spell checking and autocompletion in your editor may also continue to be used, as long as they are not based on large language models.

The Reason Fixing Even Ten Lines Is Not Enough Lies in the IP Clause

The most frequently cited FAQ item is this one. Asked whether you may contribute if you generated 100 lines with AI and then fixed 10 of them yourself, the answer is no. It still contains partially AI-generated code.

If that answer looks excessively strict, it becomes easier to understand once you see that the reason is not code quality but contract. The Oracle Contributor Agreement requires that the contributor hold the intellectual property rights to each contribution and be able to transfer those rights to Oracle without restriction. And the original writes that whether a user of generative AI tools holds intellectual property rights in the output is a matter currently in litigation.

If even 1 percent of a contribution has rights that are uncertain, the confirmation that you are "transferring without restriction" does not hold. That is why no percentage threshold can exist, and why it becomes binary.

Understand this and one common counterargument loses its force. The question is "then what about IDE autocompletion," and the original draws that line by technology rather than by kind of tool. It is written that spell checkers and autocompletion not based on large language models or similar deep learning systems may continue to be used. The criterion is not convenience but whether the training method is one whose rights attribution is being contested.

The Policy Itself Admits That Detection Is Impossible

The most candid passage in the policy is the part about reviewer responsibility. The original states explicitly that reliably distinguishing content made by a human from content made by AI is generally impossible.

Even so, it says reviewers have a responsibility to notify the contributor when signs appear, and it goes on to list examples of those signs. A particular tool left as a co-author in the commit trailer, unusually chatty and verbose writing that differs from the person's usual style, excessively structured comments with multiple headings, unnecessary comments, code that is more defensive than needed, use of emoji. The original itself adds that these clues, even if valid today, may not be tomorrow.

So enforcement hangs on declaration rather than detection. Skara adds a checkbox to the pull request body, making the contributor confirm directly that they complied with this policy. In substance it is a system of honesty declarations.

GraalVM Moves the Same Risk onto Accountability

The GraalVM document handles the same list of risks differently. It permits use, but stipulates that the person who submits is accountable for the entire contribution, including the parts AI made.

The expected behavior is concrete too. Read and understand the code, tests, documentation, and commit messages you submit; verify that the change is correct, necessary, and consistent with project standards; answer reviewer questions without hiding behind the tool; and be accountable for that contribution through review and maintenance. The document writes that if a contributor cannot explain, defend, or maintain an AI-assisted change, that contribution may be rejected.

Attribution is recommended but not required, and there is no need to name a specific model. For maintainers it states explicitly that whether something was AI-assisted is not grounds for presuming anything about its correctness.

The Linux Kernel Gives a Third Answer

The Linux kernel document on AI coding assistants, which the GraalVM document says it referenced, uses yet another axis. Permit it, but make it leave a trace.

One core rule is striking. An AI agent must not add a Signed-off-by tag, because only a human can legally attest to the Developer Certificate of Origin. A separate tag is used instead.

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Example: Assisted-by: Claude:claude-3-opus coccinelle sparse

The procedure for finding and fixing bugs is nailed down in the document as steps too. For a non-trivial bug: build a reproducer and confirm the bug is real, go as far as fixing it, add no build warnings and pass the checkpatch check, and explicitly state what you were not able to do. If you could not build a reproducer or could not test it, the requirement is to say so. The reason, that far too much maintainer time is being wasted analyzing unverified reports, is written into the document as it stands.

The Real Axis That Separates the Three Policies

Put the three documents side by side and the axis appears. It is not how much they trust AI but whom the review burden gets billed to.

OpenJDK is the strictest because its reviewer pool is narrow and irreplaceable and its output sits at the bottom of mission-critical systems. This is the place where the original gives safety and security as reasons. GraalVM, conversely, judged that under the same agreement individual accountability is enough to carry it. The same company reaching different answers is not a contradiction; it is because the bottleneck differs by project.

Four Things to Decide When Writing the Policy for Your Own Repo

Know this axis and you can write your internal repo policy briefly. Instead of copying someone else's policy, you only have to decide four things.

AI-assisted contribution policy — an example skeleton

1. Scope: code only, or PR descriptions and issue comments too
2. Accountability: is a change the submitter cannot explain rejected
3. Record: is attribution mandatory or recommended, and in which tag
4. Enforcement: rely on detection, or on declaration plus review

Default recommendation: scope is code and PR descriptions, accountability rests
entirely with the submitter, attribution recommended in the commit trailer,
enforcement by declaration plus ordinary review.

To expand on the third item only: what you get from mandating attribution is not surveillance but data. Six months later you can look separately at the post-hoc defect rate of AI-assisted changes, and then you can tune the policy by numbers rather than by feel. The reason this debate is mostly conducted on feel right now is that almost no organization has those numbers.

One last thing. The OpenJDK document is labeled interim right in its title, and the body states that Oracle intends to propose a formal policy to the governing board. The current ban is not a final conclusion but a measure that buys time. Quote it without this point and you make the original say something it did not say.

References

• OpenJDK Interim Policy on Generative AI — openjdk.org, 2026-04-09 — the scope of the ban, the permission for private use, the three risks, the 10-of-100-lines FAQ, the Skara checkbox, and reviewer responsibility with the list of clues are all in this document.
• GraalVM Coding Assistants — the oracle/graal repository — the permitted scope, contributor accountability, optional attribution, maintainer review principles.
• AI Coding Assistants — Linux kernel documentation — the sign-off ban, the Assisted-by tag format, the bug fix procedure.
• The comparison table and the policy skeleton above are things I put together after reading the three originals, and they do not appear verbatim in any of those documents.