Now that Java is going GPL, what do we do?
Even before the official announcement of the Sun’s decision to GPL Java, users started asking us how will that affect Excelsior JET. Here is our take on that.
First of all, those are pieces of Java SE 7 early build currently available under GPL. When Java SE 6 goes GA in a few weeks, it will not be GPLed. So nothing may change for us and for you Excelsior JET users until Sun releases full OpenJDK 6 and 7 as they promise in the FAQ.
(Edit: The original post stated Java 6 will not be GPLed, thanks to Shai Almog for forcing me to re-read the Sun FAQ.)
Then, everybody is talking about Sun open sourcing their reference implementations of the Java technology, but few people pay attention to the fact that Sun is not going to open source the respective compatibility tests any time soon. And if your implementation did not pass the compatibility tests, you may not call it Java. Sure, you can get the tests under a scholarship license if you are doing academic research, but if you are making a commercial product, you have to get into a commercial license agreement with Sun, just as we did for J2SE 5.0 and will do for Java SE 6 next year. So nothing will likely change for us and for you Excelsior JET users after Sun releases OpenJDK either.
Finally, the standard Java SE API implementation included in our product JET is actually the natively compiled Sun’s code, so Excelsior JET is a derived work with respect to the reference implementations. That means Excelsior JET would have to be released under the GPL if we want to make an incompatible change such as subset the standard API in order to reduce application’s download size and/or disk footprint. Excelsior JET actually had such a feature prior to compatibility certification, and users keep asking for it, so we are now designing a solution that will solve the problem without breaking compatibility – stay tuned!
That said, right now we see no advantage of switching from SCSL Commercial Use to GPL.
This topic is archived, no new comments may be posted. If you have comments or questions, please contact us.
November 28th, 2006 at 5:20 pm
Interesting to hear that. As I understand Java 6 will also be licensed under the GPL after its release so this is not a purely 7.x feature. Also as far as I can tell since excelsior is a licensee you can use the SCSL for the portions such as the GC and compiler which you took out of the RI, but the modified GPL for the libraries. Why does that matter? If you use the modified GPL it allows you to link to library code without relicensing, this would allow you to build a linker that drops unused code. IANAL but this seems to me to be valid under the modified GPL and can result in a smaller EXE. This would mean that the term Java can be used for your product but not for the resulting application compiled using your product, this seems to me to be a valid tradeoff.
Am I missing something obvious?
November 28th, 2006 at 5:33 pm
We do not just link to Sun classes, but we have modified some low-level ones, e.g. have our own native mehtods for many of the java.lang classes. So it is a derived work without any doubt.
As I said in my post, we shall come up with a compatble solution to the download size problem next year. Can you think of any other reason for us to go the GPL route?
Finally, I seem to have not read the Sun FAQ carefully enough. Yes, Java 6 will eventually be available too. Thank you for pointing that out, I will edit the post now.
November 28th, 2006 at 6:07 pm
Dmitry,
Thankyou for clarifying about JET- Java GNU License.
I was expecting that SUN’s new License will officially allow JET to decrease the size of the final java application.
Anyway, we have to wait no other go.
Kishore.
November 28th, 2006 at 9:36 pm
Interesting, I didn’t think you modified the Java classes but now that you mention it modifying java.lang is indeed essential for a VM port.
There are two separate things:
1. Can you use the GPL code without open sourcing all your work?
2. Can you use the GPL license in any way to your advantage?
Technically you can get around the GPL requirement by only open sourcing the java.lang portions of your implementation (under the modified GPL) but that is obviously at your discretion. I assume this is a relatively small portion of your code that won’t harm your intellectual property.
You would still need to be a Java licensee so this won’t save you any money. There are however several advantages I can think of that the GPL can give you:
1. Since GPL code doesn’t need to be compatible and since the resulting application is an executable anyway being GPL would allow any application developer to modify the core Java classes. Yes the GPL requirement would force them to publish everything! But this is pretty easy to do.
2. You could then link with various versions of the runtime library that were developed by 3rd parties.
3. I have no idea how you intend to develop the feature that allows including part of the classes, if this is a complicated task then the GPL approach could possibly simplify that.
4. The open source community might find issues in your java.lang implementation.
So none of these advantages is a “killer feature” and none of them matters until GPL Java is actually popular and has some developers working on it. So this is mostly a theoretical debate, food for thought
November 30th, 2006 at 8:42 pm
Shai, thanks for sharing your thoughts. I think the first thing we need to do is engage a law firm proficient in open source licensing and IP in general and ask them what are the options and limitations. However, this is much lower priority for us at the moment than support for things like Java 6, 64-bit x86 and Windows Vista, so I am not sure when we’ll be able to allocate resources for that legal excercise.
Dmitry