Java becomes more distributable
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:
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:
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:
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
"
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.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.
Posted May 17, 2006 17:55 UTC (Wed)
by cventers (guest, #31465)
[Link] (14 responses)
I'm curious what is meant to be implied (if anything) by this remark. Has
Furthermore, what would Sun (the theoretical big evil Sun that would do
I think in a practical sense, unless I'm misreading this remark, Linux
Posted May 17, 2006 17:58 UTC (Wed)
by corbet (editor, #1)
[Link] (4 responses)
Posted May 17, 2006 19:05 UTC (Wed)
by cventers (guest, #31465)
[Link] (3 responses)
So perhaps the worry is that we'll all start shipping Sun Java, drop our
Posted May 18, 2006 7:24 UTC (Thu)
by pimlott (guest, #1535)
[Link] (2 responses)
Posted May 18, 2006 16:49 UTC (Thu)
by jonabbey (guest, #2736)
[Link] (1 responses)
Remember Java on Macintosh OS 9? ;-)
Posted May 18, 2006 16:58 UTC (Thu)
by pimlott (guest, #1535)
[Link]
Posted May 17, 2006 19:08 UTC (Wed)
by felixfix (subscriber, #242)
[Link] (8 responses)
Posted May 17, 2006 20:00 UTC (Wed)
by cventers (guest, #31465)
[Link] (6 responses)
Scenario:
1. Sun says "Ooh, hey, Red Hat... you're not compatible because your
OK, I'll admit it -- I really don't like Sun, Solaris, Java or the people
Am I missing something? Is the compatibility clause a real cannon in the
Posted May 17, 2006 21:09 UTC (Wed)
by emkey (guest, #144)
[Link] (4 responses)
Posted May 17, 2006 23:54 UTC (Wed)
by piman (guest, #8957)
[Link] (3 responses)
Posted May 18, 2006 0:45 UTC (Thu)
by emkey (guest, #144)
[Link] (2 responses)
Posted May 18, 2006 1:02 UTC (Thu)
by cventers (guest, #31465)
[Link] (1 responses)
The distributions would always have options in a crunch - hell, you could
So maybe the distributions carry their own aftermarket Java patches until
Posted May 18, 2006 1:37 UTC (Thu)
by miah (guest, #639)
[Link]
A quick google turns up the following Press Release: http://www.redhat.com/about/presscenter/2004/press_apps_s...
Posted May 18, 2006 6:36 UTC (Thu)
by wookey (guest, #5501)
[Link]
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.
Posted May 18, 2006 1:58 UTC (Thu)
by ttfkam (guest, #29791)
[Link]
Posted May 17, 2006 18:50 UTC (Wed)
by b7j0c (guest, #27559)
[Link] (1 responses)
Posted May 17, 2006 19:42 UTC (Wed)
by GreyWizard (guest, #1026)
[Link]
Posted May 17, 2006 19:17 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link] (4 responses)
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.
Posted May 17, 2006 22:49 UTC (Wed)
by xtifr (guest, #143)
[Link] (1 responses)
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.
Posted May 18, 2006 6:02 UTC (Thu)
by xtifr (guest, #143)
[Link]
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.
Posted May 18, 2006 14:44 UTC (Thu)
by corbet (editor, #1)
[Link] (1 responses)
Posted May 20, 2006 23:30 UTC (Sat)
by stevenj (guest, #421)
[Link]
(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.)
Posted May 17, 2006 19:20 UTC (Wed)
by Burgundavia (guest, #25172)
[Link] (4 responses)
Corey
Posted May 17, 2006 20:22 UTC (Wed)
by allesfresser (guest, #216)
[Link] (3 responses)
(probably not, but hope springs eternal...)
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.
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:
Posted May 19, 2006 2:15 UTC (Fri)
by kmccarty (subscriber, #12085)
[Link]
Posted May 17, 2006 20:29 UTC (Wed)
by kfiles (guest, #11628)
[Link] (1 responses)
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,
Posted May 18, 2006 6:47 UTC (Thu)
by mjw (subscriber, #16740)
[Link]
Posted May 17, 2006 23:53 UTC (Wed)
by piman (guest, #8957)
[Link] (3 responses)
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...
Posted May 18, 2006 1:56 UTC (Thu)
by ttfkam (guest, #29791)
[Link] (2 responses)
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.)
Posted May 18, 2006 6:25 UTC (Thu)
by piman (guest, #8957)
[Link]
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.
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?
Posted May 18, 2006 6:43 UTC (Thu)
by wookey (guest, #5501)
[Link] (1 responses)
Posted May 19, 2006 5:51 UTC (Fri)
by ch (guest, #4097)
[Link]
Posted May 18, 2006 9:40 UTC (Thu)
by scrosland (guest, #4426)
[Link] (2 responses)
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."
Posted May 18, 2006 16:31 UTC (Thu)
by stevenj (guest, #421)
[Link]
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.)
Posted May 18, 2006 18:01 UTC (Thu)
by piman (guest, #8957)
[Link]
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.
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.
Posted May 20, 2006 9:13 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link]
(No sign for that)
Posted May 21, 2006 5:22 UTC (Sun)
by grouch (guest, #27289)
[Link] (1 responses)
Posted May 21, 2006 16:35 UTC (Sun)
by piman (guest, #8957)
[Link]
> It is unlikely - but not inconceivable - that such a term could be used"System call semantics?"
> to pressure a distributor to change Linux system call semantics which
> could be deemed to cause incompatibilities.
Sun engaged in such behavior before? Is there any real worry that they
might?
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?
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.
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?"
Well, I guess my curiosity is basically this - what would be the value of "System call semantics?"
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]...)
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?"
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.
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."System call semantics?"
"System call semantics?"
Remember Java on Macintosh OS 9? ;-)
checkmate, you win
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
Oh, absolutely -- I agree. But in this case, the licensing agreement Study capabilities, not intent
seems to require nothing more that the distributor in question stop
shipping Java.
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
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).
weeds, or are we just nodding at eachother, expressing mutual distrust of
Sun Microsystems and their motives?
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
So would changing kernel system call semantics.Study capabilities, not intent
Exactly, rock meet hard place.Study capabilities, not intent
While I don't think Java is anything close to irrelevant in the market, Study capabilities, not intent
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.
even do something crazy and temporarily hack the kernel to behave as Sun
defines compatibility, and even just for the Java process itself.
they can migrate.
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.Study capabilities, not intent
"OK, I'll admit it -- I really don't like Sun, Solaris, Java or the peopleStudy capabilities, not intent
involved."
Because that worked so well for SCO in stopping Linux?Study capabilities, not intent
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?clarification needed...
"For all the hints made at JavaOne regarding the eventual open-sourcing of Java, this code remains resolutely non-free at this time."Second to last Sentence
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).
So how can Debian use this?
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.So how can Debian use this?
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.So how can Debian use this?
FWIW, some Debian folks are wondering about this question themselves; here is the beginning of the thread which discusses these clauses.
So how can Debian use this?
Tom Marble from Sun has responded on debian-legal. The new thread begins here:
Sun's response on debian-legal
Sun Java has already been uploaded to Ubuntu's Multiverse (unsupported, non-free software)Already in Ubuntu's Multiverse
https://lists.ubuntu.com/archives/dapper-changes/2006-May...
For powerpc too?Already in Ubuntu's Multiverse
Already in Ubuntu's Multiverse
Already in Ubuntu's Multiverse
~ $ 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
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
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.Java becomes more distributable
--kirby
Excluding GNU Classpath innovation?
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).
> 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 SoftwareJava becomes more distributable
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."Java becomes more distributable
> I doubt GNU Classpath or gcj are the targets of this.Java becomes more distributable
Java becomes more distributable
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
because sun wants money for that.Java becomes more distributable
Simon Phipps has some interesting points and reponses to comments here: http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu...Java becomes more distributable
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.
"clarifications" on the side are worthless; the license is unusable
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.Java becomes more distributable
Free but shackled - the java trap
speaking of classpath
Speaking of a java-source package: where does Blackdown Java fit in this? Has it become a bit more distributable as well?Java becomes more distributable
I finally read the license and removed Sun Java. Their license is becoming as schizoid as their public commentary.
Java license becomes more inscrutable
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