When first made available in September of 1991, the Linux kernel source code was released under a very restrictive non-GPL license requiring that the source code must always be available, and that no money could be made off of it. Several months later Linus changed the copyright to the GPL, or GNU General Public License, under which the kernel source code has remained ever since. Thanks to the GPL, any source code derived from the Linux kernel source code must also be freely released under the GPL. This has led many to question the legality of "binary only" kernel modules, for which no source code is released. Linux creator Linus Torvalds talks about this issue in a recent thread on the lkml explaining:

"But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)? THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux
behaviour."

From: "Kendall Bennett [email blocked]
To:  linux-kernel
Subject: Linux GPL and binary module exception clause?
Date: Wed, 03 Dec 2003 13:31:54 -0800

Hi All,

I have heard many people reference the fact that the although the Linux 
Kernel is under the GNU GPL license, that the code is licensed with an 
exception clause that says binary loadable modules do not have to be 
under the GPL. Obviously today there are vendors delivering binary 
modules (not supported by the kernel maintainers of course), so clearly 
people believe this to be true. However I was curious about the wording 
of this exception clause so I went looking for it, but I cannot seem to 
find it. I downloaded the 2.6-test1 kernel source code and looked at the 
COPYING file, but found nothing relating to this (just the note at the 
top from Linus saying user programs are not covered by the GPL). I also 
looked in the README file and nothing was mentioned there either, at 
least from what I could see from a quick read.

So does this exception clause exist or not? If not, how can the binary 
modules be valid for use under Linux if the source is not made available 
under the terms of the GNU GPL?

Lastly I noticed that the few source code modules I looked at to see if 
the exception clause was mentioned there, did not contain the usual GNU 
GPL preable section at the top of each file. IMHO all files need to have 
such a notice attached, or they are not under the GNU GPL (just being in 
a ZIP/tar achive with a COPYING file does not place a file under the GNU 
GPL). Given all the current legal stuff going on with SCO, I figured 
every file would have such a header. In fact some of the files I looked 
at didn't even contain a basic copyright notice!!

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



From: Arjan van de Ven [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Wed, 03 Dec 2003 22:47:54 +0100

On Wed, 2003-12-03 at 22:31, Kendall Bennett wrote:
> Hi All,
> 
> I have heard many people reference the fact that the although the Linux 
> Kernel is under the GNU GPL license, that the code is licensed with an 
> exception clause that says binary loadable modules do not have to be 
> under the GPL. 

there is no such exception, for example see:

http://www.kernelnewbies.org/kernels/rh9/SOURCES/COPYING.modules



From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Wed, 3 Dec 2003 16:00:21 -0800 (PST)

On Wed, 3 Dec 2003, Kendall Bennett wrote:
>
> I have heard many people reference the fact that the although the Linux
> Kernel is under the GNU GPL license, that the code is licensed with an
> exception clause that says binary loadable modules do not have to be
> under the GPL.

Nope. No such exception exists.

There's a clarification that user-space programs that use the standard
system call interfaces aren't considered derived works, but even that
isn't an "exception" - it's just a statement of a border of what is
clearly considered a "derived work". User programs are _clearly_ not
derived works of the kernel, and as such whatever the kernel license is
just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same.
The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that
leads to any gray areas. There are areas that are not gray at all: user
space is clearly not a derived work, while kernel patches clearly _are_
derived works.

But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.

Basically:
 - anything that was written with Linux in mind (whether it then _also_
   works on other operating systems or not) is clearly partially a derived
   work.
 - anything that has knowledge of and plays with fundamental internal
   Linux behaviour is clearly a derived work. If you need to muck around
   with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem
module: a standard filesystem that really wasn't written for Linux in the
first place, and just implements a UNIX filesystem. Is that derived just
because it got ported to Linux that had a reasonably similar VFS interface
to what other UNIXes did? Personally, I didn't feel that I could make that
judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
area.

Personally, I think that case wasn't a derived work, and I was willing to
tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work?
HELL NO! It has nothing to do with modules per se, except that non-modules
clearly are derived works (if they are so central to the kenrel that you
can't load them as a module, they are clearly derived works just by virtue
of being very intimate - and because the GPL expressly mentions linking).

So being a module is not a sign of not being a derived work. It's just
one sign that _maybe_ it might have other arguments for why it isn't
derived.

		Linus



From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Wed, 3 Dec 2003 16:23:33 -0800 (PST)


On Wed, 3 Dec 2003, Linus Torvalds wrote:
>
> So being a module is not a sign of not being a derived work. It's just
> one sign that _maybe_ it might have other arguments for why it isn't
> derived.

Side note: historically, the Linux kernel module interfaces were really
quite weak, and only exported a few tens of entry-points, and really
mostly effectively only allowed character and block device drivers with
standard interfaces, and loadable filesystems.

So historically, the fact that you could load a module using nothing but
these standard interfaces tended to be a much stronger argument for not
being very tightly coupled with the kernel.

That has changed, and the kernel module interfaces we have today are MUCH
more extensive than they were back in '95 or so. These days modules are
used for pretty much everything, including stuff that is very much
"internal kernel" stuff and as a result the kind of historic "implied
barrier" part of modules really has weakened, and as a result there is not
avery strong argument for being an independent work from just the fact
that you're a module.

Similarly, historically there was a much stronger argument for things like
AFS and some of the binary drivers (long forgotten now) for having been
developed totally independently of Linux: they literally were developed
before Linux even existed, by people who had zero knowledge of Linux. That
tends to strengthen the argument that they clearly aren't derived.

In contrast, these days it would be hard to argue that a new driver or
filesystem was developed without any thought of Linux. I think the NVidia
people can probably reasonably honestly say that the code they ported had
_no_ Linux origin. But quite frankly, I'd be less inclined to believe that
for some other projects out there..

			Linus

From: Jason Kingsland [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 10:21:55 -0500

On Wed, 3 Dec 2003, "Linus Torvalds" wrote:

> And in fact, when it comes to modules, the GPL issue is exactly the same.
> The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
> anything that is a derived work has to be GPL'd. It's that simple.
> ...
>  - anything that has knowledge of and plays with fundamental internal
>    Linux behaviour is clearly a derived work. If you need to muck around
>    with core code, you're derived, no question about it.


If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
MODULE_LICENSE()?

Specifying explicit boundaries for the module interface has legitimised
binary-only modules.
This was the signal to developers of proprietary code that binary-only
modules are tolerable.

Note that I said tolerable, not acceptable. Ref also the 'tainted' flag
("man 8 insmod")
My personal view is that Linux should mandate GPL for all modules in 2.6 and
beyond.

The Kevin Dankwardt article gives an alternative perspective for Linux
embedded use:
http://www.linuxdevices.com/articles/AT5041108431.html


From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 07:58:30 -0800 (PST)

On Thu, 4 Dec 2003, Jason Kingsland wrote:
> >  - anything that has knowledge of and plays with fundamental internal
> >    Linux behaviour is clearly a derived work. If you need to muck around
> >    with core code, you're derived, no question about it.
>
>
> If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
> MODULE_LICENSE()?

It is really just documentation.

This is exactly so that it is more clear which cases are black-and-white,
and where people shouldn't even have to think about it for a single
second. It still doesn't make the gray area go away, but it limits it a
bit ("if you need this export, you're clearly doing something that
requires the GPL").

Note: since the kernel itself is under the GPL, clearly anybody can modify
the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be
against the license per se. But it doesn't make a module that needs that
symbol any less needful of the GPL - exactly because the thing is just a
big cluehint rather than anything else.

			Linus

From: Valdis Kletnieks [email blocked]
Subject: Re: Linux GPL and binary module exception clause? 
Date: Fri, 05 Dec 2003 00:13:01 -0500

On Fri, 05 Dec 2003 15:23:10 +1100, Peter Chubb said:

> As far as I know, interfacing to a published API doesn't infringe
> copyright.

Well, if the only thing in the .h files was #defines and structure definitions,
it would probably be a slam dunk to decide that, yes.

Here's the part where people's eyes glaze over:

% cd /usr/src/linux-2.6.0-test10-mm1
% find include -name '*.h' | xargs egrep 'static.*inline' | wc -l
   6288

That's 6,288 chances for you to #include GPL code and end up
with executable derived from it in *your* .o file, not the kernel's.

More to the point, look at include/linux/rwsem.h, and ask yourself
how to call down_read(), down_write(), up_read(), and up_write()
without getting little snippets of GPL all over your .o.  

And even if your module doesn't get screwed by that, there's a
few other equally dangerous inlines waiting to bite you on the posterior.

I seem to recall one of the little buggers was particularly nasty, because it
simply Would Not Work if not inlined, so compiling with -fno-inline wasn't an
option.  Unfortunately, I can't remember which it was - it was mentioned on
here a while ago when somebody's kernel failed to boot because a gcc 3.mumble
had broken inlining.....



From: David Schwartz [email blocked]
Subject: RE: Linux GPL and binary module exception clause? 
Date: Thu, 4 Dec 2003 22:34:37 -0800

> On Fri, 05 Dec 2003 15:23:10 +1100, Peter Chubb said:
>
> > As far as I know, interfacing to a published API doesn't infringe
> > copyright.
>
> Well, if the only thing in the .h files was #defines and
> structure definitions,
> it would probably be a slam dunk to decide that, yes.
>
> Here's the part where people's eyes glaze over:
>
> % cd /usr/src/linux-2.6.0-test10-mm1
> % find include -name '*.h' | xargs egrep 'static.*inline' | wc -l
>    6288
>
> That's 6,288 chances for you to #include GPL code and end up
> with executable derived from it in *your* .o file, not the kernel's.

	I'm sorry, but that just doesn't matter. The GPL gives you the unrestricted
right to *use* the original work. This implicitly includes the right to
peform any step necessary to use the work. (This is why you can 'make a
copy' of a book on your retina if you have the right to read it.) Please
tell me how you use a kernel header file, other than by including it in a
code file, compiling that code file, and executing the result.

> More to the point, look at include/linux/rwsem.h, and ask yourself
> how to call down_read(), down_write(), up_read(), and up_write()
> without getting little snippets of GPL all over your .o.

	Exactly, it's impossible. So doing so is a necessary step to using the
header file.

> And even if your module doesn't get screwed by that, there's a
> few other equally dangerous inlines waiting to bite you on the posterior.

	No problem. If you can't avoid them, then you're allowed to do them.

> I seem to recall one of the little buggers was particularly
> nasty, because it
> simply Would Not Work if not inlined, so compiling with
> -fno-inline wasn't an
> option.  Unfortunately, I can't remember which it was - it was
> mentioned on
> here a while ago when somebody's kernel failed to boot because a
> gcc 3.mumble
> had broken inlining.....

	So you're argument is that it's impossible to use the header file without
creating a derived work, hence permission to use the header file is
permission to create the derived work. This supports my argument that you
can create a derived work without agreeing to the GPL. Thanks.

	DS



From: Linus Torvalds [email blocked]
Subject: RE: Linux GPL and binary module exception clause? 
Date: Thu, 4 Dec 2003 22:58:09 -0800 (PST)

On Thu, 4 Dec 2003, David Schwartz wrote:
>
> The GPL gives you the unrestricted right to *use* the original work.
> This implicitly includes the right to peform any step necessary to use
> the work.

No it doesn't.

Your logic is fundamentally flawed, and/or your reading skills are
deficient.

The GPL expressly states that the license does not restrict the act of
"running the Program" in any way, and yes, in that sense you may "use" the
program in whatever way you want.

But that "use" is clearly limited to running the resultant program. It
very much does NOT say that you can "use the header files in any way you
want, including building non-GPL'd programs with them".

In fact, it very much says the reverse. If you use the source code to
build a new program, the GPL _explicitly_ says that that new program has
to be GPL'd too.

> Please tell me how you use a kernel header file, other than by including
> it in a code file, compiling that code file, and executing the result.

You are a weasel, and you are trying to make the world look the way you
want it to, rather than the way it _is_.

You use the word "use" in a sense that is not compatible with the GPL. You
claim that the GPL says that you can "use the program any way you want",
but that is simply not accurate or even _close_ to accurate. Go back and
read the GPL again. It says:

	"The act of running the Program is not restricted"

and it very much does NOT say

	"The act of using parts of the source code of the Program is not
	 restricted"

In short: you do _NOT_ have the right to use a kernel header file (or any
other part of the kernel sources), unless that use results in a GPL'd
program.

What you _do_ have the right is to _run_ the kernel any way you please
(this is the part you would like to redefine as "use the source code",
but that definition simply isn't allowed by the license, however much you
protest to the contrary).

So you can run the kernel and create non-GPL'd programs while running it
to your hearts content. You can use it to control a nuclear submarine, and
that's totally outside the scope of the license (but if you do, please
note that the license does not imply any kind of warranty or similar).

BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.

Comprende?

		Linus

From: Erik Andersen [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 17:46:54 -0700

On Thu Dec 04, 2003 at 03:50:55PM -0800, Paul Adams wrote:
> Unless actual Linux code is incorporated in a binary
> distribution
> in some form, I don't see how you can claim
> infringement of the
> copyright on Linux code, at least in the U.S.

A kernel module is useless without a Linux kernel in which it can
be loaded.  Once loaded, it becomes not merely an adjunct, but an
integrat part of the Linux kernel.  Further, it clearly
"incorporate[s] a portion of the copyrighted work" since it
can only operate within the context of the kernel by utilizing
Linux kernel function calls.

To abuse your earlier metaphor, a kernel module is not comparable
to a programmatic musical composition inspired by a novel.  It is
better comparared with another novel with substantial similarity
in the theme, plot, sequence, settings, mood, dialogue, and
characters, with the same story being told, with trademarked
phrases and taglines, and that makes no sense whatsoever unless
you insert it's entire content over the top of page 450,
paragraph 4 (of the Linux "novel"), and which thereby changes 
the ending of the original book...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



From: Zwane Mwaikambo [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 19:58:18 -0500 (EST)

On Thu, 4 Dec 2003, Erik Andersen wrote:
> A kernel module is useless without a Linux kernel in which it can
> be loaded.  Once loaded, it becomes not merely an adjunct, but an
> integrat part of the Linux kernel.  Further, it clearly
> "incorporate[s] a portion of the copyrighted work" since it
> can only operate within the context of the kernel by utilizing
> Linux kernel function calls.

What about software which utilises Linux specific kernel services, such as
say some cd writing software?



From: Erik Andersen [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 18:03:49 -0700

On Thu Dec 04, 2003 at 07:58:18PM -0500, Zwane Mwaikambo wrote:
> What about software which utilises Linux specific kernel
> services, such as say some cd writing software?

An ordinary program that uses normal system calls?

linux/COPYING says: 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".

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



From: Larry McVoy [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 17:21:24 -0800

On Thu, Dec 04, 2003 at 06:03:49PM -0700, Erik Andersen wrote:
> On Thu Dec 04, 2003 at 07:58:18PM -0500, Zwane Mwaikambo wrote:
> > What about software which utilises Linux specific kernel
> > services, such as say some cd writing software?
> 
> An ordinary program that uses normal system calls?
> 
> linux/COPYING says: 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".

Yeah, and the GPL specificly invalidates that statement.  We're on thin
ice here.  Linus is making up the rules, which is cool (since I tend to
like his rules) but the reality is that the GPL doesn't allow you to 
extend the GPL.  It's the GPL or nothing.

Given the GPL rules you have to disregard Linus' rules that are extensions
and work off of standard law.  When you get there it becomes an issue of
boundaries and the law seems to clearly support Linus' point of view, he
didn't need to make that clarification, whether he did or not, that's what
is true in the eyes of the law.

But given that, neither Linus (nor any of you) get to say "well, that's fine
for userland but drivers are derived works".  

I've said this over and over and I'll say it again.  If you want the
protection of the law you have to live with the law's rules.  You DO
NOT get to say "user programs are a boundary across which the GPL does
not apply but drivers are a boundary across which the GPL does apply".
It doesn't, and can't, work that way.  Either userland is GPL and drivers
are GPL or neither are GPLed.  Take your pick.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm



From: Linus Torvalds [email blocked]
Subject: Re: Linux GPL and binary module exception clause?
Date: Thu, 4 Dec 2003 17:58:18 -0800 (PST)

On Thu, 4 Dec 2003, Larry McVoy wrote:
> >
> > linux/COPYING says: 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".
>
> Yeah, and the GPL specificly invalidates that statement.  We're on thin
> ice here.  Linus is making up the rules, which is cool (since I tend to
> like his rules) but the reality is that the GPL doesn't allow you to
> extend the GPL.  It's the GPL or nothing.

Larry, you are wrong.

The license _IS_ the GPL. There's no issue about that. The GPL rules apply
100%.

But a license only covers what it _can_ cover - derived works. The fact
that Linux is under the GPL simply _cannot_matter_ to a user program, if
the author can show that the user program is not a derived work.

And the linux/COPYING addition is not an addition to the license itself
(indeed, it cannot be, since the GPL itself is a copyrighted work, and so
by copyright law you aren't allowed to just take it and change it).

No, the note at the top of the copying file is something totally
different: it's basically a statement to the effect that the copyright
holder recognizes that there are limits to a derived work, and spells out
one such limit that he would never contest in court.

See? It's neither a license nor a contract, but it actually does have
legal meaning: look up the legal meaning of "estoppel" (google "define:"
is qutie good). Trust me, it's got _tons_ of legal precedent.

		Linus

• Archive of above thread
• KernelTrap interview with Larry McVoy