You’ve probably already read about Sun’s continuing effort to open source Java. And, before I get too far into what I have to say — my preliminary reaction is that this is awesome.

Sun has even made a couple nice ways to provide feedback.

I think quite frequently about the properties that a free Java implementation must have; this, after all, is the reason for the existence of Classpath and gcj. I’m going to make a stab at writing them all down here, in the hopes that this helps the efforts at Sun.

License

What license should be used?

I don’t have a particular answer to that. However, I do have a few requirements to place on the result.

First, the license absolutely must be open in the DSFG sense. This probably goes without saying, but I figured I’d be explicit.

Second, ideally the license would be GPL compatible. It doesn’t make sense to me to limit innovation by closing off the JDK from mixing with an entire class of software. Also, a move like this would be an important victory in the battle against “license silos” and for license harmonization — important because, let’s face it, the opening of the JDK will be a truly significant open source event, the most important one in years.

If GPL compatibility somehow cannot be achieved, LGPL compatibility is still required. The reason for this is that a reasonable chunk of the platform (e.g., all the gnome-ish GUI libraries) are LGPL. This is a much lower bar to meet, I’m sure there won’t be a problem here.

Likewise ASL compatibility is a must.

Geir claims that the GPL would be a bad choice. From my perspective it would not be. True, Classpath isn’t pure GPL — but that is largely an accident of history, based on the embedded systems origin of gcj. My impression now is that with the advent of embeddded Linux, the embedded world has largely crossed the GPL barrier. Beyond that, my focus these days is really on the free operating systems like Linux; GPL would present no problems for, say, Fedora.

One important consideration in the license is what to do about patents. This isn’t really my area; I think patents are pretty bad and so I have a huge blank spot in my brain about them, a spot which is filled with a mixture of denial, anxiety, and loathing. The key is to make sure that the result is acceptable to the various players — corporations and also nonprofits like Debian or Fedora. This shouldn’t be hard, plenty of other organizations already have done it.

Compatibility

Sun worries about compatibility. I hope those fears can slowly be put to rest. At least here in the free world, we recognize that compatibility is very important. In fact, we put an absurd amount of effort into guaranteeing compatibility in Classpath. The whole point, for us, is to make it possible to run the enormous body of existing Java code on free OSs.

Ideally the TCK would also be opened as part of Java. I picture Fedora’s Sun-based Java RPM working much the same way as the GCC RPM: we would run the TCK as part of the build process, and die if it does not pass. This would provide critical quality assurance.

Note that rules requiring testing of binaries by some 3rd party won’t work too well. For Fedora and the like, the ability to build from source is crucial. This is especially true as the kernel and glibc hackers continue to innovate — over the years changes in these areas have caused problems for the various proprietary JVMs. (And, supporting this whole opening process: had the JVMs been opened, we would simply have fixed them. But due to their closed nature we either required workarounds, or simply lived with the brokenness.)

Sharing

We’ve heard that not all of the code will be available under an open-source license. It would be great to get more details on what, precisely, won’t be available.

The sooner we get feedback on this, the better. This seems like a great area for collaboration to occur. I can think of a couple ways to make it happen.

First, if the problem areas are already implemented in Classpath, we could open a discussion on contributing them. RMS would most likely have to be involved — but, really, his reputation is much worse than the reality. I’d support cooperation along these lines (assuming of course that the baseline is met properly: an acceptable license, etc). There are probably a few interesting things in Classpath that would benefit the JDK.

Second, if the areas in question aren’t covered by Classpath, maybe we could put a little focus on them in order to have the code available when the JDK is opened. This needn’t be a Classpath-driven effort — I’m sure many people out there would be interested in this same result.

Governance

There are plenty of well-run free software projects out there. Choosing a functioning governance model isn’t that big of a deal any more — heck, folks at Sun can just walk across campus and ask people working on any of their other free software projects. I’m just not concerned about this; the biggest thing is to have a committment to success, so that if something isn’t working, you change it.

That said, there are a couple things worth noting.

The JCP could be more open. Both Dalibor and Geir have covered this point well. Listen to them!

I’ve read the occasional blog entry worrying about simply opening the process to anybody. I agree with Simon here — anarchy is no way to run an open source project. I can’t think of a single successful one that is run that way; instead, developers have to earn their stripes by a process of patch submission and review. I don’t think Java should be any different; if anything, the barrier to entry ought to be a bit higher than ordinary, since Java is a large, mature, and (presumably 🙂 stable code base. We certainly vet people before giving them access to Classpath, and we also watch them more carefully just after they’ve been given commit rights.

Final Advice

You’ll probably see a lot of random, uninformed, and hostile commentary on slashdot and javalobby. At least, that’s been my experience historically — “open source java” is a big red flag for the bulls. My advice is, ignore the crap and concentrate on pushing forward.