To Sun: Good Job on on the JRE License, But I’ve Got Another Job For You

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

For anybody that’s ever tried to install Sun’s JRE on the Linux platform, it’s been readily apparent that one of the major issues with Java on the Linux platform has always been the installation. Due to some rather absurd provisions within the license that governed the JRE, Linux distributions both community and commerical have been unable to include Java as another runtime. So as I’ve been telling various parties within Sun for some time, when Java goes to battle it out with the likes of Mono, Perl, PHP, or Ruby, it’s consistently been fighting with one hand tied behind its back. Sun’s Dave Johnson noted this a little over a year ago, saying “Wouldn’t it be awesome if you could just apt-get, pkg-get or emerge Java on your favorite open source *nix platform?” I concurred, describing the difficulty of installing Java on Gentoo thusly:

If it’s not clear to you, here’s what he means. Gentoo users such as myself use the command emerge to install new packages; typically, I simply type something like ’emerge mozilla-firefox’ and Gentoo goes out, downloads the necessary components, checks the dependencies, and installs the software. No fuss, no muss. Here’s what happens when I try to emerge the J2SE:

!!! dev-java/sun-jre-bin- has fetch restriction turned on.
!!! This probably means that this ebuild’s files must be downloaded
!!! manually. See the comments in the ebuild for more information.

* Please download j2re-1_4_2_08-linux-i586.bin from:
* http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2re-1.4.2_08-oth-JPR&SiteId=JSC&TransactionId=noreg
* (select the “Linux self-extracting file” package format of the JRE
* and move it to /usr/portage/distfiles

Slightly less convenient, I think we can all agree. Why it has to be this way is part licensing and part ideology, but either way it’s not an ideal experience from either the developer or user perspectives.

Well, guess what? Sun’s got good news for you, because they – with help from the Debian & Ubuntu communities – have taken the time to fix the license for Java and the distros have noticed. According to Simon, who told the assembled crowd here at DebConf about this yesterday, Debian, Ubuntu and my own Gentoo will all be picking up the JRE and including it within their package libraries. I can’t verify that it works as promised just yet, because the JRE hasn’t hit the Gentoo libraries and my Ubuntu box at home (via SSH) seems unable to find it, but I’m sure it’ll be just as Simon outlined. apt-get install sun-java5-jre? You got it.

So what has the general reaction been? Well, the man behind Debian seems to think it’s a pretty good plan, though he has doubts about the distros shipping it by default as they do with Perl and Python. The reaction amongst the Debian folks I’ve spoken with down here? Mostly positive, although I can’t say that anyone’s jumping up and down excited.

It seems clear to me that only the most ardent Sun critics will perceive this change as a negative, as it’s more or less an unalloyed good – regardless of what one thinks of the Java language and platform. For all that, it will undoubtedly leave some wanting in that it stops short of actually open sourcing Java. While I personally have reservations about the prospect of that happening – compatability must be preserved at all costs, in my view – there are many who are desperately hoping that Sun makes that next step. For folks that count themselves as members of that camp, there’s hope yet. According to Tim Bray, the two people one presumes have the most say as to whether Java goes open source – Sun’s new CEO Jonathan Schwartz and new head of software Rich Green – both sound amenable to the idea. Publically, at least.

What I’m interested in seeing, as mentioned previously, is whether or not the licensing change leads to a lessened interest in open source Java. While there are obvious advantages to an open source Java, the licensing restriction was one of the more significant and obvious drawbacks. As one very intelligent individual reminded me this morning, however, the lack of an open source Java still imposes roadblocks. Within Ubuntu, for example, Java will be marked as non-free and therefore will reside in a different repository from the majority of applications; as a result, installation will require an extra click. A small point, but no less relevant for that.

Some of you may be convinced at this point that the other “job” referred to in the title of this entry is in fact open sourcing Java, but you’d be mistaken. There are many people I know that will shudder to hear this, but I’m actually not terribly concerned about whether Java is open sourced. Would it solve some problems? Unquestionably. Would it introduce some new ones? Potentially. I think there are problems – logistical, technical, and political/people – that need to be solved before it gets there, and I’m not optimistic that they’ll be addressed in the short term.

If not Java, however, what might I be referring to? To answer that, consider where I’ve been for the past three days, and ask yourself what the world would look like if Linux and Solaris could compete on kernel features, while consolidating the architecture above the kernel. Imagine, if you will, a world in which Debian’s package management system formed the underpinnings not just for Debian or its Linux derivatives such as Ubuntu, but for the Solaris family of applications. Many will ask whether that’s even technically possible; one need look no further than Nexenta to answer that. Is is possible in practical terms? Unclear.

Solaris is clearly in need of such features, and Simon’s talk from Sunday indicates that the walls between Linux and Solaris lands are thinner than they used to be. Sun could make it even more interesting for the folks from Debian if they decided to dual license and port a piece of their technology in return – something like, say, ZFS. But will the two groups – each of whom has a reputation for being obstinate at times – seek common ground in this area? Tough to say.

But just in case any of the folks from Sun are listening, and are looking for other problems to solve, let me humbly suggest they start with the package management problem, and they consider Debian’s approach as a potential solution (whether the actual tools are ported or not). The potential solution. There’s a reason I’m blowing away Solaris 10 on our V20Z and replacing it with Nexenta, after all. In doing so, Sun could potentially make the largest Linux community on the planet quite happy, while giving their Solaris customers an inexpressably useful new feature. Why not make Debian’s tools an industry – and cross-OS – standard for application/package management. Why not, indeed, build traction for the Debian packaging format as a standard for the OSDL, LSB or other Linux standards body to rally around. Maybe it would even be worthwhile for Sun to have a chat with Ubuntu’s Gustavo about using Smart Package Manager as a means of leveraging the considerable assets currently located in the Blastwave repositories.

I mean, how hard could this all really be? 😉

Disclaimer: Of the mentioned firms, only Sun is a client. I use Gentoo, Debian and Ubuntu on a regular basis, and have plans to install Nexenta, but none of those distros are clients.


  1. Well, there *is* blastwave and pkg-get, but they have their own set of ideological incompatibilities with the Solaris Wad Of Stuff. That said, Blastwave is better than nothing.

    It also occurs to me that there’s another wildly popular operating system out there that doesn’t have an automated package installation mechanism: Microsoft Windows. But the Windows world solves that problem differently: rather than having a nasty, intricate, terribly complicated, viciously-hard-to-grok software dependency graph that’s exposed to users, they have a nasty, intricate, terribly complicated, viciously-hard-to-grok dependency graph that only developers ever have to worry about.

  2. You’re blowing away Solaris to replace it with an innovative OpenSolaris distro, and this is supposed to somehow be bad news for Sun or for Solaris? Seems to me that it’s more vindicating than anything else — I would much rather Nexenta thrive than Solaris accidentally step on Nexenta by trying to usurp Nexenta’s differentiator. Is Debian packaging great? Sure. Is is better than System V packaging? Probably, but making that switch for Solaris is an expensive proposition: for better or ill, many Solaris enterprise customers (to say nothing of Sun itself) have customized tools around the extant Solaris packaging. Which is not to say it can’t or shouldn’t be done, but rather to say that a primary reason for open sourcing Solaris was to allow for new choices for customers by allowing new distributions to innovate in new ways — while still taking building on Solaris bedrock. So to me, it’s much more relevant that you were able to make a new choice here than it is that a particular technology is absent in Sun’s distribution of Solaris…

  3. Dan: i’ve used – and contributed to – Blastwave, and i applaud their efforts. more, i think it’s critical that those efforts be leveraged going forward. but i think it’d be wise for Solaris to consolidate on Debian’s software so as to seamlessly leverage skills from the Linux community.

    Bryan: not bad news, precisely, but if Solaris begins losing a volume audience to distros on the basis of package management, that would seem to be less than ideal. Nexenta is great, don’t get me wrong, and i’m happy to see it. but i don’t think Solaris should leave that problem to distros, lest they find themselves in a situation to Linux a few years down the line; one in which everyone has solved the same problem using different, incompatible means.

Leave a Reply

Your email address will not be published. Required fields are marked *