LWN: Comments on "Java becomes more distributable"

Java license becomes more inscrutable

piman — Sun, 21 May 2006 16:35:41 +0000

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

Java license becomes more inscrutable

grouch — Sun, 21 May 2006 05:22:16 +0000

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

Sun's response on debian-legal

stevenj — Sat, 20 May 2006 23:30:48 +0000

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.)

Java becomes more distributable

tzafrir — Sat, 20 May 2006 09:13:27 +0000

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 becomes more distributable

ch — Fri, 19 May 2006 05:51:56 +0000

because sun wants money for that.

Already in Ubuntu's Multiverse

kmccarty — Fri, 19 May 2006 02:15:05 +0000

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.

Already in Ubuntu's Multiverse

allesfresser — Thu, 18 May 2006 22:21:53 +0000

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

Java becomes more distributable

piman — Thu, 18 May 2006 18:01:56 +0000

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.

"System call semantics?"

pimlott — Thu, 18 May 2006 16:58:22 +0000

Remember Java on Macintosh OS 9? ;-)

checkmate, you win

"System call semantics?"

jonabbey — Thu, 18 May 2006 16:49:56 +0000

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? ;-)

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

stevenj — Thu, 18 May 2006 16:31:48 +0000

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.)

So how can Debian use this?

corbet — Thu, 18 May 2006 14:44:57 +0000

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

speaking of classpath

coriordan — Thu, 18 May 2006 14:10:41 +0000

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

Free but shackled - the java trap

coriordan — Thu, 18 May 2006 13:57:38 +0000

Widening the mouth of the Java trap?

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

Java becomes more distributable

scrosland — Thu, 18 May 2006 09:40:30 +0000

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."

"System call semantics?"

pimlott — Thu, 18 May 2006 07:24:57 +0000

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.

Java becomes more distributable

job — Thu, 18 May 2006 06:55:48 +0000

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?

Excluding GNU Classpath innovation?

mjw — Thu, 18 May 2006 06:47:22 +0000

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

wookey — Thu, 18 May 2006 06:43:15 +0000

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.

Study capabilities, not intent

wookey — Thu, 18 May 2006 06:36:03 +0000

"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.

Java becomes more distributable

piman — Thu, 18 May 2006 06:25:49 +0000

> 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.

So how can Debian use this?

xtifr — Thu, 18 May 2006 06:02:41 +0000

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.

Study capabilities, not intent

ttfkam — Thu, 18 May 2006 01:58:06 +0000

Because that worked so well for SCO in stopping Linux?

Java becomes more distributable

ttfkam — Thu, 18 May 2006 01:56:36 +0000

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.)

Study capabilities, not intent

miah — Thu, 18 May 2006 01:37:17 +0000

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

cventers — Thu, 18 May 2006 01:02:33 +0000

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

emkey — Thu, 18 May 2006 00:45:42 +0000

Exactly, rock meet hard place.

Study capabilities, not intent

piman — Wed, 17 May 2006 23:54:30 +0000

So would changing kernel system call semantics.

Java becomes more distributable

piman — Wed, 17 May 2006 23:53:24 +0000

> 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...

So how can Debian use this?

xtifr — Wed, 17 May 2006 22:49:02 +0000

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.

Study capabilities, not intent

emkey — Wed, 17 May 2006 21:09:09 +0000

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.

Already in Ubuntu's Multiverse

kmccarty — Wed, 17 May 2006 21:01:45 +0000

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.

Java becomes more distributable

kfiles — Wed, 17 May 2006 20:29:25 +0000

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

Already in Ubuntu's Multiverse

allesfresser — Wed, 17 May 2006 20:22:29 +0000

For powerpc too?

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

Study capabilities, not intent

cventers — Wed, 17 May 2006 20:00:20 +0000

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?

Second to last Sentence

GreyWizard — Wed, 17 May 2006 19:42:51 +0000

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

Already in Ubuntu's Multiverse

Burgundavia — Wed, 17 May 2006 19:20:58 +0000

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

Corey

So how can Debian use this?

JoeBuck — Wed, 17 May 2006 19:17:50 +0000

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.

Study capabilities, not intent

felixfix — Wed, 17 May 2006 19:08:40 +0000

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.

"System call semantics?"

cventers — Wed, 17 May 2006 19:05:59 +0000

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...)