Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
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.
>> The distinction really does come down to whether something is a
>> derivative work:
>
> A ''derivative work'' is a work based upon one or
> more preexisting works, such as a translation,
> musical arrangement, dramatization, fictionalization,
> motion picture version, sound recording, art reproduction,
> abridgment, condensation, or any other form in which a
> work may be recast, transformed, or adapted. A work
> consisting of editorial revisions, annotations,
> elaborations, or other modifications which, as a whole,
> represent an original work of authorship, is a
> ''derivative work''. (Title 17 USC, Sec. 101)
>
> It's hard to see how a shell script could be a derivative work of grep
> under that definition. I don't think the shell script is an
> transformation, recasting, or adaption of grep. Or a modification.
It certainly can be. For example, consider the shell script
greppager, which simply runs grep and pipes the output through
$PAGER. That's a program constructed as a transformation and
recasting of grep. That it includes grep by reference rather than by
copying shouldn't matter -- this is the heart of the FSF's "linking is
modification" argument. Greppager is a work based on a pre-existing
work, consisting of elaborations and other modifications which, as a
whole, represents an original work of authorship.
I don't need to edit the source of a computer program to modify the
program: I can create a derivative function by wrapping another
function. The output of (lambda (f) (lambda (l) (map f (filter even?
l)))) may be a derivative work of f, for example. That a shell script
is easily broken apart and read by a human shouldn't matter.
For example, if I distribute a macro package which, given some text,
loads MS Excel and uses that to perform some calculations, then closes
Excel and uses the output of the calculations for some other purpose,
that's clearly a derivative work of Excel. If my work couldn't have
existed in the same form without another work, my work is derivative
of that work.
>> a shell script which coincidentally uses generic grep
>> functions isn't a derivative work of grep. A shell script which wraps
>> GNU grep to provide some of its peculiar functions to another program
>> is a derivative work of GNU grep.
>
> Where do you see that in the definition above?
To further clarify, given a copyrightable program P which implements
an algorithm A(x), a program Q which implements B(A(x)) by nontrivial
use of P is a derivative work of P. Put simply, if it's clear that
you wrote Q intending it to wrap P, Q is a derivative work of P. If
you wrote Q to work with a separate standard, or with a wide variety
of programs P1, P2, etc. all presenting a similar interface to P, then
Q isn't a derivative work of any of them (and it's most likely not
derivative of the standard, because the procedures expressed in the
standard are not copyrighted, only their expression there).
-Brian
--
Brian T. Sniffen bts@alum.mit.edu
http://www.evenmere.org/~bts/
Reply to: