[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

On Wed, May 21, 2003 at 01:01:06AM -0500, Branden Robinson wrote:

> It seems wrong to me that we can take a free, but GPL-incompatible
> application out of Debian main and hand it to two software distributors.
> Each distributor grabs a different ABI-compatible implementation of a
> shared library (upon which this app depends) out of Debian main.  One of
> those happens to be GPLed and the other does not (it's, say, under the
> MIT/X11 license), but the distributors just flip a coin to decide which
> one they ship.

> Under your analysis, one of these guys is in deep shit with the
> copyright holder of the GPLed implementation of the shared library, and
> the other guy is not.

> It's just a bellyfeel, but it's a strong one.  What the Debian Project
> distributes should not be subjecting people to this sort of risk.  I
> think one should be able to distribute arbitrary subsets of the Debian
> OS in pretty much total ignorance of the licensing on the software
> within.  If they modify stuff, that's a different story.

I think that's a reasonable requirement, and I don't think my analysis
supports the conclusion that someone distributing a subset of Debian
packages would be in violation of the GPL, *if* Debian itself is in
compliance with the license.

If someone distributes a subset of Debian's packages that includes a GPL
library and a GPL-incompatible app, there are two principal

* Installing the application package automatically pulls in the library
package, which means that whoever created the original packages (Debian)
is also responsible for any GPL violations that result from such a

* Installing the application package does *not* automatically pull in
the library package, or does so in a way that the application will not
automatically load the library when you try to run the application.
Manual intervention is required to combine the GPL and GPL-incompatible
code, and the distributor (and Debian) cannot possibly be in violation
of the license.

The one corner case I can see would be an application kfrob-not-so-gpl
which depends on libfrob-lgpl | libfrob-gpl.  If someone installs
kfrob-not-so-gpl from the Debian archive, it will pull in libfrob-lgpl
unless the user declares otherwise.  If a distributor ships only
kfrob-not-so-gpl and libfrob-gpl, the result is different.  I agree that
this is bad, but I don't know of any packages this is a problem for in
practice.  Perhaps the best way to address this corner case would be to
prohibit maintainers from doing this.

> > > I hate to say this because I love my bright-line tests, but I think
> > > intent matters here.  Shipping "such code together with readline
> > > itself", and nothing else, should be distinguishable from what Debian
> > > does, which is ship "such code", "readline itself", a clone or two of
> > > readline, and a whole boatload of other stuff that has nothing to do
> > > with any of the above.

> > I think references to the file name of the GPL'ed library in an
> > application's ELF header constitute pretty damning evidence of the real
> > intent.  "Your honor, the plaintiff's license is non-binding because I
> > could have used editline instead" doesn't sound like much of a defense
> > to me.

> If that's the case with readline vs. editline -- I can't be assed to
> check, then you're right.  But does your analysis change at all if
> libeditline ships, say, its own /lib/libreadline.so.4?  I mean, this is
> exactly the point of ABI compatibility.  Just look at the LessTif
> project.

I think it does change in such a case.  Today, the libeditline0 and
libreadline4 packages can be installed side-by-side, however, and
applications built against each look for a different library name.

Steve Langasek
postmodern programmer

Attachment: pgpTitqW5WNqA.pgp
Description: PGP signature

Reply to: