Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
Andrew Suffield wrote:
[This part of the thread belongs on -legal]
So, there it goes.
On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote:
[Paul TBBle Hampson]
This of course assumes the phrase "derived work" is legalese for
"code dependancy" or something. I'm sure the GPL actually defines
what _they_ mean by it...
The GPL simply defers to copyright law to define "derivative work".
(most jurisdictions') copyright law defines "derivative work" as "a work
that, being a novel intellectual creation by itself, results in a
transformation of another (original) work", the key word being
"transformation".
This is a part of copyright law originally thought for controlling
instrument re-arranging of musical works, translations of a work from a
language to another, and sequels and prequels re-using characters from a
literary/theatrical work.
Anyway, this is a very foggy issue, because the GPL uses thoughout the
license text the expression "work based on the Program" (as opposed to
the [legally-defined] expression "derivative work"), which it defines in
the following (contradictory) phrase of section 0, caput:
''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.''
Notice that before the colon, it gives one definition; after the colon,
it gives another definition (a wrong one, considering that the "that is
to say" introduces an explanatory part of the phrase, and that the
explanation differs from the copyright law definition, and that
copyright laws vary with jurisdictions, etc).
This can be contrasted with the infamous "mere aggregation" clause,
section 2, paragraph 3: ''In addition, mere aggregation of another work
not based on the Program with the Program (or with a work based on the
Program) on a volume of a storage or distribution medium does not bring
the other work under the scope of this License.'', and with the other
occurences of the (legally-defined) expression "derivative work" in the
GPL, after section 0:
The first one in section 2, paragraph 2: ''the intent [of this section
of the GPL, section 2] is to exercise the right to control the
distribution of derivative or collective works based on the Program''
[braces mine];
The second one in section 5: ''You are not required to accept this
License, since you have not signed it. However, nothing else grants you
permission to modify or distribute the Program or its derivative
works.''; this one, combined with the "mere aggregation" clause, can be
construed as an authorization to distribute collective works containing
the GPL'd work;
And the last one in section 10: ''Our decision [on licensing any
FSF-owned software under different terms] will be guided by the two
goals of preserving the free status of all derivatives of our free
software and of promoting the sharing and reuse of software generally''
[braces mine]; again, without mentioning the collective works, this can
be combined with the "mere aggregation" clause as a confirmation of the
authorization to distribute collective works containing the GPL'd work.
And yes, I noticed that the first one kind of contradicts the other two,
too.
I might add that
claiming a program that uses a library's published API is a "derived
work" is a bit shaky from the get-go. If you actually cut and paste
code from the library into your program, it's a lot more clear-cut.
Yes, in the former case there was no transformation of the library's
source code; in the latter, there was.
We talk about APIs on forums like -legal to save time, because
everybody (supposedly) knows what we're talking about there. They
aren't directly relevant, it's just that certain aspects of program
design will normally have certain legal implications because that's
how those things are normally implemented.
Changing static linking to dynamic, or replacing a linker call with a
dlopen() call, *always* has precisely *zero* effect on whether
something is a derivative work or not. A work is created derivative,
or not, at the time of inception. For source code, this is the time
Yes! I could not agree more.
when the code is written. The way in which it is compiled is
irrelevant. For a binary, this is the time when the binary is built
and linked. A statically linked binary is a derivative work of
I disagree here: there is no novel intellectual work involved in
building/linking a binary. A binary can be, at most, a collective
(anthology) work, and this makes a difference in some point in time.
Especially if the GPL is involved.
everything it links because it contains verbatim copies of those
things. Every binary, static, dynamic, or other, is a derivative of
everything that any part of its source was derived from.
Nope. Collective. No intellectually-novel transformation was applied,
other than (maybe) choosing and ordering the parts.
A good rule of thumb for whether one piece of source code is a
derivative of another is "Will it function in a reasonable manner
without this other piece?". Thusly a telnet client is not a derivative
The best rule of thumb is: "would this have the same form if the
allegedly original work did not exist"? If so, the work is not
derivative. (If not, NOTHING CAN BE SAID -- you have to get deeper in
the abstraction, filtration and comparison process).
of the socksified tcp library you stuff in with LD_PRELOAD, but the
part which sets up ssl connections is a derivative of the ssl library
you use. This is a rule of thumb because it fails in pathological
cases; don't abuse it.
Notice that my rule of thumb applies to a far smaller universe of
allegedly-derivative works.
[There are many other, more complicated cases. Consult -legal for
consideration of specific examples.]
IANAL, TINLA, etc.
Reply to: