Java becomes more distributable

[Posted May 17, 2006 by corbet]

With a great deal of fanfare, Sun Microsystems used its podium at JavaOne to announce a change in the Java licensing terms intended to make it easier for distributors to ship Sun's Java implementation. To this point, the terms have been so difficult that few distributors bother; those wanting to run Java code must either install Sun's implementation themselves, or go with one of the free alternatives. Sun, perhaps seeing that said free alternatives are rapidly improving, has tried to reestablish its own dominance by way of a small licensing tweak. It is a half measure at best.

Sun's new terms go under the name "Operating System Distributor License for Java," or "DLJ" for short. As always, when pondering licenses, one must go to the actual text. So, for the curious, a look at the text of the DLJ (v1.1) is warranted. The core of the DLJ is this:

Sun also grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and distribute the Software, directly or indirectly through your licensees, distributors, resellers, or OEMs, electronically or in physical form or pre-installed with your Operating System on a general purpose desktop computer or server, provided that...

So distributors can now ship the Java code as part of the operating system, assuming they meet all the conditions - and there are several of those. They include some obvious ones, such as indemnification of Sun from liability, and some that one would expect, such as the requirement that the software be distributed without modifications. Some of the other conditions are interesting, though. Consider:

(b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System;

So the license only applies to operating system distributors. This clause would appear to make it impossible for a third party to distribute Java packages for somebody else's distribution. So this license may not improve the lives of people who run distributions from organizations which will not distribute non-free code at all.

Next condition:

c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software

So Sun's Java remains incompatible with any free Java implementations and, presumably, a fair amount of related code. How this term might affect the combination of Sun's Java and Eclipse is an interesting question.

Finally, there is a term stating that if any compatibility issues arise "caused by the interaction of the Software with your Operating System", the distributor has 90 days to fix the problem or stop distributing Java. It is unlikely - but not inconceivable - that such a term could be used to pressure a distributor to change Linux system call semantics which could be deemed to cause incompatibilities.

This license can be advantageous for distributors with mechanisms for distributing non-free software. Some of them may now be able to ship Sun's Java code for the first time. Thus, for example, Java has just landed in Debian's non-free repository; Ubuntu and Gentoo seem interested as well. But the new license will not help Fedora users, since there is no place in Fedora for non-free code (though what Red Hat does with RHEL could be different). For all the hints made at JavaOne regarding the eventual open-sourcing of Java, this code remains resolutely non-free at this time. Sun's slightly more friendly license has not changed that fundamental fact.

to post comments

"System call semantics?"

Posted May 17, 2006 17:55 UTC (Wed) by cventers (guest, #31465) [Link] (14 responses)

> It is unlikely - but not inconceivable - that such a term could be used
> to pressure a distributor to change Linux system call semantics which
> could be deemed to cause incompatibilities.

I'm curious what is meant to be implied (if anything) by this remark. Has
Sun engaged in such behavior before? Is there any real worry that they
might?

Furthermore, what would Sun (the theoretical big evil Sun that would do
such a thing) stand to gain? Just to be sure we're on the same page,
we're talking about the kernel to userspace ABI here, right?

I think in a practical sense, unless I'm misreading this remark, Linux
distributors would choose to keep the Linux ABI (and toss Java) as
opposed to keeping their half-assed Java distribution rights and
breaking, well, everything.

"System call semantics?"

Posted May 17, 2006 17:58 UTC (Wed) by corbet (editor, #1) [Link] (4 responses)

As noted in the article, it's an unlikely scenario. But if, say, Sun were to decide to pick on the relative thread-safety of the write() system call, there could be an issue here. When looking at licenses and contracts, it is good to keep an eye on what the language allows.

"System call semantics?"

Posted May 17, 2006 19:05 UTC (Wed) by cventers (guest, #31465) [Link] (3 responses)

Well, I guess my curiosity is basically this - what would be the value of
Sun "picking on" a Linux vendor because of supposed incompatibilities? At
least how I see today's distributions operating, I think most of them
would (politically) tell Sun off. There are legions of Linux users like
myself that don't particularly care for Java. (Besides, as we all know,
there are some reasonably good open implementations that are hard at
work. The fact that we've had to do that tells me that Java is not a
language I'd ever choose [on a political or ideological level]...)

So perhaps the worry is that we'll all start shipping Sun Java, drop our
open implementations, become dependant and then Sun will have us by the
balls? (Of course, as you say, it's an unlikely scenario... but who knows
what a dying company might do if their entire operating system division
went South, leaving them with nothing but an enterprise language powering
far too much of the Internet...)

"System call semantics?"

Posted May 18, 2006 7:24 UTC (Thu) by pimlott (guest, #1535) [Link] (2 responses)

what would be the value of Sun "picking on" a Linux vendor because of supposed incompatibilities?

I suspect a more realistic scenario is: Java's threading is implemented using POSIX pthreads, but Linux threads aren't quite POSIX. This was in fact the case until recently, the cause of much griping by thread programmers (pour souls) and contention among Linux hackers. I believe this issue is now quite resolved, but if it weren't, I can imagine Sun refusing to allow distributors who ship the non-standard Linux threads to also ship Sun's Java. It's not too much of a stretch that this would tip the distributor's decision to switch to a new thread library. This could indeed break some other program relying on the old thread behavior.

"System call semantics?"

Posted May 18, 2006 16:49 UTC (Thu) by jonabbey (guest, #2736) [Link] (1 responses)

Actually, Java's threading semantics have always been relatively underspecified, specifically to make it possible to have Jave implementations on a wide variety of underlying operating systems.

Remember Java on Macintosh OS 9? ;-)

"System call semantics?"

Posted May 18, 2006 16:58 UTC (Thu) by pimlott (guest, #1535) [Link]

Remember Java on Macintosh OS 9? ;-)

checkmate, you win

Study capabilities, not intent

Posted May 17, 2006 19:08 UTC (Wed) by felixfix (subscriber, #242) [Link] (8 responses)

It is important to evaluate someone's capabilities more than their intent. Maybe current management at Sun has no intention of dropping a bomb on Linux, but all it would take is a bad year or two, a shareholder revolt, and a hostile takeover by some corporate raider or patent troll who sees a chance to make a quick buck.

Study capabilities, not intent

Posted May 17, 2006 20:00 UTC (Wed) by cventers (guest, #31465) [Link] (6 responses)

Oh, absolutely -- I agree. But in this case, the licensing agreement
seems to require nothing more that the distributor in question stop
shipping Java.

Scenario:

1. Sun says "Ooh, hey, Red Hat... you're not compatible because your
silly kernel doesn't guarantee that write() is atomic and ours does. Now
you must stop distributing Java"
2. Red Hat stops distributing Sun's version of Java
3. Sun continues to go broke
4. Even more people migrate from Sparc/Solaris to x86/Linux
5. Sun continues to go broke
6. Even more people migrate from Sparc/Solaris to x86/Linux
7. The last Java programmer sees the light and switches to
_________________ (perl/ruby/python) OR gcj continues to get better...
8. Sun goes broke (totally) and stops bothering people

OK, I'll admit it -- I really don't like Sun, Solaris, Java or the people
involved. And I agree with the notion that you should read the licenses
carefully. The reason for my comment was just that the way the article
was written - well, the language seemed to imply that Sun either had
control over the Linux system call interface or could use it to somehow
do damage to Linux vendors. I can't possibly see how Sun could do any
damage at all to Linux vendors in this way (unless being an Indian giver
counts).

Am I missing something? Is the compatibility clause a real cannon in the
weeds, or are we just nodding at eachother, expressing mutual distrust of
Sun Microsystems and their motives?

Study capabilities, not intent

Posted May 17, 2006 21:09 UTC (Wed) by emkey (guest, #144) [Link] (4 responses)

The hammer is potentially larger then you imply in that many vendors, Redhat and Novell for instance have enterprise editions that are in theory supposed to be stable for the multi year lifespan of a particular version. Swapping from one Java implamentation to another would basically break things badly in this case.

Study capabilities, not intent

Posted May 17, 2006 23:54 UTC (Wed) by piman (guest, #8957) [Link] (3 responses)

So would changing kernel system call semantics.

Study capabilities, not intent

Posted May 18, 2006 0:45 UTC (Thu) by emkey (guest, #144) [Link] (2 responses)

Exactly, rock meet hard place.

Study capabilities, not intent

Posted May 18, 2006 1:02 UTC (Thu) by cventers (guest, #31465) [Link] (1 responses)

While I don't think Java is anything close to irrelevant in the market,
there is a lot more to Linux than Java. I think that if anything like that
ever did happen, a patch author who wanted to change the system call
semantics would have to prove he could do so without side effects.

The distributions would always have options in a crunch - hell, you could
even do something crazy and temporarily hack the kernel to behave as Sun
defines compatibility, and even just for the Java process itself.

So maybe the distributions carry their own aftermarket Java patches until
they can migrate.

Study capabilities, not intent

Posted May 18, 2006 1:37 UTC (Thu) by miah (guest, #639) [Link]

RedHat has already been shipping Java, I'm not sure for how long, but I can easily install it on my RHEL systems by adding the proper channel. But guess what, its not Sun Java, its IBM, the IBM JDK, Bea WebLogic and other Java tools are already there. I'd be suprised if Redhat decided to go with Sun Java in RHEL 5.

A quick google turns up the following Press Release: http://www.redhat.com/about/presscenter/2004/press_apps_s...

Study capabilities, not intent

Posted May 18, 2006 6:36 UTC (Thu) by wookey (guest, #5501) [Link]

"OK, I'll admit it -- I really don't like Sun, Solaris, Java or the people
involved."

I too have generally got a bad vibe from Sun over Java and the CDDL. However, after hearing Simon Phipps here at Debconf talking about where they are going, where they have come from and why the licenses are the way they are, I have to say I am a lot more inclined to give them some slack than before. There are sun Java developers at Debconf, and Danese Cooper who wrote the CDDL. All of them appear to have an excellent understanding of the problems the Free Software community has with Sun and its licenses, and are doing a good job of explaining to the rest of the huge organisation how they need to change if they want us to stop being rude about them. But that is a really slow process for a multitude of reasons.

Now 3 good people in a 38,000 employee organisation does not guarantee anything, but it is clear to me that significant people are pushing in the right direction and Sun really is trying to be a proper friend of free software. The CDDL has been tweaked to make opensolaris free-er and more Debian-compatible - further tweakage is likely. The new Java licence is a (rather late) step in the right direction, and at least parts of Sun really do want to make it properly free (and realise that ultimately they have to if they don't want to become irrelevant). I think those people would benefit from our support (as well as constructive criticism).

So, Sun haters - there is genuine good will here; lets try to cultivate it.

Study capabilities, not intent

Posted May 18, 2006 1:58 UTC (Thu) by ttfkam (guest, #29791) [Link]

Because that worked so well for SCO in stopping Linux?

clarification needed...

Posted May 17, 2006 18:50 UTC (Wed) by b7j0c (guest, #27559) [Link] (1 responses)

my understanding is that these changes make it easier for distributions to package the sun jre/jdk, but do not in fact signal a true FOSS release of the code. is this accurate?

Second to last Sentence

Posted May 17, 2006 19:42 UTC (Wed) by GreyWizard (guest, #1026) [Link]

"For all the hints made at JavaOne regarding the eventual open-sourcing of Java, this code remains resolutely non-free at this time."

So how can Debian use this?

Posted May 17, 2006 19:17 UTC (Wed) by JoeBuck (guest, #2330) [Link] (4 responses)

Debian officially maintains that non-free is "not part of Debian". If the license only allows distributors to include their Java as a bundled component with the OS, then doesn't that rule out putting it in the separate non-free archive? After all, the article above says that the license doesn't bless inclusion in third-party archives (livna.org and such).

Or is there something I'm missing? Or are some Debian folks trying to have it both ways -- non-free is part of Debian so we can have Java. non-free is not part of Debian so we don't violate the DFSG.

So how can Debian use this?

Posted May 17, 2006 22:49 UTC (Wed) by xtifr (guest, #143) [Link] (1 responses)

You may be right, but I think it's up to Sun to complain. The non-free repository does have a somewhat ambiguous relationship to Debian. Sun says they want it to be part of OSes, and the non-free repository is as close as Debian will allow it to being part of Debian. If that turns out to be insufficient, I'm sure Debian will be perfectly happy to remove it again.

Debian is also not going to remove the truly free java clones like gjc and kaffe from their main archive, so, again, that's a place where there may be issues, but if Sun complains, I'm sure Debian will be happy to toss their precious "real java" back in trash bin.

Like you, I'm a little surprised that Debian jumped on this so quickly, but I would tend to suspect that they're just testing the waters.

So how can Debian use this?

Posted May 18, 2006 6:02 UTC (Thu) by xtifr (guest, #143) [Link]

Quick followup to my earlier comment. The announcement sent to the Debian Developers Announcement List says, "During the past weeks there has been close collaboration between Sun engineers and Debian and Ubuntu developers." Which definitely implies (or at least suggests) that Sun is both aware of and amenable to Debian's actions in this, and is thus unlikely to complain.

http://lists.debian.org/debian-devel-announce/2006/05/msg...

As for Debian's side, well, in my experience, they tend to be very strict about what goes in main, and very liberal about what goes in non-free, so I'm not really surprised by all this. And if there are still unresolved issues (and I agree that it seems like there might be), I'm sure the people who love to debate license terms on the Debian lists will be discussing them soon enough.

So how can Debian use this?

Posted May 18, 2006 14:44 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

FWIW, some Debian folks are wondering about this question themselves; here is the beginning of the thread which discusses these clauses.

Sun's response on debian-legal

Posted May 20, 2006 23:30 UTC (Sat) by stevenj (guest, #421) [Link]

Tom Marble from Sun has responded on debian-legal. The new thread begins here:

Sun responds to questions on the DLJ

(Personally, I wish they would fix the license instead of continually referring to a FAQ that explicitly states it is not legally binding. However, at least a public dialogue has begun.)

Already in Ubuntu's Multiverse

Posted May 17, 2006 19:20 UTC (Wed) by Burgundavia (guest, #25172) [Link] (4 responses)

Sun Java has already been uploaded to Ubuntu's Multiverse (unsupported, non-free software)
https://lists.ubuntu.com/archives/dapper-changes/2006-May...

Corey

Already in Ubuntu's Multiverse

Posted May 17, 2006 20:22 UTC (Wed) by allesfresser (guest, #216) [Link] (3 responses)

For powerpc too?

(probably not, but hope springs eternal...)

Already in Ubuntu's Multiverse

Posted May 17, 2006 21:01 UTC (Wed) by kmccarty (subscriber, #12085) [Link] (2 responses)

Not if the Java .debs in Ubuntu come from the same source as those in Debian - the packages are only for AMD64 and x86. (There is also a package for Itanium but it depends on that processor's x86 emulation capability.)

Since there is also a package of source code available, it's conceivable someone might compile it for other architectures, but I'm not sure that Debian or Ubuntu would be allowed to distribute the result.

Already in Ubuntu's Multiverse

Posted May 18, 2006 22:21 UTC (Thu) by allesfresser (guest, #216) [Link] (1 responses)

Unfortunately that aforementioned package of source code is somewhat less than portable:

~ $ tar zxf sun-java5_1.5.0-06.orig.tar.gz
sun-java5-1.5.0-06/
sun-java5-1.5.0-06/jdk-1_5_0_06-distro-linux-amd64.bin
sun-java5-1.5.0-06/jdk-1_5_0_06-distro-linux-i586.bin

Already in Ubuntu's Multiverse

Posted May 19, 2006 2:15 UTC (Fri) by kmccarty (subscriber, #12085) [Link]

The source code isn't in the "source package" (orig.tar.gz + diff.gz), it's in the "binary package" (.deb) called sun-java5-source, confusingly enough.

Java becomes more distributable

Posted May 17, 2006 20:29 UTC (Wed) by kfiles (subscriber, #11628) [Link] (1 responses)

This would absolutely seem to exclude the combination of Sun JDK and Eclipse (and also Tomcat), as eclipse includes its own compiler and runtime, eclipse-jdt, also used by Tomcat to compile JSPs.

Obviously, it's intended to exclude things like gcj and classpath specifically, despite their great usefulness in creating native apps out of Java bytecode, a feature not offered by Sun.

Thanks,
--kirby

Excluding GNU Classpath innovation?

Posted May 18, 2006 6:47 UTC (Thu) by mjw (subscriber, #16740) [Link]

Obviously, it's intended to exclude things like gcj and classpath specifically, despite their great usefulness in creating native apps out of Java bytecode, a feature not offered by Sun.

Next they will try to exclude Mono, because guess what? Mono includes GNU Classpath! Through IKVM it has a very interesting bridge between the C# and java programming languages. Reading the blog of Jeroen Frijters (or any of the blogs from Planet Classpath) is a facinating. GNU Classpath has become a catalyst for useful (and of course less useful) experiments and innovation that nobody can stop or exclude anymore (imho).

Java becomes more distributable

Posted May 17, 2006 23:53 UTC (Wed) by piman (guest, #8957) [Link] (3 responses)

> c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software

So, uh, how can distributions still distribute this? Or does shipping Kaffe and GCJ and Classpath alongside this not count as distributing "to run in conjunction with"? It doesn't seem any better than the old license...

Java becomes more distributable

Posted May 18, 2006 1:56 UTC (Thu) by ttfkam (guest, #29791) [Link] (2 responses)

I doubt GNU Classpath or gcj are the targets of this. Methinks this clause is there to prevent Microsoft from tweaking the VM again. Note: I said "again."

When someone has actively tried to screw you in the past, isn't it prudent to take steps to avoid getting screwed in the same way next time?

I mean c'mon! Let's be honest. How often has Sun tried to mess with gcj development in the past? You think they don't know about it by now? When has Sun ever tried to attack the Kaffe project, who have been banging out code for the last ten years?

Why on Earth would they start now when it would only foster ill will?

(Disclaimer: I am not now nor ever have been a Sun employee, but I do code in Java on occasion.)

Java becomes more distributable

Posted May 18, 2006 6:25 UTC (Thu) by piman (guest, #8957) [Link]

> I doubt GNU Classpath or gcj are the targets of this.

Whether or not they're the "targets", they're definitely affected. In fact, I see no way this clause harms MS, who have their (successful) Java competitor. It only harms free software -- probably because Sun sees GCJ, Kaffe, and Classpath as dangerous to their Java hegemony (and they see it that way because they are).

> How often has Sun tried to mess with gcj development in the past?

Have you ever read the old Java license? I'd assume so initially since you said you used Java, but I guess not, or you'd know about all the clauses in it that prevented free Java developers from going within ten feet of it.

Java becomes more distributable

Posted May 18, 2006 6:55 UTC (Thu) by job (guest, #670) [Link]

I don't understand. How can you accept a license on the basis of "c'mon, you don't actually have to adhere to it"?

And how can this be acceptable to Ubuntu? Will they stop distributing classpath and friends or will they break the license until Sun says something? If that is the case, why was the license a problem before?

Java becomes more distributable

Posted May 18, 2006 6:43 UTC (Thu) by wookey (guest, #5501) [Link] (1 responses)

The licence allows Sun Java distribution for desktop and server systems, which would appear to preclude it being shipped with embedded Systems of any type. I don't really see why the box being smaller means we can't have the JRE too.

Java becomes more distributable

Posted May 19, 2006 5:51 UTC (Fri) by ch (guest, #4097) [Link]

because sun wants money for that.

Java becomes more distributable

Posted May 18, 2006 9:40 UTC (Thu) by scrosland (guest, #4426) [Link] (2 responses)

Simon Phipps has some interesting points and reponses to comments here: http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu...

In particular, this is clarifies co-existence with other Java implementations:

"it's OK to distribute along with GCJ, GNU/Classpath and so on - that was one of the explicit intents of the new license as that was previously the chief obstacle to distribution with GNU/Linux.

That clause of DLJ simply means you can't take the Sun package apart and use elements of it to complete or modify another package - so, for example, it would be a breach of the license to take the Swing classes from the Sun JDK and add them to GNU/Classpath. Just shipping the two systems alongside each other is explicitly OK."

"clarifications" on the side are worthless; the license is unusable

Posted May 18, 2006 16:31 UTC (Thu) by stevenj (guest, #421) [Link]

That's nice, but if that was their intent they should have said so in the license, rather than leaving it vague and open to later reinterpretation.

The goal of a license should be to give users and developers confidence and clear knowledge of what they can and cannot do. As it stands, the text of the license is so broad and vague in forbidding software with the "same or similar functionality or APIs" from running "in conjunction with" Sun's code, that it seems basically unusable.

I mean, "similar functionality?" That could include everything from Tcl/Tk to Mono. (Notice that it says "functionality or APIs" so it's not limited to things like classpath.)

Java becomes more distributable

Posted May 18, 2006 18:01 UTC (Thu) by piman (guest, #8957) [Link]

If you're forced to build a wall between "real Java" and "free Java" when you distribute them, it's not much use. You'd have to ship two copies of every free Java library, you wouldn't be able to name both of them "/usr/bin/java" via an alternatives system, etc. So even if you can come up with a way to distribute them together, the license forces you to cripple one of them.

Free but shackled - the java trap

Posted May 18, 2006 13:57 UTC (Thu) by coriordan (guest, #7544) [Link] (1 responses)

Widening the mouth of the Java trap?

This is probably partly in response to the great progress being made by GNU classpath.

speaking of classpath

Posted May 18, 2006 14:10 UTC (Thu) by coriordan (guest, #7544) [Link]

And just yesterday was the release of GNU Classpath 0.91. The release announcement mail is quite detailed.

Java becomes more distributable

Posted May 20, 2006 9:13 UTC (Sat) by tzafrir (subscriber, #11501) [Link]

Speaking of a java-source package: where does Blackdown Java fit in this? Has it become a bit more distributable as well?

(No sign for that)

Java license becomes more inscrutable

Posted May 21, 2006 5:22 UTC (Sun) by grouch (guest, #27289) [Link] (1 responses)

I finally read the license and removed Sun Java. Their license is becoming as schizoid as their public commentary.

Java license becomes more inscrutable

Posted May 21, 2006 16:35 UTC (Sun) by piman (guest, #8957) [Link]

The license is not substantially different than their old one, so I don't know why this prompted your change. It's just shorter.