* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] @ 2006-12-16 18:27 Ricardo Galli 2006-12-16 21:01 ` Linus Torvalds 0 siblings, 1 reply; 59+ messages in thread From: Ricardo Galli @ 2006-12-16 18:27 UTC (permalink / raw) To: linux-kernel > I think it would be a hell of a lot better idea if people just realized > that they have "fair use" rights whether the authors give them or not, and ^^^^^^^^^ > that the authors copyrights NEVER extend to anything but a "derived work" ... > I find the RIAA's position and the DMCA distasteful, and in that I > probably have a lot of things in common with a lot of people on this list. > But by _exactly_ the same token, I also find the FSF's position and a lot > of GPL zealots' position on this matter very distasteful. ... > Because "fair use" is NOT somethng that should be specified in the ^^^^^^^^^ > license. As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried to change or restrict "fair use". GPL[23] covers only to "distibution" of the covered program. The freedom #0 says explicitly: "right to use the program for any purpose". So, I don't see any clash here between GPL/FSF/RMS with "fair use" And you probably know that any GPLed code can be linked and executed with any other program, whatever is its license if it's for personal use (is that worse than "fair use"?). And even if there is a function in linux that disables loading of non GPL modules, it's still allowed under the GPL to distribute a kernel with those functions removed. Any user can load any other module in this kernel without worrying about "fair use" or "derived work", GPL allows her to do it. So, where's the freaking relationship between GPL (or its "zealots") and "fair use"? Who is trying to re-define it? FUD, FUD, FUD. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 18:27 GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Ricardo Galli @ 2006-12-16 21:01 ` Linus Torvalds 2006-12-17 0:22 ` Ricardo Galli 2006-12-17 13:54 ` GPL only modules Alexandre Oliva 0 siblings, 2 replies; 59+ messages in thread From: Linus Torvalds @ 2006-12-16 21:01 UTC (permalink / raw) To: Ricardo Galli; +Cc: linux-kernel On Sat, 16 Dec 2006, Ricardo Galli wrote: > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried > to change or restrict "fair use". GPL[23] covers only to "distibution" of the > covered program. The freedom #0 says explicitly: "right to use the program > for any purpose". I'm sorry, but you're just rewriting history. The FSF very much _has_ tried to make "fair use" a very restricted issue. The whole reason the LGPL exists is that people realized that if they don't do something like that, the GPL would have been tried in court, and the FSF's position that anything that touches GPL'd code would probably have been shown to be bogus. In reality, if the FSF actually believed in "fair use", they would just have admitted that GNU libc could have continued to be under the GPL, and that any programs that link against it are obviously not "derived" from it. But no. The FSF has very much tried to confuse and muddle the issue, and instead have claimed that projects like glibc should be done under the "Lesser" GPL. That's just idiocy, but it works as a way to defuse the problem that the FSF has always had with admitting that not only _they_ have "fair use" rights, but others have them too. Do you REALLY believe that a binary becomes a "derived work" of any random library that it gets linked against? If that's not "fair use" of a library that implements a standard library definition, I don't know what is. And yes, the FSF really has tried to push that totally insane argument. So don't tell me that the FSF honors "fair use". They say they do, but they only seem to honor it when it helps _their_ argument, not when it helps "those evil people who try to take advantage of our hard work". The fact is, if you accept fair use, you have to accept it for other people to take advantage of too. Fair use really isn't just a one-way street. Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 21:01 ` Linus Torvalds @ 2006-12-17 0:22 ` Ricardo Galli 2006-12-17 4:10 ` Theodore Tso 2006-12-17 13:54 ` GPL only modules Alexandre Oliva 1 sibling, 1 reply; 59+ messages in thread From: Ricardo Galli @ 2006-12-17 0:22 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel On Saturday 16 December 2006 22:01, Linus Torvalds wrote: > On Sat, 16 Dec 2006, Ricardo Galli wrote: > > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never > > tried to change or restrict "fair use". GPL[23] covers only to > > "distibution" of the covered program. The freedom #0 says explicitly: > > "right to use the program for any purpose". > > I'm sorry, but you're just rewriting history. > > The FSF very much _has_ tried to make "fair use" a very restricted issue. > The whole reason the LGPL exists is that people realized that if they > don't do something like that, the GPL would have been tried in court, and > the FSF's position that anything that touches GPL'd code would probably > have been shown to be bogus. > > In reality, if the FSF actually believed in "fair use", they would just > have admitted that GNU libc could have continued to be under the GPL, and > that any programs that link against it are obviously not "derived" from > it. > > But no. The FSF has very much tried to confuse and muddle the issue, and > instead have claimed that projects like glibc should be done under the > "Lesser" GPL. OK, let assume your perspective of the history is the valid and real one, then, ¿where are all lawsits against other big GPL only projects? For example libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold in court. > The fact is, if you accept fair use, you have to accept it for other > people to take advantage of too. Fair use really isn't just a one-way > street. "Fair use: The right set forth in Section 107 of the United States Copyright Act, to use copyrighted materials for certain purposes, such as criticism, comment, news reporting, teaching, scholarship, and research. The Copyright Act does not define fair use. Instead, whether a use is fair use is determined by balancing these factors: ..." According to the law, I don't see how FSF tries to avoid or to reject the fair use rights. It seems to me you provides us with a copyright law interpretation supported only by the very [narrow] exceptions of the copyright law, a logical fallacy. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-17 0:22 ` Ricardo Galli @ 2006-12-17 4:10 ` Theodore Tso 0 siblings, 0 replies; 59+ messages in thread From: Theodore Tso @ 2006-12-17 4:10 UTC (permalink / raw) To: Ricardo Galli; +Cc: Linus Torvalds, linux-kernel On Sun, Dec 17, 2006 at 01:22:12AM +0100, Ricardo Galli wrote: > OK, let assume your perspective of the history is the valid and real one, > then, ¿where are all lawsits against other big GPL only projects? For example > libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold > in court. There's no need for lawsuits against things like libqt. The question is whether someone who writes a commercial program that happens to dynamically link against libqt is in fact in violation of copyright claims. In such a case, the owners of libqt would have to sue the commercial application writer, not the other way around. There haven't been any such cases, mostly because (a) the FUD generated by the FSF about GPL vs. LGPL has generally been enough to cause application authors to avoid using GPL'ed code even if it would be legally defensible in court, and (b) I personally suspect that the FSF has deliberately not tried to make a test case out of a commercial application dynamically linking against a GPL'ed library. In point of fact, if you compile libss from e2fsprogs on a Solaris machine, and then let the Sun Enterprise Authentication Mechanism (a propietary version of Kerberos v5) link against that version of libss (as opposed to the one derived from the MIT Kerberos version of libss), you can have a propietary Sun binary linking against libss which will called will dynamically pull in the GPL'ed version of readline (or the BSD licensed editline library, whichever one it finds first in its search path). Quick! Is there a GPL violation involved, and if so, who should the FSF try to sue first? There are indeed plenty of cases where the GPL has been upheld in a court of law, but usually it's some straightforward case of an embedded version of Linux being used without releasing source. As far as I know, there has been no case on point about GPL and dynamic linking, and I personally suspect it's at least partially because the FSF is afraid it would lose such a case. (As I've said, at least one law professor of mine from the MIT Sloan School of Management has told me that in her opinion the FSF's theory would be "laughed out of court"). - Ted ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-16 21:01 ` Linus Torvalds 2006-12-17 0:22 ` Ricardo Galli @ 2006-12-17 13:54 ` Alexandre Oliva 2006-12-17 15:56 ` Ricardo Galli ` (2 more replies) 1 sibling, 3 replies; 59+ messages in thread From: Alexandre Oliva @ 2006-12-17 13:54 UTC (permalink / raw) To: Linus Torvalds; +Cc: Ricardo Galli, linux-kernel On Dec 16, 2006, Linus Torvalds <torvalds@osdl.org> wrote: > The whole reason the LGPL exists is that people realized that if they > don't do something like that, the GPL would have been tried in court, and > the FSF's position that anything that touches GPL'd code would probably > have been shown to be bogus. Or that people would feel uncomfortable about the gray area and avoid using the GPLed code in cases in which this would be perfectly legal and advantageous to Free Software. Sure enough, when people create and distribute proprietary code by taking advantage of Free Software, that's something to be avoided, but since there are other Free Software licenses that are not compatible with the GNU GPL, it made sense to enable software licensed under them to be combined with these few libraries. Letting concerns about copyright infringement, be such acts permissible by law or not, scare Free Software developers away from Free Software was not good for Free Software. > Do you REALLY believe that a binary becomes a "derived work" of any random > library that it gets linked against? If that's not "fair use" of a library > that implements a standard library definition, I don't know what is. There are many factors involved and you're oversimplifying the issue. Some claim that, in the case of static linking, since there part of the library copied to the binary, it is definitely a case of derived work. Some then take this notion that linking creates derived works and further extend the claim that using dynamic linking is just a trick to avoid making the binary a derived work, and thus it shouldn't be taken into account, even if there still is *some* information from the dynamic library that affects the linked binary. Others then introduce exceptions such as the existence of another implementation of the library that is binary- and license-compatible, and that thus might make the license of the library actually used to create the binary irrelevant. Some disregard the fact that header files sometimes aren't just interface definitions, but they also contain functional code, in the form of preprocessor macros and inline functions, that, if used, do make it to the binary. All of these arguments have their strengths and weaknesses. As you and others point out, and it matches my personal knowledge, none of them has been tried in court, and the outcome of a court dispute will often depend on specifics anyway. So calling these arguments idiocy is as presumptuous as FSF's alleged behavior. While at that, I feel you allegation is groundless, and I hope this message makes it clear why, so I wish you'd take it back. The gray area between what is clearly permitted by a license and the murky lines that determine what constitutes a derived work, and what is fair use even if it's a derived work, is not for any of us to decide. The best we can do is to offer interpretations on intent of license authors and software authors, and of laws. Even though we're not lawyers or judges, such interpretations may be taken into account in court disputes. When the FSF says a license does not permit such and such behavior, you apparently interpret that as a statement that the FSF thinks this behavior wouldn't be permissible by fair use either. This is an incorrect interpretation. As we've seen above, there *is* a gray area beyond what is permitted by the license. But the FSF must not give anyone the impression that the *license* permits actions that would make it less effective in fulfilling its intent, this would just weaken the license. Similarly, when you make an unqualified statement that some action is permitted, because you mean it's permitted by fair use even if not by the license, this might be mis-interpreted as something explicitly permitted by the license. So this weakens the license, one of our most valuable tools to make the world a better place. Is this what you intend to do? I hope not. Thanks, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 13:54 ` GPL only modules Alexandre Oliva @ 2006-12-17 15:56 ` Ricardo Galli 2006-12-17 16:25 ` Kyle Moffett 2006-12-17 17:59 ` Linus Torvalds 2 siblings, 0 replies; 59+ messages in thread From: Ricardo Galli @ 2006-12-17 15:56 UTC (permalink / raw) To: Alexandre Oliva; +Cc: linux-kernel On Sunday 17 December 2006 14:54, Alexandre Oliva wrote: > > The whole reason the LGPL exists is that people realized that if they > > don't do something like that, the GPL would have been tried in court, and > > the FSF's position that anything that touches GPL'd code would probably > > have been shown to be bogus. > > Or that people would feel uncomfortable about the gray area and avoid > using the GPLed code in cases in which this would be perfectly legal > and advantageous to Free Software. Sure enough, when people create > and distribute proprietary code by taking advantage of Free Software, > that's something to be avoided, but since there are other Free > Software licenses that are not compatible with the GNU GPL, it made > sense to enable software licensed under them to be combined with these > few libraries. Letting concerns about copyright infringement, be such > acts permissible by law or not, scare Free Software developers away > from Free Software was not good for Free Software. LGPL somehow fixes this gray area to allow a wider and clear "fair use" by allowing people to easily[*] run proprietary programs in a free operating system. [*] In the sense they don't need to compile/link the program themselves, which is clearly legal under the GPL and the FSF intentions (freedom #0). So, people that just worries about "fair use" could interpret it --besides the "official" arguments- as a message that makes clear FSF is not trying to push his agenda into the gray areas of copyright laws. But the very same evidence is used to loudly support an opposite interpretation of FSF [evil] intentions, to weaken the legal strength of the GPL, and to accuse FSF of pushing some hidden and insane arguments. Presumptuous, to say the least. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 13:54 ` GPL only modules Alexandre Oliva 2006-12-17 15:56 ` Ricardo Galli @ 2006-12-17 16:25 ` Kyle Moffett 2006-12-17 21:32 ` David Schwartz 2006-12-18 19:41 ` Alexandre Oliva 2006-12-17 17:59 ` Linus Torvalds 2 siblings, 2 replies; 59+ messages in thread From: Kyle Moffett @ 2006-12-17 16:25 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Linus Torvalds, Ricardo Galli, linux-kernel On Dec 17, 2006, at 08:54:17, Alexandre Oliva wrote: > On Dec 16, 2006, Linus Torvalds <torvalds@osdl.org> wrote: >> Do you REALLY believe that a binary becomes a "derived work" of >> any random library that it gets linked against? If that's not >> "fair use" of a library that implements a standard library >> definition, I don't know what is. > > Some disregard the fact that header files sometimes aren't just > interface definitions, but they also contain functional code, in > the form of preprocessor macros and inline functions, that, if > used, do make it to the binary. I would argue that this is _particularly_ pertinent with regards to Linux. For example, if you look at many of our atomics or locking operations a good number of them (depending on architecture and version) are inline assembly that are directly output into the code which uses them. As a result any binary module which uses those functions from the Linux headers is fairly directly a derivative work of the GPL headers because it contains machine code translated literally from GPLed assembly code found therein. There are also a fair number of large perhaps-wrongly inline functions of which the use of any one would be likely to make the resulting binary "derivative". On the other hand, certain projects like OpenAFS, while not license- compatible, are certainly not derivative works. The project was created independently of Linux and operates on several different operating systems, so even though it uses the very-Linux-specific keyring interfaces under 2.6, no GPL licensing could possibly apply. > The gray area between what is clearly permitted by a license and > the murky lines that determine what constitutes a derived work, and > what is fair use even if it's a derived work, is not for any of us > to decide. The best we can do is to offer interpretations on intent > of license authors and software authors, and of laws. Even though > we're not lawyers or judges, such interpretations may be taken into > account in court disputes. I agree, and I think that this thread has outlived its useful life. Cheers, Kyle Moffett ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-17 16:25 ` Kyle Moffett @ 2006-12-17 21:32 ` David Schwartz 2006-12-17 21:46 ` D. Hazelton 2006-12-18 19:41 ` Alexandre Oliva 1 sibling, 1 reply; 59+ messages in thread From: David Schwartz @ 2006-12-17 21:32 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org > I would argue that this is _particularly_ pertinent with regards to > Linux. For example, if you look at many of our atomics or locking > operations a good number of them (depending on architecture and > version) are inline assembly that are directly output into the code > which uses them. As a result any binary module which uses those > functions from the Linux headers is fairly directly a derivative work > of the GPL headers because it contains machine code translated > literally from GPLed assembly code found therein. There are also a > fair number of large perhaps-wrongly inline functions of which the > use of any one would be likely to make the resulting binary > "derivative". That's not protectable expression under United States law. See Lexmark v. Static Controls and the analogous case of the TLP (ignore the DMCA stuff in that case, that's not relevant). If you want to make that kind of content protectable, you have to get it out of the header files. You cannot protect, by copyright, every reasonably practical way of performing a function. Only a patent can do that. If taking something is reasonably necessary to express a particular idea (and a Linux module for the ATI X850 card is an idea), then that something cannot be protected by copyright when it is used to express that idea. (Even if it would clearly be protectably expression in another context.) The premise of copyright is that there are millions of equally-good ways to express the same idea or perform the same function, and you creatively pick one, and that choice is protected. But if I'm developing a Linux module for a particular network card, choosing to use the Linux kernel header files is the only practical choice to perform that particular function. So their content is not protectable when used in that context. (If you make another way to do it, then the content becomes protectable in that context again.) IANAL. DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 21:32 ` David Schwartz @ 2006-12-17 21:46 ` D. Hazelton 2006-12-18 15:47 ` Dave Neuer 2006-12-18 17:16 ` David Schwartz 0 siblings, 2 replies; 59+ messages in thread From: D. Hazelton @ 2006-12-17 21:46 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On Sunday 17 December 2006 16:32, David Schwartz wrote: > > I would argue that this is _particularly_ pertinent with regards to > > Linux. For example, if you look at many of our atomics or locking > > operations a good number of them (depending on architecture and > > version) are inline assembly that are directly output into the code > > which uses them. As a result any binary module which uses those > > functions from the Linux headers is fairly directly a derivative work > > of the GPL headers because it contains machine code translated > > literally from GPLed assembly code found therein. There are also a > > fair number of large perhaps-wrongly inline functions of which the > > use of any one would be likely to make the resulting binary > > "derivative". > > That's not protectable expression under United States law. See Lexmark v. > Static Controls and the analogous case of the TLP (ignore the DMCA stuff in > that case, that's not relevant). If you want to make that kind of content > protectable, you have to get it out of the header files. > > You cannot protect, by copyright, every reasonably practical way of > performing a function. Only a patent can do that. If taking something is > reasonably necessary to express a particular idea (and a Linux module for > the ATI X850 card is an idea), then that something cannot be protected by > copyright when it is used to express that idea. (Even if it would clearly > be protectably expression in another context.) > > The premise of copyright is that there are millions of equally-good ways to > express the same idea or perform the same function, and you creatively pick > one, and that choice is protected. But if I'm developing a Linux module for > a particular network card, choosing to use the Linux kernel header files is > the only practical choice to perform that particular function. So their > content is not protectable when used in that context. (If you make another > way to do it, then the content becomes protectable in that context again.) > > IANAL. > > DS Agreed. You missed the point. Since the Linux Kernel header files contain a chunk of the source code for the kernel in the form of the macros for locking et. al. then using the headers - including that code in your module - makes it a derivative work. Actually, thinking about it, the way a Linux driver module works actually seems to make *ANY* driver a derivative work, because they are loaded into the kernels memory space and cannot function without having that done. *IF* the "Usermode Driver" interface that is being worked on ever proves useful then, and only then, could you consider it *NOT* a derivative work. Because then the only thing it is using *IS* an interface, not complete chunks of the source as generated when the pre-processor finishes running through the file. But as David said - IANAL D. Hazelton ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 21:46 ` D. Hazelton @ 2006-12-18 15:47 ` Dave Neuer 2006-12-18 17:46 ` D. Hazelton 2006-12-18 17:16 ` David Schwartz 1 sibling, 1 reply; 59+ messages in thread From: Dave Neuer @ 2006-12-18 15:47 UTC (permalink / raw) To: D. Hazelton; +Cc: davids, Linux-Kernel@Vger. Kernel. Org On 12/17/06, D. Hazelton <dhazelton@enter.net> wrote: > On Sunday 17 December 2006 16:32, David Schwartz wrote: > > > I would argue that this is _particularly_ pertinent with regards to > > > Linux. For example, if you look at many of our atomics or locking > > > operations a good number of them (depending on architecture and > > > version) are inline assembly that are directly output into the code > > > which uses them. As a result any binary module which uses those > > > functions from the Linux headers is fairly directly a derivative work > > > of the GPL headers because it contains machine code translated > > > literally from GPLed assembly code found therein. There are also a > > > fair number of large perhaps-wrongly inline functions of which the > > > use of any one would be likely to make the resulting binary > > > "derivative". > > > > That's not protectable expression under United States law. See Lexmark v. > > Static Controls and the analogous case of the TLP (ignore the DMCA stuff in > > that case, that's not relevant). If you want to make that kind of content > > protectable, you have to get it out of the header files. > > > > You cannot protect, by copyright, every reasonably practical way of > > performing a function. Only a patent can do that. If taking something is > > reasonably necessary to express a particular idea (and a Linux module for > > the ATI X850 card is an idea), then that something cannot be protected by > > copyright when it is used to express that idea. (Even if it would clearly > > be protectably expression in another context.) > > > > The premise of copyright is that there are millions of equally-good ways to > > express the same idea or perform the same function, and you creatively pick > > one, and that choice is protected. But if I'm developing a Linux module for > > a particular network card, choosing to use the Linux kernel header files is > > the only practical choice to perform that particular function. So their > > content is not protectable when used in that context. (If you make another > > way to do it, then the content becomes protectable in that context again.) > > > > IANAL. > > > > DS > > Agreed. You missed the point. Since the Linux Kernel header files contain a > chunk of the source code for the kernel in the form of the macros for locking > et. al. then using the headers - including that code in your module - makes > it a derivative work. David didn't miss the point; Lexmark vs. Static Controls, however unintuitively, ruled that even _verbatim_ copying is not always copyright infringement in the case of software because of issues like the doctrine of scenes a faire. In the case of spinlocks, if the only way to accomplish atomic operations on an architecture is to use something like the assembler that the inclusion of spinlock.h injects into your binary, then according to Lexmark vs. Static Controls that makes that included code unprotectable by copyright. Where I disagree with David (as I have publicly before on this list), is that he incorrectly applies the concept of "functional idea" to "write a linux kernel module." I don't believe that is a "functional idea" in the sense that is meaningful in the context of software copyright or patents (at least until someone writes a piece of software that writes kernel modules). Dave ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 15:47 ` Dave Neuer @ 2006-12-18 17:46 ` D. Hazelton 2006-12-18 21:01 ` Dave Neuer 0 siblings, 1 reply; 59+ messages in thread From: D. Hazelton @ 2006-12-18 17:46 UTC (permalink / raw) To: Dave Neuer; +Cc: davids, Linux-Kernel@Vger. Kernel. Org On Monday 18 December 2006 10:47, Dave Neuer wrote: > On 12/17/06, D. Hazelton <dhazelton@enter.net> wrote: > > On Sunday 17 December 2006 16:32, David Schwartz wrote: > > > > I would argue that this is _particularly_ pertinent with regards to > > > > Linux. For example, if you look at many of our atomics or locking > > > > operations a good number of them (depending on architecture and > > > > version) are inline assembly that are directly output into the code > > > > which uses them. As a result any binary module which uses those > > > > functions from the Linux headers is fairly directly a derivative work > > > > of the GPL headers because it contains machine code translated > > > > literally from GPLed assembly code found therein. There are also a > > > > fair number of large perhaps-wrongly inline functions of which the > > > > use of any one would be likely to make the resulting binary > > > > "derivative". > > > > > > That's not protectable expression under United States law. See Lexmark > > > v. Static Controls and the analogous case of the TLP (ignore the DMCA > > > stuff in that case, that's not relevant). If you want to make that kind > > > of content protectable, you have to get it out of the header files. > > > > > > You cannot protect, by copyright, every reasonably practical way of > > > performing a function. Only a patent can do that. If taking something > > > is reasonably necessary to express a particular idea (and a Linux > > > module for the ATI X850 card is an idea), then that something cannot be > > > protected by copyright when it is used to express that idea. (Even if > > > it would clearly be protectably expression in another context.) > > > > > > The premise of copyright is that there are millions of equally-good > > > ways to express the same idea or perform the same function, and you > > > creatively pick one, and that choice is protected. But if I'm > > > developing a Linux module for a particular network card, choosing to > > > use the Linux kernel header files is the only practical choice to > > > perform that particular function. So their content is not protectable > > > when used in that context. (If you make another way to do it, then the > > > content becomes protectable in that context again.) > > > > > > IANAL. > > > > > > DS > > > > Agreed. You missed the point. Since the Linux Kernel header files contain > > a chunk of the source code for the kernel in the form of the macros for > > locking et. al. then using the headers - including that code in your > > module - makes it a derivative work. > > David didn't miss the point; Lexmark vs. Static Controls, however > unintuitively, ruled that even _verbatim_ copying is not always > copyright infringement in the case of software because of issues like > the doctrine of scenes a faire. In the case of spinlocks, if the only > way to accomplish atomic operations on an architecture is to use > something like the assembler that the inclusion of spinlock.h injects > into your binary, then according to Lexmark vs. Static Controls that > makes that included code unprotectable by copyright. Ah, okay. However I'm quite sure that there are more ways to accomplish the tasks handled by the code in the header files (in most cases). > Where I disagree with David (as I have publicly before on this list), > is that he incorrectly applies the concept of "functional idea" to > "write a linux kernel module." I don't believe that is a "functional > idea" in the sense that is meaningful in the context of software > copyright or patents (at least until someone writes a piece of > software that writes kernel modules). Agreed. And thanks for clarifying that. DRH ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 17:46 ` D. Hazelton @ 2006-12-18 21:01 ` Dave Neuer 0 siblings, 0 replies; 59+ messages in thread From: Dave Neuer @ 2006-12-18 21:01 UTC (permalink / raw) To: D. Hazelton; +Cc: davids, Linux-Kernel@Vger. Kernel. Org On 12/18/06, D. Hazelton <dhazelton@enter.net> wrote: > > Ah, okay. However I'm quite sure that there are more ways to accomplish the > tasks handled by the code in the header files (in most cases). Well, that may be so. Unfortunately, Lexmark vs. Static Controls actually says that even if there are other ways, if those ways are far less optimal, the result is as if there were only one way. I think the decision is part of one big, giant mess that is US IP law as it relates to software. Dave ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-17 21:46 ` D. Hazelton 2006-12-18 15:47 ` Dave Neuer @ 2006-12-18 17:16 ` David Schwartz 2006-12-19 6:35 ` D. Hazelton 1 sibling, 1 reply; 59+ messages in thread From: David Schwartz @ 2006-12-18 17:16 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org Combined responses to save bandwidth and reduce the number of times people have to press "d". > Agreed. You missed the point. I don't understand how you could lead with "agreed" and then proceed to completely ignore the entire point I just made. > Since the Linux Kernel header files > contain a > chunk of the source code for the kernel in the form of the macros > for locking > et. al. then using the headers - including that code in your > module - makes > it a derivative work. No, it does not. The header files are purely function and not expressive in this case. Copyright only protects one choice among many equally-practical choices for expressing the same idea or performing the same function. > Actually, thinking about it, the way a Linux driver module works actually > seems to make *ANY* driver a derivative work, because they are > loaded into > the kernels memory space and cannot function without having that done. If every practical way of expressing an idea contains something, then that something is *not* protectable when used to express an idea of that kind. > *IF* the "Usermode Driver" interface that is being worked on ever proves > useful then, and only then, could you consider it *NOT* a > derivative work. > Because then the only thing it is using *IS* an interface, not complete > chunks of the source as generated when the pre-processor finishes running > through the file. No, you have it completely backwards. If a usermode driver interface was equally practical to develop a particular type of driver, then using the kernel headers would make the driver a derivative work. Because, in that case, the choice to use the kernel headers would be a creative choice -- one chosen method among many equally practical one. Copyright only protects creative choices, not purely functional ones. "A Linux 2.6 driver for the ATI X800 graphics chipset" is an idea. If the only reasonably practical way to express that idea is with the Linux kernel header files, then using the Linux kernel header files is scenes a fair, not protected content. For example, you cannot discuss the Napeleonic wars with using the word "Napoleon", at least, not nearly as well. So nobody can claim copyright on the word "Napoleon" when used to describe those wars because it is deomnstrably *superior*. Only patents protect "best ways". Copyrights protected "the way I choose among thousands of equally-good ways". See Lexmark v. Static Controls and the Sega and Atari cases. This is clearly a cases where "[w]hile, hypothetically, there might be a myriad of ways in which a programmer may effectuate certain functions within a program . . . efficiency concerns may so narrow the practical range of choice as to make only one or two forms of expression workable options." "In order to characterize a choice between alleged programming alternatives as expressive, in short, the alternatives must be feasible within real-world constraints." The inclusion of the kernel header files in a kernel module is not expressive, it's purely functional. The kernel header files are simply not protectable expression when used in a kernel module. - >The difference - really - at least for static linking - is that "ln" >makes modifications to each piece to make them work together, and in >the case of a library, makes a selection of the parts of the library >as needed by the rest of the program. What ends up in the executable >is not just a set of verbatim copies of the input files packed >together, but rather a single program where the various parts have >been modified so as to fit together and create a whole. Thus it seems >quite reasonable to me to say that a statically linked binary is a >derived work of all of the object files and libraries that were linked >together to form it. IANAL, of course. The linker makes no creative choices, so it does not produce a "work" for copyright purposes. If it does not even produce a work, it cannot produce a derivative work. The question is not whether the combination is verbatim or transformative but whether it is creative or mechanical. The linker combines things in a mechanical and purely functional way. A tar/gzip does the same thing. The compressed output for the third file may be as dependent on the content of the second file as on the content of the third file and in a very real sense will contain aspects of both of their structures. "Mere aggregation" does not mean a literal splicing of the raw code for two or more files. It means a purely functional combination dictated completely by technical concerns and lacking any creative input. DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 17:16 ` David Schwartz @ 2006-12-19 6:35 ` D. Hazelton 2006-12-19 16:39 ` David Lang 0 siblings, 1 reply; 59+ messages in thread From: D. Hazelton @ 2006-12-19 6:35 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On Monday 18 December 2006 12:16, David Schwartz wrote: > Combined responses to save bandwidth and reduce the number of times people > have to press "d". > > > Agreed. You missed the point. > > I don't understand how you could lead with "agreed" and then proceed to > completely ignore the entire point I just made. I *initially* thought you had missed the point. After your later post clarifying things I saw that my statement had been in error and that I did agree with you completely. > > Since the Linux Kernel header files > > contain a > > chunk of the source code for the kernel in the form of the macros > > for locking > > et. al. then using the headers - including that code in your > > module - makes > > it a derivative work. > > No, it does not. The header files are purely function and not expressive in > this case. Copyright only protects one choice among many equally-practical > choices for expressing the same idea or performing the same function. In this case, well. We aren't talking Copyright, but the license under which the software is distributed. According to the USPTO placing a statement such as (c) 2006 Pornrat Watanabe on a work you have created automatially places it under a copyright. The kernel source code, copyrighted as it is, is then distributed under the terms of the GNU GPL. Using the code from the header files may not make the module a derivative, but it is including parts of a copyrighted work. By *NOT* complying with the license under which said copyrighted work is distributed, you are giving up your rights under the license. This doesn't negate any problems with people making Blob drivers, because, as you pointed out, under the same laws they aren't a derivative work, which means that that clause of the license doesn't apply. Now if the GPL contained a clause specifically defining what it considered a derivative work things would be different. > > Actually, thinking about it, the way a Linux driver module works actually > > seems to make *ANY* driver a derivative work, because they are > > loaded into > > the kernels memory space and cannot function without having that done. > > If every practical way of expressing an idea contains something, then that > something is *not* protectable when used to express an idea of that kind. Not what I was saying. There are any number of ways to make a driver function - the FUSE system has shown that clearly. But by making that driver one that is loaded directly into the kernels memory space... It's that act that *I* *FEEL* makes it a derivative work. > > *IF* the "Usermode Driver" interface that is being worked on ever proves > > useful then, and only then, could you consider it *NOT* a > > derivative work. > > Because then the only thing it is using *IS* an interface, not complete > > chunks of the source as generated when the pre-processor finishes running > > through the file. > > No, you have it completely backwards. No, you missed my point. I was saying that the Usermode Driver interface would make the current style of kernel modules fully derivative works. This being because they are using an open system interface and *NOT* including code distributed with the kernel. > If a usermode driver interface was equally practical to develop a > particular type of driver, then using the kernel headers would make the > driver a derivative work. Because, in that case, the choice to use the > kernel headers would be a creative choice -- one chosen method among many > equally practical one. And this is what I was saying. Perhaps I didn't state it in clear and concise english. > Copyright only protects creative choices, not purely functional ones. > > "A Linux 2.6 driver for the ATI X800 graphics chipset" is an idea. If the > only reasonably practical way to express that idea is with the Linux kernel > header files, then using the Linux kernel header files is scenes a fair, > not protected content. Okay. I understood this back at the start of your reply. <snip> > DS Okay, after a lot of thought and me realizing some mistakes I had made in interpreting the law and legal precedents I see we are on the same page. DRH ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 6:35 ` D. Hazelton @ 2006-12-19 16:39 ` David Lang 0 siblings, 0 replies; 59+ messages in thread From: David Lang @ 2006-12-19 16:39 UTC (permalink / raw) To: D. Hazelton; +Cc: davids, Linux-Kernel@Vger. Kernel. Org On Tue, 19 Dec 2006, D. Hazelton wrote: > This doesn't negate any problems with people making Blob drivers, because, as > you pointed out, under the same laws they aren't a derivative work, which > means that that clause of the license doesn't apply. Now if the GPL contained > a clause specifically defining what it considered a derivative work things > would be different. incorrect, the GPL (or any other license) cannot define what is a derived work, the law does that. they could have a clause in them that said that something that is a derived work under the law is not considered a derived work by the author (implicitly giving unrestricted permission to that something), but you cannot define something that the law doesn't consider a derived work to be one in the license. David Lang ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 16:25 ` Kyle Moffett 2006-12-17 21:32 ` David Schwartz @ 2006-12-18 19:41 ` Alexandre Oliva 2006-12-18 22:14 ` Christoph Hellwig 2006-12-19 3:42 ` D. Hazelton 1 sibling, 2 replies; 59+ messages in thread From: Alexandre Oliva @ 2006-12-18 19:41 UTC (permalink / raw) To: Kyle Moffett; +Cc: Linus Torvalds, Ricardo Galli, linux-kernel On Dec 17, 2006, Kyle Moffett <mrmacman_g4@mac.com> wrote: > On the other hand, certain projects like OpenAFS, while not license- > compatible, are certainly not derivative works. Certainly a big chunk of OpenAFS might not be, just like a big chunk of other non-GPL drivers for Linux. But what about the glue code? Can that be defended as not a derived work, such that it doesn't have to be GPL? If not, can the whole containing both the non-derivative work and the source code providing the glue without which the whole wouldn't fulfill its intended purpose be regarded as a mere aggregate, and thus not be subject to the requirement that the whole be released under the GPL? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 19:41 ` Alexandre Oliva @ 2006-12-18 22:14 ` Christoph Hellwig 2006-12-19 3:42 ` D. Hazelton 1 sibling, 0 replies; 59+ messages in thread From: Christoph Hellwig @ 2006-12-18 22:14 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Kyle Moffett, Linus Torvalds, Ricardo Galli, linux-kernel On Mon, Dec 18, 2006 at 05:41:17PM -0200, Alexandre Oliva wrote: > On Dec 17, 2006, Kyle Moffett <mrmacman_g4@mac.com> wrote: > > > On the other hand, certain projects like OpenAFS, while not license- > > compatible, are certainly not derivative works. > > Certainly a big chunk of OpenAFS might not be, just like a big chunk > of other non-GPL drivers for Linux. > > But what about the glue code? Can that be defended as not a derived > work, such that it doesn't have to be GPL? Actually the OpenAFS kernel code almost 100% is a derived work of both the original AFS codebase and Linux. Just go and take a look at it, there's shitloads of copy & paste and very deep poking into kernel internals. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 19:41 ` Alexandre Oliva 2006-12-18 22:14 ` Christoph Hellwig @ 2006-12-19 3:42 ` D. Hazelton 2006-12-20 1:02 ` Alexandre Oliva 1 sibling, 1 reply; 59+ messages in thread From: D. Hazelton @ 2006-12-19 3:42 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Kyle Moffett, Linus Torvalds, Ricardo Galli, linux-kernel On Monday 18 December 2006 14:41, Alexandre Oliva wrote: > On Dec 17, 2006, Kyle Moffett <mrmacman_g4@mac.com> wrote: > > On the other hand, certain projects like OpenAFS, while not license- > > compatible, are certainly not derivative works. > > Certainly a big chunk of OpenAFS might not be, just like a big chunk > of other non-GPL drivers for Linux. > > But what about the glue code? Can that be defended as not a derived > work, such that it doesn't have to be GPL? That has never been an issue, really. Its what 99% of the binary drivers believe - hence the reason that there is the user-compiled component to all of them. > If not, can the whole containing both the non-derivative work and the > source code providing the glue without which the whole wouldn't > fulfill its intended purpose be regarded as a mere aggregate, and thus > not be subject to the requirement that the whole be released under the > GPL? The view that binary vendors take is "Linking does not create a derived work" - regardless of the fact that you cannot have a complete compiled program or module *WITHOUT* that linking. However I have a feeling that the lawyers in the employ of the companies that ship BLOB drivers say that all they need to do to comply with the GPL is to ship the glue-code in source form. And I have to admit that this does seem to comply with the GPL - to the letter, if not the spirit. DRH ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 3:42 ` D. Hazelton @ 2006-12-20 1:02 ` Alexandre Oliva 2006-12-20 23:28 ` Scott Preece 0 siblings, 1 reply; 59+ messages in thread From: Alexandre Oliva @ 2006-12-20 1:02 UTC (permalink / raw) To: D. Hazelton; +Cc: Kyle Moffett, Linus Torvalds, Ricardo Galli, linux-kernel On Dec 19, 2006, "D. Hazelton" <dhazelton@enter.net> wrote: > However I have a feeling that the lawyers in the employ of the > companies that ship BLOB drivers say that all they need to do to > comply with the GPL is to ship the glue-code in source form. > And I have to admit that this does seem to comply with the GPL - to the > letter, if not the spirit. I don't see that it does comply even with the letter. Consider this: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not 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 work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. The work, in this case, is the GPLed glue code, in source form, and the binary blob, without sources. See that, even though the binary blob is an independent and separate work in itself, and so it can indeed be distributed separaly under a different license, when it's distributed as part of a whole, then the whole must be on the terms of the GPL. So the question becomes whether the copyright holder of the glue code bound by these GPL terms. (a) If the glue code can be shown to be a derived work from Linux, even in source form, then the copyright holder *is* bound by these terms, and thus the whole could only be distributed under the GPL, so including the binary blob would be in violation of the license. (b) Now, if the glue code is *not* a derived work from Linux, then the copyright holder is entitled to use whatever terms she likes. It could be any license whatsoever, that permits the distribution of the whole or of the parts with whatever constraints copyright law permitted. Why would they choose the GPL in this case, then? Let's assume they're not intentionally violating the GPL, but rather that they believe they're entitled to do what they're doing, i.e., that they believe (a) their glue code is not a derived work from Linux. In this case, they *can* distribute the glue source code under the GPL along with their binary blob. But can anyone else? Methinks anyone else would be entitled to pass the same whole along under the GPL, per section 1, but wouldn't be entitled to distribute modified versions, because this would require the derived work to be licensed under the GPL, and nobody else is able to provide the source code to the binary blob. And then, who'd be entitled to complain? Only the copyright holder of the glue code and the binary blob. Would you like to be on the wrong end of a copyright infringement lawsuit by one of these binary blob distributors for distributing a patched version of their glue code + binary blob? More to the point, do you think they would actually bring suit, just to make it clear that the whole point is for them to keep a monopoly on the rights to modify and then distribute the combined work, in spite of using the GPL for (part of) the work? It gets trickier for binaries, since they are quite possibly derived works from the kernel, licensed under the GPL. If they are, they can't be distributed at all, not even by the copyright holder of the glue code + binary blob. If they aren't, then the copyright holder can distribute them, but nobody else can because that would be a violation of the GPL, as in the discussion above. So, the copyright holder would be keeping a monopoly on the rights to distribute binaries, and anyone else could be sued by them. Sure enough, one might think of praising them for distributing the glue code under the GPL. Then others could take this glue code and use it for something else that is useful, right? Well... Not quite. For one, even if enabling others to distribute glue code + binary blobs were a good thing, using somebody else's glue code means you're bound by the GPL requirements, so you can't ship the combination of the glue code with your binary blob. And then, if you intend to use the glue code to plug in some other code that is GPL-compatible in the kernel, perhaps you'd be better off not using the glue code at all, but rather modifying the GPL-compatible code to fit. So, even if condoning binary blobs were morally acceptable, we still wouldn't be gaining anything from this relationship, we'd only be enabling vendors to sell us their undocumented hardware while denying us our freedoms. Why should we do this? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-20 1:02 ` Alexandre Oliva @ 2006-12-20 23:28 ` Scott Preece 0 siblings, 0 replies; 59+ messages in thread From: Scott Preece @ 2006-12-20 23:28 UTC (permalink / raw) To: Alexandre Oliva Cc: D. Hazelton, Kyle Moffett, Linus Torvalds, Ricardo Galli, linux-kernel On 12/19/06, Alexandre Oliva <aoliva@redhat.com> wrote: > On Dec 19, 2006, "D. Hazelton" <dhazelton@enter.net> wrote: > > > However I have a feeling that the lawyers in the employ of the > > companies that ship BLOB drivers say that all they need to do to > > comply with the GPL is to ship the glue-code in source form. > > > And I have to admit that this does seem to comply with the GPL - to the > > letter, if not the spirit. > > I don't see that it does comply even with the letter. Consider this: > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the Program, > and can be reasonably considered independent and separate works in > themselves, then this License, and its terms, do not 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 work > based on the Program, the distribution of the whole must be on the > terms of this License, whose permissions for other licensees extend > to the entire whole, and thus to each and every part regardless of > who wrote it. > > The work, in this case, is the GPLed glue code, in source form, and > the binary blob, without sources. See that, even though the binary > blob is an independent and separate work in itself, and so it can > indeed be distributed separaly under a different license, when it's > distributed as part of a whole, then the whole must be on the terms of > the GPL. --- The question is what "the whole work" is. If the binary is not a derived work, and is not prelinked with the work, then it seems likely to be considered merely an aggregation, not requiring GPL licensing. Note that there's some difficulty in the language, in that the GPL uses "work based on the work" to mean something that it defines specifically, while the Copyright Act defines "derived work" as "work based on the work". THere is no equivalence there - The GPL's "work based on the work" includes cases that do not fit the Act's definition. So, the GPL's requirement for licensing under the GPL clearly applies to prelinked binaries, but it is not at all clear that it would apply to a binary object, not derived from the kernel, shipped on the same media. That is, the aggregation is NOT a modification of the original work, it's just an aggregation (work of colective authorship). --- > ... > Let's assume they're not intentionally violating the GPL, but rather > that they believe they're entitled to do what they're doing, i.e., > that they believe (a) their glue code is not a derived work from > Linux. > > In this case, they *can* distribute the glue source code under the GPL > along with their binary blob. But can anyone else? > > Methinks anyone else would be entitled to pass the same whole along > under the GPL, per section 1, but wouldn't be entitled to distribute > modified versions, because this would require the derived work to be > licensed under the GPL, and nobody else is able to provide the source > code to the binary blob. --- I'm confused here. If the glue code is not a derived work, then they don't need to use the GPL at all. If they DO ue the GPL, then (as you note) if they didn't include the source code, nobody else could redistribute it because nobody else would be able to meet the license terms. I would expect that if they were going to GPL the glue code, they would also provide the source for it. --- >... > Well... Not quite. For one, even if enabling others to distribute > glue code + binary blobs were a good thing, using somebody else's glue > code means you're bound by the GPL requirements, so you can't ship the > combination of the glue code with your binary blob. --- Only if you assume that using the glue code would make your blob a derived work of the glue code. In many cases the point of the glue code is to be an adapter between Linux and an existing interface. In such a case, any binary blob using that interface would not be a derived work of the glue code. As before, though, if you linked the binary blob with the glue code object, then the combined object probably would be a derived work and have to conform to the GPL. --- > ... > So, even if condoning binary blobs were morally acceptable, we still > wouldn't be gaining anything from this relationship, we'd only be > enabling vendors to sell us their undocumented hardware while denying > us our freedoms. > > Why should we do this? --- To enable the use of the hardware in Linux systems? Most people would prefer well-documented hardware with free drivers, but when that isn't available, many people might still like to be able to use the hardware. It's less than ideal, but so is having no way at all to use the hardware. scott ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 13:54 ` GPL only modules Alexandre Oliva 2006-12-17 15:56 ` Ricardo Galli 2006-12-17 16:25 ` Kyle Moffett @ 2006-12-17 17:59 ` Linus Torvalds 2006-12-17 22:45 ` Paul Mackerras ` (2 more replies) 2 siblings, 3 replies; 59+ messages in thread From: Linus Torvalds @ 2006-12-17 17:59 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Ricardo Galli, linux-kernel On Sun, 17 Dec 2006, Alexandre Oliva wrote: > On Dec 16, 2006, Linus Torvalds <torvalds@osdl.org> wrote: > > > > The whole reason the LGPL exists is that people realized that if they > > don't do something like that, the GPL would have been tried in court, and > > the FSF's position that anything that touches GPL'd code would probably > > have been shown to be bogus. > > Or that people would feel uncomfortable about the gray area and avoid > using the GPLed code in cases in which this would be perfectly legal > and advantageous to Free Software. I agree. A lot of it is about "comfort". But you can _easily_ handle that comfort level in other ways. For example, many programs already do have clarifications that certain uses do not introduce any GPL dependency what-so-ever. The kernel COPYING makes it clear that user space is not a derived work of the kernel, for example. You don't actually need to use a different license for this case: if all you're looking for is "comfort", then you really can comfort people other ways. For example, glibc could easily have just come out and said the thing that is obvious to any sane person: "using this library as just a standard library does not make your program a derived work". There really wassn't much need for the LGPL, I think. > There are many factors involved and you're oversimplifying the issue. Sure. It's never clear-cut. It's never black and white. > Some claim that, in the case of static linking, since there part of > the library copied to the binary, it is definitely a case of derived > work. No, the sane way to think about it is that linking just creates an "aggregate" work. It's no less "aggregate" than creating a CD-ROM that contains the library and some random program: you "link" them together with "mkisofs". Why do people think that using "ln" is _any_ different from using "mkisofs". Both create one file that contains multiple pieces. What's the difference - really? Of course, the _aggregate_ still needs permission from all the copyright holders in order to be distributed, that goes without saying. But the GPLv2 clearly allows aggregation. And don't get me wrong: I do not say that "linking" _never_ creates derived works. I'm just saying that "linking" is just a technical step, and as such is not the answer to whether something is derived or not. Things can be derived works of each other _without_ being linked, and they may not be derived works even if they _are_ linked. So "linking" basically has very little to do with "derived" per se. Linking does have one thing that it implies: it's maybe a bit "closer" relationship between the parts than "mkisofs" implies. So there is definitely a higher _correlation_ between "derived work" and "linking", but it's really a correlation, not a causal relationship. For example, if you link two object files together where neither is a "library" with standard interfaces, then the result is most likely a derived work from both. But it wasn't the "act of linking" that caused that to happen, but simply the fact that they were part of a bigger whole, and were meaningless apart from each other. Think of this in the sense of a book. Does binding pages together create a "derived work"? Not always: you can have anthologies (which are *aggregations* of works with *independent* copyright), and the binding of pages together didn't really do anything to the independent pieces. But clearly, if you're talking about individual pages in one story, then each individual page is not an independent work in itself. Linking is the same way. Are the two pieces you link "independent works" on their own? If so, the end result is really just an aggregate, no different from using "mkisofs". They are still clearly separable: you could have built either piece AGAINST SOMETHING ELSE. > Some then take this notion that linking creates derived works and > further extend the claim that using dynamic linking is just a trick to > avoid making the binary a derived work, and thus it shouldn't be taken > into account, even if there still is *some* information from the > dynamic library that affects the linked binary. See how this whole "trick" discussion becomes a totally moot point once you realize that "mkisofs" and "ld" aren't really all that different. Does "mkisofs" create a derived work, or an aggregate? Does "ld" create a derived work or an aggregate? The answer in BOTH cases is the same: it's not about the name of the command, or some technical detail about how the pieces are bound together. Copyright law doesn't concern itself with "mkisofs" vs "ld". It would be totally INSANE if it did, wouldn't you say? So if it isn't about "mkisofs" vs "ld", then _what_ is it about? I gave you one answer above. Feel free to make your own judgements. I'm just saying that anybody who thinks that copyright law cares about "mkisofs" vs "ld" is just obviously misguided. So I think the "dynamic vs static" linking argument is a red herring. It _is_ meaningful in two ways: - static linking obviously means that even at a MINIMUM, the result will _contain_ both things, so at a minimum, you do need the permission to distribute the pieces as parts of an aggregate work. In contrast, in dynamic linking, since you're not _actually_ distributing the thing you linked against, you don't need to have the license to distribute it as an aggregate work. This particular thing is a non-issue wrt the GPLv2, since you always have the right to do distribution of aggregates, but it does come up in some OTHER licenses. - you can (quite validly, in my opinion) argue that dynamic linking is a sign of separation, and as such if you're able to do dynamic linking against an unmodified second work, you have a much stronger argument that they really can be seen as two independent works. But notice how this was not a technical argument about the _linking_ per se: this comes back to a much more important (and much more fundamental) issue of whether things are independent (and being independent is certainly one _requirement_ for them not being derived works) In other words: the _ability_ to do dynamic linking is certainly meaningful, not because of the linking itself, but because of what it implies from a perspective of "independence". So to get back to the example of glibc: if a program _could_ have been linked against some other library, then that pretty clearly shows that it's really independent of glibc, and the linking is "mere aggregation" exactly the same way "mkisofs" is generally considered "mere aggregation". And that is actually true whether you link dynamically or statically. Since the GPLv2 allows aggregation, I think you can very much argue in front of a judge that you could have linked statically against even a GPL'd glibc. But notice how the thing changes if you talk about a specialized library like libqt - and notice how it again doesn't really matter whether you do dynamic or static linking. Libqt is still a work in its own right, but what about the program that links _to_ it? You can't generally really claim that it could equally well have been built against some other library, so now that program - whether linked dynamically or statically - obviously cannot stand on its own independently of libqt. As a result, something that links against libqt is very different from something that links against glibc. But note how it wasn't "static" vs "dynamic" that mattered AT ALL. What mattered was whether they had independent lives. And finally, in case it's not clear: I'm not a lawyer, and I don't play one on TV, and if I did, I'd be better looking and wouldn't spend my time on some technical discussion forum. So I'm not claiming that my viewpoint is "Right(tm)". But I _am_ claiming that it makes a hell of a lot more sense as a viewpoint than the "linking is magic" argument does. Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 17:59 ` Linus Torvalds @ 2006-12-17 22:45 ` Paul Mackerras 2006-12-18 6:50 ` Junio C Hamano 2006-12-18 15:38 ` Dave Neuer 2006-12-18 19:27 ` Alexandre Oliva 2 siblings, 1 reply; 59+ messages in thread From: Paul Mackerras @ 2006-12-17 22:45 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel Linus Torvalds writes: > Why do people think that using "ln" is _any_ different from using > "mkisofs". Both create one file that contains multiple pieces. What's the > difference - really? The difference - really - at least for static linking - is that "ln" makes modifications to each piece to make them work together, and in the case of a library, makes a selection of the parts of the library as needed by the rest of the program. What ends up in the executable is not just a set of verbatim copies of the input files packed together, but rather a single program where the various parts have been modified so as to fit together and create a whole. Thus it seems quite reasonable to me to say that a statically linked binary is a derived work of all of the object files and libraries that were linked together to form it. IANAL, of course. Dynamic linking is different, of course, if only because the final runnable program is never distributed, but only formed in memory during execution. Also, the shared libraries are not modified and incorporated during linking. Paul. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 22:45 ` Paul Mackerras @ 2006-12-18 6:50 ` Junio C Hamano 2006-12-18 23:16 ` Paul Mackerras 0 siblings, 1 reply; 59+ messages in thread From: Junio C Hamano @ 2006-12-18 6:50 UTC (permalink / raw) To: Paul Mackerras Cc: Linus Torvalds, Alexandre Oliva, Ricardo Galli, linux-kernel Paul Mackerras <paulus@samba.org> writes: > Linus Torvalds writes: > >> Why do people think that using "ln" is _any_ different from using >> "mkisofs". Both create one file that contains multiple pieces. What's the >> difference - really? > > The difference - really - at least for static linking - is that "ln" > makes modifications to each piece to make them work together, and in > the case of a library, makes a selection of the parts of the library > as needed by the rest of the program. Excuse me, but are you two discussing "ld"? ;-) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 6:50 ` Junio C Hamano @ 2006-12-18 23:16 ` Paul Mackerras 0 siblings, 0 replies; 59+ messages in thread From: Paul Mackerras @ 2006-12-18 23:16 UTC (permalink / raw) To: Junio C Hamano Cc: Linus Torvalds, Alexandre Oliva, Ricardo Galli, linux-kernel Junio C Hamano writes: > Excuse me, but are you two discussing "ld"? ;-) Oops. Yes. :) Paul. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 17:59 ` Linus Torvalds 2006-12-17 22:45 ` Paul Mackerras @ 2006-12-18 15:38 ` Dave Neuer 2006-12-18 17:02 ` Theodore Tso 2006-12-18 19:27 ` Alexandre Oliva 2 siblings, 1 reply; 59+ messages in thread From: Dave Neuer @ 2006-12-18 15:38 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel On 12/17/06, Linus Torvalds <torvalds@osdl.org> wrote: > > Linking does have one thing that it implies: it's maybe a bit "closer" > relationship between the parts than "mkisofs" implies. So there is > definitely a higher _correlation_ between "derived work" and "linking", > but it's really a correlation, not a causal relationship. > > But it wasn't the "act of linking" that caused > that to happen, but simply the fact that they were part of a bigger whole, > and were meaningless apart from each other. I think this is the key, both with libraries and w/ your book example below; the concept of independant "meaning." If your code doesn't do whatever it is supposed to do _unless_ it is linked with _my_ code, then it seems fairly clear that your code is derivative of mine, just as your sequel to my novel (or your pages added onto my book) don't "mean" anything if someone hasn't read mine. > > Think of this in the sense of a book. Does binding pages together create a > "derived work"? Not always: you can have anthologies (which are > *aggregations* of works with *independent* copyright), and the binding of > pages together didn't really do anything to the independent pieces. But > clearly, if you're talking about individual pages in one story, then each > individual page is not an independent work in itself. Dave ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 15:38 ` Dave Neuer @ 2006-12-18 17:02 ` Theodore Tso 2006-12-18 17:23 ` Dave Neuer 0 siblings, 1 reply; 59+ messages in thread From: Theodore Tso @ 2006-12-18 17:02 UTC (permalink / raw) To: Dave Neuer; +Cc: Linus Torvalds, Alexandre Oliva, Ricardo Galli, linux-kernel On Mon, Dec 18, 2006 at 10:38:38AM -0500, Dave Neuer wrote: > I think this is the key, both with libraries and w/ your book example > below; the concept of independant "meaning." If your code doesn't do > whatever it is supposed to do _unless_ it is linked with _my_ code, > then it seems fairly clear that your code is derivative of mine, just > as your sequel to my novel (or your pages added onto my book) don't > "mean" anything if someone hasn't read mine. That's a wonderful theory, but I don't believe it's recognized by the courts. I'm also pretty sure you don't want to go there. Consider folks who create add-ons to Tivo player, or extensions to MacOS. They don't _do_ anything unless they are used with the Tivo player. Or a game meant for a Playstation 3; it won't _do_ anything unless it's calls the BIOS and system functions provided by the PS3. Does that automatically make them derived works? What about a GPL'ed program which interfaces with the iTunes server? It won't _do_ anything unless it can connect across the network and talks to iTunes code. Does that make it a derived work? If the answer is no --- or should be no --- then maybe you should be more careful before making such statements. For myself, I believe we actually get the largest amount of programming freedom if we use a very tightly defined definition of derived code, and not try to create new expansive definitions and try to ram them through the court system or through legislatures. In the end, we may end up regretting it. - Ted ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 17:02 ` Theodore Tso @ 2006-12-18 17:23 ` Dave Neuer 0 siblings, 0 replies; 59+ messages in thread From: Dave Neuer @ 2006-12-18 17:23 UTC (permalink / raw) To: Theodore Tso, Dave Neuer, Linus Torvalds, Alexandre Oliva, Ricardo Galli, linux-kernel On 12/18/06, Theodore Tso <tytso@mit.edu> wrote: > On Mon, Dec 18, 2006 at 10:38:38AM -0500, Dave Neuer wrote: > > I think this is the key, both with libraries and w/ your book example > > below; the concept of independant "meaning." If your code doesn't do > > whatever it is supposed to do _unless_ it is linked with _my_ code, > > then it seems fairly clear that your code is derivative of mine, just > > as your sequel to my novel (or your pages added onto my book) don't > > "mean" anything if someone hasn't read mine. > > For myself, I believe we actually get the largest amount of > programming freedom if we use a very tightly defined definition of > derived code, and not try to create new expansive definitions and try > to ram them through the court system or through legislatures. In the > end, we may end up regretting it. To be sure, we as programmers will have the most freedom if there is no form of intellectual property protection for software at all (imagine all of those Renaissance publishers whose sensibilities would have been quite shocked by the suggestion that their distribution of some author's work for a small fee was somehow "theft"). It's less clear to me that a more expansive "we" will be equally well served, freedom-wise, by less protection though I'm very sympathetic to the argument. > - Ted > Dave ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-17 17:59 ` Linus Torvalds 2006-12-17 22:45 ` Paul Mackerras 2006-12-18 15:38 ` Dave Neuer @ 2006-12-18 19:27 ` Alexandre Oliva 2006-12-18 19:42 ` Linus Torvalds 2 siblings, 1 reply; 59+ messages in thread From: Alexandre Oliva @ 2006-12-18 19:27 UTC (permalink / raw) To: Linus Torvalds; +Cc: Ricardo Galli, linux-kernel On Dec 17, 2006, Linus Torvalds <torvalds@osdl.org> wrote: > For example, glibc could easily have just come out and said the thing that > is obvious to any sane person: "using this library as just a standard > library does not make your program a derived work". > There really wassn't much need for the LGPL, I think. So I guess you approve of the reformulation of LGPL as an additional permission on top of GPL, as in its draft at gplv3.fsf.org, right? >> Some claim that, in the case of static linking, since there part of >> the library copied to the binary, it is definitely a case of derived >> work. > No, the sane way to think about it is that linking just creates an > "aggregate" work. That's your take on it. It does make sense, but claiming it's *the* sane way to think about it is making the mistake you accused the FSF of making. > Why do people think that using "ln" is _any_ different from using > "mkisofs". Maybe because mkisofs will create a functional filesystem image out of whatever you could possibly throw at it, while ld will perform a number of cross-checks between the inputs it is given which indicates a much closer relationship between the inputs? You said so yourself, so I guess we agree. > Does "mkisofs" create a derived work, or an aggregate? I'd say both. I understand it's a derived work, but one that happens to be a mere aggregate of works that might or might not be based on a GPLed program included in the aggregate. Now, does this mean that a court would be pretty much forced to admit the aggregate as a derived work, and thus that the copyright holder (or the license author) gets a say on what 'mere aggregate' means in the license chosen by the copyright holder? ld creates works that perhaps can be construed as not being mere aggregates or even derived works, since ld doesn't always copy the contents of its inputs to the output. But it does extract some information that makes to the output, and there is a closer relationship between the works than in the mere aggregation case of mkisofs, so there is still room for claiming that the output is a derived work, and that it's not a mere aggregate. In fact, it can't possibly be exempt by this paragraph in clause 2 of the GPL: 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. because we're not talking about mere aggregation of the work (or a work based on it) with another work not based on the program, but rather about whether the linker output is based on the program or not. A court gets to decide whether it is a derived work, but since in the dynamic linking case you're not aggregating (because you're not copying the entire library) the program with other works not based on the program, then this exception doesn't apply, methinks. > This particular thing is a non-issue wrt the GPLv2, since you always > have the right to do distribution of aggregates, but it does come up in > some OTHER licenses. Make it *mere* aggregates. That *might* turn out to be a relevant distinction. E.g., if there's functional dependence of one of the elements of the aggregate on another, is the aggregate work still the result of mere aggregation? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 19:27 ` Alexandre Oliva @ 2006-12-18 19:42 ` Linus Torvalds 2006-12-18 20:37 ` Alexandre Oliva 2006-12-19 8:00 ` Sanjoy Mahajan 0 siblings, 2 replies; 59+ messages in thread From: Linus Torvalds @ 2006-12-18 19:42 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Ricardo Galli, linux-kernel On Mon, 18 Dec 2006, Alexandre Oliva wrote: > > So I guess you approve of the reformulation of LGPL as an additional > permission on top of GPL, as in its draft at gplv3.fsf.org, right? Yes. I think that part of the GPLv3 is a good idea. That said, I think they are still pushing the "you don't have any rights unless we give you additional rights explicitly" angle a bit too hard. The fact is, people DO have rights, regardless of what the license says. We have them when it comes to music, and we have them when it comes to software. Copyright law only gives _limited_ rights to copyright holders, and we should actually fight those rights being expanded, instead of trying to expand on them ourselves. > > No, the sane way to think about it is that linking just creates an > > "aggregate" work. > > That's your take on it. It does make sense, but claiming it's *the* > sane way to think about it is making the mistake you accused the FSF > of making. I did point that out at the end of the email you quote. I said it's not necessarily the only way to look at things. But I GUARANTEE you that it makes more sense than the "no rights" approach, and I GUARANTEE you that it makes more sense than thinking that "ld is magic, and makes a derived work" approach. > In fact, it can't possibly be exempt by this paragraph in clause 2 of > the GPL: > > 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. This is actually a red herring. The way the GPLv2 _defines_ "work" and "Program" is by derived "derived work". You're confused by _your_ interpretation of "work" and "Program". You think that "Program" means "binary", because that's you think normally. But the GPLv2 actually defines that "Program" is just the "derivative work under copyright law". Really. Go look. It's right there at the very top, in section 0. In other words, in the GPL, "Program" does NOT mean "binary". Never has. And in fact, it wouldn't make sense if it did, since you can use the GPL for other things than just programs (and people have). So you _always_ get back to the question: what is "derivative"? And the GPLv2 doesn't actually even say anything about that, but EXPLICITLY says that it is left to copyright law. Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 19:42 ` Linus Torvalds @ 2006-12-18 20:37 ` Alexandre Oliva 2006-12-18 20:50 ` Linus Torvalds 2006-12-19 8:00 ` Sanjoy Mahajan 1 sibling, 1 reply; 59+ messages in thread From: Alexandre Oliva @ 2006-12-18 20:37 UTC (permalink / raw) To: Linus Torvalds; +Cc: Ricardo Galli, linux-kernel On Dec 18, 2006, Linus Torvalds <torvalds@osdl.org> wrote: > That said, I think they are still pushing the "you don't have any rights > unless we give you additional rights explicitly" angle a bit too hard. Maybe it's just a matter of perception. I don't see it that way from the inside. How about http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-2&id=2238 Would it help address your mis-perception? > But I GUARANTEE you that it makes more sense than the "no rights" > approach Yeah, but that's a Straw Man. > and I GUARANTEE you that it makes more sense than thinking that "ld > is magic, and makes a derived work" approach. I believe you and I have already shot down the 'ld-is-like-mkisofs' argument. >> In fact, it can't possibly be exempt by this paragraph in clause 2 of >> the GPL: >> 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. > This is actually a red herring. The way the GPLv2 _defines_ "work" and > "Program" is by derived "derived work". No, that's how it defines 'work based on the Program', see the quoted portion below. > You're confused by _your_ interpretation of "work" and "Program". You > think that "Program" means "binary", because that's you think normally. I can't see where you drew that conclusion from, but it's an incorrect conclusion. Program can denote the sources as much as the binaries. > But the GPLv2 actually defines that "Program" is just the "derivative work > under copyright law". > Really. Go look. It's right there at the very top, in section 0. /me looks again 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. 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. (Hereinafter, translation is included without limitation in the term "modification".) > In other words, in the GPL, "Program" does NOT mean "binary". Never has. Agreed. So what? How does this relate with the point above? The binary is a Program, as much as the sources are a Program. Both forms are subject to copyright law and to the license, in spite of http://www.fsfla.org/?q=en/node/128#1 > And in fact, it wouldn't make sense if it did, since you can use the GPL > for other things than just programs (and people have). People do many odd things. How do you define source code and object code to other things that are not programs. > So you _always_ get back to the question: what is "derivative"? And the > GPLv2 doesn't actually even say anything about that, but EXPLICITLY says > that it is left to copyright law. Exactly. No disagreement here. I'm not disputing this fact. In the point you quoted above, I was only disputing your argument of "mere aggregation" in the context of dynamic linking. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 20:37 ` Alexandre Oliva @ 2006-12-18 20:50 ` Linus Torvalds 2006-12-18 21:23 ` David Schwartz ` (6 more replies) 0 siblings, 7 replies; 59+ messages in thread From: Linus Torvalds @ 2006-12-18 20:50 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Ricardo Galli, linux-kernel On Mon, 18 Dec 2006, Alexandre Oliva wrote: > > > In other words, in the GPL, "Program" does NOT mean "binary". Never has. > > Agreed. So what? How does this relate with the point above? > > The binary is a Program, as much as the sources are a Program. Both > forms are subject to copyright law and to the license, in spite of > http://www.fsfla.org/?q=en/node/128#1 Here's how it relates: - if a program is not a "derived work" of the C library, then it's not "the program" as defined by the GPLv2 AT ALL. In other words, it doesn't matter ONE WHIT whether you use "ld --static" or "ld" or "mkisofs" - if the program isn't (by copyright law) derived from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY AFFECT THE RESULTING BINARY. And I'm simply claiming that a binary doesn't become "derived from" by any action of linking. Even if you link using "ld", even if it's static, the binary is not "derived from". It's an aggregate. "Derivation" has nothing to do with "linking". Either it's derived or it is not, and "linking" simply doesn't matter. It doesn't matter whether it's static or dynamic. That's a detail that simply doesn't have anythign at all to do with "derivative work". THAT is my point. Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, static linking aggregates the library with the other program in the same binary. There's no question about that. And that _does_ have meaning from a copyright law angle, since if you don't have permission to ship aggregate works under the license, then you can't ship said binary. It's just a non-issue in the specific case of the GPLv2. In the presense of dynamic linking the binary isn't even an aggregate work. THAT is the difference between static and dynamic. A simple command line flag to the linker shouldn't really reasonably be considered to change "derivation" status. Either something is derived, or it's not. If it's derived, "ld", "mkisofs", "putting them close together" or "shipping them on totally separate CD's" doesn't matter. It's still derived. Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-18 20:50 ` Linus Torvalds @ 2006-12-18 21:23 ` David Schwartz 2006-12-18 22:35 ` Scott Preece 2006-12-20 0:06 ` Alexandre Oliva 2006-12-18 22:06 ` Jeff V. Merkey ` (5 subsequent siblings) 6 siblings, 2 replies; 59+ messages in thread From: David Schwartz @ 2006-12-18 21:23 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org > Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, > static linking aggregates the library with the other program in the same > binary. There's no question about that. And that _does_ have meaning from > a copyright law angle, since if you don't have permission to ship > aggregate works under the license, then you can't ship said binary. It's > just a non-issue in the specific case of the GPLv2. The right to ship aggregate works is not one specifically reserved by law to the copyright holder. It's also not clear that an aggregate work is in fact a single work for any legal purpose other than the aggregator's claim to copyright. All you need to ship an aggregated work is the right to ship each of the individual works aggregated in it. For GPL'd works, you get that right from first sale, assuming you lawfully acquired the GPL'd work in the first place. If the aggregation is performed in an automated and mechanized way, the aggregate is not a single work. It's still multiple works aggregated together. For copyright law purposes, it is not a work because no creative input was needed to produce it beyond what was used to create the works from which it was formed. I recently bought two DVDs as a present for a friend of mine. I put the two DVDs in one box and shipped them to him. Just because the two DVDs are in one box does not make them a derivative work for copyright purposes because no creative input went in to them. I can even staple the two DVDs together if I want. I also don't need any special permission to ship the two of them together to my friend, first sale covers that. The right to ship each individual work is all that's needed to ship the aggregate. Now, if I wanted to write my own story with elements from the content of both DVDs, that would be a derivative work because the combination itself is done in a creative way. No automated, mechanical process can create a derivative work of software. (With a few exceptions not relevant here.) DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 21:23 ` David Schwartz @ 2006-12-18 22:35 ` Scott Preece 2006-12-19 1:29 ` David Schwartz 2006-12-20 0:06 ` Alexandre Oliva 1 sibling, 1 reply; 59+ messages in thread From: Scott Preece @ 2006-12-18 22:35 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On 12/18/06, David Schwartz <davids@webmaster.com> wrote: > > > Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, > > static linking aggregates the library with the other program in the same > > binary. There's no question about that. And that _does_ have meaning from > > a copyright law angle, since if you don't have permission to ship > > aggregate works under the license, then you can't ship said binary. It's > > just a non-issue in the specific case of the GPLv2. > > The right to ship aggregate works is not one specifically reserved by law to > the copyright holder. --- Well, it's reserved to the authors of all the works in the aggregate, possibly including the person doing the aggregation. And the author of each of those works does have the right to limit your permission to distribute in ways that might bar use in aggregations. --- > It's also not clear that an aggregate work is in fact > a single work for any legal purpose other than the aggregator's claim to > copyright. --- Not sure what you're trying to say there - what are we talking about here other than the copyright? --- > All you need to ship an aggregated work is the right to ship each > of the individual works aggregated in it. For GPL'd works, you get that > right from first sale, assuming you lawfully acquired the GPL'd work in the > first place. --- An aggregate work (the word used in the Copyright Act is either "Compilation" or "Collective work", depending on the level of creativity involved in forming it). In either case it is an independent work. The person creating a Compilation has, at the least, copyright in the organization of the material, plus copyright in any original material she contributes. I agree, however, that all you need to distribute tthe compilation is permission to distribute each of the pieces in the given form (the author could have given you the right to distribute only in conjunction with other specified works, for instance) or placed other restrictions on the license. First sale has nothing to do with this. First sale applies to the redistribution or resale of copies you have purchased, not with the right to make additional copies. --- > ... For copyright law purposes, it is not a work because no creative > input was needed to produce it beyond what was used to create the works from > which it was formed. --- Selection and organization are potentially creative. The Act distinguishes between derivative works, compilations, and collective works. A derivative work is a work "based on" the original work; a compilation is a work formed by "collecting and assembling" preexisting works "in such a way that the resulting work as a whole constitutes an original work of authorship. A "collective work" is any work formed by assembling independent works into a whole. All compilations are collective works, but not all collective works are compilations. Derivative works have nothing to do with aggregation. --- > I recently bought two DVDs as a present for a friend of mine. I put the two > DVDs in one box and shipped them to him. Just because the two DVDs are in > one box does not make them a derivative work for copyright purposes because > no creative input went in to them. I can even staple the two DVDs together > if I want. I also don't need any special permission to ship the two of them > together to my friend, first sale covers that. The right to ship each > individual work is all that's needed to ship the aggregate. --- First sale is separate from Copyright. You have the right to ship them, but not to make copies of them. You can't for instance, ship your friend a single DVD that combines the contents of the two you bought. That's not unlike the distinction GPLv3 makes between "propagating" and "conveying". --- > > Now, if I wanted to write my own story with elements from the content of > both DVDs, that would be a derivative work because the combination itself is > done in a creative way. --- If it just rearranged the pieces, it would not be a derivative work, it would be a compilation. If you transformed the pieces, it might be a derivative work (depending on the nature of the transformation). --- > > No automated, mechanical process can create a derivative work of software. > (With a few exceptions not relevant here.) --- The truth of that statement depends on exactly what you mean by "an automated, mechanical process". There are mechanical processs that would simply produce the original work itself, not a derivative (e.g., changing the type from Courier to Times). There are other mechanical proceses that would produce a collective work (e.g., inserting after each line of the program a statement indicating whether or not it was valid C). There are other mechanical processes that would create a derivative work (e.g., a paraphrasing tool). It depends on the nature of the mechanical process; that is, the decision, by you, to apply a particular mechanical process is itself creative. But, perhaps that's what you meant by your "few exceptions". As always, IANAL, scott ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-18 22:35 ` Scott Preece @ 2006-12-19 1:29 ` David Schwartz 2006-12-19 16:55 ` Scott Preece 2006-12-20 0:09 ` Alexandre Oliva 0 siblings, 2 replies; 59+ messages in thread From: David Schwartz @ 2006-12-19 1:29 UTC (permalink / raw) To: sepreece; +Cc: Linux-Kernel@Vger. Kernel. Org > > It's also not clear that an aggregate work is in fact > > a single work for any legal purpose other than the aggregator's claim to > > copyright. > Not sure what you're trying to say there - what are we talking about > here other than the copyright? We are talking about two different possible copyright claims. One is the person who aggregates the works who may try to claim a "compilation copyright" in the aggregate. The other is the authors of the original works who may try to claim that the aggregate is a derivative work. > First sale has nothing to do with this. First sale applies to the > redistribution or resale of copies you have purchased, not with the > right to make additional copies. First sale is exactly what this is about. Nobody needs to make "additional copies" of the Linux kernel because I can download a thousand of them from a computer operated by the guy in the office down the hall from me. > > ... For copyright law purposes, it is not a work because no creative > > input was needed to produce it beyond what was used to create > > the works from > > which it was formed. > Selection and organization are potentially creative. The Act > distinguishes between derivative works, compilations, and collective > works. A derivative work is a work "based on" the original work; a > compilation is a work formed by "collecting and assembling" > preexisting works "in such a way that the resulting work as a whole > constitutes an original work of authorship. A "collective work" is any > work formed by assembling independent works into a whole. All > compilations are collective works, but not all collective works are > compilations. Derivative works have nothing to do with aggregation. Good, so we agree that aggregate is not a derivative work. That means it doesn't have to be GPL'd even if some of its component works are GPL'd. > > I recently bought two DVDs as a present for a friend of mine. I > > put the two > > DVDs in one box and shipped them to him. Just because the two > > DVDs are in > > one box does not make them a derivative work for copyright > > purposes because > > no creative input went in to them. I can even staple the two > > DVDs together > > if I want. I also don't need any special permission to ship the > > two of them > > together to my friend, first sale covers that. The right to ship each > > individual work is all that's needed to ship the aggregate. > First sale is separate from Copyright. You have the right to ship > them, but not to make copies of them. You can't for instance, ship > your friend a single DVD that combines the contents of the two you > bought. That's not unlike the distinction GPLv3 makes between > "propagating" and "conveying". I don't see why you can't distribute a single DVD that combines the contents of the two you bought, so long as you destroy the originals. There is no issue about the number of copies with the GPL because you can download any number of copies of a GPL'd work from someone else who provides you with source. > > Now, if I wanted to write my own story with elements from the content of > > both DVDs, that would be a derivative work because the > > combination itself is > > done in a creative way. > If it just rearranged the pieces, it would not be a derivative work, > it would be a compilation. If you transformed the pieces, it might be > a derivative work (depending on the nature of the transformation). I think it depends upon how small the pieces are. If you rearranged them creatively, and the result was in effect a single work, I think it would be a derivative work. > > No automated, mechanical process can create a derivative work > > of software. > > (With a few exceptions not relevant here.) > The truth of that statement depends on exactly what you mean by "an > automated, mechanical process". There are mechanical processs that > would simply produce the original work itself, not a derivative (e.g., > changing the type from Courier to Times). There are other mechanical > proceses that would produce a collective work (e.g., inserting after > each line of the program a statement indicating whether or not it was > valid C). There are other mechanical processes that would create a > derivative work (e.g., a paraphrasing tool). It depends on the nature > of the mechanical process; that is, the decision, by you, to apply a > particular mechanical process is itself creative. But, perhaps that's > what you meant by your "few exceptions". I mean that you can't link together a bunch of works that would otherwise be independent and get a derivative work as a result. Linking combines mechanistically, not creatively, so it aggregates. DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 1:29 ` David Schwartz @ 2006-12-19 16:55 ` Scott Preece 2006-12-20 0:09 ` Alexandre Oliva 1 sibling, 0 replies; 59+ messages in thread From: Scott Preece @ 2006-12-19 16:55 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On 12/18/06, David Schwartz <davids@webmaster.com> wrote: > > > > First sale has nothing to do with this. First sale applies to the > > redistribution or resale of copies you have purchased, not with the > > right to make additional copies. > > First sale is exactly what this is about. Nobody needs to make "additional > copies" of the Linux kernel because I can download a thousand of them from a > computer operated by the guy in the office down the hall from me. --- This is an interesting argument that was new to me. However, it is not clear at all that First Sale applies to intangible copies. And it's not clear that there is a sale involved, legally. Again, IANAL, but I think this is seriously untested ground. scott ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 1:29 ` David Schwartz 2006-12-19 16:55 ` Scott Preece @ 2006-12-20 0:09 ` Alexandre Oliva 1 sibling, 0 replies; 59+ messages in thread From: Alexandre Oliva @ 2006-12-20 0:09 UTC (permalink / raw) To: davids; +Cc: sepreece, Linux-Kernel@Vger. Kernel. Org On Dec 18, 2006, "David Schwartz" <davids@webmaster.com> wrote: > I don't see why you can't distribute a single DVD that combines the contents > of the two you bought, so long as you destroy the originals. Because, for example, per Brazilian law since 1998, fair use only grants you the right to copy small portions of copyrighted works for personal use. http://www.petitiononline.com/netlivre Remember that the GPL is not only about US copyright law or US courts. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 21:23 ` David Schwartz 2006-12-18 22:35 ` Scott Preece @ 2006-12-20 0:06 ` Alexandre Oliva 1 sibling, 0 replies; 59+ messages in thread From: Alexandre Oliva @ 2006-12-20 0:06 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On Dec 18, 2006, "David Schwartz" <davids@webmaster.com> wrote: > No automated, mechanical process can create a derivative work of software. > (With a few exceptions not relevant here.) Can you explain what mechanisms are involved in copyright monopolies over object code, then? (there's a hint at http://www.fsfla.org/?q=en/node/128#1 ) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 20:50 ` Linus Torvalds 2006-12-18 21:23 ` David Schwartz @ 2006-12-18 22:06 ` Jeff V. Merkey 2006-12-18 23:28 ` Alexandre Oliva ` (4 subsequent siblings) 6 siblings, 0 replies; 59+ messages in thread From: Jeff V. Merkey @ 2006-12-18 22:06 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel Linus Torvalds wrote: >On Mon, 18 Dec 2006, Alexandre Oliva wrote: > > >>>In other words, in the GPL, "Program" does NOT mean "binary". Never has. >>> >>> >>Agreed. So what? How does this relate with the point above? >> >>The binary is a Program, as much as the sources are a Program. Both >>forms are subject to copyright law and to the license, in spite of >>http://www.fsfla.org/?q=en/node/128#1 >> >> > >Here's how it relates: > - if a program is not a "derived work" of the C library, then it's not > "the program" as defined by the GPLv2 AT ALL. > >In other words, it doesn't matter ONE WHIT whether you use "ld --static" >or "ld" or "mkisofs" - if the program isn't (by copyright law) derived >from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY >AFFECT THE RESULTING BINARY. > >And I'm simply claiming that a binary doesn't become "derived from" by any >action of linking. > >Even if you link using "ld", even if it's static, the binary is not >"derived from". It's an aggregate. > >"Derivation" has nothing to do with "linking". Either it's derived or it >is not, and "linking" simply doesn't matter. It doesn't matter whether >it's static or dynamic. That's a detail that simply doesn't have anythign >at all to do with "derivative work". > >THAT is my point. > >Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, >static linking aggregates the library with the other program in the same >binary. There's no question about that. And that _does_ have meaning from >a copyright law angle, since if you don't have permission to ship >aggregate works under the license, then you can't ship said binary. It's >just a non-issue in the specific case of the GPLv2. > >In the presense of dynamic linking the binary isn't even an aggregate >work. > >THAT is the difference between static and dynamic. A simple command line >flag to the linker shouldn't really reasonably be considered to change >"derivation" status. > >Either something is derived, or it's not. If it's derived, "ld", >"mkisofs", "putting them close together" or "shipping them on totally >separate CD's" doesn't matter. It's still derived. > > Linus >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > Yep. We love you linus, keep going. Also, we are taking over SCO's office space after the first of the year, since they have no one left. We will try to get that annoying eyesore of a sign taken off the building as soon as possible. They moved to Holliday, UT (or are moving there at present). :-) Jeff ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 20:50 ` Linus Torvalds 2006-12-18 21:23 ` David Schwartz 2006-12-18 22:06 ` Jeff V. Merkey @ 2006-12-18 23:28 ` Alexandre Oliva 2006-12-19 1:35 ` David Schwartz 2006-12-18 23:52 ` Paul Mackerras ` (3 subsequent siblings) 6 siblings, 1 reply; 59+ messages in thread From: Alexandre Oliva @ 2006-12-18 23:28 UTC (permalink / raw) To: Linus Torvalds; +Cc: Ricardo Galli, linux-kernel On Dec 18, 2006, Linus Torvalds <torvalds@osdl.org> wrote: > On Mon, 18 Dec 2006, Alexandre Oliva wrote: >> > In other words, in the GPL, "Program" does NOT mean "binary". Never has. >> Agreed. So what? How does this relate with the point above? > Here's how it relates: > - if a program is not a "derived work" of the C library, then it's not > "the program" as defined by the GPLv2 AT ALL. In the case I'm talking about, libgpl (make it a GPLed libc) is the program, and a binary produced by linking anything else with the program (libgpl) is what you claim to be an aggregate (a term not defined in the GPL; is it defined in US law?). For both static and dynamic linking, you might claim the output is an aggregate, but that doesn't matter. What matters is whether or not the output is a work based on the program, and whether the "mere aggregation" paragraph kicks in. If the output is not an aggregate, which is quite likely to be the case for dynamic linking, and quite possibly also for many static linking cases, then the "mere aggregation" paragraph of clause 2 does not kick in. If the output is indeed an aggregate, as it may quite likely be in the case of static linking, then the "mere aggregation" considerations of clause 2 may kick in and enable the 'anything else' to not be brought under the scope of the license. You still need permission to distribute the whole. The GPL asserts its non-interference with your ability to distribute the separate portion separately, under whatever license you can, as long as it's not a derived work from the GPL portion. But what about the whole? If you can't separate the whole into, well, the separate components, is it still a mere aggregate? mkisofs will create an image in which the components are all there, easily extractable individually in their original form. This is *clearly* mere aggregation, even if some components turn out to be works based on other GPL programs. But even in the case of static linking, this is not how it works. Say, if the portions of the static libgpl to be copied to the output are selected based on the contents of the 'anything else', could you legitimately claim that the output is not a derived work of both libgpl and this 'anything else', but rather a mere aggregation of unrelated works? In either case, if you distribute the linker output, and it happens to be found to be a derived work of the program (libgpl), aggregate or not, then you must license the whole of the linker output under the GPL, and this means to me that you have to be able to provide the source code of every portion thereof under the GPL, except for portions explicitly excluded by the GPL itself. So whether it's an aggregate or not is completely irrelevant. What matters is whether it's a derived work of a GPLed program (and if there is copying, it probably is) and whether the mere aggregation clause kicks in to grant an exception. > THAT is the difference between static and dynamic. A simple command line > flag to the linker shouldn't really reasonably be considered to change > "derivation" status. If in one case there is extraction, copying and transformation of the GPLed intput, and in the other there is something much simpler (does it still qualify as extraction, copying and transformation?), then derivation becomes more or less obvious to prove, but you're right in that the status of the output probably won't change. The status of the inputs certainly doesn't. > Either something is derived, or it's not. If it's derived, "ld", > "mkisofs", "putting them close together" or "shipping them on totally > separate CD's" doesn't matter. It's still derived. But the important questions at hand, I think, are what makes it derived, and whether it qualifies for any of the exceptions in the GPL. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-18 23:28 ` Alexandre Oliva @ 2006-12-19 1:35 ` David Schwartz 2006-12-19 2:38 ` D. Hazelton 2006-12-20 0:20 ` Alexandre Oliva 0 siblings, 2 replies; 59+ messages in thread From: David Schwartz @ 2006-12-19 1:35 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org > For both static and dynamic linking, you might claim the output is an > aggregate, but that doesn't matter. What matters is whether or not > the output is a work based on the program, and whether the "mere > aggregation" paragraph kicks in. > > If the output is not an aggregate, which is quite likely to be > the case for dynamic linking, and quite possibly also for many static > linking cases, then the "mere aggregation" paragraph of clause 2 does > not kick in. > > If the output is indeed an aggregate, as it may quite likely be in the > case of static linking, then the "mere aggregation" considerations of > clause 2 may kick in and enable the 'anything else' to not be brought > under the scope of the license. You still need permission to > distribute the whole. The GPL asserts its non-interference with your > ability to distribute the separate portion separately, under whatever > license you can, as long as it's not a derived work from the GPL > portion. No! It makes no difference whether the "mere aggregation" paragraph kicks in because the "mere aggregation" paragraph is *explaining* the *law*. What matters is what the law actually *says*. We are talking about what works are within the GPL's scope. The text of the GPL does not matter because the GPL does not set its own scope, copyright law does. The GPL could say that if you ever see the source code to a GPL'd work, every work you ever write must be placed under the GPL. But that wouldn't make it true, because that would be a requirement outside the GPL's scope. We are talking about works are inside the GPL's legal scope, and in that case, nothing the GPL says can enlarge the scope. DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 1:35 ` David Schwartz @ 2006-12-19 2:38 ` D. Hazelton 2006-12-19 12:42 ` Horst H. von Brand 2006-12-20 0:20 ` Alexandre Oliva 1 sibling, 1 reply; 59+ messages in thread From: D. Hazelton @ 2006-12-19 2:38 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On Monday 18 December 2006 20:35, David Schwartz wrote: > > For both static and dynamic linking, you might claim the output is an > > aggregate, but that doesn't matter. What matters is whether or not > > the output is a work based on the program, and whether the "mere > > aggregation" paragraph kicks in. > > > > If the output is not an aggregate, which is quite likely to be > > the case for dynamic linking, and quite possibly also for many static > > linking cases, then the "mere aggregation" paragraph of clause 2 does > > not kick in. > > > > If the output is indeed an aggregate, as it may quite likely be in the > > case of static linking, then the "mere aggregation" considerations of > > clause 2 may kick in and enable the 'anything else' to not be brought > > under the scope of the license. You still need permission to > > distribute the whole. The GPL asserts its non-interference with your > > ability to distribute the separate portion separately, under whatever > > license you can, as long as it's not a derived work from the GPL > > portion. > > No! > > It makes no difference whether the "mere aggregation" paragraph kicks in > because the "mere aggregation" paragraph is *explaining* the *law*. What > matters is what the law actually *says*. > > We are talking about what works are within the GPL's scope. The text of the > GPL does not matter because the GPL does not set its own scope, copyright > law does. > > The GPL could say that if you ever see the source code to a GPL'd work, > every work you ever write must be placed under the GPL. But that wouldn't > make it true, because that would be a requirement outside the GPL's scope. > > We are talking about works are inside the GPL's legal scope, and in that > case, nothing the GPL says can enlarge the scope. > > DS Actually, after rereading the GPLv2 because of this discussion I came to a most surprising conclusion. While there are *IMPLICIT* and *EXPLICIT* copyrights on the code, they have no bearing on the text of the GPL. The GPL is a License that covers how the code may be used, modified and distributed. This is the reason that the FSF people had to make the big exception for Bison, because the parser skeleton is such an integral part of Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the program) that truthfully, any parser built using Bison is a derivative work of code released under the GPL. That said, since there is a distribution, use and modification license on the Linux Kernel - the GPLv2 - there are those extra restrictions on the code *OUTSIDE* the copyright rules. DRH ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 2:38 ` D. Hazelton @ 2006-12-19 12:42 ` Horst H. von Brand 0 siblings, 0 replies; 59+ messages in thread From: Horst H. von Brand @ 2006-12-19 12:42 UTC (permalink / raw) To: D. Hazelton; +Cc: davids, Linux-Kernel@Vger. Kernel. Org D. Hazelton <dhazelton@enter.net> wrote: [...] > The GPL is a License that covers how the code may be used, modified and > distributed. This is the reason that the FSF people had to make the big > exception for Bison, because the parser skeleton is such an integral part of > Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the > program) that truthfully, any parser built using Bison is a derivative work > of code released under the GPL. They didn't "have to make the big exception", if Linus' view is correct: The parser is built mechanically from the skeleton and the user's input, so it is just an aggregation. Sure, it is best to make this clear (by the exception), even if not needed. > That said, since there is a distribution, use and modification license on > the Linux Kernel - the GPLv2 - there are those extra restrictions on the > code *OUTSIDE* the copyright rules. A license like GPL works /inside/ copyright law, by allowing you to do things the law prohibits unless the owner of the right agrees. What the law allows explicitly, regardless of the owner's wishes, can't be taken away. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 1:35 ` David Schwartz 2006-12-19 2:38 ` D. Hazelton @ 2006-12-20 0:20 ` Alexandre Oliva 1 sibling, 0 replies; 59+ messages in thread From: Alexandre Oliva @ 2006-12-20 0:20 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On Dec 18, 2006, "David Schwartz" <davids@webmaster.com> wrote: > It makes no difference whether the "mere aggregation" paragraph kicks in > because the "mere aggregation" paragraph is *explaining* the *law*. What > matters is what the law actually *says*. You mean "mere aggregation" is defined in copyright law? I don't think so, otherwise the term 'aggregate' probably wouldn't have been used in GPLv3. AFAIK it's perfectly legitimate (even if immoral) for a copyright license to prohibit the distribution of the software governed by the license with anything else the author establishes. E.g., some Java virtual machine's license used to establish that you couldn't ship it along with other implementations of Java that didn't pass some comformance test. Now, the GPL doesn't do this. It doesn't say you can't distribute GPLed software along with any other software. It only says that, when you distribute together works that don't constitute mere aggregation (providing its own definition of mere aggregation), then the whole must be licensed under the GPL. > The GPL could say that if you ever see the source code to a GPL'd work, > every work you ever write must be placed under the GPL. But that wouldn't > make it true, because that would be a requirement outside the GPL's scope. It is indeed possible that this would fall outside the scope of copyright law in the US, and it would not be morally acceptable for the GPL to impose such a condition. But then, since nobody can be forced to see the source code of a GPLed work, or any work for that matter, acceptance is voluntary, and one shouldn't enter an agreement one's not willing to abide by. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 20:50 ` Linus Torvalds ` (2 preceding siblings ...) 2006-12-18 23:28 ` Alexandre Oliva @ 2006-12-18 23:52 ` Paul Mackerras 2006-12-18 23:59 ` Linus Torvalds 2006-12-19 1:39 ` David Schwartz 2006-12-19 4:20 ` Daniel Barkalow ` (2 subsequent siblings) 6 siblings, 2 replies; 59+ messages in thread From: Paul Mackerras @ 2006-12-18 23:52 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel Linus Torvalds writes: > "Derivation" has nothing to do with "linking". Either it's derived or it > is not, and "linking" simply doesn't matter. It doesn't matter whether > it's static or dynamic. That's a detail that simply doesn't have anythign > at all to do with "derivative work". There is in fact a pretty substantial non-technical difference between static and dynamic linking. If I create a binary by static linking and I include some library, and I distribute that binary to someone else, the recipient doesn't need to have a separate copy of the library, because they get one in the binary. If on the other hand the binary is dynamically linked, then the recipient needs to get hold of a copy of the library from somewhere, implying that they need to have satisfied whatever license conditions the copyright owner of the library places on it, in order to have obtained their copy of the library legally. In other words, static linking gives the recipient a "free" copy of the library, but dynamic linking doesn't. That is why some companies' legal guidelines have quite different rules about the distribution of binaries, depending on whether they are statically or dynamically linked. If the library was a proprietary library, for which the copyright owner wanted to charge a per-copy fee, the owner would no doubt object to me distributing statically-linked binaries containing his library, but could conceivably be perfectly happy with me distributing binaries that have been dynamically linked against his library, since then anyone who wants to use my binary has to purchase a copy of his library from him. So therefore I don't think you can reasonably claim that static vs. dynamic linking is only a technical difference. There are clearly other differences when it comes to distribution of the resulting binaries. Paul. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 23:52 ` Paul Mackerras @ 2006-12-18 23:59 ` Linus Torvalds 2006-12-19 0:43 ` Paul Mackerras 2006-12-19 1:39 ` David Schwartz 1 sibling, 1 reply; 59+ messages in thread From: Linus Torvalds @ 2006-12-18 23:59 UTC (permalink / raw) To: Paul Mackerras; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel On Tue, 19 Dec 2006, Paul Mackerras wrote: > > There is in fact a pretty substantial non-technical difference between > static and dynamic linking. If I create a binary by static linking > and I include some library, and I distribute that binary to someone > else, the recipient doesn't need to have a separate copy of the > library, because they get one in the binary. I agree, and I do agree that it's a real difference. I personally think that it's the "aggregation" issue, not a "derivation" issue, but I'll freely admit that it's just my personal view of the situation. > In other words, static linking gives the recipient a "free" copy of > the library, but dynamic linking doesn't. That is why some companies' > legal guidelines have quite different rules about the distribution of > binaries, depending on whether they are statically or dynamically > linked. Yes. There is not doubt at all that regardless of anything else, if you link statically, you at the VERY LEAST need to have the right to distribute the library as part of an "aggregate work". > So therefore I don't think you can reasonably claim that static > vs. dynamic linking is only a technical difference. There are clearly > other differences when it comes to distribution of the resulting > binaries. Yes. And I have actually talked about this exact issue - even in the absense of any "derivation" from the library, the fact that static linking includes a _copy_ of the library does mean that you have to have the right to distribute that particular copy. Now, under the GPL, aggregate distribution is allowed, but you still do need to follow the other GPL rules (ie you would need to distributed sources for the library - even if you don't necessarily distribute sources to the binary you linked _with_). So there's no question that "dynamic linking" simplifies issues, by virtue of not even distributing any library code at all. I absolutely agree about that part. Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 23:59 ` Linus Torvalds @ 2006-12-19 0:43 ` Paul Mackerras 0 siblings, 0 replies; 59+ messages in thread From: Paul Mackerras @ 2006-12-19 0:43 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel Linus Torvalds writes: > > > On Tue, 19 Dec 2006, Paul Mackerras wrote: > > > > There is in fact a pretty substantial non-technical difference between > > static and dynamic linking. If I create a binary by static linking > > and I include some library, and I distribute that binary to someone > > else, the recipient doesn't need to have a separate copy of the > > library, because they get one in the binary. > > I agree, and I do agree that it's a real difference. > > I personally think that it's the "aggregation" issue, not a "derivation" > issue, but I'll freely admit that it's just my personal view of the > situation. I think the critical issue is whether any human creativity is required to establish derivation. Clearly there is some modification and adaptation that ld does to a library in the process of linking it into a binary, and ld is unlike mkisofs or gzip in that you can't extract the library in its original form (or any form suitable for linking with another program) from the output of ld --static. The question is whether it matters that the process that ld does is mechanical in nature. This is possibly an area where you'll get a different answer in different jurisdictions. I believe that in the US, some creative input is required to establish copyright, whereas in Australia, only "effort" is needed. I don't know whether that affects the definition of "derived work". I personally would think that a mechanical process of modification *does* create a derived work, but it would take a court of law or a legislature to make an authoritative decision, I guess. Paul. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-18 23:52 ` Paul Mackerras 2006-12-18 23:59 ` Linus Torvalds @ 2006-12-19 1:39 ` David Schwartz 1 sibling, 0 replies; 59+ messages in thread From: David Schwartz @ 2006-12-19 1:39 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org Combined responses: > So therefore I don't think you can reasonably claim that static > vs. dynamic linking is only a technical difference. There are clearly > other differences when it comes to distribution of the resulting > binaries. We're only talking about the special case of GPL'd works. You can download a million copies of a GPL'd work from a server run by a family member across the room. You can then delete one copy for each copy you distribute in the form of a statically linked work. Issues of copying don't apply to GPL'd works unless you have no access to the source code. Otherwise, someone else can copy you as many works as you want with the source code, and you can use first sale to transfer every one of them. > I personally would think that a mechanical process of modification > *does* create a derived work, but it would take a court of law or a > legislature to make an authoritative decision, I guess. Under at least United States law, copyright protected creative expression and only creative expression. In other jurisdictions, there are other types of rights similar to copyright that one can obtain by means of hard work, for example database compilation rights. They are usually legally distinct from copyright and grant different rights with different rules. DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 20:50 ` Linus Torvalds ` (3 preceding siblings ...) 2006-12-18 23:52 ` Paul Mackerras @ 2006-12-19 4:20 ` Daniel Barkalow 2006-12-20 19:14 ` David Schwartz 2006-12-19 7:39 ` Giacomo A. Catenazzi 2006-12-19 7:40 ` Giacomo A. Catenazzi 6 siblings, 1 reply; 59+ messages in thread From: Daniel Barkalow @ 2006-12-19 4:20 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel On Mon, 18 Dec 2006, Linus Torvalds wrote: > Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, > static linking aggregates the library with the other program in the same > binary. There's no question about that. And that _does_ have meaning from > a copyright law angle, since if you don't have permission to ship > aggregate works under the license, then you can't ship said binary. It's > just a non-issue in the specific case of the GPLv2. Under US law, the distinction is between works that are copyrightable themselves as "derivative works" and works that are derived from others, but aren't copyrightable. Provided you're allowed to ship aggregate works, the question is whether the output of "ld" is a copyrightable work distinct from the inputs. I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I think that "objcopy" does create a derived work, and "ld" does too, by virtue of modifying the objects it takes to resolve symbols. Now, you could distribute to somebody an ar archive of your program, and the recipient (given fair use rights to the copy of the program they received) could do "gcc program.a -o program" to link it. But I don't think you automatically get the right (under the "mere aggregation" permission) to distribute the result of relocating the symbols of gnutls around those of your program and vice versa, along with modifying the references to external symbols from each of these to point to specific locations. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-19 4:20 ` Daniel Barkalow @ 2006-12-20 19:14 ` David Schwartz 2006-12-20 23:08 ` Scott Preece 0 siblings, 1 reply; 59+ messages in thread From: David Schwartz @ 2006-12-20 19:14 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org Note: Combined responses. > I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I > think that "objcopy" does create a derived work, and "ld" does too, by > virtue of modifying the objects it takes to resolve symbols. Now, you > could distribute to somebody an ar archive of your program, and the > recipient (given fair use rights to the copy of the program they > received) > could do "gcc program.a -o program" to link it. But I don't think you > automatically get the right (under the "mere aggregation" permission) to > distribute the result of relocating the symbols of gnutls around those of > your program and vice versa, along with modifying the references to > external symbols from each of these to point to specific locations. The question is, as a matter of copyright law, what right do you need to distribute the aggregate? As I understand the law, the answer is that you need the right to distribute each of the individual works in the aggregate. Fortunately, you can trivially get the right to distribute any GPL'd work under first sale. (Simply download as many copies as you plan to distribute.) To argue otherwise would be to argue that you can't buy a DVD and a Hallmark card and ship the two of them together to your mother. -- >This is an interesting argument that was new to me. However, it is not >clear at all that First Sale applies to intangible copies. And it's >not clear that there is a sale involved, legally. Again, IANAL, but I >think this is seriously untested ground. First sale has nothing do with a sale. 17 USC 109(a) says, "Notwithstanding the provisions of section 106 (3), the owner of a particular copy or phonorecord lawfully made under this title, or any person authorized by such owner, is entitled, without the authority of the copyright owner, to sell or otherwise dispose of the possession of that copy or phonorecord." I think it's well settled law that everyone who lawfully acquires a copy of a copyrighted work has the right to its normal expected use and may transfer that right along with their copy to another without needing any special permission from the copyright holder. Exceptions would include cases where there was specific assent to a license, such as shrink-wrap, click-through, or EULA. I'm not really qualified to respond to the argument that first sale doesn't apply to an intangible copy. As the law is written, it simply refers to the owner of a "a particular copy". Sometimes "a copy" only means tangible copies and sometimes it simply means the result of copying. It seems bizarre to me, however, to argue that if I lawfully download a program, I need special permission from the copyright holder to put it on CD but not a hard drive. What is the *legal* difference? And if I put it no a hard drive, I can't sell it? Seems crazy to me. -- >AFAIK it's perfectly legitimate (even if immoral) for a copyright >license to prohibit the distribution of the software governed by the >license with anything else the author establishes. E.g., some Java >virtual machine's license used to establish that you couldn't ship it >along with other implementations of Java that didn't pass some >comformance test. Nobody ever said a copyright holder couldn't restrict the distribution of his software when such distribution is not authorized by things like fair use, first sale, or other things. Of course a copyright holder can set any rules he want for those distributions not authorized by law. However, those restrictions do not affect those who did not agree to them. For example, if I buy such a JVM and don't agree to the license (assuming I don't have to agree to the license to lawfully acquire the JVM), I can give it to a friend along with any other software I want. -- >A bare license probably cannot take them away, since you haven't >agreed to anything. But (1) that may not be true in all legal >systems, and (2) a contract-based license can take it away (e.g. an >NDA). So the GPL's clarification is worthwhile. For the same reason, >I'm guessing, the Creative Commons licenses have (also in section 2, >at least in v2.5): The clarification serves another important purpose as well. If some provision is ambiguous and admits of two readins, one which conflicts with fair use and would not be enforceable and one which doesn't that is, these disclaimers make clear that the latter interpretation is the one that should be chosen. So they may actually *increase* the scope of the license. DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-20 19:14 ` David Schwartz @ 2006-12-20 23:08 ` Scott Preece 2006-12-20 23:26 ` David Schwartz 0 siblings, 1 reply; 59+ messages in thread From: Scott Preece @ 2006-12-20 23:08 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On 12/20/06, David Schwartz <davids@webmaster.com> wrote: > > I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I > > think that "objcopy" does create a derived work, and "ld" does too, by > > virtue of modifying the objects it takes to resolve symbols. ... > > The question is, as a matter of copyright law, what right do you need to > distribute the aggregate? As I understand the law, the answer is that you > need the right to distribute each of the individual works in the aggregate. > Fortunately, you can trivially get the right to distribute any GPL'd work > under first sale. (Simply download as many copies as you plan to > distribute.) > > To argue otherwise would be to argue that you can't buy a DVD and a Hallmark > card and ship the two of them together to your mother. --- If the aggregate is not a derived work, then you only need the separate permissions for the original works. If the aggregate is a derived work, then you need permissions relative to the derived work, not just the original work - essenitlally, permission to modify the work. And, the permissions would all have to allow the specific form of distribution and aggregation involved. [Don't give me back the example of breaking the DVD in half - "the work" is not the medium; your purchase of a DVD does not give you the right to modify the movie it carries and redistribute the modified version, even under first sale.] --- > > >This is an interesting argument that was new to me. However, it is not > >clear at all that First Sale applies to intangible copies. And it's > >not clear that there is a sale involved, legally. Again, IANAL, but I > >think this is seriously untested ground. > > First sale has nothing do with a sale. 17 USC 109(a) says, "Notwithstanding > the provisions of section 106 (3), the owner of a particular copy or > phonorecord lawfully made under this title, or any person authorized by such > owner, is entitled, without the authority of the copyright owner, to sell or > otherwise dispose of the possession of that copy or phonorecord." --- While I generally agree with you that first sale can occur without an actual sale, the GPL (and distribution by free download in general) is an odd situation (the law wasn't designed for works that could be freely copied) and I would not suggest anyone depend on a court to interpret that clause the way you are. --- > I'm not really qualified to respond to the argument that first sale doesn't > apply to an intangible copy. As the law is written, it simply refers to the > owner of a "a particular copy". Sometimes "a copy" only means tangible > copies and sometimes it simply means the result of copying. It seems bizarre > to me, however, to argue that if I lawfully download a program, I need > special permission from the copyright holder to put it on CD but not a hard > drive. What is the *legal* difference? And if I put it no a hard drive, I > can't sell it? Seems crazy to me. --- Nevertheless, the only decided cases I could find in the area went the other way - saying that intangible copies did not exhaust the author's distribution rights. Note that your example is misleading - you don't need different permission to put it on a CD than to put it on a hard drive, but you might not have permission to distribute it (depending on the terms under which you received it). There is case law finding that, in at least some cases, the author's rights in particular copies (even tangible copies) was not exhausted. --- > > Nobody ever said a copyright holder couldn't restrict the distribution of > his software when such distribution is not authorized by things like fair > use, first sale, or other things. Of course a copyright holder can set any > rules he want for those distributions not authorized by law. > > However, those restrictions do not affect those who did not agree to them. > For example, if I buy such a JVM and don't agree to the license (assuming I > don't have to agree to the license to lawfully acquire the JVM), I can give > it to a friend along with any other software I want. --- No, as with the language in the GPL, your right to distribute is provided by the license you received with the JVM, so if you don't accept it, you can't distribute. However, the first sale doctrine provides a limited exception; if you got the JVM through an unrestricted sale, then you would normally have the right to sell that particular copy without any further license (though possibly not to someone in a different part of the world). scott ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: GPL only modules 2006-12-20 23:08 ` Scott Preece @ 2006-12-20 23:26 ` David Schwartz 0 siblings, 0 replies; 59+ messages in thread From: David Schwartz @ 2006-12-20 23:26 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org > > However, those restrictions do not affect those who did not > > agree to them. > > For example, if I buy such a JVM and don't agree to the license > > (assuming I > > don't have to agree to the license to lawfully acquire the > > JVM), I can give > > it to a friend along with any other software I want. > No Yes. > as with the language in the GPL, your right to distribute is > provided by the license you received with the JVM, so if you don't > accept it, you can't distribute. This is flat out self-contradiction. If my right is provided by the license, then I can distribute. If I don't accept the license, then how is my right to distribute provided by it? The paragraph you are saying "No" to is completely correct and your response is complete double-speak. > However, the first sale doctrine > provides a limited exception; Exactly. So the idea that you can't distribute a work unless you agree to its license is nonsense. With a license like the GPL, that is something that is not a shrink-wrap, click-through, or EULA, the license does not apply to anyone who does not agree to it. The GPL makes this totally clear in section 5. If you don't accept the license, you simply don't get the additional rights the license offers. You still have all the rights you originally had. > if you got the JVM through an > unrestricted sale, then you would normally have the right to sell that > particular copy without any further license (though possibly not to > someone in a different part of the world). Your license to distribute is provided by the license if and only if you agree to the license. Otherwise, it's as if the license doesn't exist. You can get the right to distribute the work any other way that may be available to you. First sale is just one example. DS ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 20:50 ` Linus Torvalds ` (4 preceding siblings ...) 2006-12-19 4:20 ` Daniel Barkalow @ 2006-12-19 7:39 ` Giacomo A. Catenazzi 2006-12-19 7:40 ` Giacomo A. Catenazzi 6 siblings, 0 replies; 59+ messages in thread From: Giacomo A. Catenazzi @ 2006-12-19 7:39 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel Linus Torvalds wrote: > > On Mon, 18 Dec 2006, Alexandre Oliva wrote: >>> In other words, in the GPL, "Program" does NOT mean "binary". Never has. >> Agreed. So what? How does this relate with the point above? >> >> The binary is a Program, as much as the sources are a Program. Both >> forms are subject to copyright law and to the license, in spite of >> http://www.fsfla.org/?q=en/node/128#1 > > Here's how it relates: > - if a program is not a "derived work" of the C library, then it's not > "the program" as defined by the GPLv2 AT ALL. > > In other words, it doesn't matter ONE WHIT whether you use "ld --static" > or "ld" or "mkisofs" - if the program isn't (by copyright law) derived > from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY > AFFECT THE RESULTING BINARY. I really don't agree. It seems you confuse source and binary application. The source surelly is not derived, you can link *any* libc to your program. But a binary is different. Let start with your example about books: you write a book, you have the copyright of the text, but if you publish it with X publiher, he may use a own font. You can read the book, scan it to extract text (I hope fair use allows it), but not copy the book pages: there is your text, but also copyrighted font. Publisher should check that the two license are compatible, as the user that links with a new library. For binary, it is the same. You can extract libraries and rest of programs (better doing with sources), but until it is one binary, it is a new mixed entity. It is not only linking, it is mixing bytes! Some part of library is linked statically, there are some references in the static part of program. It is a mix and until the two part are mixed (not only linked) you should follow both licenses for copying! Choose any dynamic program in your machine, try to link glibc with an other (not directly derived libc) library... you see how it is hard, and it is very different to an "aggregation". And dynamic links is only the latest step of "merging" the two binaries. Other libraries tend to be more "dynamic", but glibc mixes to much In other word, source A, library B: the binary C is derived both from A and B, but surelly A is not derived by B. So IMHO IANAL, in arguments we should not confuse the sources and the binary in the arguments, so not calling simply "the program". ciao cate > > And I'm simply claiming that a binary doesn't become "derived from" by any > action of linking. > > Even if you link using "ld", even if it's static, the binary is not > "derived from". It's an aggregate. > > "Derivation" has nothing to do with "linking". Either it's derived or it > is not, and "linking" simply doesn't matter. It doesn't matter whether > it's static or dynamic. That's a detail that simply doesn't have anythign > at all to do with "derivative work". > > THAT is my point. > > Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, > static linking aggregates the library with the other program in the same > binary. There's no question about that. And that _does_ have meaning from > a copyright law angle, since if you don't have permission to ship > aggregate works under the license, then you can't ship said binary. It's > just a non-issue in the specific case of the GPLv2. > > In the presense of dynamic linking the binary isn't even an aggregate > work. > > THAT is the difference between static and dynamic. A simple command line > flag to the linker shouldn't really reasonably be considered to change > "derivation" status. > > Either something is derived, or it's not. If it's derived, "ld", > "mkisofs", "putting them close together" or "shipping them on totally > separate CD's" doesn't matter. It's still derived. > > Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 20:50 ` Linus Torvalds ` (5 preceding siblings ...) 2006-12-19 7:39 ` Giacomo A. Catenazzi @ 2006-12-19 7:40 ` Giacomo A. Catenazzi 6 siblings, 0 replies; 59+ messages in thread From: Giacomo A. Catenazzi @ 2006-12-19 7:40 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel Linus Torvalds wrote: > > On Mon, 18 Dec 2006, Alexandre Oliva wrote: >>> In other words, in the GPL, "Program" does NOT mean "binary". Never has. >> Agreed. So what? How does this relate with the point above? >> >> The binary is a Program, as much as the sources are a Program. Both >> forms are subject to copyright law and to the license, in spite of >> http://www.fsfla.org/?q=en/node/128#1 > > Here's how it relates: > - if a program is not a "derived work" of the C library, then it's not > "the program" as defined by the GPLv2 AT ALL. > > In other words, it doesn't matter ONE WHIT whether you use "ld --static" > or "ld" or "mkisofs" - if the program isn't (by copyright law) derived > from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY > AFFECT THE RESULTING BINARY. I really don't agree. It seems you confuse source and binary application. The source surelly is not derived, you can link *any* libc to your program. But a binary is different. Let start with your example about books: you write a book, you have the copyright of the text, but if you publish it with X publiher, he may use a own font. You can read the book, scan it to extract text (I hope fair use allows it), but not copy the book pages: there is your text, but also copyrighted font. Publisher should check that the two license are compatible, as the user that links with a new library. For binary, it is the same. You can extract libraries and rest of programs (better doing with sources), but until it is one binary, it is a new mixed entity. It is not only linking, it is mixing bytes! Some part of library is linked statically, there are some references in the static part of program. It is a mix and until the two part are mixed (not only linked) you should follow both licenses for copying! Choose any dynamic program in your machine, try to link glibc with an other (not directly derived libc) library... you see how it is hard, and it is very different to an "aggregation". And dynamic links is only the latest step of "merging" the two binaries. Other libraries tend to be more "dynamic", but glibc mixes to much In other word, source A, library B: the binary C is derived both from A and B, but surelly A is not derived by B. So IMHO IANAL, in arguments we should not confuse the sources and the binary in the arguments, so not calling simply "the program". ciao cate > > And I'm simply claiming that a binary doesn't become "derived from" by any > action of linking. > > Even if you link using "ld", even if it's static, the binary is not > "derived from". It's an aggregate. > > "Derivation" has nothing to do with "linking". Either it's derived or it > is not, and "linking" simply doesn't matter. It doesn't matter whether > it's static or dynamic. That's a detail that simply doesn't have anythign > at all to do with "derivative work". > > THAT is my point. > > Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, > static linking aggregates the library with the other program in the same > binary. There's no question about that. And that _does_ have meaning from > a copyright law angle, since if you don't have permission to ship > aggregate works under the license, then you can't ship said binary. It's > just a non-issue in the specific case of the GPLv2. > > In the presense of dynamic linking the binary isn't even an aggregate > work. > > THAT is the difference between static and dynamic. A simple command line > flag to the linker shouldn't really reasonably be considered to change > "derivation" status. > > Either something is derived, or it's not. If it's derived, "ld", > "mkisofs", "putting them close together" or "shipping them on totally > separate CD's" doesn't matter. It's still derived. > > Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-18 19:42 ` Linus Torvalds 2006-12-18 20:37 ` Alexandre Oliva @ 2006-12-19 8:00 ` Sanjoy Mahajan 2006-12-19 13:09 ` Horst H. von Brand 1 sibling, 1 reply; 59+ messages in thread From: Sanjoy Mahajan @ 2006-12-19 8:00 UTC (permalink / raw) To: Linus Torvalds; +Cc: Alexandre Oliva, Ricardo Galli, linux-kernel Linus Torvalds wrote: > That said, I think they are still pushing the "you don't have any > rights unless we give you additional rights explicitly" angle a bit > too hard. >From section 2 (GPLv3, draft 2): This License acknowledges your rights of "fair use" or other equivalent, as provided by copyright law. By choosing 'acknowledges' as the verb, the licensee says explicitly that fair-use rights are already yours, not that they are being given to you. -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 8:00 ` Sanjoy Mahajan @ 2006-12-19 13:09 ` Horst H. von Brand 2006-12-19 17:27 ` Sanjoy Mahajan 2006-12-20 1:06 ` Alexandre Oliva 0 siblings, 2 replies; 59+ messages in thread From: Horst H. von Brand @ 2006-12-19 13:09 UTC (permalink / raw) To: Sanjoy Mahajan Cc: Linus Torvalds, Alexandre Oliva, Ricardo Galli, linux-kernel Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> wrote: > Linus Torvalds wrote: > > That said, I think they are still pushing the "you don't have any > > rights unless we give you additional rights explicitly" angle a bit > > too hard. > > From section 2 (GPLv3, draft 2): > > This License acknowledges your rights of "fair use" or other > equivalent, as provided by copyright law. > > By choosing 'acknowledges' as the verb, the licensee says explicitly > that fair-use rights are already yours, not that they are being given > to you. Pure noise, a license can't take them away in any case. [That is my pet pevee with GPL: It has a bit of legally binding text, and lots of "explanation" and "philosophy" that don't add anything but confusion. A clear-cut license plus an explanation/comment would have been better. IMHO, IANAL. HAND.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 13:09 ` Horst H. von Brand @ 2006-12-19 17:27 ` Sanjoy Mahajan 2006-12-20 1:06 ` Alexandre Oliva 1 sibling, 0 replies; 59+ messages in thread From: Sanjoy Mahajan @ 2006-12-19 17:27 UTC (permalink / raw) To: Horst H. von Brand Cc: Linus Torvalds, Alexandre Oliva, Ricardo Galli, linux-kernel >> [GPL acknowledging fair-use rights] > Pure noise, a license can't take them away in any case. A bare license probably cannot take them away, since you haven't agreed to anything. But (1) that may not be true in all legal systems, and (2) a contract-based license can take it away (e.g. an NDA). So the GPL's clarification is worthwhile. For the same reason, I'm guessing, the Creative Commons licenses have (also in section 2, at least in v2.5): 2. Fair Use Rights. Nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use, first sale or other limitations on the exclusive rights of the copyright owner under copyright law or other applicable laws. -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-19 13:09 ` Horst H. von Brand 2006-12-19 17:27 ` Sanjoy Mahajan @ 2006-12-20 1:06 ` Alexandre Oliva 1 sibling, 0 replies; 59+ messages in thread From: Alexandre Oliva @ 2006-12-20 1:06 UTC (permalink / raw) To: Horst H. von Brand Cc: Sanjoy Mahajan, Linus Torvalds, Ricardo Galli, linux-kernel On Dec 19, 2006, "Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote: > Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> wrote: >> This License acknowledges your rights of "fair use" or other >> equivalent, as provided by copyright law. >> By choosing 'acknowledges' as the verb, the licensee says explicitly >> that fair-use rights are already yours, not that they are being given >> to you. > Pure noise, a license can't take them away in any case. Yeah, that's merely informative, indeed. Point is to ensure people know their rights, while at the same time avoiding giving impressions such the one Linus somehow got. > [That is my pet pevee with GPL: It has a bit of legally binding text, and > lots of "explanation" and "philosophy" that don't add anything but > confusion. A clear-cut license plus an explanation/comment would have been > better. IMHO, IANAL. HAND.] This bit would probably fit better in the spirit (preamble) than in the letter. That's why I filed the comment about it in the preamble. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
@ 2006-12-14 0:32 Greg KH
2006-12-14 0:43 ` Jonathan Corbet
2006-12-14 0:55 ` Greg KH
0 siblings, 2 replies; 59+ messages in thread
From: Greg KH @ 2006-12-14 0:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel
On Wed, Dec 13, 2006 at 02:09:11PM -0800, Greg KH wrote:
> On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote:
> > On Wed, 13 Dec 2006 13:32:50 -0800
> > Martin Bligh <mbligh@mbligh.org> wrote:
> >
> > > So let's come out and ban binary modules, rather than pussyfooting
> > > around, if that's what we actually want to do.
> >
> > Give people 12 months warning (time to work out what they're going to do,
> > talk with the legal dept, etc) then make the kernel load only GPL-tagged
> > modules.
> >
> > I think I'd favour that. It would aid those people who are trying to
> > obtain device specs, and who are persuading organisations to GPL their drivers.
>
> Ok, I have no objection to that at all. I'll whip up such a patch in a
> bit to spit out kernel log messages whenever such a module is loaded so
> that people have some warning.
Here you go. The wording for the feature-removal-schedule.txt file
could probably be cleaned up. Any suggestions would be welcome.
thanks,
greg k-h
-----------
From: Greg Kroah-Hartmna <gregkh@suse.de>
Subject: Notify non-GPL module loading will be going away in January 2008
Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright. Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been set.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Documentation/feature-removal-schedule.txt | 9 +++++++++
kernel/module.c | 6 +++++-
2 files changed, 14 insertions(+), 1 deletion(-)
--- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
+++ gregkh-2.6/Documentation/feature-removal-schedule.txt
@@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
---------------------------
+
+What: non GPL licensed modules will able to be loaded successfully.
+When: January 2008
+Why: Numerous kernel developers feel that loading non-GPL drivers into the
+ kernel violates the license of the kernel and their copyright.
+
+Who: Greg Kroah-Hartman <greg@kroah.com> or <gregkh@suse.de>
+
+---------------------------
--- gregkh-2.6.orig/kernel/module.c
+++ gregkh-2.6/kernel/module.c
@@ -1393,9 +1393,13 @@ static void set_license(struct module *m
license = "unspecified";
if (!license_is_gpl_compatible(license)) {
- if (!(tainted & TAINT_PROPRIETARY_MODULE))
+ if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
printk(KERN_WARNING "%s: module license '%s' taints "
"kernel.\n", mod->name, license);
+ printk(KERN_WARNING "%s: This module will not be able "
+ "to be loaded after January 1, 2008 due to its "
+ "license.\n", mod->name);
+ }
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
}
}
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:32 GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Greg KH @ 2006-12-14 0:43 ` Jonathan Corbet 2006-12-14 0:55 ` Greg KH 1 sibling, 0 replies; 59+ messages in thread From: Jonathan Corbet @ 2006-12-14 0:43 UTC (permalink / raw) To: Greg KH Cc: Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Greg's patch: > + printk(KERN_WARNING "%s: This module will not be able " > + "to be loaded after January 1, 2008 due to its " > + "license.\n", mod->name); If you're going to go ahead with this, shouldn't the message say that the module will not be loadable into *kernels released* after January 1, 2008? I bet a lot of people would read the above to say that their system will just drop dead of a New Year's hangover, and they'll freak. I wouldn't want to be the one getting all the email at that point... jon ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:43 ` Jonathan Corbet (?) @ 2006-12-14 0:55 ` Greg KH 2006-12-14 4:15 ` Linus Torvalds -1 siblings, 1 reply; 59+ messages in thread From: Greg KH @ 2006-12-14 0:55 UTC (permalink / raw) To: Jonathan Corbet Cc: Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Wed, Dec 13, 2006 at 05:43:29PM -0700, Jonathan Corbet wrote: > Greg's patch: > > > + printk(KERN_WARNING "%s: This module will not be able " > > + "to be loaded after January 1, 2008 due to its " > > + "license.\n", mod->name); > > If you're going to go ahead with this, shouldn't the message say that > the module will not be loadable into *kernels released* after January 1, > 2008? I bet a lot of people would read the above to say that their > system will just drop dead of a New Year's hangover, and they'll freak. > I wouldn't want to be the one getting all the email at that point... Heh, good point. An updated version is below. Oh, and for those who have asked me how we would enforce this after this date if this decision is made, I'd like to go on record that I will be glad to take whatever legal means necessary to stop people from violating this. Someone also mentioned that we could just put a nice poem into the kernel module image in order to be able to enforce our copyright license in any court of law. Full bellies of fish Penguins sleep under the moon Dream of wings that fly thanks, greg k-h -------------- From: Greg Kroah-Hartmna <gregkh@suse.de> Subject: Notify non-GPL module loading will be going away in January 2008 Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- Documentation/feature-removal-schedule.txt | 9 +++++++++ kernel/module.c | 7 ++++++- 2 files changed, 15 insertions(+), 1 deletion(-) --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt +++ gregkh-2.6/Documentation/feature-removal-schedule.txt @@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --------------------------- + +What: non GPL licensed modules will able to be loaded successfully. +When: January 2008 +Why: Numerous kernel developers feel that loading non-GPL drivers into the + kernel violates the license of the kernel and their copyright. + +Who: Greg Kroah-Hartman <greg@kroah.com> <gregkh@novell.com> + +--------------------------- --- gregkh-2.6.orig/kernel/module.c +++ gregkh-2.6/kernel/module.c @@ -1393,9 +1393,14 @@ static void set_license(struct module *m license = "unspecified"; if (!license_is_gpl_compatible(license)) { - if (!(tainted & TAINT_PROPRIETARY_MODULE)) + if (!(tainted & TAINT_PROPRIETARY_MODULE)) { printk(KERN_WARNING "%s: module license '%s' taints " "kernel.\n", mod->name, license); + printk(KERN_WARNING "%s: This module will not be able " + "to be loaded in any kernel released after " + "January 1, 2008 due to its license.\n", + mod->name); + } add_taint_module(mod, TAINT_PROPRIETARY_MODULE); } } ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH @ 2006-12-14 4:15 ` Linus Torvalds 2006-12-14 15:46 ` Jeff Garzik 0 siblings, 1 reply; 59+ messages in thread From: Linus Torvalds @ 2006-12-14 4:15 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Wed, 13 Dec 2006, Greg KH wrote: > > Numerous kernel developers feel that loading non-GPL drivers into the > kernel violates the license of the kernel and their copyright. Because > of this, a one year notice for everyone to address any non-GPL > compatible modules has been set. Btw, I really think this is shortsighted. It will only result in _exactly_ the crap we were just trying to avoid, namely stupid "shell game" drivers that don't actually help anything at all, and move code into user space instead. What was the point again? Was the point to alienate people by showing how we're less about the technology than about licenses? Was the point to show that we think we can extend our reach past derived work boundaries by just saying so? The silly thing is, the people who tend to push most for this are the exact SAME people who say that the RIAA etc should not be able to tell people what to do with the music copyrights that they own, and that the DMCA is bad because it puts technical limits over the rights expressly granted by copyright law. Doesn't anybody else see that as being hypocritical? So it's ok when we do it, but bad when other people do it? Somehow I'm not surprised, but I still think it's sad how you guys are showing a marked two-facedness about this. The fact is, the reason I don't think we should force the issue is very simple: copyright law is simply _better_off_ when you honor the admittedly gray issue of "derived work". It's gray. It's not black-and-white. But being gray is _good_. Putting artificial black-and-white technical counter-measures is actually bad. It's bad when the RIAA does it, it's bad when anybody else does it. If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview. We should make decisions on TECHNICAL MERIT. And this one is clearly being pushed on anything but. I happen to believe that there shouldn't be technical measures that keep me from watching my DVD or listening to my music on whatever device I damn well please. Fair use, man. But it should go the other way too: we should not try to assert _our_ copyright rules on other peoples code that wasn't derived from ours, or assert _our_ technical measures that keep people from combining things their way. If people take our code, they'd better behave according to our rules. But we shouldn't have to behave according to the RIAA rules just because we _listen_ to their music. Similarly, nobody should be forced to behave according to our rules just because they _use_ our system. There's a big difference between "copy" and "use". It's exatcly the same issue whether it's music or code. You can't re-distribute other peoples music (becuase it's _their_ copyright), but they shouldn't put limits on how you personally _use_ it (because it's _your_ life). Same goes for code. Copyright is about _distribution_, not about use. We shouldn't limit how people use the code. Oh, well. I realize nobody is likely going to listen to me, and everybody has their opinion set in stone. That said, I'm going to suggest that you people talk to your COMPANY LAWYERS on this, and I'm personally not going to merge that particular code unless you can convince the people you work for to merge it first. In other words, you guys know my stance. I'll not fight the combined opinion of other kernel developers, but I sure as hell won't be the first to merge this, and I sure as hell won't have _my_ tree be the one that causes this to happen. So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees first. This is not something where we use my tree as a way to get it to other trees. This is something where the push had better come from the other direction. Because I think it's stupid. So use somebody else than me to push your political agendas, please. Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds @ 2006-12-14 15:46 ` Jeff Garzik 2006-12-14 17:03 ` Linus Torvalds 0 siblings, 1 reply; 59+ messages in thread From: Jeff Garzik @ 2006-12-14 15:46 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Linus Torvalds wrote: > Because I think it's stupid. So use somebody else than me to push your > political agendas, please. ACK, I agree completely. I think its a silly, political, non-technical decision being pushed here. For the record, I also disagree with the sneaky backdoor way people want to add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need. EXPORT_SYMBOL_GPL() is more to emphasize that certain symbols are more 'internal' or frequently changed, and therefore use of them would imply you are using a derived work of the kernel. EXPORT_SYMBOL_GPL() is /not/ a place for political activism either. Jeff ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:46 ` Jeff Garzik @ 2006-12-14 17:03 ` Linus Torvalds 2006-12-14 17:08 ` Chris Wedgwood 0 siblings, 1 reply; 59+ messages in thread From: Linus Torvalds @ 2006-12-14 17:03 UTC (permalink / raw) To: Jeff Garzik Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, 14 Dec 2006, Jeff Garzik wrote: > > For the record, I also disagree with the sneaky backdoor way people want to > add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need. I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done properly (and I think we use it fairly well). I think we _can_ do things where we give clear hints to people that "we think this is such an internal Linux thing that you simply cannot use this without being considered a derived work". It's really just a strong hint about what we consider to be internal. The fact is, "intent" actually does matter, and as such our _intent_ in saying "these are very deep and internal interfaces" is actually meaningful - even in a court of law. So I personally don't see EXPORT_SYMBOL_GPL() to be a "technical measure", I see it as being "documentation". That said, I think that some people seem to be a bit over-eager to use it. And I actually think that weakens the rest of them too (imagine a lawyer saying in front of a judge: "Look, they marked 'strcpy()' as a symbol that requires us to be GPL'd, but look, it's a standard function available everywhere else too, and you can implement it as one line of code, so a module that uses it clearly is NOT a derived work, so EXPORT_SYMBOL_GPL is obviously not something that means anything" So this is why I've actually argued in the past for some EXPORT_SYMBOL_GPL's to be demoted to "normal" EXPORT_SYMBOL's. Exactly because over-using them actually _weakens_ them, and makes them pointless both from a documentation _and_ from a legal standpoint. Btw, I've actually had a lawyer tell me that EXPORT_SYMBOL_GPL makes legal sense and has actually made people happier, for what its worth. Of course, you can get <n*2> different opinions from <n> lawyers, so that may not be all that meaningful ;) Linus ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:03 ` Linus Torvalds @ 2006-12-14 17:08 ` Chris Wedgwood 2006-12-14 17:38 ` Christoph Hellwig 0 siblings, 1 reply; 59+ messages in thread From: Chris Wedgwood @ 2006-12-14 17:08 UTC (permalink / raw) To: Linus Torvalds Cc: Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if > done properly (and I think we use it fairly well). > > I think we _can_ do things where we give clear hints to people that > "we think this is such an internal Linux thing that you simply > cannot use this without being considered a derived work". Then why not change the name to something more along those lines? ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:08 ` Chris Wedgwood @ 2006-12-14 17:38 ` Christoph Hellwig 2006-12-14 17:52 ` Chris Wedgwood 0 siblings, 1 reply; 59+ messages in thread From: Christoph Hellwig @ 2006-12-14 17:38 UTC (permalink / raw) To: Chris Wedgwood Cc: Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 09:08:41AM -0800, Chris Wedgwood wrote: > On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: > > > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if > > done properly (and I think we use it fairly well). > > > > I think we _can_ do things where we give clear hints to people that > > "we think this is such an internal Linux thing that you simply > > cannot use this without being considered a derived work". > > Then why not change the name to something more along those lines? Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:38 ` Christoph Hellwig @ 2006-12-14 17:52 ` Chris Wedgwood 2006-12-14 18:09 ` Jan Engelhardt 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen 0 siblings, 2 replies; 59+ messages in thread From: Chris Wedgwood @ 2006-12-14 17:52 UTC (permalink / raw) To: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: > Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. A quick grep shows that changing this now would require updating nearly 1900 instances, so patches to do this would be pretty large and disruptive (though we could support both during a transition and migrate them over time). ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:52 ` Chris Wedgwood @ 2006-12-14 18:09 ` Jan Engelhardt 2006-12-18 10:28 ` GPL only modules Eric W. Biederman 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen 1 sibling, 1 reply; 59+ messages in thread From: Jan Engelhardt @ 2006-12-14 18:09 UTC (permalink / raw) To: Chris Wedgwood Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Dec 14 2006 09:52, Chris Wedgwood wrote: >On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: > >> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. > >A quick grep shows that changing this now would require updating >nearly 1900 instances, so patches to do this would be pretty large and >disruptive (though we could support both during a transition and >migrate them over time). I'd prefer to do it at once. But that's not my decision so you anyway do what you want. That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL is somehow contrary. Just a wording issue. -`J' -- ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-14 18:09 ` Jan Engelhardt @ 2006-12-18 10:28 ` Eric W. Biederman 0 siblings, 0 replies; 59+ messages in thread From: Eric W. Biederman @ 2006-12-18 10:28 UTC (permalink / raw) To: Jan Engelhardt Cc: Chris Wedgwood, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> writes: > On Dec 14 2006 09:52, Chris Wedgwood wrote: >>On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: >> >>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. >> >>A quick grep shows that changing this now would require updating >>nearly 1900 instances, so patches to do this would be pretty large and >>disruptive (though we could support both during a transition and >>migrate them over time). > > I'd prefer to do it at once. But that's not my decision so you anyway do what > you want. > > That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL > is somehow contrary. Just a wording issue. I would suggest that we make the prefix MODULE and not EXPORT. It more accurately conveys what we are trying to say, and it doesn't have the conflicting problem with INTERNAL. I don't know if it is actually worth doing a great rename for such a simple clarification in language. But it is worth considering because it would more strongly convey that we don't expect these symbols to be used by everything. Eric ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:52 ` Chris Wedgwood 2006-12-14 18:09 ` Jan Engelhardt @ 2006-12-14 18:15 ` Eric Sandeen 2006-12-14 18:39 ` Chris Wedgwood 1 sibling, 1 reply; 59+ messages in thread From: Eric Sandeen @ 2006-12-14 18:15 UTC (permalink / raw) To: Chris Wedgwood Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Chris Wedgwood wrote: > On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: > >> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. > > A quick grep shows that changing this now would require updating > nearly 1900 instances, so patches to do this would be pretty large and > disruptive (though we could support both during a transition and > migrate them over time). Please don't use that name, it strikes me as much more confusing than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite convey what it means, either. EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least something which is not internally inconsistent would be good (how is something which is exported "internal?") And, as long as EXPORT_SYMBOL_GPL continues to check that the module using it has a GPL license, then it really -is- exactly descriptive of what it's doing and probably shouldn't be changed. IIMHO. -Eric ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen @ 2006-12-14 18:39 ` Chris Wedgwood 2006-12-14 19:42 ` Scott Preece 0 siblings, 1 reply; 59+ messages in thread From: Chris Wedgwood @ 2006-12-14 18:39 UTC (permalink / raw) To: Eric Sandeen Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > Please don't use that name, it strikes me as much more confusing > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite > convey what it means, either. Calling internal symbols _INTERNAL is confusing? > EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least > something which is not internally inconsistent would be good (how is > something which is exported "internal?") But those symbols aren't, they're about internal interfaces that might change. > And, as long as EXPORT_SYMBOL_GPL continues to check that the module > using it has a GPL license, then it really -is- exactly descriptive > of what it's doing and probably shouldn't be changed. IIMHO. Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about documenting things, why restrict who can use them based on the license? Surely the licence is more about tainting the kernel and debugging not politics? Do we even need to check the license at all in that case? Maybe a better idea would be to embed where the source code is located and use the non-existence of that for a tainting? ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:39 ` Chris Wedgwood @ 2006-12-14 19:42 ` Scott Preece 2006-12-14 19:34 ` Jeff V. Merkey 0 siblings, 1 reply; 59+ messages in thread From: Scott Preece @ 2006-12-14 19:42 UTC (permalink / raw) To: Chris Wedgwood Cc: Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote: > On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > > > Please don't use that name, it strikes me as much more confusing > > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite > > convey what it means, either. > > Calling internal symbols _INTERNAL is confusing? I think it's the combination of "INTERNAL" and "EXPORT" that seems contradictory - "If it's internal, why are you exporting it?" I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the meaning clearer, but I don't really think the gain is worth the pain. Anybody using kernel interfaces ought to be able to figure it out. > > But those symbols aren't, they're about internal interfaces that might > change. Folks who think this is likely to make a difference in court might want to look at <http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a litany of court cases that have rejected infringement claims where a much sterner effort had been made to hide or block use of interfaces. The article claims that courts have increasingly found that interfacing your code to an existing work is not infringement, regardless of what you have to work around to do it. Of course, that's one author's reading of the case law and I'm sure there are others who disagree, but it's something you'd want to keep in mind in calculating the expected value of a suit... scott ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:42 ` Scott Preece @ 2006-12-14 19:34 ` Jeff V. Merkey 2006-12-15 5:28 ` GPL only modules Alexandre Oliva 0 siblings, 1 reply; 59+ messages in thread From: Jeff V. Merkey @ 2006-12-14 19:34 UTC (permalink / raw) To: Scott Preece Cc: Chris Wedgwood, Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel This whole effort is pointless. This is the same kind of crap MICROSOFT DOES to create incompatibilities DELIBERATELY. The code is either FREE or its NOT FREE. If the code is FREE then let it be. You can put whatever you want in the code -- I will remove any such constructs, just like I remove them frm Red Hat's releases when they put in the same kind of deliberate breakage for anti-competitive reasons. You can go and yell at Novell too, since they do the SAME THING with their releases and mix their modules with Linux. All someone has to do or say is. "... I did not ever accept the GPL license with the FREE code I was given. They said the code was FREE, and I took them at their word. .." FREE implies a transfer of ownsership and you also have to contend with the Doctrine of Estoppel. i.e. if someone has been using the code for over two years, and you have not brought a cause of action, you are BARRED from doing so under the Doctrine of Estoppel and statute of limitations. Here's what that means so you can look it up: http://en.wikigadugi.org/wiki/Estoppel What Linus argued is that FREE means just that. Jeff Scott Preece wrote: > On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote: > >> On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: >> >> > Please don't use that name, it strikes me as much more confusing >> > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite >> > convey what it means, either. >> >> Calling internal symbols _INTERNAL is confusing? > > > I think it's the combination of "INTERNAL" and "EXPORT" that seems > contradictory - "If it's internal, why are you exporting it?" > > I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the > meaning clearer, but I don't really think the gain is worth the pain. > Anybody using kernel interfaces ought to be able to figure it out. > >> >> But those symbols aren't, they're about internal interfaces that might >> change. > > > Folks who think this is likely to make a difference in court might > want to look at > <http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a > litany of court cases that have rejected infringement claims where a > much sterner effort had been made to hide or block use of interfaces. > The article claims that courts have increasingly found that > interfacing your code to an existing work is not infringement, > regardless of what you have to work around to do it. > > Of course, that's one author's reading of the case law and I'm sure > there are others who disagree, but it's something you'd want to keep > in mind in calculating the expected value of a suit... > > scott > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: GPL only modules 2006-12-14 19:34 ` Jeff V. Merkey @ 2006-12-15 5:28 ` Alexandre Oliva 0 siblings, 0 replies; 59+ messages in thread From: Alexandre Oliva @ 2006-12-15 5:28 UTC (permalink / raw) To: Jeff V. Merkey Cc: Scott Preece, Chris Wedgwood, Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Dec 14, 2006, "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> wrote: > FREE implies a transfer of ownsership It's about freedom, not price. And even then, it's the license that has not cost, not the copyright. > and you also have to contend with the Doctrine of Estoppel. i.e. if > someone has been using the code for over two years, and you have not > brought a cause of action, you are BARRED from doing so under the > Doctrine of Estoppel and statute of limitations. Sure, but we're not necessarily talking about code that is two years old. We're talking about future releases. Then, if someone interfaces with code that was already there before, they might claim they're still entitled to do so. But if it's new code they interface with, or new code they wrote after this clarification is published, would they still be entitled to estoppel? FWIW, IANAL. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2006-12-20 23:28 UTC | newest] Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-12-16 18:27 GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Ricardo Galli 2006-12-16 21:01 ` Linus Torvalds 2006-12-17 0:22 ` Ricardo Galli 2006-12-17 4:10 ` Theodore Tso 2006-12-17 13:54 ` GPL only modules Alexandre Oliva 2006-12-17 15:56 ` Ricardo Galli 2006-12-17 16:25 ` Kyle Moffett 2006-12-17 21:32 ` David Schwartz 2006-12-17 21:46 ` D. Hazelton 2006-12-18 15:47 ` Dave Neuer 2006-12-18 17:46 ` D. Hazelton 2006-12-18 21:01 ` Dave Neuer 2006-12-18 17:16 ` David Schwartz 2006-12-19 6:35 ` D. Hazelton 2006-12-19 16:39 ` David Lang 2006-12-18 19:41 ` Alexandre Oliva 2006-12-18 22:14 ` Christoph Hellwig 2006-12-19 3:42 ` D. Hazelton 2006-12-20 1:02 ` Alexandre Oliva 2006-12-20 23:28 ` Scott Preece 2006-12-17 17:59 ` Linus Torvalds 2006-12-17 22:45 ` Paul Mackerras 2006-12-18 6:50 ` Junio C Hamano 2006-12-18 23:16 ` Paul Mackerras 2006-12-18 15:38 ` Dave Neuer 2006-12-18 17:02 ` Theodore Tso 2006-12-18 17:23 ` Dave Neuer 2006-12-18 19:27 ` Alexandre Oliva 2006-12-18 19:42 ` Linus Torvalds 2006-12-18 20:37 ` Alexandre Oliva 2006-12-18 20:50 ` Linus Torvalds 2006-12-18 21:23 ` David Schwartz 2006-12-18 22:35 ` Scott Preece 2006-12-19 1:29 ` David Schwartz 2006-12-19 16:55 ` Scott Preece 2006-12-20 0:09 ` Alexandre Oliva 2006-12-20 0:06 ` Alexandre Oliva 2006-12-18 22:06 ` Jeff V. Merkey 2006-12-18 23:28 ` Alexandre Oliva 2006-12-19 1:35 ` David Schwartz 2006-12-19 2:38 ` D. Hazelton 2006-12-19 12:42 ` Horst H. von Brand 2006-12-20 0:20 ` Alexandre Oliva 2006-12-18 23:52 ` Paul Mackerras 2006-12-18 23:59 ` Linus Torvalds 2006-12-19 0:43 ` Paul Mackerras 2006-12-19 1:39 ` David Schwartz 2006-12-19 4:20 ` Daniel Barkalow 2006-12-20 19:14 ` David Schwartz 2006-12-20 23:08 ` Scott Preece 2006-12-20 23:26 ` David Schwartz 2006-12-19 7:39 ` Giacomo A. Catenazzi 2006-12-19 7:40 ` Giacomo A. Catenazzi 2006-12-19 8:00 ` Sanjoy Mahajan 2006-12-19 13:09 ` Horst H. von Brand 2006-12-19 17:27 ` Sanjoy Mahajan 2006-12-20 1:06 ` Alexandre Oliva -- strict thread matches above, loose matches on Subject: below -- 2006-12-14 0:32 GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Greg KH 2006-12-14 0:43 ` Jonathan Corbet 2006-12-14 0:55 ` Greg KH 2006-12-14 4:15 ` Linus Torvalds 2006-12-14 15:46 ` Jeff Garzik 2006-12-14 17:03 ` Linus Torvalds 2006-12-14 17:08 ` Chris Wedgwood 2006-12-14 17:38 ` Christoph Hellwig 2006-12-14 17:52 ` Chris Wedgwood 2006-12-14 18:09 ` Jan Engelhardt 2006-12-18 10:28 ` GPL only modules Eric W. Biederman 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen 2006-12-14 18:39 ` Chris Wedgwood 2006-12-14 19:42 ` Scott Preece 2006-12-14 19:34 ` Jeff V. Merkey 2006-12-15 5:28 ` GPL only modules Alexandre Oliva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).