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

Sun responds to questions on the DLJ


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.

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.

- Ignoring the FAQ is not helpful as it answers many of their
  questions (it's a FAQ, after all).

- The DLJ represents a very significant shift in Sun's approach to
  licensing by trusting that distributors will "do the right thing"
  (so that JDK works AND is integrated with the OS while adhering to
  OS standards and policies).

- We think our intent is pretty clear - if it isn't, we're happy to clarify
  and incorporate those clarifications into updates to the FAQ.

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

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:


  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.

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

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

I am pleased to have worked with some of you on the first
implementation of packaging under the DLJ.  I was hoping just to
get java in the PATH....  I'm very impressed that the result

- Not just PATH integration and man page integration using
  Debian alternatives but indeed a new consensus based solution for
  marshaling several related alternatives (including plugin
  for many browsers) leveraging JPackage conventions.
  This builds on the 1-N features of alternatives (with slaves)
  to handle the M-N problem (M plugin providers, N web browsers).
  Pretty cool stuff -- and uniquely Debian.
  (see java-common for details).

- Applets work correctly (including sound)

- Java Web Start works correctly (this is really nice).

- Desktop (Gnome) integration works.

- The power of debconf is demonstrated in allowing the license
  to be presented in a character terminal, a GUI, or for large
  server installations pre-seeded for noninteractive installation.

- The layout of the bits conforms to FHS and JPackage conventions
  while preserving the legacy JAVA_HOME directory tree approach.

- The work with Debian has highlighted several bugs, RFE's and
  general opportunities for improvement in our upstream bundles...
  Most notably to reduce unnecessary duplication and better
  handle the architecture dependent and independent parts.

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



[1] DLJ


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: