Proprietary kernel modules - the boundary shifts? [LWN.net]

The GNU General Public License places strong requirements on anybody who distributes code derived from GPL-licensed source: the derived code, too, must be released under the GPL. The Linux kernel's license states explicitly that programs running in user mode and making use of kernel system calls are not derived works, and may thus be proprietary. The situation with loadable kernel modules has always been a little more fuzzy, however. The legal status of proprietary Linux kernel modules may heading toward a long-term resolution, however; the news may not be good for vendors of such modules.

User-space programs run in a separate address space, in a different processor mode, and communicate with the kernel via special instructions. There is a clear boundary between the two. Loadable modules, however, are linked into the kernel itself; they run in kernel mode, access the kernel address space, and require (GPL-licensed) header files to build. For all practical purposes, they look like part of the kernel itself, and thus should perhaps be seen as derived works.

Linus Torvalds's longstanding policy - never actually written down anywhere - has been that binary-only kernel modules were permissible as long as they restricted themselves to the (never really defined) kernel API. That has been interpreted to mean that modules which use only explicitly exported symbols can be proprietary, and numerous such modules have been shipped over the years. Linus is not the only copyright holder on the Linux kernel, however, and quite a few other kernel developers have been known to mumble that they had never agreed that their code could be linked to proprietary modules.

This situation has thus always been a little unstable. It came up again in recent times when Christoph Hellwig posted a patch which explicitly made the Linux Security Module functionality available only to modules licensed under the GPL. People were, says Christoph, using the LSM hooks to change the behavior of system calls, and that went further than he thought was appropriate. In a separate posting, Christoph stated:

My argument is that I want this flag as a hint for authors of proprietary security modules that I'm going to sue them if they use hooks called from code I have copyright on. This includes such central parts as vfs_read/vfs_write.

This is, of course, an explicit shot across the bow of anybody who distributes proprietary kernel modules. Linus, then, sent out his current view on binary-only modules:

There is NOTHING in the kernel license that allows modules to be non-GPL'd. The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

This is a more restrictive view than has been seen in the past. Linus would likely argue that his position has not changed, but he has not been quite so clear before. One possible reason for a change in attitude can be seen in another quote from the same posting:

The original binary-only modules were for things that were pre-existing works of code, ie drivers and filesystems ported from other operating systems, which thus could clearly be argued to not be derived works, and the original limited export table also acted somewhat as a barrier to show a level of distance.

What's different now? Certainly one relevant point is that far more kernel functionality is exported to loadable modules. Proprietary modules, once, didn't have the access to kernel internals that they have now. But there may be a more important message here: years ago, binary-only modules were useful for bringing in capabilities that nobody had, yet, been able to write as free software. As the kernel has developed, the role of this sort of imported code has diminished.

In other words, we may be seeing a harder line against proprietary kernel modules for the simple, pragmatic reason that we don't need them anymore. Linux has evolved from a small, struggling system into one of the most capable systems available. Proprietary module vendors now have little to offer the kernel. Over the coming years, it would not be surprising to see the policy on binary-only modules harden further, until one day they are explicitly forbidden.

(Log in to post comments)

Written down somewhere...just not well known

Posted Oct 24, 2002 10:03 UTC (Thu) by leandro (guest, #1460) [Link]

Thanks for the link, very informative.

I think these messages by Linus illustrate very clearly what I think is wrong about his instance on licensing and that taken by the FSF.

Linus accept all code sent him that he deems sane. He asks for no assignment, so now there are lots of authors holding copyrights on fundamental parts of Linux. He uses GNU GPL v2, and admits he might have to change if something catastrophic like the GNU GPL v2 being considered unenforceable happened. Unlikely as that is, it is a theoretical possibility, and to change licenses Linus would have to get agreement from all copyright holders. I don't know if he could even contact all of them today. This also severely complicates, and could even hinder, enforcement.

Moreover, any copyright holder can disagree over his interpretation on linking and sue people around. Theoretically, an author could sell his copyrighs on fundamental parts of Linux to some Big Corp and this big, proprietary software, freedom-hating Corp could cause havoc. Again unlikely, but theoretically possible.

Now contrast that to the FSF. It requires assignment, so that all GNU software is defensible by the FSF in court. It will try to enforce its copyrights as to its own interpretation of the GNU GPL, which besides being authoritative coming from the authors of the said license is published, clear and well-known. Changing the licensing to GNU GPL v3 or whatever then is as trivial as a new release, without the hassle of multiple copyright holders which also complicates enforcement.

Even the recommendations from the FSF for non-GNU, but still GPL'd software are saner. Licensing under GNU GPL v2 or later makes "licensing upgrade" trivial.

I understand Linus and other "OpenSourcers" get annoyed at FSF's emphasis on ethics, law and politics, but what I don't accept is their instance that equates to thinking and advocating that ignoring the problem will make it go away.

Assignments and license changes and geeks, oh my!

Posted Oct 24, 2002 17:34 UTC (Thu) by roelofs (subscriber, #2599) [Link]

leandro wrote:

Actually, ESR has turned up some information that indicates things may not be as bleak as you think. (Or maybe they're more bleak, depending on your viewpoint.) Hopefully he'll speak up about it soon; in fact, I think he was planning to discuss it with Linus this week on the cruise, so you might hear something as soon as next week. It's definitely an interesting new twist to the topic. Not being able to talk about it can be...trying at times. :-)

Greg

Proprietary kernel modules - the boundary shifts?

Posted Oct 24, 2002 12:20 UTC (Thu) by mrshiny (subscriber, #4266) [Link]

I personally am in favour of binary modules, for one reason: Hardware vendors are paranoid and don't want to (or can't) open-source their code for fear of their IP being violated. While I disagree with this approach, I can at least see where they are coming from. <p>Consider 3D gaming under linux: Graphics cards are so complex and full of proprietary technology that writing drivers for them is very hard. Many open-source drivers for 3D accelerators have been less than great. Some 3D cards were never accellerated under Linux. Today, there are essentially only two players in the 3D market: nVidia and ATI. Guess what? Neither is providing full, open-source drivers for their latest cards.<p>While I can certainly understand the linux kernel team's unwillingness to SUPPORT binary modules, since they have no access to the code, allowing binary modules is still a necessity, since taking away support for binary modules would probably mean that I, and lots of other gamers, would be unable to use any reasonably good hardware. This means that I would have to reboot into Windows to play games, and that's something I don't like doing. My life is so much better now that I never have to use Windows at all.<p>Don't get me wrong; I believe that open-source is better than closed source, and if nVidia opened up their drivers their products would improve and their linux support would improve. However, I still feel that there are some things the open-source community is poorly adapted to do, and writing 3D graphics drivers is one of those things. It takes too much time and is too difficult to do without documentation. By the time the drivers are "finished" a new product is out and the cycle begins again. The driver needs to be written as the hardware is developed, since the lifetime of the hardware is short. Thus, the hardware vendor is really the only group that can successfully create drivers for everything.<p>

Proprietary kernel modules - the boundary shifts?

Posted Oct 25, 2002 21:24 UTC (Fri) by xyzzy (subscriber, #1984) [Link]

3D graphics drivers would still be able to be written by nVidia, etc; they would merely have to release the source, too. Many vendors (e.g. those of ethernet cards) provide the source to their Linux drivers these days.

Some provide binary drivers for a specific (old) version of the kernel; personally I'd be quite happy to see those go away, as to me they're worse than useless: they let said vendors say "look, we support linux!" - they conveniently leave out the "linux == 2.4.16 kernel with RedHat patches".

Proprietary kernel modules - the boundary shifts?

Posted Oct 31, 2002 13:13 UTC (Thu) by forthy (guest, #1525) [Link]

Graphics cards and binary kernel modules: Most of the 3D rendering stuff is done inside XFree86. That's why it's called "direct rendering infrastructure". The kernel code basically handles passing data to the graphics card. Yes, nVidia keeps that secret, too. But there's not that much to hide. They probably just hide it because they think they are allowed to, not because it is necessary.

Proprietary kernel modules - the boundary shifts?

Posted Oct 31, 2002 14:55 UTC (Thu) by elanthis (subscriber, #6227) [Link]

nVidia doesn't use the DRI. And besides, the DRI and Mesa interfaces are slow. If it came down to using the Open Source ATI drivers, which let you use maybe $100 worth of a $300 card's features, or using Windows, guess which most people would do?

nVidia isn't going to open-source their drivers, they legally can't thanks to third-party licensed code, end of story. Binary drivers go away, 3D goes away (the only good 3D drivers for XFree being the proprietary ones made by ATI and nVidia, and if Xig needs binary modules, there goes the only good support for all the other cards available through their X server implementation), and with that, goes Linux gaming, any chance at the Linux desktop market, visualization market, etc.

Linux is great because it is technically superiour to alternatives like Windows. As soon as it becomes nothing but a play-ground for Free Software fanatics, it's dead on the desktop, home or business. As soon as my very very high-speed acceleration stops working (i.e., no more fast non-DRI non-open-source nVidia drivers are available), Linux gets stuck on a POS 686 in the corner for development and my desktop becomes an operating system that can actually make use of the hardware I paid for. Maybe that'll be FreeBSD if nVidia releases those drivers for it...

Proprietary kernel modules - the boundary shifts?

Posted Nov 1, 2002 7:37 UTC (Fri) by anandsr (guest, #3160) [Link]

The bigger problem is Embedded applications. There everything is a module which is also linked into the kernel. Currently people were using the interfaces to create a dynamically linked objects for their code. But now with this licensing they just can't muck in the kernel space at all. Killing Linux in the embedded space.

No shift is needed to explain both views.

Posted Oct 24, 2002 15:03 UTC (Thu) by leonb (subscriber, #3054) [Link]

Suppose a company distributes a binary kernel module
that does not contain any code derived from linux.
This company does not fall under the copyright law
and is not bound by the kernel GPL.
Users are free to download this and insmod it
because the GPL says that using the software
is not regulated.

This is another matter, of course, if the company
distributes complete binary kernels including
their code. But this is not the issue here.

In practice, part of a kernel module is mildly
derived from the kernel because it requires
knowledge of some hooks into the kernel,
for instance by using GPL'ed kernel headers.

Yet binary modules often come as a big object
file accompanied by a small source code that
includes these headers and makes the interface
between the kernel and the binary-only part.
One could argue that this source code itself
depends on a knowledge of the kernel headers
and therefore is a derived work and must be
GPL'ed. It all depends whether this knowledge
is in fact public knowledge (found in LWN for
instance) or requires a close analysis of the
kernel source code. This is where the notion
of kernel API plays a role.

But this is only valid if the company is
very sure that the binary only part of its
module is not a derived work!

In practice, the binary only part should
not contain anything from linux. No kernel
source code, no kernel headers,
nothing GPL'ed.

As Linus points out, pre-existing
drivers ported to Linux probably qualify.

- Leon Bottou

Proprietary kernel modules - the boundary shifts?

Posted Oct 26, 2002 22:19 UTC (Sat) by olaf_sc (guest, #4057) [Link]

Wel the main issue is not 3D companies but companies like e.g. Veritas. The desktop part of Linux is small but the server is definitly big. There is a lot of shops using veritas products on e.g. Sun boxes. If such a shop want to shift to Linux they most likely want to still use e.g. veritas volume manager to mange it's disks with.

If we can't use binary modules we will not have products sush as vxfs, vxvm etc for Linux. This may eventually slowdown the shift from proparitary Unix boxes to Linux. Even worse shop A is using vxvm then a once if a sudden they can't run it since they upgraded the kernel. Now they need to upgrade the kernel to due to security issues. Hence the shop will be in a catch 22.

Just my view

Proprietary kernel modules - the boundary shifts?

Posted Oct 31, 2002 21:38 UTC (Thu) by mmarq (guest, #2332) [Link]

WHAT ABOUT A LINUX KERNEL FOUNDATION????

There is now lot to learn about mistakes from APACHE, FSF, GNOME, KDE, XFree86 foudations, that this new one could go very successful, very quickly!!

I'm very confident that this organisation could be very small, whit few people, have a tyne budget, and yet defend and preserve the linux kernel far beyond the life time of Linus and all the others kernel hackers, even the youngest!!!

It could for exemple:(under agreements of fairness and mutual beneficial)
-Hold the Trademark Linux far beyond Linus sons of sons!!
-Hold all the copyrigths and or promote its defence and enforcement against all foes!!
-Hold patent agreements whit other entitys, corporations or individuals!!
-Be the home house of the official kernel trees(even if there is more than one co-maintainer, as it should)!!
-Could even provide certification of linux drivers against a well defined interface that for shore is going to came out!!!...it has to!!!...

ISN'T ALL THIS GREAT????...EVEN TO LINUS, BECAUSE HE WOULD'T OWN THE FOUDATION OR THE KERNEL, AS HE LIKES AND SHOULD BE....

LINUS SEEMS A VERY DECENT AND NICE GUY(I'M CONFIDENT HE IS), BUT IF HE THINKS THAT MICROSOFT IS GOING TO SEAT QUITLY WHILE LINUX ERODES BIG PARTES OF IT'S MONOPOLY, JUST BECAUSE LINUX IS A BETTER PRODUCT, HE BETTER THINK AGAIN, BECAUSE MS IS GONNA CAME OUT OF EVERY "LOOPHOLE" THEY COULD FIND!..., ALTOUGH UNLIKELY I WOULD NOT BE SURPRISED IF "SGI" ENDS UP IN THE CONTROL OF A SURPRISE NEW CORPORATION, A SECRET SHADOW OF MICROSOFT(OR UNDER IT'S CONTROL), AND STARTS TO SUE EVERYBODY AND THERE SISTERS AND BROTHERS ABOUT PATENT INFRINGEMENTS IN THE "rmap" CODE OF THE LINUX"vm"!!!

Proprietary kernel modules - the boundary shifts?

Posted Nov 1, 2002 0:45 UTC (Fri) by scharkalvin (guest, #7372) [Link]

Perhaps there is a way to have binary modules that comply. Write a binary module library
that performs your propritary functions and provide an interface to it. Now write your kernel module and link your kernel module with your library. Now link your module with the kernel (dynamic link, done at kernel load time so it's NOT a part of the kernel image, except in memory). Your kernel module is licensed under the GPL with an exception that you allow linking IT to a binary module. It's your module so you can do this. You provide the source to the module when you distribute it. Your module is an interface between the kernel and your binary library. Now you can hide your propritary info on your hardware, but show how to interface to it. There are already a few drivers done this way, I know of one for a sound card.

Proprietary kernel modules - the boundary shifts?

Posted Nov 1, 2002 3:28 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

>Your kernel module is licensed under the GPL with an exception that
>you allow linking IT to a binary module. It's your module so you
>can do this

No, you can't. Not for that reason, anyway. When you take code from someone under the GPL you agree that if you redistribute it or any derived works, you will do it under the GPL. The whole GPL, not with exceptions that let someone do additional stuff with your code.

But this isn't relevant to the point made here, because the GPL doesn't say you can't dynamically link to a binary-only module. In fact, it explicitly doesn't place any restrictions at all on how you can use the code.

The issue with loadable kernel modules is that if in order to make it insmod, you have to derive the code from Linux or some other GPL code, then you can't distribute the LKM under any license but GPL.

Some people think that if you include kernel header files, or write your own C declarations based on what you read in kernel header files, you have derived your module from Linux. Others say hogwash. And the same analysis holds to what you have to do to make your own main module work with your own GPL interface module. If you copied in any legal sense from your GPL interface module to create your main module, you must distribute source code with your main module.

Does private interface use implies derivation ?

Posted Nov 1, 2002 6:20 UTC (Fri) by slumbukken (guest, #6937) [Link]

The concept that "new MODULE that interfaces with old MODULE through its private interface" is necessarily a derived work and covered by the copy-rights of the "old MODULE" seems to fail the absurdity test.

eg SAMBA is a derived work of prior Microsoft networking OSes and hence the copyright of SAMBA is Microsoft's to exploit. The interfaces Samba deals with were never open and the code that implements them in the old MODULE is not copyright free.

eg the clean room reimplementations of the IBM-PC Bios which implement interfaces required to support the original PC motherboard are at the mercy of IBM. Actually - I am confused here - maybe the interfaces are again owned by Microsoft via MS-DOS?

eg software that uses Microsoft 'secret' internal interfaces of Windows-XX are the property of Microsoft.

There is a long tradition of 'interaction' by reverse engineering of the interfaces of other companies products. Primarily the smaller companies products interacting with the pre-existing dominant product of a near monopoly.