Tom Marble wrote: > Josh Triplett wrote: >> Tom Marble wrote: >>> Don Armstrong wrote: >>>> On Fri, 19 May 2006, Tom Marble wrote: >>>>> + SECTION 2(c) >>>>> >>>>> There have been a series of speculations about this, despite the >>>>> clarifications of FAQ #8. The term "alternate technologies" refers >>>>> to projects such as kaffe, gcj, classpath, harmony and the like. >>>>> We want Debian users that include "non-free" to be able to have a >>>>> choice which includes Sun Java. We don't want to put wacky >>>>> restrictions on every programming language. >>>> Right, but from what I can tell the 2a does this as well... what >>>> additional restrictions does Sun gain by adding 2c in addition to 2a? >>> 2c is the please "don't mix and match with 'alternate technologies' " >>> provision. >> Right. So, what precisely does this intend to ban? The clause reads: >>> (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; >> Since the Sun Java packages use the alternatives system (which they >> clearly should do), we could reasonably consider any Java software >> shipped by Debian as configured to run in conjunction with Sun Java. >> Thus, this clause prevents Debian from shipping any Java software which >> "implements the same or similar functionality or APIs as" Sun Java. For >> example, this could prevent Debian from shipping SWT, which provides >> similar functionality to Swing, or even more clearly SwingWT, which >> provides the Swing API on top of SWT. > > From FAQ #8, "there is nothing in the DLJ intended to prevent you from > shipping alternative technologies with your OS distribution." > When I say mix and match I mean please don't take bits from the > alternate technologies (see above) and put them into use with > the Java platform (e.g. replace rt.jar which is part of the platform > with an alternate rt.jar). In a similar way please don't take > bits from the Java platform and use them as part of or to complete > alternate technologies (e.g. plugin.jar). That much, as stated, sounds reasonable. However, it doesn't seem clear from the clause in question. Also, what does this mean for packages like jikes-sun <http://packages.debian.org/jikes-sun>, which uses the Jikes compiler with the Sun Java library, by depending on Sun Java and setting Jikes' classpath to include it? This doesn't copy or move any files from the Sun Java package, and it doesn't replace any bits in the Sun Java package; it just points a variable to a file in the Sun Java distribution. And does this prevent a package from (for example) build-depending on sun-java and jikes and invoking jikes with the appropriate arguments to do the same thing? Or, in general, from build-depending or depending on sun-java and $OTHER_JAVA_IMPLEMENTATION, and invoking pieces of both to build or run? > So you can distribute alternate technologies or SWT on your OS > and still ship Sun Java. If this is still unclear please let me know. So, to clarify, no package that Debian could ship in main or contrib (assuming it didn't dpkg-divert anything from the Sun Java package) could by itself suddenly put Debian in violation of this clause, even though Sun Java ships using Debian's normal mechanisms which allow it to work with any random Java stuff a user installs? Only modifications to the Sun Java packaging (which mixed-and-matched pieces with other implementations) could violate the license? If so, that seems fine, but not obvious from the license clause. >> Furthermore, the alternatives system allows a user to choose between >> programs based on priority, on a program-by-program basis. Suppose we >> shipped packages in main with alternative priorities set such that if a >> user installed certain of those packages along with Sun Java, they'd end >> up with parts of the JDK pointing to Sun Java and others pointing to >> software in main. For example, with "java" pointing to Sun's Java but >> "javadoc" pointing to gjdoc, and gjdoc in turn running with whatever >> java pointed to, namely Sun Java. Since Sun Java also ships a javadoc >> implementation, that sounds very clearly like configuration or >> distribution to run in conjunction with additional software that >> implements the same functionality. > > Yes this is a potential problem that was raised this week. AFAIK > a fix is in progress with a complete set of "noop" alternatives so > the update-java-alternatives script (in java-common) will not accidentally > mix Java with alternate technologies. That doesn't sound sufficient. Imagine the following case: * I write a package "foodoc" which implements javadoc. * My package uses update-alternatives to install an alternative for just the javadoc binary. * A user does "apt-get install sun-java foodoc" * sun-java gets unpacked and configured first, and sets all the alternatives (java, javac, javadoc, ...) to point to its implementations. * foodoc gets unpacked and configured next, and sets the javadoc alternative to point to foodoc. * The resulting system has /usr/bin/java and /usr/bin/javac pointing to sun-java's implementations, and /usr/bin/javadoc pointing to foodoc, which seems to violate the license. Does this in fact violate the license? If so, how, changing only sun-java and *not* changing foodoc, could you resolve this situation? >> I can understand why Sun currently wants a clause like this: they want >> to know that when a user gets "Sun Java", they don't have any non-Sun >> implementations of portions of Java that Sun wants to guarantee the >> functionality of, for the benefit of software certified in some way to >> run on Sun Java. However, that sounds like an issue better solved by a >> trademark license, [...] > > That might be an approach in the Java platform's libre future. You have > captured the essence of the goal of compatibility as expressed in the DLJ. Glad to hear that. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature