[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.]


Reply to: