All:
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:
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.
+ 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
demonstrates:
- 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".
Respectfully,
--Tom
[1] DLJ
http://download.java.net/dlj/DLJ-v1.1.txt
[2] DLJ-FAQ
http://download.java.net/dlj/DLJ-FAQ-v1.1.txt
Attachment:
signature.asc
Description: OpenPGP digital signature