Re: LGPL module linked with a GPL lib
** Jeff Licquia ::
> On Tue, 2005-07-26 at 11:14 -0300, Humberto Massa Guimarães wrote:
> > I find this discussion ultimately absurd. Debian is *not*
> > distributing a derivative work. Debian does *not* distribute a
> > work that includes both plugins/libraries. The fact that the
> > things are (dynamically) linked at run time, especially combined
> > with the fact that the plugins are opened with dlopen() and use
> > stable API, is *more* than enough to lift any (inexistent IMHO)
> > "no-link" requirement of the GPL.
> I find most of this response confusing.
Yes, it is. I was ranting, because this discussion makes me see red.
> First of all, it's clear that Debian *is* distributing a derived
> work based on GPLed libraries, called "Debian GNU/Linux". The
First of all, Debian GNU/Linux is *NOT* a derivative work of
OpenSSL, GStreamer, nor any of its plugins. A derivative work has a
definition in the statute (in the US case, 17USC).
> specific case in question may fall under the "mere aggregation"
> clause of the GPL, but then this is the point you should argue. I
The last paragraph holds, independently of the "mere aggregation"
> abhor imprecision in these discussions, as they are the breeding
> ground for all kinds of myths and speculation. (Not that I am
> immune to imprecision, or that I am not occasionally a myth-monger
> in my own right. But I welcome the correction.)
> Second, you seem to be asserting that an app and its dynamically
> linked libraries do not constitute a derived work based on both
> for the purposes of the GPL. Rather than debate this point, I
Yes. There is no derivative work status on the program that uses a
library. I and M.K.Edwards, in the last 3 months or so, have brought
a lot of arguments and case law to this extent to d-l, and my own
and humble conclusion is that: especially in the case of dynamic
linking (and more so in the case of dlopen()ing), the distribution
by debian of both a program A and a linking-to-A B.so is subject
only to the *separate* compliance to the terms of both A and B.so,
independently of any terms applied only to derivative works of A or
> think it best to point out that this runs counter to accepted
> precedent within Debian that dates back a long time; see the
> KDE/Qt controversy for a famous example. Basing conclusions on
> this past precedent is not "absurd"; indeed, it would seem that
> the onus is on you to prove your assertion.
I do not have enough time right now to answer properly (ie, with the
links to the discussions, examples, and caselaw that I, amongst
others, presented here on d-l), but I trust that you can find them
if you are interested.
As I said two paragraphs above, I consider that I presented all my
arguments in this direction, and (to me, at least) I consider my
> That's probably enough for starters. If I am indeed confused and
> you are correct, then there doesn't seem much point to proceed to
> the dlopen() question.