On Tue, 5 Feb 2008 13:46:08 +0200 "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> Hi David, > > Marcel Holtmann writes: > > > You driver was meant to be running as Linux kernel module and > > > thus it is derivative work. > > On Feb 5, 2008 1:39 PM, David Newall <[EMAIL PROTECTED]> wrote: > > It is precisely the fact that it is a loadable module, and does not > > form part of the kernel, that removes the requirement to distribute > > it under GPL. > > What makes you qualified to make that statement (without giving any > evidence)? Are you're an expert on international copyright law? Are you? You've made some very definite statements about copyright law. Things that I've been told are definitely in a gray area and not at all as clear cut as you and the FSF likes to say. FSF has a very clear agenda, and taking what they say as the gospel is a big mistake. If I link a binary .o file into a static kernel image, does that make it a derivative work of the kernel? It most definitely violates the GPL in that the total is a derivative work, but does it really make the .o file a derivative work? What if I let the user do the linking at runtime? But as Alan Cox wrote, how the linking is done doesn't decide if it is a derivative work or not, copyright law does. So what does make it a derivative work then? If I use an in kernel API, but from a piece of code which is external to the kernel, is that really a derived work? If you say it is, do you realise that you are advocating something which is very close to an API copyright, something which I think most open source people are very adverse to. If API copyrights were valid, Wine, or editline, or lesstiff would be in a lot of trouble. Of course, the Linux headers don't only define an API, they also contain a lot of inline code. But if I don't care about an extra jump, I could write a glue layer between the Linux kernel and some proprietary code that wraps all inline functions. In that case, is a module written against that glue layer a derivative work of the kernel? If I write a glue layer that allows me to run the same driver in userspace via libusb and directly in the kernel, and give the user a choice to link my binary .o file either the userspace or kernel space glue, does that make my code a derivative work of the kernel? Most probably not, it is independent of the kernel in that case. So where is the line in the sand that makes it clearly a derivative work? It's up to the courts to decide, and until there is a clear and final court ruling it is a gray area. Lawyers can guess at what the outcome might be, and some companies are apparently willing to take the risk that it isn't as clear cut as you think. /Christer - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
