On Wed, Jan 19, 2005 at 01:07:16AM -0500, Brian Thomas Sniffen wrote:
> Joel Aelwyn <fenton@debian.org> writes:
>
> > On Fri, Jan 14, 2005 at 11:41:41PM -0500, Brian Thomas Sniffen wrote:
> >> Joel Aelwyn <fenton@debian.org> 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 <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature