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. 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. 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, with some set of requirements for claiming that a particular installed configuration will run programs certified to run on Sun Java. That way, if someone has a piece of software certified to run on Sun Java, they won't get surprised, because either 1) an installation meets the requirements to get called Sun Java, and their software runs on it, or 2) an installation doesn't meet the requirements to get called Sun Java, and they thus have no grounds to complain to Sun or anyone else if their software doesn't run. The same kind of trademark license could eliminate the issues related to the "you must fix your OS so Sun Java works" clause. You could make such a requirement if a distributor wanted to claim they support applications certified to run on Sun Java, and thus distributors that don't care to make such a guarantee don't need to guarantee bugfixes/workarounds/hacks for Sun Java compatibility. One other request: if you go this route, please keep packagers and packaging systems in mind. Naming clauses that have requirements like "must not contain Sun or Java in their name", or that in any way affect the naming of files or packages, would pose a burden on packagers like Debian. On the other hand, requirements on what a distributor must do to make a claim that their OS "runs programs certified for Sun Java" poses no burden on Debian, since Debian could simply avoid making such a claim. Or, to make such a claim, Debian could make a package which set the appropriate conflicts, alternative priorities, and similar, to ensure that JAVA_HOME=/path/to/sun/java/ gave a compliant implementation. A properly worded trademark clause along these lines, in conjunction with a Free Software license, could make Sun Java suitable for main while continuing to meet Sun's goal of ensuring compatibility. >>> + SECTION 2(d) >>> >>> A bug was fixed in debconf 1.5.1 so that a user with the Gnome >>> (GUI) front end could Cancel the installation. Otherwise the >>> package has been configured that if the debconf key for accepting >>> the DLJ has not been pre-accepted that the installation will be >>> canceled if the license cannot be presented. This is an excellent >>> example of leveraging Debian infrastructure to comply with these >>> DLJ terms. >> The point here was that it's possible in Debian to preseed the key >> that the package checks to see if it's presented the license or not so >> that the package never actually presents the license. This is >> extreemly trivial to do. > > Yes, and this is a feature, not a bug. One of the reasons that > Debian is great is the ability to do fully automated installs > and such. The point of presenting the license is that an individual, > corporation, non-profit or other entity has had a chance to review > and agree to the DLJ. If a user or administrator pre-seeds the > key for DLJ acceptance on behalf of herself or her group then > it is perfectly acceptable to install Sun Java on 1 or 10,000 nodes. Glad to hear this; I think that resolves the issues raised about this particular clause, assuming the above clarification goes into the license or otherwise becomes binding. >>> And, as I am sure you know, Rich Green has announced a very >>> interesting Open Source future for Java. Simon, I (and many others) >>> are going to work very hard on that internally so that soon you will >>> be able consider Java for "main". >> For that, I applaud you; let me know if there is anything that I can >> do to help speed that process (which is infinetly more interesting to >> me than dealing with EULAs) along. Fully seconded; I would gladly help with this as well. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature