LWN.net Logo

IBM Memo has interesting implications for GPL interpretation

IBM Memo has interesting implications for GPL interpretation

Posted Aug 18, 2004 2:47 UTC (Wed) by tbird20d (subscriber, #1901)
Parent article: IBM's summary judgment motion

If you read the memorandum carefully, you will note that at one point
IBM discounts the notion that including Sys V code into AIX fails
to make the rest of AIX a derivative work. This has interesting
implications for FOSS advocates, some of whom hold to the notion that
including GPL code in a larger work makes the larger work
a derivative under copyright law. The IBM memo seems to counter this.


(Log in to post comments)

IBM Memo has interesting implications for GPL interpretation

Posted Aug 18, 2004 5:08 UTC (Wed) by ami.ganguli (guest, #9613) [Link]

This has occurred to me as well. One thing to notice, however, is that not every GPL user believes this.

The bottom line is that the definition of 'derivative work' is a question of copyright law. Presumably it's easier to make the case that your work is not derivative if the binaries are not linked, but there may be cases where a separate binary _is_ derivative, and there may be cases where a linked binary is not derivative. It will depend on the specifics of the code and how the court interprets the situation.

IBM Memo has interesting implications for GPL interpretation

Posted Aug 18, 2004 7:15 UTC (Wed) by melevittfl (guest, #5409) [Link]

"If you read the memorandum carefully, you will note that at one point
IBM discounts the notion that including Sys V code into AIX fails
to make the rest of AIX a derivative work. "

No, you're misunderstanding the issue.

SysV + Other code = AIX. IBM has never disputed that AIX contains Unix code. Therefore, AIX, as a whole, is a derivitive work of Unix.

IBM is pointing out that Other code on it's own is a) not a derivitive work under copyright law, and b) not intended to be covered by the contract.

The GPL uses the same definition:
GPL code + Your code is a derivitive work of the GPL code.
You code on it's own is still yours. If you remove all the GPL code from your code, you can do what you want with it.

Exactly ... furthermore

Posted Aug 18, 2004 9:25 UTC (Wed) by AnswerGuy (guest, #1256) [Link]

If I create a derivative work of GPL then all of the code I wrote myself is still mine and can be cross-licensed under any terms that I like (and that anyone would be silly enough to accept).

You are both mistaken, sorry.

Posted Aug 18, 2004 11:43 UTC (Wed) by hummassa (subscriber, #307) [Link]

Both you and the parent poster are mixing derivative works with
"compilation" (or anthology) works.

I will try to explain this to you based on Brazilian law, but
this /should/ apply equally to USC17 (USofA law) and other
jurisdictions', also. Anyway, IANAL and TINLA.

Derivative works are works that have identity (they are novel
intellectual works) but are the result of some (non-automated -- or else
they wouldn't be intellectualy novel) transformation on the original
works.

Anthology works have intellectual merit on the selection or the
organization of the contents... but the contents, per se, are other
separated works.

The copyrights of derivative works are not exclusive -- they are
"blended" (condominium?) between the authors of the original and the
derivative works.

The copyrights of anthology works, OTOH, ARE exclusive -- the original
works' authors have the copyrights to it, and the anthologist has the
copyrights of the selection/organization/etc.

Linux -- the kernel, obviously -- is an example of derivative works.
Everytime you get a patch included in the kernel, you have the copyright
on your patch in a non-exclusive manner: all the copyright owners of the
version of Linux you based your path on (ie, you TRANSFORMED by applying
your patch to) are co-copyright-owners of your patch (this is a
simplification -- you can prove, for instance, that your patch is not
based on iptables/alsa/some other part of the kernel or does not
transform it -- but there is a large part of the kernel that your patch
transforms, so it *is* a derivative work of).

Debian -- the distro -- is an example of compilation/anthology works. The
selection/organization of its packages are copyrighted by the Debian
project; while the pacakges individually are copyrigthed by the upstream
authors, and probably by the packagers/maintainers also.

The GPL tries (wrongly) to determine what is or not a derivative work by
saying "if you link, it's a derivative work", but this is *not* true. The
better way to read the GPL is: "If you don't link, then it's not a
derivative work. But if you do, you are generally augmenting your program
by using my program/library and augmenting my program/library by using
your program, so it has a great probability of being a derivative work."

HTH

Massa

Terminology.

Posted Aug 18, 2004 13:03 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

The GPL tries (wrongly) to determine what is or not a derivative work by saying "if you link, it's a derivative work", but this is *not* true. The better way to read the GPL is: "If you don't link, then it's not a derivative work
I think you're getting muddled. The GPL does not mention linking at all, except in passing in the final paragraph. It defers to copyright law on the matter of what a derivative work is.

I wish people would stop using the term 'derived work' as if it were equivalent to "work which GPL terms require to also be GPL'd".

The 'infection' of the GPL does not apply only to derived works. If you have a collective work which is based on a GPL'd Program, and identifiable sections of that work can reasonably be considered independent and separate works in themselves, then the GPL doesn't apply to those sections when you distribute them as separate works.

But when you distribute the same sections as part of a whole which is a collective work based on the GPL'd Program, the distribution of the WHOLE must be under the terms of the GPL. The permissions for other licensees extend to the entire whole; to each and every part regardless of who wrote it.

For "a whole which is a collective work based on the GPL'd Program" consider, by way of example, the firmware for an embedded Linux router. For "independent and separate work distributed as part of that whole" consider a binary-only kernel module distributed as part of that whole.

I disagree.

Posted Aug 18, 2004 14:06 UTC (Wed) by hummassa (subscriber, #307) [Link]

One contradiction: " The GPL does not mention linking at all, except in passing in the final paragraph. " The fact is: the GPL mentions linking, in its last paragraph. It's the last paragraph of the "postamble", it's true, but it mentions it in a very authoritative way.

Now another part of your argument: " The 'infection' of the GPL does not apply only to derived works. "... Section 0 defines a "work based on the Program" authoritatively as "either the Program or any derivative work under copyright law" -- the "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" is an explanation (begins with that is to say), but not only this, it's a *wrong* explanation because it mixes derivatives and anthologies. IMHO the "explanation" part is a NOOP because of that.

IRT the same argument, there is still the question of the "explanations" contained in the postable for the section 2: The 2nd paragraph explains that "the intent is to exercise the right to control the distribution of derivative OR COLLECTIVE works based on the Program" (emphasis mine -- sorry for the caps) but the 3rd paragraph comes to contradict it, saying that "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" which, basically, defines what a collective (=anthology) work is.

Linus has done his homework, and studied USC 17 (I don't have the pointer right now); so have I, studying Brazilian applicable laws (Author's Rights Act [9610/98], Computer Programs Act [9609/98], and Industrial Property Rights Act [9279/96]). And I have a very clear opinion that is "in tune" with Linus': the GPL only restricts redistribution of derivative works -- the "mere aggregation" clause encompasses anthology works; to determine what is a derivative work, you have to follow the steps of abstraction, filtration and comparison. Linking does not make a derivative work. The GPL, in last paragraph of the postamble, exempts non-linking works from being considered derivative works, [reference: estoppel].

One last comment on _why_ I think the "mere aggregation" clause encompasses _all_ anthology works: if it doesn't, you fall in the "slippery slope" thing. The "gold standard" for determining what is a derivative work exists (abstraction, filtration, comparison). Other than that, a license can waive rights, but not try to acquire other rights (ok, in some jurisdictions, it can, but a Free license shouldn't anyway and the GPL has the intention of being a Free license).

I disagree.

Posted Aug 18, 2004 15:27 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

One contradiction: " The GPL does not mention linking at all, except in passing in the final paragraph. " The fact is: the GPL mentions linking, in its last paragraph. It's the last paragraph of the "postamble", it's true, but it mentions it in a very authoritative way.
The final paragraph looks like just an advert for the LGPL to me:
This General Public License does not permit incorporating your program into
proprietary programs.  If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library.  If this is what you want to do, use the GNU Library General
Public License instead of this License.
It is restating a restriction. I certainly can't see any support for your claim that it "exempts non-linking works from being considered derivative works".

I disagree with your assertion that the 'mere aggregation on a volume of a storage or distribution medium' clause contradicts the part about collective works. The GPL clearly intends to make a distinction between the act of collecting a handful of software packages onto a CD for distribution, and the act of producing a coherent work which is based in part on the GPL'd work.

Not only is it clear that this is what is intended, it is also clear that the author of the GPL'd code in question has the right to do so -- it's perfectly within the rights of the author to state that the work may only be redistributed as part of a larger work if certain conditions are met.

One last comment on _why_ I think the "mere aggregation" clause encompasses _all_ anthology works: if it doesn't, you fall in the "slippery slope" thing.
That sounds more like a reason why you think the "mere aggregation on a volume of a storage or distribution medium" clause should encompass all anthology works; not a reason why it does. The GPL clearly makes a distinction between what we shall abbreviate to "mere aggregation" and the production of a more coherent collective work. The precise boundary between those two may indeed be a grey area, but it is not for us to declare that this means it doesn't exist.

IANAL and TINLA

Posted Aug 18, 2004 17:02 UTC (Wed) by hummassa (subscriber, #307) [Link]

I am just a (now-working-in-another-field) paralegal, but I am pretty sure my research is valid, at least WRT Brazilian Law; I am very certain that my arguments hold in other jurisdictions, too, because basically all copyright law are some "translation" of the Geneva convention. That said,

" The final paragraph looks like just an advert for the LGPL to me "... but it's part of a section name "how to apply this terms to your program", denouncing the intentions behind the license.

" I certainly can't see any support for your claim that it "exempts non-linking works from being considered derivative works" "... my claim is: *nothing* that is *not* a (non-automatic-,intelectually-novel-) transformation is a derivative work. the GPL specifically uses the "links to" property as a means of attributing some transformation over the works, that I think does not exist. is main(){printf("hello, world\n");} derivative of glibc? I don't think so.

Now, one can argue that when the last para of the GPL attributes derivation to works that link with GPL'd works AND the section 2 attribute derivation to works containing the original work or parts or translations of it except in the case of mere aggregation, it exempts the rest of the universe of works from being derivative. When you try to define what colors are blue, you are implicitly defining that the other colors aren't.

" The GPL clearly intends to make a distinction between the act of collecting a handful of software packages onto a CD for distribution, and the act of producing a coherent work which is based in part on the GPL'd work. "... this I can believe if it comes from Eben Morglen, but in any case, the distinction is not a very practical one. Debian, to me, is a coherent work that functions as a whole, not just the aggregation of separated parts. But who does this distinction? Copyrights law. And copyrights law makes dispositions about the division of copyrights when works are derivative and separation of copyrights when works are anthologies (=collections, =mere-aggregations)

" The GPL clearly makes a distinction between what we shall abbreviate to "mere aggregation" and the production of a more coherent collective work. The precise boundary between those two may indeed be a grey area, but it is not for us to declare that this means it doesn't exist. "... My argument is precisely the opposite. The precise boundary exists, it's defined in the copyright law, and that is what has to be used. Abstraction, filtration, comparison.

Terminology.

Posted Aug 19, 2004 4:21 UTC (Thu) by Ross (subscriber, #4065) [Link]

No. The GPL does not claim to have rights over "mere aggregations". The
combined work must somehow be a derivative of the original GPLed work.

You are both mistaken, sorry.

Posted Aug 19, 2004 18:17 UTC (Thu) by mmarsh (subscriber, #17029) [Link]

My understanding of the GPL is that if you write a piece of code from scratch, it's yours to license as you see fit. If you link it against a GPL'ed library and distribute the resulting binary, then you must abide by the GPL for that work, necessitating the release of your source code. If you release just the source, and no GPL'ed code is included, then you can use any license you like, regardless of how the users compile and link the code. Linking thus only applies to binary distribution.

Returning to the subject of IBM's claim re: AIX and SVRX, even under the GPL, IBM's code for AIX would not be a derivative work of SVRX, even though the OS as a whole, when compiled and linked, is. Using the example of a program that calls printf, writing code that calls printf doesn't create a derivative work, since it could be linked against any library that provides a function called "printf" that has the same semantics. Only when distributed with the actual _version_ of printf from glibc does the latter's license come into play. At worst, IBM might have to accept some relatively small amount of "glue" code in AIX as derivative of SVRX, if SCO could convincingly argue that the semantics of the call to SVRX code are sufficiently unique. Even then, we'd be talking about individual lines, and possibly some structs, that would need to be sanitized to become free of the SVRX restrictions.

You are both mistaken, sorry.

Posted Aug 23, 2004 5:47 UTC (Mon) by dberkholz (subscriber, #23346) [Link]

It could also be argued that AIX is a "transformative" derivative work and as a result no longer subject to the copyright issues.

IBM Memo has interesting implications for GPL interpretation

Posted Aug 18, 2004 15:10 UTC (Wed) by dkite (guest, #4577) [Link]

Both the GPL and the original AT&T contract had to do with conditions
where the original works could be used and distributed.

IBM has shown here that the intent of the AT&T contract was simply to
maintain AT&T ownership of the original code, anything else would belong
to and be controlled by IBM. Everyone involved knew what the deal was,
the terms, etc. They paid AT&T presumably for the privilege, and later
paid Novell 10m or so for an irrevocable license. Hence SCO has no
interest at all in any of IBM's code.

The GPL is essentially an agreement where if IBM were to include some
GPL'd code in an application, or built on an existing application, they
would own the code they wrote, but to be able to distribute the whole
they would have to abide by the terms of the GPL, ie. make source code
available.

If IBM didn't like the terms of the GPL, they have two options. Take the
original GPL'd code out and rewrite (the copyright standards of
derivative works applying here), hence owning all the body of code, or
they could negotiate a relicense with the original authors.

IBM indeed says it would be unreasonable to assume an understanding of
the original AT&T contract to be something as broad as what SCO is
saying, especially when the intent of the parties was obvious. However,
say 20 years from now there is a suit where the original parties, you or
I as a developer released some application under GPL, including
contributions from a dozen other developers, and a large corporation
takes our application and starts contributing substantial amounts of
code, each file marked with the GPL. The suit argues ownership and
control, so you or I and the dozen other developers are interviewed. The
intent of the GPL was clear to all who contributed.

What IBM said doesn't invalidate the GPL. IBM is only stating that you
cannot impose a drastic and unreasonable interpretation on contract
wording.

The GPL is very clear in it's intent.

Derek

IBM Memo has interesting implications for GPL interpretation

Posted Aug 19, 2004 7:16 UTC (Thu) by ekj (subscriber, #1524) [Link]

Sort of.

First, what a "derivative" work is, is an issue of copyrigth-law, not an issue of what the GPL (or any other license) says.

Assume I buy some code X from you, and then add my own code Y to that to produce and sell product XY. Later I contribute some of my code Y to a third project Z, producing ZY.

Now, XY migth quite reasonably be a derivative work of X. That is reasonable. What is *NOT* reasonable, and what SCO is attempting, is to say that ZY (which contains no traces of X) nevertheless is a derived work of X.

IBM Memo has interesting implications for GPL interpretation

Posted Aug 19, 2004 10:41 UTC (Thu) by hummassa (subscriber, #307) [Link]

It depends. Remember that the definition of derivative is "transformation of". If Y was not just added to X, but transformed somehow till the point that XY was possible, then Y *is* a derivative work of X; if Z was transformed in a way that made YZ possible, then Z also is a derivative of X, by way of being a derivative of Y. And this *is* reasonable.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds