-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should README examples recommend graalvm-community
by default?
#107
Comments
Hi @Marcono1234, Thanks for raising this. Let me note that I cannot provide legal advice. Nonetheless, let me try and answer the questions you raised to the best of my knowledge:
I guess this is true, not just for JDK distributions but also for any other piece of software. The choice of Oracle GraalVM vs. CE is documented, but I do agree that the README.md could make this a bit clearer and also mention specific licenses explicitly (similar to how it's done in
No, this is not meant to trick users into violating licenses: a) The license of a particular release of Oracle GraalVM is not going to be changed retroactively, and b) after three years of updates under GFTC, new CPU releases of GraalVM will be released under a different license such as OTN as you mentioned, and distributed through different channels. This is, by the way, very similar to Oracle JDK: old releases of Java SE 11 are still available in the archive, but newer CPU releases are now distributed via OTN.
I'm not sure I agree with this statement, given that users will not automatically receive Oracle GraalVM under a different license. In fact, defaulting to Oracle GraalVM is beneficial to users: GraalVM Community Edition receives only six months of updates (just like OpenJDK), while Oracle GraalVM receives three years of updates. Not to mention access to advanced features such as PGO, G1 GC, SBOM, etc.
If we do that, then users cannot build with an up-to-date JDK 21 anymore. However, most users deploy on LTS releases and there is no such thing as an LTS release of GraalVM CE. Recommending Oracle GraalVM while still providing pointers to alternative distributions seems reasonable to me. I hope this helps (and let me know if it didn't)! -- Fabio |
Thanks a lot for the clarification and the README changes! So if I understand it correctly, you cannot accidentally use GraalVM under the "Oracle Technology Network License Agreement", but instead remain on the last (outdated) GFTC licensed version unless you explicitly specify a |
Currently the usage examples in the README show
distribution: 'graalvm'
. Only if read the details about the options you notice thatgraalvm
actually means "Oracle GraalVM".And then you have to manually look up the license terms for this distribution. You might then notice https://www.oracle.com/java/technologies/javase/jdk-faqs.html#GraalVM-licensing and see that the version you are using is currently licensed with "GraalVM Free Terms and Conditions (GFTC)".
But then the next problem arises: The GFTC only seems to apply for a limited time (which you might overlook):
So what happens if you still use your workflow configuration with
distribution: 'graalvm'
after 'one year' after the subsequent LTS? Are you then automatically using GraalVM under the "Oracle Technology Network License Agreement" (and possibly unwittingly violating it)?For users this licensing situation seems rather unclear and potentially legally dangerous. So maybe it would be good to:
distribution
valuegraalvm
tograalvm-oracle
, deprecatinggraalvm
and emitting a warning when usedgraalvm-community
in the examplesWhat do you think? Maybe I am also misunderstanding parts of this.
The text was updated successfully, but these errors were encountered: