http://lwn.net/Articles/196726/
true expert in "derivative works" under copyr^Hleft regime in the GNU Republic: http://kororaa.org/comments.php?y=06&m=06&entry=entry060614-184527 ------- Dear Chris I apologize for the delay in getting back to you. Your questions generated some discussion over here, and I wanted to make sure we got you the best possible answers. > I have some questions below I am hoping you, or someone, can > answer for me so that I can get some clearer understanding as > to why they are a violation. I've addressed your questions as best I can below. Please feel free to reproduce in full any e-mail that I send you. I ask that you please don't just quote specific portions of the mail, or omit any parts; the context goes a long way to prevent confusion. > > We believe that kernel modules are derivative works of Linux. > Can you explain WHY you believe the kernel modules are > derivative works of Linux? What actually makes them a derivative work? The term "derivative work" is defined in copyright legislation, including all the relevant case law. Put generally, one piece of software is a derivative work of another if the first is combined with the second to provide some functionality. This is true even if the functionality is optional or not commonly used. For example, if a program uses readline to provide support for rich command editing, it's a derivative work of readline. Note that this does require a dependency on a *specific* piece of code, instead of on software that performs a particular function. A wide variety of programs run on systems with the Linux kernel, but they're not all derivative works of Linux: most simply require that the kernel recognize certain system calls, which is more about functionality than particular code. Likewise, web browsers have the capability to interact with web servers, but this does not make the browser a derivative work of any particular server. There is admittedly a fuzzy line here; in close cases, deciding whether one work is a derivative of another is a judgment call, which is why we have courts. But let me be very clear about this: it is impossible to write a kernel module for Linux that isn't a derivative work of Linux. Even if we assume that all these proprietary drivers shun Linux's implementations of common data structures, perform their own memory management, and so on, they still have to register themselves as modules. To do that, they have to use code in the kernel to call functions like module_init(), and that's enough to make the software a derivative work of Linux. The argument in the kerneltrap link you provided that these modules make "no Linux specific calls" is absurd on its face: if they made no Linux-specific calls, they wouldn't be kernel modules. > >If there weren't any special licensing considerations for > > Linux, we would say that those modules must adhere to the > > requirements set forth in the GPL. > So is this due to your understanding that they ARE > derivative works, and therefore also have to be GPL? That's correct. > > In particular, this means that they, too, would be licensed under the > > GPL, and users would be able to obtain source when the work > > is distributed in binary form. In such a case, if there were binary-only > > modules, we would say they were violating Linux's license, along with > > anybody who was distributing them. > Would you be able explain why a binary-only module violates the license? Because such a module is a derivative work, it's subject to the terms in section 2 of the GNU GPL. Again, if there were no special licensing considerations for Linux, binary-only modules would clearly violate section 2(b) of the license. > > Some kernel developers apparently agree with him. Others do not: I > > was at OSCon last year, and I saw Greg Kroah-Hartman give a quick > > presentation about kernel development where he flatly stated that > > binary modules are illegal. > Is this presentation available? He doesn't really elaborate on this issue in the presentation, but slides are available at <http://www.kroah.com/linux/talks/oscon_2005_state_of_the_kernel/>; in particular, see the bottom of <http://www.kroah.com/linux/talks/oscon_2005_state_of_the_kernel/mgp00038.html>. > >It's not clear whether or not Linus' relaxed restrictions are > > meant to apply to the entire Linux kernel, or just his contributions to > > it. > I would assume that he cannot speak for the copyright of code owned by > other developers. That's my understanding as well. > But perhaps he does have some sort of overriding power because > "Linux" is his trademark, I don't know. To the best of my knowledge, this would not give him any special standing. I would expect an argument along the lines of: "Contributors provided code to Linux when it had this license exception, and so it's reasonable to assume that they assented to licensing their code with this exception as well if they didn't say otherwise." Like I said, I think that's a poor argument, and I hope a court would agree, but it probably wouldn't be dismissed out of hand. Instead, we believe that, absent other arrangements, interactions between developers are governed by the license provided in the code being written. Under those terms, every programmer who writes a patch is a licensee of everyone else, and every maintaner who merges that patch is a licensee of the patch author. For most code in Linux, that's the plain GPL, with no exceptions. > Even if he disagrees on behalf of > "Linux" I think that individual developers have the right to enforce > their own copyright. Of course it would have to be a part > against which the violation is occurring. > Surely iptables cannot lay claim to a violation from > a video driver if it has nothing to do with his code? I'm reluctant to give your question a simple yes or no answer, because copyright law sets a standard for "nothing to do with his code" that's probably stricter than you think. To keep things simple, let's assume for the purposes of this discussion that Linux is under the GPL without any exceptions. If you distribute a kernel that includes iptables, and makes use of proprietary video drivers, the iptables developers could likely take action against you. This is because you've distributed a derivative work in violation of section 2 of the GPL -- since again, the whole combination isn't being released under the GPL. The iptables developers may be able to take action against ATI and nVidia directly as well, even if their modules don't have any relationship with iptables itself, by claiming it's contributory infringement. It's against the law to provide material contribution to activity that you know will infringe copyright. It's possible that these companies are doing both: the way they distribute their modules makes it easy to violate the GPL (which infringes the work's copyright), and it seems like they must know this is happening, since expressly allow other parties to distribute their work verbatim. > > It also means that for a program with many copyright holders, like > > Linux, it's at least conceivable that any single one of them could hold > > you accountable for license violations, and that they may not intend > > for their work to have exceptions in the GPL's requirements, > > like Linus apparently does. > Surely they can only lay claim to a violation if it is against their > code? > But I guess it needs some clarification on the copyright of Linux as a > whole, and whether one single piece of code entitles that author to have > copyright on the entire Linux code. It does not. I hope these clarifications help you understand our reasoning better. Again, this is not legal advice. If you still have concerns, I'd be happy to address those; just let me know. Best regards, -- Brett Smith Free Software Foundation Licensing Team ------- regards, alexander. _______________________________________________ gnu-misc-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-misc-discuss
