[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

Stephen Ryan <taketwoaspirin@deepthought.dartmouth.edu> writes:

> On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote:
>> Anthony DeRobertis <asd@suespammers.org> writes:
>> > On Wed, 2003-05-21 at 11:59, Brian T. Sniffen wrote:
>> >
>> >> I don't.  If it makes use of features specific to the GNU version, it
>> >> should either use the "normally part of your OS" exception, or if
>> >> distributed with GNU grep be itself available under the GNU GPL.
>> >
>> > So every script that Debian distributes that makes use of features only
>> > found in GPL tools must be under the GPL (since Debian can't use the
>> > normal part of OS exception).
>> >
>> > Let's take a concrete example: apache-ssl. In particular, it's postint.
>> > It uses "adduser", which is under the GPL. It also uses update-rc.d,
>> > also under the GPL. So, as above, we have to say the postinst is
>> > available under the GPL. However, it also uses
>> > /usr/sbin/ssl-certificate, which uses OpenSSL. It is well-known that the
>> > GPL and the OpenSSL license are not compatible.
>> >
>> > Is the above legal? If so, why? 
>> I'm not a lawyer -- but I think distribution of apache-ssl.postinst
>> must be distributed under the terms of the GPL.  As such, it can't be
>> distributed by others without an OpenSSL exception or a license which
>> grants a superset of the freedoms of the GPL.
> I'm surprised no one else has jumped on this yet.
> No.  The script in question is a derivative of both OpenSSL and of
> adduser, and the author of the script has no legal standing to relicense
> either of those.  Thus, no script which uses both OpenSSL and adduser
> may be distributed by anyone under any terms, because it would "link"
> OpenSSL with adduser, and they are under incompatible terms.  Even
> though the script itself may offer an exception for OpenSSL, adduser
> doesn't have that exception, and thus, the work as a whole is
> undistributable.  

Sounds reasonable.  I'm not entirely clear on why adduser and
update-rc.d are under the GPL and not the BSD license... but given
their authors licensed them in ways that forbid linking with
non-GPL-compatible software, such as OpenSSL, that sounds reasonable

> Wait.  Isn't dpkg under the GPL?  Now everything on the entire system
> has to be under the GPL, because you can't even get it installed without
> the use of dpkg.

I don't see how a program which merely happened to be installed using
dpkg can be said to be a derivative work of dpkg, any more than it
being a derivative work of whatever tool was used to download the .deb
file, or whatever router software runs in the middle.  All of those --
TCP, HTTP, and DEB -- are generic formats.  Implementing to a standard
does not make your work a derivative work of a popular implementation
of that standard.

> The other option, of course, is that the kernel exec() function *is* a
> barrier, 

I don't understand why you believe a technical definition is relevant.
Why exec and not ld?  Why not JMP?  Why not #include?  The "barrier"
as you put it has nothing to do with bits.  It is defined by thought:
by the intent of an author of a potentially derivative work.  If he,
in his creation, is intentionally deriving creative ideas from the
author of a previous work, his work is derivative.  If he's creating
independently of previous programs, or implementing to a
specification, his program is not derivative of any other program.

So if I write a shell script which makes calls to /usr/bin/openssl, my
program is derivative of Eric Young's program, so we both have a
copyright on the result.  If my script also calls GNU grep, and I
looked at the info page while writing it, consciously implementing it
to use features particular to GNU grep, then it's also derivative of 
that program, and the FSF also owns a copyright on it.

Doesn't this framework seem easier to work with than trying to find a
technical definition of a barrier?

> Debian *can* be used for real work and not just an exercise in
> ivory-tower masturbation.  
> Center for Educational Outcomes
> at Dartmouth College

Ahem.  I'm all for getting real work done: I just don't see a need to
bend the law or the intent of an author to do it.


Brian T. Sniffen                                        bts@alum.mit.edu

Reply to: