Steve Langasek <vor...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d2kerm9u....@windlord.stanford.edu
