Open Source Java

I've had a lot to say about Sun open-sourcing Java, and I never managed to get it posted given the crash Codehaus had. I knew that Sun was going to announce something at JavaOne, but had no idea what it was. I had a lot of thoughts about it, and I'll be perfectly frank - I was wrong. I thought Sun was going to actually do something specific. I'm not dissatisfied - I think that the significance was that Jonathan Schwartz committed Sun to releasing Java SE under an Open Source license, and that was a big thing. So, now might be a good time to start musing about this...

It Won't Happen At Once

Like Glassfish and OpenSolaris, Sun won't do it at once. Some Sun people think they can, but they can't. There has been 10 years of very fast, very competitive growth in that codebase, and I'm betting that Sun doesn't have a real clue what's in there. The code will have to be sorted through and examined. I know from my experience at both IBM and Intel in OSS code contributions, it's prudent to go over the code with a fine-toothed lawyer, even when the code was specifically written to be clean-room and clear of external IP issues. In this case, there's going to be lots of encumbrances, and I'm really hoping that those with the encumbering IP help out and make this easy for Sun. This is a big and important step for the entire Java ecosystem.

License?

What license will Sun use? This has been and will be a source of rampant speculation. Sun needs to balance two things - dealing with their darkest fears around compatibility with the need for a licensing regime in which all players can innovate and control their own IP. Clearly the GPL won't do. While I am a big fan of the Apache License and the full freedom it offers, I can live with the CDDL and other soft-copyleft licenses. At least then, people could invest in innovation, and choose how they wished to license the IP for the things they created that were truly new.

I've suggested to anyone who listens that if Sun does have to do the GPL, they at least dual license under something free-as-in-freedom like the Apache License, with a non-free/non-open-source addendum that licenses the code under the Apache License if and only if any derivative work passes the TCK - IOW, is compatible Java. While we couldn't use that code at the ASF, as it's not open source, they would at least make it easy for people to do innovative things with Java (port to new platforms, better performance, embed in new applications...) and retain the freedom over their own code.

Maybe the best solution is the CDDL for core stuff, and BSD-like license for the not-critical-to-compatibility parts. Maybe do all the tools and plugins under BSD (so we can use them in Harmony), and the rest under CDDL? (Except for the bytecode verifier that we also need in Harmony...)

Community?

The community that Sun creates around their open source implementation of Java will be the most important aspect - more important than the license. People tend to forget that 'open source' is really a combination of a license for code and a governance model for the community. Simply put, people want to participate on a level playing field where all activity is transparent, where everyone is a peer, and everyone shares in the same benefits of the collaboration. To that end I hope that Sun creates a community that allows anyone to be a committer after some amount of demonstrated competence, that the copyright model is symmetric (IOW, it's not like Glassfish where Sun's copyright contributions belong to Sun, and your copyright contribution belong to Sun...), and that the governance model is clearly defined, and open in it's execution.

Again, this project will only reap the collaborative benefits of open source if every possible participant - be it individual, academic or commercial - has the same chance to contribute and the same opportunity to benefit as every other participant.

While it does seem like I'm shooting myself in the foot as I'm one of the founders of and a big proponent of Apache Harmony, I'm actually willing to help with this one. I just don't know who to ask....

Maybe They Will Confuse Java with the Ecosystem

So here's where the crazy talk comes... I'll bet, and it's only based on sheer optimism and that things happen for good in the universe, that the people from Sun listening to Jonathan at JavaOne got it wrong, and aren't going to just open source Java SE, but rather open source the whole kit and kaboodle. Java EE is almost done with Glassfish, so it's only Java SE and Java ME, and the JCP.

Now, that's just crazy talk, of course. But Sun has done some odd things, and if you understand Sun's business model, it actually makes sense. "Lift heavy or go home" as a good friend used to tell me. (I work at home now...)

Were they to do that, I have some thoughts here too :

First, do it in steps. You didn't get Glassfish (Java EE) right, so I don't believe you'll get Java SE right either. But it will be better, and the learning you do in Java SE can be both plowed backwards into Glassfish as well as forward into Java ME.

Second, engage the community on what to do with the JCP. A lot of us (speaking as the Apache EC rep) have poured a lot of love and energy into the JCP, and given the promise that it will become a truly open and neutral ground for governing the ecosystem, I think you'll get a lot of positive engagement on how to make it better.

Finally, be careful with the name "Java". Don't abuse and dilute it by branding this new endeavour as "Java" or "Something Java". Just as we at Apache Harmony are "Apache Harmony, an implementation of Java SE", so should you be "Sun 'Jonathan', an implementation of Java SE".

You've done it in the past with "Java Enterprise System" and "Java Desktop System", and most recently with that awful idea, "Java DB". Yes, you own the trademark, but "Java" is bigger than a mere trademark now, and in a community sense, we each own a little piece of it. People are pouring in creativity and innovation, planning for the future on it, building their businesses, their educations. It's a part of their social fabric. It's a promise of things interconnecting, it's a way of thinking, of working, it's an important facet of our technologically-oriented lives. Let it continue to be the thing around which we all share, all collaborate. You've created a wonderful thing - let us all continue to build on it, rally around it and yes, as owners, help protect it.

Thanks for reading this far :)

Note : the above is my personal opinion, and doesn't reflect the view or policy of my current or past employers.

28 Comments

The GPL has worked very well for Linux and I can't think of a reason it won't work just as well for Java. A clear statement (or exception to the licence) that the GPL won't reach across the boundary between the VM / standard API and user applications is all that is needed to assure platform users that they are free to license their applications as they choose. The GPL will also prevent any single company from taking defacto control of the Java platform, which is likely an important consideration from Sun's perspective.

But Linux doesn't actually use the GPL - it uses the GPL plus an exception. As you point out, a modification would be needed to prevent the GPL from doing what the GPL is intended to do. So if we agree that we don't actually want the GPL, why not another license, like CDDL? All of Sun's IP would be 'protected', while still allowing important degrees of freedom to those building on or modifying the codebase.

Besides the issue about user code, I think that a GPL-ed Java implementation would limit where that code could be integrated, and I think that ubiquity of Java is an important.

As for Sun's worry that [another] company will have control of the Java platform, I wonder if there's a bit too much of "fighting the last war" there or better, not being able to see around their own muzzle flash. No one wants a bent or broken Java, or a managed runtime that's sort-of-like Java. Today's IT has a huge investment in Java, and they also understand the dangers of lock-in. I'd be very surprised if they'd let another company take proprietary control.

I think we forget that it's not through control of source code that Java maintained it's compatibility promise, but through careful control of the brand Java, and what it technically means to be able to call something Java. That doesn't go away if Sun used a liberal licene for it's source.

Geir, have you told Linus that the Linux kernel is GPL+Exception? He is unaware of that (http://kerneltrap.org/node/1735). Frankly Geir, your arguments are a bit fetched. Sun has stated their clear interest in not having incompatible forks of Java. The GPL does not prevent forks it just legally guarantees sunlight into the situation. If I know that Sun will take any significant GPL'd code that is published anyhow back into the VM than my motivation to create a fork is of course lower. The second way is through trademarks and such. You are arguing that the right to create proprietary forks of Sun's JDK is an important freedom. One benefit of that (ASL/BSD type license) is that the proprietary forker might be creating something completely different (maybe a .NET VM) and might make improvements to say the GC algorythm and donate that back. It makes the codebase more available to those producing proprietary software (wider distribution) and hopes that they in turn will support the project. That might happen because they value the continued life of the project. For instance, Microsoft might think "gee all this great VM research is good, we should support it by donating any innovations we create from their code back to them" and share the love. However they also might not feel love. The GPL means they probably won't use it. However if they do they're legally obligated to share-alike. However their is a more complicated issue of the copyright assignment. If Sun does GPL (without an exception like GNU classpath's) then they do not have to require copyright assignment, but if they want to be able to sell the freedom to create proprietary closed-source forks for profit then they will need that (c) to do it. There is a clear downside to them there. In short ultimately the "freedom" you're arguing over is the "freedom to close" and nothing more. The question is whether sun thinks the "Freedom to close" is in their interest. You've said nothing that convinces me (or will likely convince them) that it is.

For the record I don't care which way they do it, but let's not be disingenuous about hat is in their interest and what is not.

It is known that there are modules for that Sun has no right for releasing them under arbitrary license. Why then not to choose GPL and take these modules from the GNU Classpath implementation? The known sources talk about fonts, but I know that also omg.org.* classes are normally generated from the OMG IDL files with "no modify" license. Despite I have only seen javadoc, the Sun's classes seem generated as well. And despite I do not known how and from where, it is likely that from the same IDL.

GNU Classpath has the same classes manually written using the printed .pdf documentation only. Adding proprietary parts without sources is something that the world open source community would not like very well.

It is known that there are modules for that Sun has no right for releasing them under arbitrary license. Why then not to choose GPL and take these modules from the GNU Classpath implementation? The known sources talk about fonts, but I know that also omg.org.* classes are normally generated from the OMG IDL files with "no modify" license. Despite I have only seen javadoc, the Sun's classes seem generated as well. And despite I do not known how and from where, it is likely that from the same IDL.

GNU Classpath has the same classes manually written using the printed .pdf documentation only. Adding proprietary parts without sources is something that the world open source community would not like very well.

I don't know where to start :) From the link you gave, clearly Linus sees a gray area with the GPL and kernel binaries, so thus has given a verbal clarifying statement. Given that this statement isn't operational to everyone that uses the GPL for other projects, it's an "exception". If you would prefer that I refer to it as a "clarification", I'd be happy to do that, but it's clear that it's the GPL + "something else to make it palatable to the ecosystem in which it's being used".

Next, I think you need to define what "argument" is far-fetched. I'd like to point out that in my thinking, there is no such thing as an "incompatible fork of Java". If code isn't compatible with Java, it isn't Java, it's something else. No one wants broken Java - I have great confidence in the market here, and I suspect that Sun does as well, given their historical concern for compatibility.

As for proprietary forks as a freedom, please don't put words into my mouth. I'm saying it's useful and I believe that it would be beneficial to the ecosystem (being clear that compatibility is important, and therefore 'fork' is a bit of a loaded word). That doesn't imply I feel everyone has a right to it - the right to create a proprietary fork of Sun's JDK only happens if Sun chooses via it's license to allow it. It's clearly their choice. I'm just providing encouragement. :)

One of the problems in using the GPL to enforce compatibility is the side effects. The classlibrary and JVM are rich in software that can be reused outside of the VM+Classlibrary platform implementation at no risk to compatibility or the ecosystem. Compression algorithms, porting layers, data structures, etc. All can be re-used elsewhere in project that aren't competitive or disruptive to the Java platform. Maybe the GC can be reused in a VM for Ruby, for example. Or those compression algorithms can be re-used in software embedded on whale-tracking transmitters.

With respect to "Freedom to close", I guess my position boils down to having the freedom over my own IP. That's why I suggested that the CDDL would be a reasonable compromise. I can take the files licensed to me and have to give back changes I make to them - help maintain "the commons" if you will. However, I stil can create and innovate around the sides - if I replace one or more of them, I get to choose what to do with the replacement as they are my own work. I think that's fair, don't you?

Yes, and I would expect that the JCK (TCK for Java SE) will also be available under an open source license eventually. Until then, there always is things like Mauve and tests that we have in Harmony, like our Swing/AWT/Java2D suite, which the GNU Classpath project also finds useful.

We're *really* interested in this kind of feedback ... and please, if you can, do go to http://community.java.net/jdk/opensource/ and use the forums as well ... your opinions and comments really do matter to us as we move this forward.

Ideally, they'll position themselves as the upstream right between Harmony and Classpath, and dual license code under GPL2/ASL2. That would allow Sun to bridge the gap that neither ASF nor FSF really can, while gradually getting people to work on a unified code base.

I work at Sun, but I'm not involved (at this point) in any Sun open source projects. I just wanted to say that it seems totally crazy to think that Sun will drop the requirement for some kind of copyright assignment. If Sun uses GPL I would expect a dual license would the most likely scenario. Download tar file XX and get the GPL Java. Download tar file YY and get the CDDL Java. That would be the best way to get Java used (and bundled!) everywhere (IMHO).

Joint copyright ownership makes collaboration much easier, and future proof, as it provides all the copyright holders with the ability to clarify/adapt/improve the terms of the licenses, without having to re-acquire explicit consent from each contributor, like Sun has to do right now.

Not having a joint copyright mechanism would mean having to repeat the whole process again and again for every license change. That's impractical.

Of course, I would have suggested the ASF given the more liberal definition of "freedom" they use ;)

But seriously, as long as the organization was independent and transparent, and chose a license that allowed freedom over one's one work (ALv2, CDDL, ...) and had some reasonable patent language, I'd be happy.

As most of you are probably aware of, there are many organizations that can't use GPL software because of the ambiguities in the license. Corporate lawyers just won't let it happen.

A GPL'd compiler might be alright, but runtimes and especially libraries are problematic. Our large organization would have to stick with official pre-GPL releases of Java and then look for other solutions for the future.

As most of you are probably aware of, there are many organizations that can't use GPL software because of the ambiguities in the license. Corporate lawyers just won't let it happen.

A GPL'd compiler might be alright, but runtimes and especially libraries are problematic. Our large organization would have to stick with official pre-GPL releases of Java and then look for other solutions for the future.

As most of you are probably aware of, there are many organizations that can't use GPL software because of the ambiguities in the license. Corporate lawyers just won't let it happen.

A GPL'd compiler might be alright, but runtimes and especially libraries are problematic. Our large organization would have to stick with official pre-GPL releases of Java and then look for other solutions for the future.

Short answer, yes. Longer answer, it was a failed attempt to play on the word "free".

When you agree to the GPL, and combine a GPL-ed work with your own, you give up licensing freedom over your own work. I don't mind 'soft' copyleft licenses like Mozilla, CDDL, EPL or CPL, where if you build on what is licensed to you, you must give back, but you are free to build along side under your own terms. I prefer to have a choice.

Personally, that strikes me a "more free". But this really is about personal preference and personal philosophy, I suppose - strong copyleft, weak copyleft and non-copyleft open source licenses have all been successful....

Forcing others to use the GPL is no freedom. Freedom means that all developers got the choice to chose their own licence for their code base. (Even if they want a closed source licence!)

The GPL is unable to force others to contribute to Java. As such there is no benefit in it. The people willing to contribute will do it voluntary. And when they contribute on a voluntary base, they will do this also for a CDDL/EPL/BSD/... licenced Java.

In my eyes the Java Source means nothing. Its all about the community surrounding the code base. Dont force freedom of the source code - give freedom to the developers. (Im not sure, but i think thats the ASF strategy)

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.