Non-GPL Linux Kernel Modules Banned Starting January 2008?

[Ice9]

Seen on OSNews
Includes a pretty lengthy answer from Linus himself.
I tend to be on the same wavelength and don't see how limiting the user's choice could be good for linux, although I'm sure there are very valid technical reasons to just do what the kernel devs want to do.

Make sure you also read the comments, there are some very valid points in there too.

[Calum]

I also 100% agree with Torvalds. He has very eloquently put the common sense argument forward.

[JoeDude]

I think I'm going to have to agree with Linus as well. I don't believe for one minute it's going to leverage manufacturers into producing linux drivers, it's only going to alienate more users because of compatability issues...

[Void Main]

This is the first I've heard this little ditty and I really haven't read enough about it to make an informed comment on it. But here it goes anyway. :) Initially I don't really see this as a big deal. I don't really see the patch actually making it into the kernel.org source tree and even if it did any distro's implementation would have no problem patching it right back out. I normally come down on the side of Freedom in cases like this. In other words I might normally be "for" a patch like this but in this particular case I might tend to agree with Linus. I'll try and read some more discussion on the subject and maybe I would be willing to take a stronger stand one way or the other.

[piratepenguin]

Kernel dev's feeling non-GPL modules are illegal (which, I believe, they are .. but I've never heard the "grayness" Linus is talking about) is one thing .. How many of them think non-GPL modules are wrong?

Obviously not enough (unsurprising from the open source movement, I believe), since as far as I've heard nobody's been sued or anything like that. If I'd coded the relevant parts of Linux, I imagine I'd be demanding GPL compliance from the likes of ATi if I could, but I didn't write that code.

I don't think banning non-GPL modules from inside the kernel is a great idea (although printing a notification is). The users aren't infringing on the GPL, afterall.

[Void Main]

I'm not so sure binary kernel modules do infringe on the GPL. I was also under the belief that if there were in fact issues that Linus had basically included a ryder giving reprieve to binary kernel modules which was totally acceptable as I understand the GPL. I have to go back and check my facts on this but I think that's how things have pretty much been since the beginning. Of course I would like to see all modules be open but I would also like to see all applications be open. There are some similarities in the relationships of the two (modules->kernel, apps->kernel).

EDIT: The ryder I was thinking of actually refers to user applications:

http://www.kernel.org/pub/linux/kernel/COPYING

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the linux
kernel) is copyrighted by me and others who actually wrote it.

I have always had the impression that Linus thinks of modules in the same light. Since it is the kernel it's totally up to Linus whether or not to allow such a patch in the kernel.org source tree. He's the kernel's daddy so I would personally defer to him any issues like this relating to the kernel.

[Void Main]

It appears the that patch proposal has been withdrawn:

http://lkml.org/lkml/2006/12/14/63

Summary: The GPL covers distribution not usage.

[Ice9]

It's cool that he actually admits that Linus is "right" in this case and that his reaction could have been somewhat tainted by the crap he's exposed to on a daily basis.
For the kernel devs it might not be an issue about two tiny graphics drivers but judging by all the comments the end users clearly felt different about it.

[piratepenguin]

I'm not so sure binary kernel modules do infringe on the GPL. I was also under the belief that if there were in fact issues that Linus had basically included a ryder giving reprieve to binary kernel modules which was totally acceptable as I understand the GPL.

Linus can't do that, because he doesn't own the code. It's well understood that the code is under the GPL, but do patch authors have to accept any other terms? I don't think so.

There are some similarities in the relationships of the two (modules->kernel, apps->kernel).

Apps don't usually link with the kernel in any shape or form, but through libraries. The GNU C library isn't licensed under the GPL, but the LGPL, for a good reason.

[Void Main]

I'm not so sure binary kernel modules do infringe on the GPL. I was also under the belief that if there were in fact issues that Linus had basically included a ryder giving reprieve to binary kernel modules which was totally acceptable as I understand the GPL.

Linus can't do that, because he doesn't own the code. It's well understood that the code is under the GPL, but do patch authors have to accept any other terms? I don't think so.

Actually Linus is the one who put the Linux kernel under the GPL in the first place and in fact did exactly that (added a ryder statement at the top of the GPL) and at that time he did have sole copyright on all of the code in the kernel since he was the one who at the time had written 100% of it. Go look at the "COPYING" file in the root directory of the kernel source. Also, Linus is still the head guy as far as the main kernel tree at kernel.org is concerned and he regularly rejects patches for many different reasons. He does in fact have that power. Of course there is nothing stopping me from taking that kernel source and adding whatever patches I want.

There are some similarities in the relationships of the two (modules->kernel, apps->kernel).

Apps don't usually link with the kernel in any shape or form, but through libraries. The GNU C library isn't licensed under the GPL, but the LGPL, for a good reason.

But the kernel is a different type of animal. And like I said, the GPL covers distribution only. The Linux kernel does not ship with binary modules so there is no violation of the GPL. Take the nVidia module for instance. The user downloads the binary module and runs the module in the kernel. This is not a GPL violation. Now, if nVidia were to ship an entire Linux kernel along with their binary module then there would certainly be issues but that doesn't happen.

Putting in code to prevent a user from running a binary module if they choose would be akin to DRM and I'm not a fan of DRM. Believe me, I come down on the opposite side of Linus a lot when it comes to Freedom, but this is a case where Linus was right. This is not really even an issue. The person who proposed the patch as already agreed that Linus is right and the patch will not be included. Or are you saying that the kernel might have been better off placed under the LGPL in the first place? That may have actually been a more appropriate license for the kernel but I am not sure if LGPL was available at the time Linus needed a license for his kernel. I think the LGPL was added in 1991.

[piratepenguin]

I'm not so sure binary kernel modules do infringe on the GPL. I was also under the belief that if there were in fact issues that Linus had basically included a ryder giving reprieve to binary kernel modules which was totally acceptable as I understand the GPL.

Linus can't do that, because he doesn't own the code. It's well understood that the code is under the GPL, but do patch authors have to accept any other terms? I don't think so.

Actually Linus is the one who put the Linux kernel under the GPL in the first place and in fact did exactly that (added a ryder statement at the top of the GPL) and at that time he did have sole copyright on all of the code in the kernel since he was the one who at the time had written 100% of it. Go look at the "COPYING" file in the root directory of the kernel source. Also, Linus is still the head guy as far as the main kernel tree at kernel.org is concerned and he regularly rejects patches for many different reasons. He does in fact have that power. Of course there is nothing stopping me from taking that kernel source and adding whatever patches I want.

I know, I know, and I know.

But he owns very little of the kernel these days. The LARGE majority of the code he has no copyright on. In the case of a violation, if it gets to court, he'll be unnecessary in the process. Only whoever might happen to have the copyright on the particular interfaces would (mostly a guess, actually, since it's the only way this makes sense to me).

But the kernel is a different type of animal.

As far as the law is concerned the only difference is the licensing conditions afaik. Linking still results in a derivative work, and under the GPL (unlike with the LGPL) with no extra allowances the new work must be licensed under the GPL. If the people who wrote the interfaces did actually make allowances, which I don't think happened, that would be a different story. Yet still, nobody has taken any action against people redistributing binary blobs (although Novell and some others have stopped redistributing them, since they believe them to be illegal).

And like I said, the GPL covers distribution only. The Linux kernel does not ship with binary modules so there is no violation of the GPL. Take the nVidia module for instance. The user downloads the binary module and runs the module in the kernel. This is not a GPL violation. Now, if nVidia were to ship an entire Linux kernel along with their binary module then there would certainly be issues but that doesn't happen.

Shipping a kernel image wouldn't matter afaik. An nVidia module packaged for Ubuntu (as opposed to downloaded from nvidia.com, where the smallest amount of source code is shipped with the installer and linked at install time by the user (perfectly legal) so that nvidia can't possibly be breaking anybody's copyright), for example, will be questionably illegal to redistribute.

Putting in code to prevent a user from running a binary module if they choose would be akin to DRM and I'm not a fan of DRM. Believe me, I come down on the opposite side of Linus a lot when it comes to Freedom, but this is a case where Linus was right. This is not really even an issue. The person who proposed the patch as already agreed that Linus is right and the patch will not be included.

I also usually come down on the opposite side of Linus when it comes to freedom. I did say in my last post I thought this patch was a bad idea ..

Or are you saying that the kernel might have been better off placed under the LGPL in the first place? That may have actually been a more appropriate license for the kernel but I am not sure if LGPL was available at the time Linus needed a license for his kernel. I think the LGPL was added in 1991.

I generally prefer the GPL. Sounds like the kernel dev's would loove the LGPL, but like you said, it probably wasn't available.

[Void Main]

I'm not so sure binary kernel modules do infringe on the GPL. I was also under the belief that if there were in fact issues that Linus had basically included a ryder giving reprieve to binary kernel modules which was totally acceptable as I understand the GPL.

Linus can't do that, because he doesn't own the code. It's well understood that the code is under the GPL, but do patch authors have to accept any other terms? I don't think so.

Actually Linus is the one who put the Linux kernel under the GPL in the first place and in fact did exactly that (added a ryder statement at the top of the GPL) and at that time he did have sole copyright on all of the code in the kernel since he was the one who at the time had written 100% of it. Go look at the "COPYING" file in the root directory of the kernel source. Also, Linus is still the head guy as far as the main kernel tree at kernel.org is concerned and he regularly rejects patches for many different reasons. He does in fact have that power. Of course there is nothing stopping me from taking that kernel source and adding whatever patches I want.

I know, I know, and I know.

But he owns very little of the kernel these days. The LARGE majority of the code he has no copyright on. In the case of a violation, if it gets to court, he'll be unnecessary in the process. Only whoever might happen to have the copyright on the particular interfaces would (mostly a guess, actually, since it's the only way this makes sense to me).

That is a good point. Since there are thousands of copyright holders to code in the kernel who would bring suit should there be a violation and how hard would it be to determine who's code it is that is actually being violated? Could any one of the copyright holders bring suit? Would all copyright holders have to bring suit? I think the kernel would be considered a single program so without thinking too hard about I would guess any violation would be a violation of the entire program and any copyright holder should be able to bring suit, however, IANAL (but my sister is).

Back to whether patch authors have to abide by the ryder. Generally patches do not change the license of the file that they are patching but if a patch includes an entirely new source file then it could have it's own license and copyright statement. I just looked through some of the source files and any files that are not copyright Linus Torvolds usually have a statement something like this in the comments at the top:

Code: Select all

 * (C) 2006 Joe Shmoe, this code is GPL.


Now, I think the COPYING file would apply to the kernel as a whole which would include any source file in the kernel unless specifically stated otherwise within the source. And of course anything added has to be at least GPL compatible.

But the kernel is a different type of animal.

As far as the law is concerned the only difference is the licensing conditions afaik. Linking still results in a derivative work, and under the GPL (unlike with the LGPL) with no extra allowances the new work must be licensed under the GPL. If the people who wrote the interfaces did actually make allowances, which I don't think happened, that would be a different story. Yet still, nobody has taken any action against people redistributing binary blobs (although Novell and some others have stopped redistributing them, since they believe them to be illegal).

I still don't know that it's a cut and dry violation. I understand that if SUSE or Redhat distribute binary modules that it could be considered a violation but if a vendor ships a module I'm not sure that it would technically be a violation. It doesn't include any GPL code, although it does depend on a GPL program (the kernel) to be useful. If the user of the kernel wants to load a binary module there is absolutely nothing wrong with that as there is no distribution.

I guess as you see it nVidia could be violating the GPL because the FSF might consider that module to be a derivative. Question is, would the courts consider it a derivative? I am sure SCO would certainly consider it a derivative. :) I'm actually not certain that even the FSF would consider kernel modules a derivative. Is a kernel modules relationship to the kernel "linking"? I know what static and dynamic linking is when it comes to libraries but the is the kernel technically a "library"?

I appreciate your input as you seem to be pretty knowledgeable regarding the GPL. This raises my curiosity about your background in this area. :) I have enjoyed learning as much as I can about the GPL and I pick up new things all the time about it. Then it's fun to keep up with the Groklaw happenings to see how the legal process actually works (excruciatingly slow is the one word that comes to mind). This kernel module stuff is one area that is still very gray in my noggin regarding GPL compatibility.

[piratepenguin]

I still don't know that it's a cut and dry violation. I understand that if SUSE or Redhat distribute binary modules that it could be considered a violation but if a vendor ships a module I'm not sure that it would technically be a violation. It doesn't include any GPL code, although it does depend on a GPL program (the kernel) to be useful.

If the module can be considered a derivative work then anybody redistributing it should be able to provide the source code on demand, shouldn't they? I don't see how it would be any different to a vendor and an OS distributor. It doesn't matter that you're not shipping Linux, the module must be available under the GPL (if it is considered a derivative work of Linux).

Nvidia's playing it safe anyhow.

If the user of the kernel wants to load a binary module there is absolutely nothing wrong with that as there is no distribution.

Yep.

I guess as you see it nVidia could be violating the GPL because the FSF might consider that module to be a derivative.

No, Nvidia's playing it safe. The linking (assuming it can be called that) with the kernel happens at install time, by the user, with Nvidia's installer. They ship the smallest amount of source code they can to make this possible.

I'm not sure if ATi do anything similar.

Question is, would the courts consider it a derivative? I am sure SCO would certainly consider it a derivative. I'm actually not certain that even the FSF would consider kernel modules a derivative. Is a kernel modules relationship to the kernel "linking"? I know what static and dynamic linking is when it comes to libraries but the is the kernel technically a "library"?

I'm not sure. The kernel loads the modules itself, doing a similar thing to 'ld'.

http://www.cyberciti.biz/tips/build-lin ... -tree.html
Looking at that (and looking at chapter 2 of this book).. Since you need the kernel headers installed to compile a module, the modules must've #included parts of the linux-kernel-headers at compile time - in particular /usr/include/linux/module.h which seems to be under the GPL too (nothing in the file suggests otherwise).

Is that enough to make modules derivative works?

As for linking I'm not sure, there's certainly nothing involving the traditional ld, the kernel has it's own solution, and I don't know how it works. It might be something to do with the System.maps that are generated when the kernel is compiled. EDIT: reading (at least the first few parts of) that chapter would probably yield a good understanding of how the linking works, but I don't have the time atm.

I appreciate your input as you seem to be pretty knowledgeable regarding the GPL. This raises my curiosity about your background in this area. I have enjoyed learning as much as I can about the GPL and I pick up new things all the time about it. Then it's fun to keep up with the Groklaw happenings to see how the legal process actually works (excruciatingly slow is the one word that comes to mind). This kernel module stuff is one area that is still very gray in my noggin regarding GPL compatibility.

Yeah, I'm pretty much the same IANAL, just interested in this sort of stuff. It'd be interesting to say the least if someone did try to request compliance/press suit (who could? I still amn't sure) e.g. against ATi. I think that's the only way the record would be set straight, but it'll not likely happen.

[Void Main]

http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
Looking at that (and looking at chapter 2 of this book).. Since you need the kernel headers installed to compile a module, the modules must've #included parts of the linux-kernel-headers at compile time - in particular /usr/include/linux/module.h which seems to be under the GPL too (nothing in the file suggests otherwise).

Is that enough to make modules derivative works?

As for linking I'm not sure, there's certainly nothing involving the traditional ld, the kernel has it's own solution, and I don't know how it works. It might be something to do with the System.maps that are generated when the kernel is compiled. EDIT: reading (at least the first few parts of) that chapter would probably yield a good understanding of how the linking works, but I don't have the time atm.

I actually have written simple kernel modules in the past and it really is fairly trivial for a basic module. As far as headers go I have seen a lot of discussion in this area in the past. There is nothing stopping someone from placing functions or code in a header but if the header files contain what header files are designed to contain then I don't see how "#include"ing them in your code would cause your code to become a derivative. Headers usually contain only prototypes and definitions and not actual code (that is specifications for functions contained in associated libraries). However, the real issue would be with the libraries that actually contain the code that the headers are prototyping. In this case the kernel.

But earlier what I meant by the kernel being a different animal is that you can't have an operating system without a kernel. Complex applications depend on the OS and the kernel. The GNU/Linux operating system uses the Linux kernel and ultimately all things that run on the GNU/Linux operating system depend on the Linux kernel. Assume the GNU C library was under the GPL and not the LGPL. I don't *have* to link to the GNU C library to build an application that will run on the GNU/Linux operating system, there are alternative C libraries out there or I can write my own replacement functions. But my app still requires the Linux kernel. The kernel loads my application into memory and manages it when it is run. I don't see this as being significantly different than a kernel module other than a kernel module is run in "kernel space" and my application is run in "user land". It's a tricky area for sure and I think if you can argue that a proprietary Linux kernel module violates the GPL then it wouldn't be that much of a stretch to say that all proprietary applications are also a violation of the GPL.

[piratepenguin]

But earlier what I meant by the kernel being a different animal is that you can't have an operating system without a kernel. Complex applications depend on the OS and the kernel. The GNU/Linux operating system uses the Linux kernel and ultimately all things that run on the GNU/Linux operating system depend on the Linux kernel. Assume the GNU C library was under the GPL and not the LGPL. I don't *have* to link to the GNU C library to build an application that will run on the GNU/Linux operating system, there are alternative C libraries out there or I can write my own replacement functions. But my app still requires the Linux kernel. The kernel loads my application into memory and manages it when it is run. I don't see this as being significantly different than a kernel module other than a kernel module is run in "kernel space" and my application is run in "user land". It's a tricky area for sure and I think if you can argue that a proprietary Linux kernel module violates the GPL then it wouldn't be that much of a stretch to say that all proprietary applications are also a violation of the GPL.

Remember the ryder you mentioned, calling system calls is explicitly != derivative work according to Linus. (he could've just said that to clear up confusion. I'm not sure how system calls are managed the same way as function calls .. I mean, programmers make system calls via a NUMBER)

Yes, you can make system calls yourself to communicate with the kernel and get any job done, but nobody does that. They go through libraries, so the work they're developing rarely ever has anything to do with the kernel and no linking or anything happens with the kernel at compile time. The binaries can well work in other OSes, where all the libraries are ported. The new work has essentially nothing to do with the kernel. The same is not true with modules.