Evan Summers's Blog

Duke in a Tux

As we know, Sun is relicensing JDK for inclusion in Linux distros. This is a fantastic development for Java. In this blog, I muse about GPL'ing Java as "GlassFishBowl" and rigorously protect the Java trademark, so that Java still means "Java" as in the JCP, TCK, JEE, et cetera. I posted a comment to this effect on Calvin's article "Java on Linux - the real story".

By the way, I rattled on a bit about opensourcing Java in my earlier blog "Swing thumps Ajax" together with too many other issues.

Hopefully we'll see more and more opensource Java apps shipping with Linux distros once they include Sun's JRE.

This makes it a real option for opensource developers to consider Java for their desktop apps, knowing that they can get shipped in Linux distros, alongside Sun's Mustang - which is such a great JRE for Java and Swing on Linux.

I would like to see Netbeans shipping in Linux distros too! Since Netbeans provides a great out-the-box experience, for both GUI and web apps (and mobile apps), this would encourage young developers to give Java/Swing/Netbeans a twirl, on their freshly squeezed Ubuntu boxen.

As Calvin quoted on his blog, Sun's lawyers and Debian Ubuntu developers spent months thrashing out a new "binary license for the Java platform."

The distribution of the Java platform, in particular the JRE, is clearly very important for Sun to get right, and I'm sure they have done so. Probably this is just a first step, on the Duke's opensource march. As Rich Green said at JavaOne about opensourcing Java, "It's not a question of whether, it's a question of how."

So now I'm gonna muse about a possible next step...

What if Sun GPL'ed mustang.dev.java.net as "GlassFishBowl" but rigorously protected their "Java" trademark, to ensure compatibility of a single Java platform, controlled and evolved by Sun and the JCP. So "Java" becomes a standard (and not an implementation), with "GlassFishBowl" as its opensource reference implementation. Sound familiar?

Hey Linux and OpenSolaris are GPL. KDE and GNOME are GPL. Because GPL is the most developer-friendly license. And in the case of Java, the developer is Sun. Apache is BSD-style, and is the most company-friendly, and hence all the support they get from the "biggest" company of them all, IBM.

Sun don't want to be too friendly to their competition, like IBM and Red Hat. So they don't want an Apache license. So I think the GPL would be best. Or a simple variant of it, eg. the GPL plus a clause or two agreeing to protect the "Java" trademark with our lives.

Let's try to imagine how this would unfold. The competitors that Sun worries about the most are IBM/Apache, and Red Hat. How would IBM and Red Hat react to the above scenario? Would Apache fork GlassFishBowl into TomcatFishingBowl? Well all Apache products are Apache-licensed, so forking a GPL project into another GPL project doesn't make sense for Apache.

Let's say IBM or Red Hat wanted to take Java off into their own direction. (That would be crazy, but let's pretend they got crazy.) They could fork it, and call it SeaShark. But it wouldn't be Java. It would have to compete with C# and Java. Hey, it might introduce some great features that the JCP community includes into a JSR for Java, and that might make it into Java and the GlassFishBowl reference implementation. So Java wins there.

Maybe researchers and students would want to fork GlassFishBowl into PlexiFishBowl to try out some wierd and wonderful tangential things. But surely Red Hat et al, would rather choose to distribute GlassFishBowl, so that they can license the official Java branding (with its promise of compatibility) for their distribution? And the licensing royalties for "Java" would still come flowing in for Sun, wouldn't they?

Update. If Java was gonna be GPL'ed, I guess the class libraries would have to be LGPL'ed, to allow non-GPL'ed Java programs to link to them? Anyway, see my follow-on blog "CDDLing up with Sun" which considers the CDDL as a better bet for Java than the GPL/LGPL.

As a postscript, I'm thrilled that Ubuntu's Mark Shuttleworth (a fellow South African countryman) has played a role in relicensing Java for Linux. Hopefully next on his list is Adobe, for Flash and Acrobat. After that, we just need a blanket license for including freely-distributable MP3, DVD and MPEG players in Linux distros, and the desktop war is won :) Oh, and those nVidia and ATi drivers, I forgot about those... And that can't happen because those drivers are specifically engineered to beat those darn spec tests, innit.

Comments

• Open sourcing java is a really big step to spread java on linux desktop computer.

  I feel so happy to read this news in java.net.

  Posted by: alois_cochard on May 17, 2006 at 04:47 AM

• Actually, there's nothing wrong with the CDDL license, which is what GlassFish (and Solaris) already use. Trademarks are another issue - I'm sure there will be lots of discussion about this in the coming months. Should be fun!

  Posted by: driscoll on May 17, 2006 at 09:10 AM

• 
  You right Jim, I should have argued for the CDDL. I thought Solaris was GPL'ed, I guess cos I read somewhere that Mr Swartz said he thought Solaris could conceivably move to GPL3 in future.

  Since Solaris and GlassFish are both CDDL, then it would be neat for Java join the CDDL party so that Sun's stack of OpenSolaris, Java and GlassFish are under same license.

  Hey I must take a closer look at this CDDL because to be honest I don't know anything about it, except that it is OSI-approved as officially "opensource"...

  OK, I see from Jim's blog that it is "MPL with bugfixes," and a company-friendly license like Apache, so you can innovate on top of it and not have to release your additions.

  If I understand correctly from Sun's CDDL executive summary (which refers to "BSD-families" of licenses, which I assume includes Apache) the difference then between CDDL and Apache licenses is that you have to distribute your modifications (although not additions). This is on a file basis (which I like because I understand), ie. modification means modification of a file, eg. a C source file, and addition means adding new files to the source tree.

  Also I see that CDDL has a "patent peace" provision, that if you initiate a patent claim, then you have to leave the CDDL party. This seems to be where it "extends" the MPL.

  Someone wrote that how Sun manages CDDL projects (but which is not in CDDL - just how they happen to manage their projects, which happen to be CDDL), is that copyright of contributions should be handed over to Sun, to use/relicense/release as they wish. I think is more than acceptable, and is what I have had in mind for my little project - which is to release under GPL, but require any contributions to be dual-licensed under GPL and Apache. That means I can switch to Apache license in future, and also I'm always free to build a closed commercial product on top of my GPL project, incorporating any contributions by outside parties (not because I want to take advantage outside contributions, but so that accepting outside contributions doesn't limit my options). The "problem" is that no one else is allowed to build a closed commercial project, because it is GPL'ed. That is a bug and a feature.

  This does raise an issue, that the license a project is released under, is not the whole part of the story. The terms and conditions of acceptance of contributions is another issue. I guess in the extreme case, no contributions are accepted, ie. such a project would have to be forked in order to make "contributions" to the project. Another case, is the requirement that contributions are multiply-licensed (like my idea), or even submitted under a different license to the original license (which I haven't heard of yet). This might result in people not wanting to contribute, I suppose, which might or might not suit the project proponents. I'm talking in general terms now, not about Sun and Java. If anything, the back of my mind is thinking about my own project.

  One would assume that contributions would be accepted under the same license as the source is released under. The point is that there is no guarantee of this, or that contributions would be accepted at all - clearly patches can, and are, rejected, eg. in the case of the Linux kernel.

  Opensource is supposedly about involvement, where the idea is to engender a community of contributors. But maybe in some cases, it's more about distribution. And in others, it's a marketing gimmick, innit. And in many cases, it's some combination of all of the above!

  OK I'm going right off topic here and so look forward on blogging on this in the near future :)

  Posted by: evanx on May 17, 2006 at 10:06 AM

• 
  You're right. Linux (the kernel) is GPL and there is no problem or forking. Well there might be some forks out there but only one is very popular.

  This happens for a very good reason: the code base is huge. Nobody has the resources to fork and keep up to date such a huge code base. In the Java case, the code base is also huge. For this reason there will be only one up-to-date (reference) implementation. This is Sun's code whether it is open or closed.

  A last point. If Sun opens the code, competing projects will lose developers to benefit the new open source code from Sun. Once the code is open sourced, Sun must be very carefull to give a chance to these independent coders that might want to change to code.

  Posted by: imjames on May 17, 2006 at 11:42 PM

• 
  If Sun releases the JLS to the OO community Java is effectively dead already.

  If they release the standard API under GPL it's also dead as that would mean that no program written in Java can be released unless it is also under GPL, which makes writing commercial systems in Java impossible.

  If that happens we're all going to have to be looking for other jobs very soon, certainly within a few short years.

  Unless of course the community as a whole refuses to acknowledge any of the inevitable forks which will flood the world and effectively freeze the language at the last version released under the current license and distribution scheme (so either 5.0 or maybe 6.0 depending on the timeframe), which would effectively mean that the entire open source farce would end up unsupported by those who matter: the users.

  The runtime I couldn't care less about, as long as it passes the compatibility testsuite it should run any classfile you give it. But when and if Sun releases control over the JLS and the standard library the platform independence of Java is gone unless the community as a whole refuses to acknowledge the very existence of forks.

  gcj shows that quite well, it is highly incompatible with the standard (which is why it isn't called Java at the moment). If and when that farce can be called Java it's the end of the road for all of us

  Posted by: jwenting on May 18, 2006 at 06:45 AM

• "Because GPL is the most developer-friendly license"

  Bollocks. GPL is the most hostile license in existence, as it doesn't allow the developer to have any control over his own license terms for anything created using anything that is released under GPL.

  Were Java to be released under GPL, nothing written in Java could be released under anything BUT GPL itself, as technically every class is a derived work from Object and the Java compiler. Since under GPL all derived works MUST be GPL licensed themselves, this would make it impossible to create Java software unless you're a religious GPL zealot.

  Posted by: jwenting on May 18, 2006 at 06:50 AM

• 
  "This happens for a very good reason: the code base is huge. Nobody has the resources to fork and keep up to date such a huge code base. In the Java case, the code base is also huge. For this reason there will be only one up-to-date (reference) implementation. This is Sun's code whether it is open or closed."

  In the case of Java it takes only a minute change to deliberately release an incompatible version. Such will rapidly appear as soon as the JLS is released to the sharks, as their very goal is to destroy the platform independence of Java and the guarantee that you can run a Java classfile on any platform that has a JVM installed of a specific level. So you'll now have a thousand things called a JVM, all claiming to be "Java 6.34.6342.6332.654363.232.32.2143" yet all completely incompatible with each other at a binary level. Source level differences take a bit more work but not a lot, and will soon follow.

  Remember we're people who's stated goal is the destruction of Java, which is unlike the Linux kernel world where the main movement is a group of people trying to retain stringent control and stamp out all competition (and they're largely the same people...).

  Posted by: jwenting on May 18, 2006 at 07:06 AM

• 
  jwenting, of course you are right, Java cannot be GPL'ed (certainly not standard libraries, although they could be LGPL'ed), because then all Java programs would have to be GPL'ed too, and that won't work!

  Check out my latest http://weblogs.java.net/blog/evanx
  entitled "CDDL'ing up to Sun."

  Clearly the CDDL is better suited to Java than the GPL or Apache ASL licenses - for the same reasons it was chosen for Solaris and GlassFish.

  
  

  Posted by: evanx on May 18, 2006 at 07:37 AM

• 
  My main fear is that any scheme that opens the standard API to change will wreak havoc on the Java landscape.

  Think of just the following seemingly innocent scenario:
  Someone decides to release a version of the standard Collections API in which everything uses indexes starting at 1 instead of 0. This would not be in violation of the JLS because that doesn't deal with such trivialities, it deals with the core language not the standard API. But it would mean that almost every decent sized application written for the last 8 years or so will no longer run reliably. Every first element in every collection will suddenly no longer be reached, every attempt to get the last element will result in an IndexOutOfBoundsException.

  And that's just a rather small change in a small subset of the standard API, something a reasonably competent programmer could pull off in a day or so at most. Other larger changes could mean not a single class would even compile anymore unless the source were changed, all without violating the JLS.
  

  Posted by: jwenting on May 18, 2006 at 08:50 AM

• GPL is fine for the JVM and the class library. Kaffe is GPLd, and you still write non-GPLd software with it, just like the Linux kernel is GPLd, and you can still write Sun's JDK to run on it.

  cheers, dalibor topic

  Posted by: robilad on May 18, 2006 at 02:20 PM

• You don't compile things with the Linux kernel...If the JLS and standard API are released under GPL, every Java class is a derivative work of a GPL product and therefore automatically GPL as well.That's the letter of the GPL.Kaffe can't enforce that because they don't control the JLS or the standard library.

  Posted by: jwenting on May 18, 2006 at 09:33 PM

• I've been maintaining Kaffe, a GPLd VM for the past 4 years, and discussed the effects of the GPL in this case with FSF's GPL compliance engineer, so I think I know very well how the GPL works in the context of JVMs and Java bytecode.

  Control of the JLS or the standard library has nothing to do with it.

  cheers, dalibor topic

  Posted by: robilad on May 18, 2006 at 10:11 PM

• 
  My understanding of the GPL and the LGPL is that libraries (eg. GNU libc used in Linux et al) have to be LGPL in order to allow non-GPL'ed programs to link to them. That is that non-GPL'ed programs and GPL'ed cannot be statically or dynamically linked together.

  The preamble of the LGPL says
  When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library.

  
  Therefore i would assume that the class libraries (to which non-GPLed java programs link as a "shared library" albeit via the JVM) would have to be LGPL'ed.

  GNU Classpath for instance is "licensed under the GPL plus a special exception" as follows

  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...

  
  Ps. Hey check out my latest http://weblogs.java.net/blog/evanx
  entitled "CDDL'ing up to Sun" in which I suggest that java would be opensourced by Sun under the CDDL like OpenSolaris and GlassFish. Clearly the CDDL (which is a "state-of-the-art" version of the MPL license) is Sun's favourite license, and for the same reason that Sun likes it, many other companies will too.

  The CDDL is less restrictive than GPL (it allows "free use" of derived works) but is more restrictive than BSD/ASL licenses (it is copyleft with respect to modifications).
  

  Posted by: evanx on May 19, 2006 at 05:13 AM

This work is licensed under a Creative Commons License.