On Fri, 19 May 2006, Tom Marble wrote: > Let me start by repeating the message that Simon and I gave to you > at Debconf: there is every reason for us to be friends and working > with you is very important for Sun. Thanks for comming to Debconf; the discussions were interesting even if there were disagreements at times. > Please consider: > > - We consider the FAQ [2] to be an accurate representation of the > intent of this license [1] and do not consider it to be > irrelevant. Is the FAQ legally binding on Sun? > - Ignoring the FAQ is not helpful as it answers many of their > questions (it's a FAQ, after all). The reason why I have ignored the FAQ is because the language in the FAQ and within the license explicitly claims that the FAQ is not legally binding and is meaningless. If, by this, you're telling us that it is binding on Sun, then I will cease ignoring it in future analyses of the license I make. > - The design of the license which refers to the README is like > pointer to an object: the technical details in the README can > change without having to revise the license. We are planning to > revise the README to further clarify and give explicit permission > to relocate or even modify certain files (e.g. font.properties) > needed to make the system run properly. It would be nice if the license would change section 14 to make this part explicit so it's obvious that the README has some legal ramifications upon 2a. > Let me try to clarify the following: > > + SECTION 2(a) > > Special care was taken in crafting the debian copyright file to > adequately implement the direction given by: > > http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html > http://www.us.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile > > Indeed I wrote a script (albeit an ugly hack) to craft the > conforming debian/copyright file from a package preamble, the > copyright notice for Debian packaging, the license for Debian > packaging, the copyright notice for upstream, the license for > upstream and any third party notices and licenses. I guess I'm a bit lost here as to what this clarifies for the issues I've identified in 2a. > + 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? > + 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. > Put together I am very pleased by the result: the level of > integration and quality of feedback has surpassed anyone's > expectations and highlighted that the step to loosen control and > liberalize the license for Java will reap huge benefits from > community involvement. > > 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. As a final note, I just wish that these issues with the DLJ were resolved before the license was presented a fait a compli; those of us who participate in debian-legal are here to make sure that all decisions that are taken in regards to works that are present in Debian are taken with a full accounting of all of the problems present in the licenses. We are not easy to satisfy, but because many people trust Debian to be very careful with what it distributes, it's a task that we and the ftpmasters who make the final decisions do not take lightly. In the future if there's a desire to keep some strategic move under wraps, it's always possible to bring a group of people who are active here into confidence to resolve issues with the license so that what should have been a PR coup for Sun doesn't cause such a problem in the community that Sun wants to be a part of. Don Armstrong -- Those who begin coercive elimination of dissent soon find themselves exterminating dissenters. Compulsory unification of opinion achieves only the unanimity of the graveyard. -- Justice Roberts in 319 U.S. 624 (1943) http://www.donarmstrong.com http://rzlab.ucr.edu
Attachment:
signature.asc
Description: Digital signature