Open Source Java

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.

9 Comments

  • Uh, dude, GPL and Apache licenses are incompatible, so by your own argument, you couldn’t use the GPL for open source java.

  • GPLv3 is intended to be ASL compatible.

  • Which great, except that it doesn’t exist. Waiting for the FSF to finish projects in order to start your own has a history of not working terribly well.

  • “presumably stable code base”

    All Java code is available for reading, by anyone, since ever….

  • “Developers should earn their stripes by patch submission an reviews….”

    Reviews by whom? Again we will have a class of elite who may or may not be fair…its better it stay with Sun atleast we know who exactly is doing the review

  • Felipe: first, I was just being a little silly — I’m completely positive that the JDK code base is stable.
    However, secondarily, the terms of reading the source do matter. Those of us working on Classpath and gcj have never looked at the JDK sources, for cleanroom reasons.

    (Update: I originally wrote the wrong name, sorry Felipe.)

  • Detjh:
    There’s a whole literature out there on the mechanics of open source, that goes into this issue in depth. In essence the idea behind open source governance is to ensure that competence rises; in successful projects the decision makers are those who have proven themselves over time to be good at it.
    In this situation my advice to Sun would be to start with their current maintainers — people already working on the source, who are already known to be competent. From there the pool of developers with commit access can grow organically — those who submit a stream of high-quality patches would eventually be given access; perhaps their access would be limited at first and then grow as they prove themselves ever more trustworthy, or competent.
    This general model works for any number of large, complex open source projects: Apache, GCC, the linux kernel… the precise mechanics vary, but the underlying idea is the same. I don’t think there is anything special about the JDK that would warrant a different approach, but I’m willing to listen if you’ve got a more concrete objection.

  • There’s no problem with using the GPL for the Java compiler/interpreter, but it’s generally a bad idea to use the GPL for libraries since it would prevent you from using it with many open source licenses (including all proprietary libraries). It’s one of the reasons why GNOME has a LGPL (or compatible) license requirements for libraries. One consequence of this is that Mono (Java’s .NET competitor) may get into GNOME officially, but Sun’s Java won’t. Another consequence is that Classpath will never get absorbed into Sun Java because there is still a need to have Java work with non-GPL compatible open source (and otherwise) licenses. Neither of these help Java if Sun’s goal is to fight .NET (which currently has an unfair advantage due to Mono) and reduce fragmentation.

    IMO, I think the LGPL or GPL with exception would make a much better license choice.

  • […] licenza GPLv2, le malelingue comunque avevano già iniziato a parlare, come potete leggere qui, qui e […]

Join the Discussion

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>