[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 Tue, May 20, 2003 at 04:15:54AM -0500, Branden Robinson wrote:

> > > Is it any help to cite the libreadline/libeditline case?  Readline is a
> > > GPLed library authored by the FSF.  Editline is a BSD-licensed clone
> > > (with a limited feature set) developed by people who weren't happy with
> > > Readline's licensing.

> > I think it's an interesting case to consider because of the question of
> > whether an interface is copyrightable, but I think that discussion is
> > best left for another thread.  In any case, I believe the "generic
> > interface" defense is only applicable when the distributor is not
> > distributing a combination that requires selecting one specific
> > implementation as the default.

> I am not sure the U.S. courts agree.[1][2]

I don't see how the cases you cite conflict with what I said.  In both
of the cases, IIRC, the courts found in favor of someone who duplicated
a competitor's interface.  This seems to support (API vs. user interface
question aside) the notion that the generic interface defense *is*
applicable when you aren't distributing someone else's copyrighted
implementation of the generic interface.  However, it does not establish
a precedent for the case where you *are* distributing the plaintiff's
copyrighted work which provides a given interface.  Apple v. Microsoft
doesn't mean Microsoft could claim MacOS no longer enjoys copyright
protection just because someone cloned the UI.

> > To restate:  If distributing a statically-linked binary that combines a
> > GPL library with GPL-incompatible code is a violation of the GPL, then
> > shipping *any other combination of files* which constitute a program
> > that, when run, result in a corresponding intermingling of GPL and
> > GPL-incompatible code in memory is also a violation of the GPL.  You
> > cannot circumvent the GPL's requirements on source code by shipping your
> > combined work in the form of a GPLed library and a GPL-incompatible
> > program; nor can you circumvent them by writing (or reusing) a GPL
> > interpreter and shipping it together with the GPLed library and your
> > GPL-incompatible script (bytecode).  (I'm going to ignore the much
> > hairier RPC question for the moment. :)

> > > Because the two libraries are interface-compatible, the FSF is not in a
> > > position to forbid people from distributing code that "links" against
> > > libreadline if that code is not licensed GPL-compatibly, because the
> > > code could be linked against libeditline instead.[1]

> > Yes, but they are in a position to forbid distributing such code
> > together with readline itself.

> 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.

-- 
Steve Langasek
postmodern programmer

Attachment: pgpBrv3JEHzb3.pgp
Description: PGP signature


Reply to: