Re: Distributor License for Java: External Commentary
On Tue, May 23, 2006 at 03:15:32PM +1200, Adam Warner wrote:
> Hi all,
>
> Commentary by Dalibor Topic: "The license is, frankly, still pretty bad,
> and contains various nasty clauses: from the overly broad
> indemnification(i) part, which has nothing to do with Sun's JDK
> software, to the subsettig restrictions not being limited to Sun's
> software. That's from a cursory glance, I think you'll get to see more
> comments once people take it apart, and the JavaOne buzz is gone...."
Thanks for bringing my comments up, I guess. :)
I believe there are some provisions where the FAQ and the license text talk
about a different scope of right/obligations. One of them is
indemnification, where the obligations under 2.f.i seem to go too far
(any use of the os, or any part, which is a wider net than Sun's
code alone). As far as I can see, Sun could do a better job at
making the license clearly say what the FAQ says that it should say. :)
As for the subsetting restrictions, those things have really fascinating
side effects. I've talked with tmarble about one weird corner case
after the announcement, and I hoped it would not occur in practice. Since
it seems that it is about to occur in a package (JacORB apparently requires
overriding bootclasspath according to a recent mail to debian-java),
I guess I can explain it here:
One of the ideas behind Sun's restrictions on
subsetting/supersetting/messing around with their classes is that they
certify a specific binary as a whole. Now, funny enough, Sun's JVM, and
most other runtimes, provide a convenient way to mess around with the
classes anyway, using the -Xbootclasspath* options at runtime to replace core
classes by other implementations. That used to be the 'standard' way to
deal with bugs in Sun's XML implementation, for example, until Sun
introduced the official extension mechanism.
Of course, messing around in one's own privacy is a different thing from
deploying applications in public that replace chunks of Sun's implementation
before they run. So the manual page for the java binary contains a note
saying "Note: Applications that use this option for the purpose of
overriding a class in rt.jar should not be deployed as doing so would
contravene the Java 2 Runtime Environment binary code license.". See
http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html for a
reference.
This is where the fun begins. What is the effect of contravening the
DLJ? Judging by the section on termination, automatical
termination without notice would be the worst case, but I doubt that's
in the interest of the respective parties.
More seriously:
What would the effect of Debian distributing a JacORB package,
which replaces parts of the bootclasspath, potentially configured
to run with Sun's JVM, be on Debian's license to redistribute
Sun's JVM?
Less seriously:
Should a developer packaging free software have to care about
the restrictions of some piece of non-free software he may be
potentially violating? :)
Since Sun has announced their desire to open up their last bastion of
proprietary software at JavaOne, though, I don't think the DLJ matters
much, seen over the next years. I don't particularly care if Sun's
implementation ends up in non-free, or doesn't for the next two years,
as long as it joins Kaffe & gcj & IKVM & cacao & jamvm & ... in main
eventually.
cheers,
dalibor topic
Reply to: