LinkSys and binary modules

The celebration is not universal, however; the new kernel source still lacks the driver for the wireless interface. Unlike the other kernel modifications found in the WRT54G router, the wireless interface is packaged as a separate, binary module. In the eyes of many, that packaging is sufficient to ensure that the driver is not a derived product of the kernel, and, thus, it need not be licensed under the GPL. But not everybody agrees.

The status of binary modules remains the subject of a great deal of confusion; it deserves (yet another) look. There is a widespread impression that Linus Torvalds has issued a blanket exemption to the GPL for closed-source modules. There are only two problems with this idea: (1) it is not entirely true, and (2) the relevance of Linus's opinion is limited. On the first point, consider this pronouncement from Linus, issued almost exactly one year ago:

On the second point, it suffices to remember that Linus is far from the only kernel copyright holder. He made a crucial decision years ago to not require copyright assignments from contributors, and, thus, to allow each contributor to retain copyrights on his or her code. As Linus's role has shifted from coding to rejecting contributions from others, the portion of the kernel code base carrying his copyright has shrunk. Linus can speak for himself, but not for the other kernel copyright holders. And some of the others are getting increasingly grumpy about closed-source modules.

The crucial question here is whether a court would find that a kernel module is a derived product of the kernel itself or not. There is a difference of opinion on that score, to say the least. Eight years ago, Linus suggested that kernel modules, by virtue of the module API which only allowed modules to link to "logically independent" functions within the kernel, were not derived products. As others have pointed out, the list of functions available to modules is rather less controlled these days. 2.6 loadable modules have access to a great many kernel functions (a quick grep turns up over 8000 exported symbols) and require a great deal of inline code from the kernel header files. By some accounts, any code that is so intimately tied into the kernel must be a derived product.

Others have taken the view that anything which can be unplugged and replaced is not a derived product. The existence of a plug-in interface creates a boundary which the GPL cannot cross. In some cases, this must be true; consider, for example, Linuxant's controversial new DriverLoader product. DriverLoader is a proprietary module which will interface Windows NDIS network drivers to the Linux kernel. The legal status of DriverLoader may be unclear, but nobody would argue that a binary Windows driver, when shoehorned into the Linux kernel in this way, becomes a derived product of the kernel. On the other hand, with a small (GPL-licensed) patch, the kernel could be opened to "pluggable" modules implementing proprietary network protocols, memory managers, schedulers, etc. This scheme, if considered legal, would allow proprietary code to be lodged within the heart of the Linux kernel. At that point, there would be no restriction on derived products at all.

Another view, less often heard, notes that the kernel module loader checks the license of every module loaded into the system. If the module lacks a free license, the kernel complains, but loads the module anyway. One could argue that this behavior is an explicit acknowledgment that closed-source modules are permissible.

The only way to get a definitive answer on the location of the GPL boundary will be to go in front of a judge. Even then, the answer is unlikely to be useful beyond the specific case considered there.

In the LinkSys case, some developers are claiming that the source for the binary modules should be released even if they are not strictly seen to be derived products. This claim is based on the following language from section 2 of the General Public License:

Some feel that the LinkSys WRT56G router is, indeed, a "whole which is a work based on the Program" and that the entire system must be licensed under the GPL if it is to be distributed legally. This view relies on the contract provisions of the GPL, and not just on copyright law; it is controversial, to say the least. By this reasoning, a Linux distribution with, say, a proprietary installer could be seen to be violating the GPL. In the end, this claim, too, can only be verified in a courtroom. Until then, the definition of a "whole" is subject to debate.

The status of closed-source modules has always been somewhat unclear, and one gets the impression that the kernel developers have been happy to keep it that way. There is a strong desire to discourage such modules, but, seemingly, little wish to abolish them altogether. The system has worked reasonably well so far, but it may well be asking for trouble in the longer term. With the current state of affairs, it seems certain that, sooner or later, a company or individual holding kernel copyrights will take a proprietary module vendor to court.

One of the best features of free software is the fact that users don't need to worry. The rights of users are broad and well defined; there is no equivalent of the Business Software Alliance looking for companies to raid. The distribution of closed-source kernel modules is an exception, however; nobody really knows if this distribution is legal or not. The free software community is not helped by this uncertainty; it really is past time to clarify the status of closed-source modules. Doing so will be a challenging task, but doing nothing will bring unwanted challenges of its own. The free software community does not need any more litigation, be it instigated by ourselves or by others.

Note: you can avoid this step in the future by logging into your LWN account.