| |||||||||||||
|
| |||||||||||||
Exactly ... furthermoreExactly ... furthermorePosted Aug 18, 2004 9:25 UTC (Wed) by AnswerGuy (guest, #1256)In reply to: IBM Memo has interesting implications for GPL interpretation by melevittfl Parent article: IBM's summary judgment motion
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).
(Log in to post comments)
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 workI 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: 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".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. 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". Thecombined 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.
|
|
||||||||||||