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

Re: Sun responds to questions on the DLJ

Don Armstrong wrote:
> On Fri, 19 May 2006, Tom Marble wrote:
> Thanks for comming to Debconf; the discussions were interesting even
> if there were disagreements at times.

It was really great to be there... I enjoyed meeting you and many
other Debian Developers.  Perhaps the biggest thing for me to grok
was that Debian isn't as much a "technical organization" as a
"social organization" that happens to produce very interesting
technical works.

>> - 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. [...]
> 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.

It is my understanding that, due to the wording, the README actually
has legal weight.

>> 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:
>> [...]
> I guess I'm a bit lost here as to what this clarifies for the issues
> I've identified in 2a.

There was a comment, "This seems to cause a problem with actually
packaging the software unless the Debian package counts as the Software"
and as Joerg gave specific recommendations on how to unambiguously
specify which parts of the copyright refer to which parts of the bundle
it was appropriate to leverage this convention to be completely explicit.

>> + 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' "

>> + 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.

> We're currently splitting the package into pieces; and presumably the
> software is unpacked or otherwise modified from the form that Sun has
> actually distributed to us. I don't know whether Sun has approved this
> or not, but if they haven't, this seems to pose a problem.

The JRE and JDK each have been split into different Debian
packages to best fit with Debian Policy.  Partly this work is
an innovative approach to reduce redundancy (e.g. have the JDK depend
on the JRE), partly to refactor architecture independent and dependent
components and partly to better integrate with Debian (e.g include the
-font package giving defoma integration *only* if that font is not already
on the system and managed by defoma).  The numerous symlinks are intended
to give backwards compatibility with the JAVA_HOME (one directory
tree) approach that many users are used to (and certain executables
depend upon for compatibility).

>> 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.

I am certain that we will need input here... your offer is appreciated.

I recently started reading Benker's book based on the advice
of Lessig [1] (whom I hold in high esteem).  It's a captivating
read [2]:

  If the transformation I describe as possible occurs, it will lead to
  substantial redistribution of power and money from the
  twentieth-century industrial producers of information, culture, and
  communications like Hollywood, the recording industry, and perhaps the
  broadcasters and some of the telecommunications services giants to a
  combination of widely diffuse populations around the globe, and the
  market actors that will build the tools that make this population
  better able to produce its own information environment rather than
  buying it ready-made.

Sun needs to understand the role of "nonmarket" forces because:

  To be able to understand these choices, to be able to make them well,
  we must recognize that they are part of what is fundamentally a social
  and political choice -- a choice about how to be free, equal,
  productive human beings under a new set of technological and economic



[1] http://www.lessig.org/blog/archives/003368.shtml

[2] http://www.benkler.org/wealth_of_networks/index.php/Main_Page

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: