Confusion over open source Java ME
Sun has finally announced their open source plans for Java ME. As it turns out, Java ME will be licensed under strict GPLv2 — without the exception made for Java SE. That means the Java ME license is viral to all software built on top of it. All those MIDlets or Xlets extend classes from Java ME implementation after all!
Device manufacturers still have to license a non-GPL version of Java ME. Or, all Java software bundled in the device must be open source as well.
That is understandable since Sun certainly does not want to lose the large Java ME revenue it collects from Nokia, Motorola and alike. But what does it mean for developers in the OSS community? If I take the Java ME code and port it to, say, the latest Motorola Linux phone, does that make all MIDlets running on top it GPL too? Does that mean it is illegal to run non-GPL licensed MIDlets on such Java ME VMs?
I am not a lawyer. So, it would be niiiiice if someone from Sun can clarify. 
Update: Please see Terrence Barr’s explanation on java.net. In short, you are affected by GPL only if you *distribute the JVM* with your MIDP application. So, the only people affected are device vendors and integrators.
November 13th, 2006 at 4:22 pm
As I understand it, according to the FAQ they’ve published (http://www.sun.com/software/opensource/java/faq.jsp), Sun interpretes Java ME is tied to the hardware, and thus apps don’t have to be GPLd:
Q: Why is the license different for Java ME than for the JDK? Why no Classpath exception for Java ME?
A: With Java ME, there is no way to install and integrate implementations. Instead, implementations are integrated with the hardware. As such, the problem the Classpath exception is solving with the Java SE implementation isn’t present with Java ME.
I might be wrong though, I’m not a lawyer either
November 13th, 2006 at 4:28 pm
Hmm, what they are saying that since you cannot have Java ME implementation independent of hardware, you do not need the exception. That is even more confusing. Of course, there can be third party Java ME implementation independent of the device hardware! Just ask Windows Mobile users who are using Java today!
November 13th, 2006 at 4:37 pm
That’s a good point! I guess youd’d be forced to GPL the app unless the Java ME implementation is based on a commercial license from Sun?
November 13th, 2006 at 5:06 pm
Right! Without the linking exception, you have to GPL your Java ME midlets to run on a GPL licensed version of the device. What’s interesting is that many content providers will now have to check the platform license before delivering content to the device, otherwise they could run into legal problems. Generally, this won’t affect carriers and their direct partners, who often deliver based on very specific hardware IDs anyway; but it will have an impact on those game and app providers that deliver content to any Java ME capable device, including unsupported carrier devices.
November 13th, 2006 at 5:09 pm
Interesting point Michael… I am hoping (and will try to find clarification) the licensing is only related to the platform itself, as it should be, and not applications running on top of the platform… Similarly to applications on top of Tomcat, and not sure on top of JBoss.
enrique
November 13th, 2006 at 5:41 pm
Tomcat and JBoss are not GPL. JBoss is LGPL and Tomcat is Apache. So, they do not have this problem.
The problem with releasing Java SE in strict GPL is that it *will* make all Java apps GPL as well. So, there is a GPL exception for the Java SE license.
But Sun does not see the need to make an exception for Java ME …
November 14th, 2006 at 1:43 am
Interpreting Java under GPL — does it forces applications to be GPL as well?
Michael writes about a very important issue that needs clarification…
In his blog, he writes
Confusion over open source Java ME
.
The concern has to do with the effects of GPL on applications. By not using LGPL -or- not applying the GPL lin…
November 14th, 2006 at 11:54 am
Sun open sourcing Java, it’s doing it under version 2 of the Free Software Foundation’s GNU General Public License (GPLv2) using an FSF-endorsed footnote known as the “classpath exception.” The FSF’s classpath exception gives developers a bit more latitude than just the GPL itself by allowing developers to tie Java libraries into their executable code without forcing those final executables to conform to the GPL which is the normal GPL practice. The exception text states the following:
Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
The FSF’s classpath exception was originally created to go along with FSF’s GNU Classpath. GNU Classpath was a set of developer libraries that the FSF community was working on to build a free software (not just open source) version of Java much the same way GNU Linux represents free software versions of many of the utilities found in Unix. In open source fashion, essentially, the free software community had been working to produce a free software clone of Java.
November 14th, 2006 at 11:57 am
It would be utterly insane if MIDlets would in any way be tainted by “GPL smearing” just because the bytecode interpreter and base classes happen to be under GPL.
What about Linux? Are applications that run on top of Linux and using the Linux APIs affected by GPL?
November 14th, 2006 at 12:19 pm
I believe Linux is different. Linux applications only link to libraries that covered under LGPL not the GPL kernel …
November 14th, 2006 at 2:55 pm
If you look at the FAQ the FSF have for Classpath (http://www.gnu.org/software/classpath/faq/faq.html)
“2.3 What does the exception allow me to do?
If you combine GNU Classpath with independent modules to produce an executable you can copy and distribute the resulting executable under terms of your choice.
So you can use and distribute GNU Classpath as is in your program without changing the license of your software.”
So the exception only applies if you are distributing your MIDlets together with Java ME, which you would not be doing. Remember the GPL and other open source licenses are triggered by distribution. So if you are just distributing a MIDlet you are not affected.
November 14th, 2006 at 3:36 pm
Very good point, Anon. I guess that clarified my confusion. Thanks a lot.
November 17th, 2006 at 1:19 pm
Please see the reply on this issue I just posted in the Mobile & Embedded Community Interest forum:
http://forums.java.net/jive/thread.jspa?messageID=175849𪻩
Thanks,
– Terrence
November 17th, 2006 at 3:06 pm
The official FAQ page has not been updated yet (but I’ve been told it will be; check back at http://www.sun.com/software/opensource/java/faq.jsp#c), but your question has been addressed in this forum post by Terrence Barr of Sun:
http://forums.java.net/jive/thread.jspa?messageID=175849#175849
November 17th, 2006 at 3:12 pm
Great. Thanks guys!