With the DLJ ("Operating System Distributor License for Java version") being announced at JavaOne 2006, one might have thought that Linux and Java would finally get along, but apparently that's not necessarily the case. Some in the Debian community have rejected the DLJ as being "not open enough" and harming Debian. One of the initial messages about this was from Don Armstrong, who started his message with this:

Executive Summary: There are serious issues with clause 2a, 2b, 2c, 2f, and 4; and lesser issues with other bits of this license. As much as some of our users would like to see us distributing this JDK in non-free, I'm really not sure that it can be distributed while complying with the license or without incurring unreasonable burdens upon our mirror operators and Debian. I'd recommend that ftp-masters consider pulling this package from non-free until these issues are resolved (or at least understood.)

There's a FAQ on the DLJ, but Mr. Armstrong says that it's not binding - as article 14 of the DLJ specifies.

[The text of this license] supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement.

In some places, the FAQ directly controverts the statements made in the debian thread, namely:

Section 2(c) prohibits us from using the software in conjunction with C, C++, Perl, Python, or *any reasonable Turing-complete programming language*.

Worse: it seems that it prohibits combining, configuring and *distributing* the Software to run in conjunction with any similar compiler. Hence it seems that the Debian Project is already violating the license, by distributing all the other DKs (such as GCC, Python, Perl, ...)!

However, it seems absurd to think that the license actually requires all this. Are they right? Should Linux distributions continue to avoid the Sun distributions of Java?

it is almost unthinkable that a clause like this would prohibit the distribution of other language's compilers/libraries like Python, C++, et al. To me, this clause is very specific to prohibit the distribution of software that has the "same" functionality. Meaning that if you choose to distribute Sun's JDK, you must not distribute other JDK implementations, like GCJ, Kaffe, IBM's or Harmony. I can think of a couple of reasons why this is a "Good Thing", but the main one would be for Sun to avoid starting getting complains about "Java not working" when they're actually running gcj or some other thing like that. I know I've seen my share of complaints just like that one already.

it is almost unthinkable that a clause like this would prohibit the distribution of other language's compilers/libraries like Python, C++, et al.

To me, this clause is very specific to prohibit the distribution of software that has the "same" functionality. Meaning that if you choose to distribute Sun's JDK, you must not distribute other JDK implementations, like GCJ, Kaffe, IBM's or Harmony.

I can think of a couple of reasons why this is a "Good Thing", but the main one would be for Sun to avoid starting getting complains about "Java not working" when they're actually running gcj or some other thing like that. I know I've seen my share of complaints just like that one already.

Unfortunately prohibiting the distribution of other JDKs would definitely be something which would prevent inclusion in Debian. What you mentioned (getting complaints about other JDK-s) would totally be avoidable by making the JDK uninstallable if another JDK is installed on the system (conflicts with java-virtual-machine pseudo-package). Best regards, Robert

it is almost unthinkable that a clause like this would prohibit the distribution of other language's compilers/libraries like Python, C++, et al.

To me, this clause is very specific to prohibit the distribution of software that has the "same" functionality. Meaning that if you choose to distribute Sun's JDK, you must not distribute other JDK implementations, like GCJ, Kaffe, IBM's or Harmony.

I can think of a couple of reasons why this is a "Good Thing", but the main one would be for Sun to avoid starting getting complains about "Java not working" when they're actually running gcj or some other thing like that. I know I've seen my share of complaints just like that one already.

The thing with legal texts is that they should leave as little room for ambiguity as possible. If the above is not what Sun means, then they should phrase the license such that it cannot possibly be interpreted as such. In a court your opinion does not count. The only thing that counts is the judge's interpretation of the legal text you agreed to. The problem with licenses such as above is that they are deliberately vague on a number of issues. You should mistrust such legally binding contracts where they become vague and in fact assume the worst (i.e. any legal interpretation can and will be used against you). Good lawyers are never vague, except when they intend to be vague. And even if it is unintentional, the vagueness provides ammunition to lawyers in the future. In other words, if the license vagueness was the result of incompetence rather than malicious intent, that does not actually change much in a court. Sun obviously did not spend a lot of time validating if the license actually was good enough for the intended audience. It is now finding out the hard way what it could have found out just communicating drafts of the license with the relevant people from e.g. red hat, novell and debian.

I think this license prohibits only to package the JDK with some other stuff. Eg. you can't package it with your specific extensions and all license statements must be intact. (You might add yours) I think the scope of this document is the Software and not the whole linux distriubution.

2f) reads "(f) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises ..." Come on, are they serious about calling this licence a "Operating System Distributor License"?

2f) reads "(f) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises ..."

Come on, are they serious about calling this licence a "Operating System Distributor License"?

IANAL, but isn't this rendered near inert by the '...distibuted without warranty' clause that is present in GPL, ASLv2, BSD, etc., etc.? The issue is even if they are rendered inert by the actual OS distribution license, Sun Lawyers will still have to add these clauses to the agreements in order to ensure there are no legal ambiguities, that could be exploited I may be wrong, but like I said, IANAL..... --Calum

Sun would have done themselves a favour with a transparent process, rather than presenting most of Debian with a fait-accompli via their deal with Canonical. Predictably, that sorta backfired, as many Debian devs don't exactly have a desire to spend their time dealing with the wacky world of non-free software licensing restrictions. As far as the license goes, Sun could still do a better job of making the FAQ and DLJ license agree on the scope of rights and obligations. Something that's easy to understand and obviously says what Sun apprently means to say, but did not in a legally binding way, would go a long way towards fixing the issues that were pointed out. Kudos to Sun for doing the first step, and good luck with the license fixes.

From the FAQ: 8. Does this license prevent me shipping any alternative technologies in my OS distribution? The DLJ does not restrict you from shipping any other technologies you choose to include in your distribution. However, you can't use pieces of the JDK configured in conjunction with any alternative technologies to create hybrid implementations, or mingle the code from the JDK with non-JDK components of any kind so that they run together. It is of course perfectly OK to ship programs or libraries that use the JDK. Because this question has caused confusion in the past, we want to make this absolutely clear: except for these limitations on combining technologies, there is nothing in the DLJ intended to prevent you from shipping alternative technologies with your OS distribution.

So the way I get it, this is all about restricting people from including competent technologies (lets say SWT) with their JRE?

So the way I get it, this is all about restricting people from including competent technologies (lets say SWT) with their JRE?

As a seperate package you are free to do it, but not in the "JDK" package. Which is understandable.