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' " provision. >> + 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 conditions. Regards, --Tom [1] http://www.lessig.org/blog/archives/003368.shtml [2] http://www.benkler.org/wealth_of_networks/index.php/Main_Page
signature.asc
Description: OpenPGP digital signature
