Stephen Ryan <[EMAIL PROTECTED]> writes:
> On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote:
>> Anthony DeRobertis <[EMAIL PROTECTED]> 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
--
Brian T. Sniffen [EMAIL PROTECTED]
http://www.evenmere.org/~bts/
