Hi Raphael,
On Tue, Apr 15, 2003 at 10:08:59PM +0200, Raphael Hertzog wrote:
> Le Tue, Apr 15, 2003 at 02:29:52PM -0500, Steve Langasek écrivait:
> > The latest version of libdbd-mysql-perl build-depends on
> > libmysqclient-dev. I'm afraid that, although this fixed the FTBFS bug,
> > it potentially renders some software in our archive non-distributable.
> > Because the new libmysqlclient12 package is licensed under the GPL, any
> > GPL-incompatible apps which depend on libdbd-mysql-perl would be in
> > violation of the libmysqlclient12 license.
> I disagree completely with this bug.
> The perl module "links" to libmysqlclient12, but the perl module is
> available under the GPL so it's ok.
I agree that the perl module itself is not violating the license of
libmysqlclient12.
> Any other program/script "uses" DBD::mysql but doesn't link to
> libmysqlclient12 ... so there's no problem on that side either.
Here, I have to disagree. You draw a distinction based on "linking",
but this word only appears only once in /usr/share/common-licenses/GPL:
as a footnote referring to the fact that the LGPL *does* allow linking
to proprietary apps.
Please note that if you are right, this would be a gaping loophole in
the GPL: it would allow people to circumvent the GPL, just by wrapping
any code they want as a module for an interpreted language. Fortunately
for the goals of the FSF, this is not the case. If you (in this case:
Debian) are distributing GPL software, under copyright law the GPL can
(and does) place restrictions on your distribution of other software
together with the GPL software; and under the DFSG, this is acceptable
because the GPL only restricts redistribution of other software that's
*related* to the GPL code programmatically (it doesn't taint independent
software distributed alongside it).
This establishes that a license can place restrictions on scripts built
around the software and still be considered free, but of course we must
also show that the GPL actually has such a restriction. I believe the
key is in GPL section 2:
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.
We are "linking" scripts that depend on libdbd-mysql-perl in a manner
that's conceptually equivalent to a dynamically-linked binary: we have
a programmatic link, in the form of a Depends: line in our package
system, that guarantees that when the user runs the script as we
distribute it, GPL code is loaded into memory. This means that any
scripts *we* distribute that Depend: on libdbd-mysql-perl must comply
with the terms of the GPL. This is also not inconsistent with other
views of the GPL; anyone else, who is not distributing the MySQL
libraries, can distribute such scripts freely under terms of their
choice:
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
> > I have not had a chance to look through the list of packages that depend
> > on libdbd-mysql-perl to see if any of these are actually
> > GPL-incompatible; however, libmysqlclient10 has been reintroduced to the
> > archive for just this sort of situation. Please consider changing your
> > build-dep back to libmysqclient10-dev and dropping the libssl-dev
> > build-dep.
> Not until you can convince me that my interpretation of the license is
> clearly wrong.
Please let me know if you find problems with any of my reasoning above.
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.
--
Steve Langasek
postmodern programmer
Attachment:
pgpm13cXsUtCR.pgp
Description: PGP signature