In this case, this is coming from Oracle, which holds the OpenJDK purse strings, so being found in violation is also likely to have financial consequences for the violator.
Asking how do you enforce a policy that is practically unenforceable is a legitimate question.
Well, because it's going to lead to witch hunts and drama and so on. I mean, not necessarily on this project, but the same-ish discussion is going on on many community based projects (debian was recently on the front page with 4 proposals, etc).
It states in part:
> Until that policy is in place, the Governing Board has approved this interim policy:
> Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models...
Note, this would exclude most spell checkers, as they often are LLM based. That said, they do soften this with the addition:
> Q: Is it okay to continue using the spell-checking, grammar-checking, auto-completion, and refactoring features in my editor or IDE?
> A: Yes, so long as they are not based on large language models or similar deep-learning systems.
This addition will likely not help as most spell checkers are OS/IDE services and their implementation details are opaque to users.
Who is using an LLM as a spell checker?
However, I don't know if I am as I haven't seen, and will likely never see, the implementation behind the text box that is suggesting the next letter, word, or spelling correction as I type.
For now, LLMs are still bad at it, but they're already at "competitive with humans" tier of bad. I expect them to get better.
They already are better than most humans at writing code for sure but even the best SOTA model is worse than your average intern at memorization.
Someone with "memory" should be able to do the same faster, but having that memory should not be a requirement.
Whether that "someone" is a freshly onboarded mid-level SWE or a mid-tier coding LLM is largely irrelevant.
AI contribution is basically just "prompt + AI work". Even if you are okay with AI work per se, you should accept prompts (after reviewing them) and let your own AI generate the code (and then also review the code)... rather then accept an output of someone else's AI with an unknown prompt, that may or may not include an instruction to create a vulnerability.
In the age of AI, the prompt is becoming the actual source code. Accepting AI-generated code would be like accepting binary code from unknown source.
All of that are even more reasons to reject AI-generated code: if it cannot be trusted to produce same (or even similar) output just from the prompts, why accept it at all?
But even aside from the fact that writing the code is only a very small portion of the effort in this particular project (you can see that the volume of code making its way into the JDK is very small compared to the number of people involved), I'm often amazed by the gap between how well a frontier model (GPT 5.6 Sol in my case) can comprehend code and investigate a bug, and how badly it writes code and documentation, even when it understands things well. So not only is writing the code not a large portion of the effort in this project, it also happens to be one of the things current models don't do as well as other things.
Or like in the case of checking that free range eggs are in fact free range eggs.
Or like in the case of Steam demanding AI disclosure, to the dismay of Tim Sweeney ...
Let's hope the dismay increases over time.
It's not impossible - right now there are all these low-effort PRs. If the PR is indistinguishable from a normal human-written PR, that addresses some of their concerns.
In any case, a rule or policy that can be worked around is not a reason to do away with that rule or policy.
I mean, if we only ever catch 10% of murderers, do you really think it is reasonable to remove that law from the books?
But this also bans "simple" AI-powered auto-complete, like Zed's Zeta2 model. This is a very conservative model that rarely tries to propose more than a few obvious lines (at least in my use cases). If a developer accepts a three-line autocomplete that introduces a bug, that's kind of on them. Honestly, about the only thing that Zeta2 is good for is reducing the risk of RSI.
To be fair, it's also their project, and I completely support their right to set whatever policies they want.
I am speaking of spelling/grammar checkers are part of the IDE and/or OS.
You'd have to know your IDE and/or OS's implementation details to know you are not using an LLM based one.
LSPs vs LLM Autocomplete are a different story, but I can just turn that off.
?
Like, what? What are you even talking about? Most spell checkers used by programmers are certainly not LLM based. Spell-checking has always been instant for like two decades. It's such a solved problem.
- spell checkers: ok
- '.getC' autocompleting to '.getColor()': ok
- 'getC' autocompleting to 'getColor()' + five more lines based on preceding code and documentation: NO.
It's like predicting that when compilers become more popular, accepting binary contributions will become the default.
I think history agrees too, i.e. machine code > assembly language > high-level programming language > prompts.
And the AI companies aren't focused on making this process any more deterministic, where repeated prompts are sampled using different seeds. I don't know if it's because the randomness makes the models explore a larger space and perform better, but it's probably intentionally done because it'd be quite easy to remove the stochasticity.
SomeHacker44•56m ago
pron•53m ago
We're talking about one of the biggest and most critical open source projects in the world, and unless there's some immediate urgency, it's okay to wait before taking on some risk.
I should add that the potential loss here isn't big. For any fix, enhancement, or feature in the JDK, the cost of writing the code is rarely more than 10% of the total cost (which is easy to see if you compare the number of people involved in the project to the rate of code being added or changed), and the interim policy explicitly does allow the use of AI where it helps the most.
skwirl•34m ago
If they held here that it is OK to use LLM generated code for OpenJDK it could kill these cases later as they will have established that they believe it is fair use.
ToucanLoucan•51m ago
What I don't understand is: if you, for example, are a heavily AI-using dev, who spots a problem in OpenJDK, and you use Claude to figure it out: ok, why can't you then write the solution and PR yourself? Write your own code to replicate the functionality that Claude did, in your own style. Have Claude explain why this fixes the issue (it probably already did) and test it. If it works, write your own explanation and submit it as a PR.
I've done this a handful of times for smaller projects, in languages I'm unfamiliar with. Nobody complained because I didn't just copy the shit out of Claude, paste, copy the explanation, paste, and make a PR. I used Claude to increase my understanding, if even a bit and in a necessarily incomplete way, and did it myself.
grodriguez100•43m ago
You can. The policy explicitly allows you to use AI for understanding the codebase, debugging, etc. It just says “no AI generated content”. So if you use Claude to increase your understanding but then write your own code, that’s fine.
ToucanLoucan•25m ago
wildzzz•39m ago
CBLT•51m ago
streetfighter64•49m ago
Bit of an oxymoron, no?
> just require clear and detailed disclosure of the use of said tools
Do you mean disclosure of the use of tools used "privately to help comprehend, debug, and review" contributions? Or do you mean that they should not prohibit AI-generated contributions?
If the former I wonder how useful the data would be, and if the latter, they are probably not (yet) willing to allow such contributions because of the mentioned risks: "to reviewer burden, to safety and security, and to intellectual property."
bpicolo•49m ago
hajile•49m ago
This is ironic given how Oracle has bet almost everything on AI succeeding.
ofjcihen•46m ago