[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 Thu, Apr 17, 2003 at 12:02:31AM +0200, Raphael Hertzog wrote:
> Le Wed, Apr 16, 2003 at 03:15:19PM -0500, Steve Langasek écrivait:
> >     2. You may modify your copy or copies of the Program or any portion
> >   of it, thus forming a work based on the Program, and copy and
> >   distribute such modifications or work under the terms of Section 1
> >   above, provided that you also meet all of these conditions:
> > 
> >   [...]

> >       b) You must cause any work that you distribute or publish, that in
> >       whole or in part contains or is derived from the Program or any
> >       part thereof, to be licensed as a whole at no charge to all third
> >       parties under the terms of this License.

> I'm sorry but a perl script using DBI/DBD::mysql doesn't contain
> DBD::mysql and is not derived from DBD::mysql ... and it doesn't
> contain libmysqlclient12 and it isn't derived from libmysqlclient12.

> This is even more clear when you consider the fact that a perl script
> can use "DBI" as a general DB layer without knowing which driver is used
> behind the doors.

My question is, how is a package that depends on DBD::mysql materially
different from a compiled program that links dynamically against
libmysqlclient?  The mechanisms are different; the effect is the same.  I
believe that any sane interpretation of the GPL must treat these cases as
equivalent.  You seem to agree, though you disagree with me on how these
two cases should be treated.

> > Please let me know if you find problems with any of my reasoning above.

> The fact is that I think that you extend too easily the meaning of
> "contains" and "is derived".

> While a program directly linked can be considered like a derived work of
> the library, I don't think that you can say that program A is a derived
> work of libX if A is linked to libY which itself uses libX.

> Yes this means that you can go around the limitation of the GPL... but
> I'm confident that a fake library used only in that intent would be
> considered as violating the spirit of the GPL. However when that
> intermediate library serves a generic purpose like DBI, I doubt that
> we violate the spirit of the GPL.

So you don't believe that the letter of the GPL prohibits binary-only
distribution of an application, together with a GPL library that it's
dynamically linked against?  I believe there is room for argument here;
however, I also believe that Debian has a responsibility to err on the
side of caution when there is room for argument in interpreting a
license.

As to the spirit of the GPL, please read
<http://www.fsf.org/licenses/gpl-faq.html#IfInterpreterIsGPL>.  This is
the opinion of the FSF; I'm inclined to believe, based both on past
litigation and on the fact of their strange decision to relicense under
the GPL that they will take a stance that's as hard-line as or more so
than that of the FSF.

The packages I listed in the bug report are not just consumers of the
intermediary DBI library; through decisions made by the package
maintainers, there are explicit dependencies on the DBD::mysql module.

> > Since the GPL makes no reference to technical details of linking
> > mechanisms, however, I'm confident that any interpretation that permits
> > distributing GPL-incompatible perl scripts together with a GPL perl
> > module would also permit distributing GPL-incompatible compiled binaries
> > together with GPL libraries.

> Note that the perl module is not GPL only, but GPL/Artistic (like most
> perl modules). I don't know how much trouble that brings ... :-)

In this case, I think it saves trouble: if DBD::mysql were GPL-only, then
the same argument applies even if you link against the LGPL version of
libmysqlclient.

> Does your reasoning also mean that each time a proprietary perl script
> is using a standard perl module, it uses the module under the terms of
> the Artistic license and not under the GPL because it can't comply with
> the GPL ?

Only if the proprietary perl script is bundled with the perl module.  If
the proprietary perl script isn't bundled, both licenses allow this use
(the FSF seems to disagree here, but I don't think they have legal
standing to enforce their position against someone who isn't a
distributor of the GPL code).

-- 
Steve Langasek
postmodern programmer

Attachment: pgpfuhGemapg1.pgp
Description: PGP signature


Reply to: