Seems short sighted for an interim policy, to me. Why not just require clear and detailed disclosure of the use of said tools, to generate data for which to make a properly informed non interim decision?
All "interim" AI contributions to OpenJDK can and will be sued to make big money off of Oracle if those court cases don't go a certain way.
This is ironic given how Oracle has bet almost everything on AI succeeding.
The interim policy you're proposing seems to have far different priors. The clearest indication of their stance is that they don't even want bug reports that have AI generate part of the text. You don't take a stand like that (imo) unless you've experienced some serious AI-related burnout.
The copyright issue is an important one. Under the current law, you don’t own copyright on the output of GenAI.
> short sighted for an interim policy
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."
I suspect one of the principle reasons for the blanket decline is specifically that AI generated PRs are already responsible for a substantial uptick in the amount of work required to be done by maintainers. Engaging in discussions about those PRs may be more fulfilling and useful for the developer but it also then increases that work yet again manifold, so that would likely be highly counter-productive.
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.
Because, as the FAQ section clearly states, the technical and management aspects are not the only ones. There are also legal issues, and until they are clarified or resolved it's best not to let code in that has the potential of causing problems later.
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.