Steve Langasek wrote: > On Mon, Jun 05, 2006 at 01:46:29AM -0700, Walter Landry wrote: >> Steve Langasek <[EMAIL PROTECTED]> wrote: >>> On Sun, Jun 04, 2006 at 08:16:24AM -0700, Walter Landry wrote: >>>> This can be fixed by making Jython conflict with sun-java, although I >>>> suspect that there may be other packages that also cause problems. > >> Another fix for this particular problem is to make sun-java not >> Provide:java-runtime etc. at all.
Good point. That would tend to decrease the utility of sun-java, but it should avoid most of the issues. >>> There have been various clarifications that the intent of this clause is to >>> prohibit distributing sun-java5 in a configuration that mixes and matches >>> parts of Sun's implementation with other Java implementations. I don't think any of the clarifications have limited the clause to that sole purpose, and furthermore I don't think even that much of a clarification addresses the question of what constitutes such a configuration. See my message referenced at the end of this mail for examples that seem to me to fall under such a description. >>> Why are these clarifications not sufficient when we regularly accept >>> clarifications of this nature from other copyright holders? > >> There are a few problems here: > >> 1) Clarifications from other copyright holders do not come with a big >> disclaimer stating that the clarification has no legal weight. >> Debian relies on the clarification having legal weight. > > Well, this seems to have just changed in the case of the DLJ. I agree; the FAQ now seems sufficiently binding to meet the standards of other license clarifications Debian has accepted, in my opinion. I also think the answers in the FAQ address many of the other concerns raised by debian-legal: the issue of whether distributing in non-free (which Debian does not consider part of the distribution) counts as distributing with the OS, the issue of whether users can develop software for non-Debian platforms using the JDK (not a freeness issue but an important question), and the issue of whether removal affects mirrors or stable releases. >> 3) There are only two clarifications I know of. One is in the >> non-binding DLJ FAQ, and the other is from Tom Marble [1]. Neither >> of these clarifications limit the restrictions to Java >> implementations. For example, in Tom's clarification he says [2] > >> In a similar way please don't take bits from the Java platform >> and use them as part of or to complete alternate technologies >> (e.g. plugin.jar). > >> So using Java's plugin mechanism to implement python plugins for >> Jython is not allowed. And this makes sense. Sun would definitely >> be unhappy if the JDK were used to implement J++ or C#, especially >> because they are not Java. > > That's not actually clear to me; "alternate technologies" is very vague. > I'm also not convinced that dropping the java-runtime provide from the Sun > Java packages is the sort of thing Sun intends with this, either. > Basically, it seems to me that the cited clarification from Tom happens to > not clarify much after all... Same with the clarification in the FAQ. It seems to answer some questions (we don't need to worry about non-Java software qualifying as "similar functionality"), but not others; see my message referenced below for examples of what I don't think it addresses. > BTW, if jython is the only package that poses a problem for this clause, I'm > not sure there's much to worry about anyway here: jython is RC-buggy and > likely to be dropped from etch, because it build-depends on (and implements) > python2.1, which is 3 stable releases behind where we expect the main python > implementation to be for etch. Other packages raise similar concerns; please see my message <[EMAIL PROTECTED]>, available at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370295;msg=10>, for other examples, as well as suggested fixes for the DLJ (or the FAQ now that it looks like a sufficiently binding clarification) which would address those concerns. The bug probably needs a new title. :) I see no problem with the idea of not letting other Java-related software use pieces of Sun Java. My primary concern lies in avoiding any possibility that a package in main will need to change to satisfy the DLJ. - Josh Triplett
signature.asc
Description: OpenPGP digital signature
