Why binary-only modules were not banned [LWN.net]

For a moment, it seemed like things could happen pretty quickly. Martin Bligh suggested that, rather than trying to nickel-and-dime binary modules to death, it would be more honest to just ban them outright. Andrew Morton spoke out in favor of the idea as long as a one-year warning was provided. Greg Kroah-Hartman hacked up a patch to insert the warning. And Linus, at the outset, restricted himself to commenting on Greg's poetry.

The tide turned just as quickly, however. Linus spoke out against the change, and Greg withdrew it. It would appear that binary-only modules will continue to be loadable into the kernel for the foreseeable future - though other hazards may await those who distribute them.

The loading of proprietary modules was not banned for a few reasons, the first of which being that there is, in fact, nothing wrong with doing so. The GPL is quite clear in its statement that somebody who is in possession of GPL-licensed code can use it in any way they wish. If they want to combine their nice free kernel with a big, proprietary binary blob, they are fully within their rights to do so. So banning proprietary modules in the kernel source attacks the problem in the wrong place and attempts to forbid an activity which is allowed by the license.

Even if the GPL could be interpreted as forbidding the loading of binary-only modules, there is the fair use issue to consider. As a community, we tend to be generally in favor of a broad interpretation of fair-use rights. But fair use cuts both ways. A number of people in the discussion warned against adopting the tactics favored by the entertainment industry and taking an overly broad view of what the law allows copyright owners to do. As Ben Collins put it:

The gradual changes to lock down kernel modules to a particular license(s) tends to mirror the slow lock down of content (music/movies) that people complain about so loudly. It's basically becoming DRM for code.

The fact that some people were willing to discuss making use of the DMCA to make sure that nobody could patch a proprietary module ban out of the code tends to reinforce this view. Alan Cox noted that people tend to become that which they fight. Most people in the community would probably agree that the entertainment industry is not something we wish to become; this realization has, arguably, done a lot to erode support for the idea of banning proprietary modules.

What the GPL does cover is distribution; anybody who distributes something derived from GPL-licensed code must do so under the terms of the GPL. So it is the act of distributing proprietary modules which enters legally questionable territory. But, as Linus points out, the fact that a module can be loaded into the kernel does not imply that the module is necessarily a derived work of the kernel. The determination of derived work status is a complicated business, and can often require a court to provide the definitive word. But banning all proprietary modules on the idea that they are all illegal derived works is a hard action to defend.

The end result is that there will be no technical measures for the blocking of binary modules added to the kernel anytime soon. Unhappiness with these modules remains, however, as can be seen in Greg's message withdrawing the patch:

It's just that I'm so damn tired of this whole thing. I'm tired of people thinking they have a right to violate my copyright all the time. I'm tired of people and companies somehow treating our license in ways that are blatantly wrong and feeling fine about it. Because we are a loose band of a lot of individuals, and not a company or legal entity, it seems to give companies the chutzpah to feel that they can get away with violating our license.

It seems clear that the issue will not go away, even though this particular approach to addressing it has been rejected. The course which appears to be open to disgruntled kernel developers is legal action: if the distribution of a specific binary module can be shown to be a copyright violation, then the copyright owners have the right to go to court to put a stop to it. GPL enforcement efforts have, so far, tended to be successful. So it would not be surprising to see one or more developers decide to bring a suit against a binary module distributor in the next year or so. The discontent which is so visibly out there is unlikely to just fade away.

(Log in to post comments)

Why binary-only modules were not banned

Posted Dec 21, 2006 10:15 UTC (Thu) by copsewood (subscriber, #199) [Link]

This seems more a problem with management of your employer's purchasing than Linux. If the SAN hardware people are not releasing specs but are releasing Linux binary only modules, without selling or specifying a supported operating system together with these, this would discourage you from buying their hardware again would it not ? It seems you have bought OS support from one supplier and SAN hardware from another where neither side is guaranteeing high level support for the combination. Given that the need to use SAN systems in a "multibillion and global enterprise" isn't going to be based on sentiment, then presumably there is a good business case for using Linux for this application ? Perhaps if you were to tell the SAN supplier that your repurchase decision will be based on compatibility with your preferred OS this might concentrate the minds of their sales and marketing reps to release driver source ?

Why binary-only modules were not banned

Posted Dec 21, 2006 14:28 UTC (Thu) by khim (subscriber, #9252) [Link]

You cannot break driver interfaces at random points in the development and tolerate binary drivers, which are then unsupportable.

Why ? They are tolerated, not encouraged. Linus said is quite good: I don't like binary modules. I refuse to support them. And that's final: if there are a problem with binary drivers - bug you vendor who created this crap in first place.

Well one could say, the distribution vendors should solve the issues, but that is more a wish than a reality.

Sane distribution vendors will refuse to support such configuration - so it's your problem.

If Suse/Novell then states to the head of platform engineering, that he has to wait until the community solves the issue, you know what will happen.

If Suse/Novell decided to support unsupportable configuration - it's their problem. Right now binary drivers have quite clear status: You can use them on your own risk - it's unsupported configuration. What's so difficult about that ?

He will make the decision to move away from Linux as fast as he can.

Ok. Correct me if I'm wrong, but
1. He uses unsupported configuration
2. He got problem.
3. He decides to drop Linux

Weird choice but it's his choice... what kernel developers can do about this ?

Why binary-only modules were not banned

Posted Dec 21, 2006 20:37 UTC (Thu) by iabervon (subscriber, #722) [Link]

Basically this "Wer are not the RIAA!" policy is not solving the issue. You cannot break driver interfaces at random points in the development and tolerate binary drivers, which are then unsupportable.

Sure you can. The driver interface is under the GPL. If it can be changed while continuing to serve the same function, it is a copyrightable work. Any code which this sort of change breaks is derived from that work, and therefore may only be distributed under the GPL.

Really, producers of binary kernel modules should between them design a stable driver API, release it under the BSD license, and maintain a GPL-licensed shim layer for Linux. (For that matter, insterested parties could maintain shim layers for other kernels, too.) All of these actions are clearly permitted by copyright law and the appropriate licenses. Sure, it adds a bit of overhead, but no more than any mechanism for providing a stable driver API would have to (either by direct overhead or by not permitting further core optimizations).

You're solving a nonexistent problem without solving the real one.

Posted Dec 22, 2006 5:45 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> The driver interface is under the GPL. If it can be changed while
> continuing to serve the same function, it is a copyrightable work.

Programming interfaces are widely held *not* to be copyrightable.
Reimplementing an API for the purposes of interoperability is not held to
be a copyright infringement -- or MS could have drowned Wine and Mono at
birth, and SCO would have won years ago. If replacing an API
implementation doesn't create a derivative work, how on earth can merely
*calling* the API do so?

> Any code which this sort of change breaks is derived from that
> work, and therefore may only be distributed under the GPL.

This is absolutely incorrect. Using an API does not make your program a
derivative work of the API. Programs written using win32 are not
derivatives of either Windows or Wine. Programs written using Posix are
not derivatives of any implementation of libc.

> producers of binary kernel modules should between them design a
> stable driver API

This is hardly necessary. The bits which are common enough to be
standardised are not subject to rapid change, nor to GPL_ONLY-type
DRM measures.

> and maintain a GPL-licensed shim layer for Linux ... clearly
> permitted by copyright law

You're technically correct. You can write any code you like for any
purpose without violating any released version of the GPL.

But this doesn't solve the only real problem with linking a GPL kernel
and a GPL-incompatible module. Any combined work which contains both (A
real example is the Kororaa CD image which contained a bootable kernel
and a .ko file to be inserted into the kernel at runtime) is not
redistributable according to the terms of the GPL. The number of API
shim layers in between and their respective licences is utterly
irrelevant -- the GPL must be applicable to the whole.

Plugins as derived works

Posted Dec 22, 2006 8:25 UTC (Fri) by jhs (guest, #12429) [Link]

I think the technical perspective is less useful when considering the derived works issue. Consider a legal viewpoint, since "copyright law" seems to be the name that is dropped so often. If a derived work is decided on a case-by-case basis, then let's look at it case by case. Let's not concern ourselves with what function pointer was dereferenced and jumped to; but rather, which side provides a primary benefit to the other. Look at the relationship between the two works: the Linux kernel and the additional software module. Decide whether, if the software were human, which end would be saying "thank you" more.

Consider hardware drivers, especially those which are portable to other OSes: they provide a service to the kernel. They allow the kernel to make the hardware available to applications, which allows the hardware to be useful to the user. Since the driver's primary function is to make good on the kernel's expectations (e.g. display some graphic, print something, write data to storage), then I think it is clear the module is not derived from Linux, because Linux would be just fine without the module.

Next, consider some sort of wrapper module -- or even userland software, including tricks using stdio that even the FSF says are OK. The purpose of this wrapper software is to exploit or provide to the user the benefits of Linux (e.g. a network stack, filesystem services, security features, etc.). Here, it is clear that the primary direction of service is from Linux to the module or obscurity layer, and so it is derived from Linux. What if it is portable to BSD? Fine. Then the software is derived from Linux when it ships with Linux, and derived from BSD when it ships with BSD.

Finally, consider that this method of evaluating derivative works generalizes to any two companies, for-profit or non-profit, amy set of licenses, any set of languages, any operating system, and basically any two pieces of software which have a relationship. So that is the true hacker's approach.

Plugins as derived works

Posted Dec 22, 2006 14:31 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Who does say (or not)"thank you" is completely irrelevant for copyright purposes. Something is a "derived work" if it was built out of (a piece of) the original work. Exact details aren't clear, plus much what is routinely done in software has helped mush the area: Including header.h is most probably "just normal use" or even "fair use" (even if it means using the expansion of largeish macros or inline functions in your program).

Plugins as derived works

Posted Dec 22, 2006 17:57 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I think you're missing what derived work means and are just talking about the ordinary copyright cases where A distributes stuff written by B.

The derived works part of copyright law is what lets the copyright owner of the existing Harry Potter books stop you from selling a new installment in the series that you wrote entirely yourself.

When people apply this to loadable kernel modules, they say that an LKM is a derived work of the existing kernel, and thus must not be distributed without source code. It doesn't matter if it is packaged together with the existing kernel, or whether existing header files were used to compile it. Even if you distribute just the source code and never saw a line of existing Linux source code, you still have to license it with GPL rights.

Not everyone agrees that an LKM is to the base kernel as your new Harry Potter book is to the Harry Potter series; there will probably be a tough line for a court to draw some day.

There's a more complete description of the arguments in Module-HOWTO

Plugins as derived works

Posted Dec 22, 2006 18:45 UTC (Fri) by jhs (guest, #12429) [Link]

The "thank you" test shows judges, attorneys, and pedantic hackers the reality of whether a work is derived from the kernel. It is silly to say that, because some software accesses some other software's routines, it is a derived work. People love to say that the API is this magic legal DMZ with some kind of precedent, but the reality is that Firefox is not derived from Windows not because it uses the API, but because Firefox does not exploit some hidden value within Windows to give to the user. This is clear because Firefox performs the same function on other OSes. To say that the NVidia driver is derived from Linux, but that Firefox is not derived from Windows is, in my opinion, a double standard.

And again, I am not even talking about kernel modules. I am talking about any two pieces of software which have any interaction with each other. But I argue that this method sheds some light on the LKM derived works question.

Distributing CD with kernel and binary-only module violates GPL?

Posted Dec 22, 2006 14:22 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

This is a red herring, AFAICS. The kernel and module just reside on the same CD ("mere aggregation") until the end user links them (loads the module). Sure, the result can't be redistributed, but who would want to redistribute the in-memory image anyway?

IANAL, and I haven't looked further into this in any case. I'm assuming that the module itself is kosher, if that is possible is another question. Besides, the license to the module also comes into play (there is stuff out there that you can get for free, but can't redistribute).

You're solving a nonexistent problem without solving the real one.

Posted Dec 22, 2006 17:49 UTC (Fri) by iabervon (subscriber, #722) [Link]

Programming interfaces are widely held *not* to be copyrightable. Reimplementing an API for the purposes of interoperability is not held to be a copyright infringement -- or MS could have drowned Wine and Mono at birth, and SCO would have won years ago. If replacing an API implementation doesn't create a derivative work, how on earth can merely *calling* the API do so?

The copyrightability of programming interfaces depends, like everything else, on whether it is the only way to accomplish a certain purpose, or whether it incorporates arbitrary decisions on the part of the author. Furthermore, a public API inherently becomes the only way of building a program that uses that API, and therefore not copyrightable. But the internal kernel API is not the only way to accomplish the purposes it accomplishes, as evidenced by the fact that it is often replaced with a different way of accomplishing those purposes. As a miscellaneous collection of functions that get changed regularly, it is a copyrightable work, and anything that uses it is a derived work thereof.

Using an API does not make your program a derivative work of the API. Programs written using win32 are not derivatives of either Windows or Wine. Programs written using Posix are not derivatives of any implementation of libc.

This is irrelevant; Windows and Wine are not APIs, and neither is any implementation of libc. Programs using win32 are derivates of win32, and programs using Posix are derivatives of Posix. And the copyrightability of win32 and Posix went away when comforming to them became the only way of doing things (e.g., getting Posix-conformance certification).

But this doesn't solve the only real problem with linking a GPL kernel and a GPL-incompatible module. Any combined work which contains both (A real example is the Kororaa CD image which contained a bootable kernel and a .ko file to be inserted into the kernel at runtime) is not redistributable according to the terms of the GPL.

"In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." In addition to the fact that this just reiterates copyright law, it's an example explicitly mentioned in the GPL (section 2, last paragraph). It is obviously fine to include on a single medium a proprietary work derived from a BSD-licensed shim; the shim, licensed under the BSD license but distributed under the GPL as required due to the implementation being derived from the kernel; and the kernel, so long as the license of the proprietary work permits such distribution (which not all of them do; some vendors don't allow redistribution).

Just to make this point especially clear, every single GPL-licensed work, as distributed, is a collection containing a work which is incompatible with the GPL: the GPL document itself, whose license is "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." The reason this is okay is exactly that the license document is not a derivative work of the work under the license. Using a shim layer so your kernel module is not a derivative work of the kernel puts it in exactly the same status.

Why binary-only modules were not banned

Posted Dec 22, 2006 0:08 UTC (Fri) by smitty_one_each (subscriber, #28989) [Link]

>...policy is not solving the issue.
Is the issue actually 'solveable', or are we merely going to move the issue, or create a few new ones by hacking off a particular head from the hydra?