Re: GnuTLS in Debian

[Russ Allbery <rra@debian.org>]

Steve Langasek <vorlon@debian.org> writes:

> The GPL requirement about dependency licensing does not rely on the
> legal definition of derivative works.  So arguments that a GPL program
> that links against OpenSSL is not a derivative work of OpenSSL are
> missing the point.

I don't believe this is true of the GPLv2.  The restrictions on
distribution of GPL'd code apply to the Program or to a work based on the
Program, which are defined in clause 0 of the GPLv2 as follows:

    The "Program", below, refers to any such program or work, and a "work
    based on the Program" means either the Program or any derivative work
    under copyright law:  that is to say, a work containing the Program or
    a portion of it, either verbatim or with modifications and/or
    translated into another language.

The GPLv2 explicitly defers to copyright law's definition of derivative
work.  The subsequent statement about source code in section 3:

    For an executable work, complete source code means all the source code
    for all modules it contains, plus any associated interface definition
    files, plus the scripts used to control compilation and installation
    of the executable.

does not add shared libraries to that restriction (programs linked to
shared libraries do not "contain" those shared libraries in any defensible
technical sense).

Now, the GPLv3 does try to broaden the scope of the source code
requirement to include shared libraries:

    The "Corresponding Source" for a work in object code form means all
    the source code needed to generate, install, and (for an executable
    work) run the object code and to modify the work, including scripts to
    control those activities.  However, it does not include the work's
    System Libraries, or general-purpose tools or generally available free
    programs which are used unmodified in performing those activities but
    which are not part of the work.  For example, Corresponding Source
    includes interface definition files associated with source files for
    the work, and the source code for shared libraries and dynamically
    linked subprograms that the work is specifically designed to require,
    such as by intimate data communication or control flow between those
    subprograms and other parts of the work.

and this is where the point about multiple implementations of an API
clearly comes into play ("that the work is specifically designed to
require").

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>