[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sun responds to questions on the DLJ

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

Reply to: