On Wed, Jan 19, 2005 at 01:07:16AM -0500, Brian Thomas Sniffen wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > On Fri, Jan 14, 2005 at 11:41:41PM -0500, Brian Thomas Sniffen wrote: > >> Joel Aelwyn <[EMAIL PROTECTED]> writes: > >> > >> > The user has T installed, and types "apt-get install noteclipse". Since > >> > >> Does this also answer the case of Debian CDs? > > > > It answers it in precisely the same fashion that it answers the main > > archive. If you have something installed which meets the dependancies > > already, our tools do not, by default, install something *else* (say, > > Kaffe) to try to meet them. > > But the Debian CDs have nothing to do with the Depends-based tools. > It's just a work containing copies of Kaffe and (soon) Eclipse in > closer proximity than aggregation.
I have yet to see any convincing argument that it is not, in fact, mere aggregation, except for "we provide metadata" - which is exactly what the Depends discussion is about. The metadata we provide says exactly two things: 1) Anything which provides java2-runtime will suffice (this happens to include Kaffe, along with many other things) 2) Because our tools are limited and imperfect, we must give a hint to them about what might be prefferable for resolving the above if more than one thing can do it (as is the case). Kaffe is free, and the packager of Eclipse apparently thinks it's a good choice for a hint. If you'd like to see something else hinted here, file a wishlist bug and provide reasoning, but this is a technical consideration, not a legal one. > > This does depend on the accuracy of the Depends line. If something > > uses native (JNI) library calls that are not standardized across some > > significantly-multiple set of JVMs, that Depends is not going to be correct > > if it just says "kaffe | virtual-package-for-jvms", since most things that > > provide the latter don't provide the necessary JNI calls. > > > > If it *is* accurate, that means the whole damned thing is programmed to an > > API that is *not* owned by Kaffe (namely, the Java language standards), but > > rather, is implemented by Kaffe, and this means it cannot be a derivative > > work of Kaffe. > > It's not about a derivative work or ownership of an API. It's just > about distributing copies of Kaffe with copies of non-GPL'd works. See above. This is really getting quite silly. We have strong reason to believe that the Kaffe folks *do not* interpret the GPL as contaminating things which are run within Kaffe (with the possible exception of things that use JNI calls to accomplish things which are not possible in other JVMs, if any such exist). As such, stretching to try to prove there's a problem where even the copyright holder believes there isn't one, and which is built on tenuous arguments which appear to contradict case law in the country where those arguments origionate, is getting into a state beyond ludicrous. We've gone to plaid. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `-
signature.asc
Description: Digital signature