Linux GPL and binary module exception clause?

10 views
Skip to first unread message

Kendall Bennett

unread,
Dec 3, 2003, 4:40:20 PM12/3/03
to
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! ~

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Arjan van de Ven

unread,
Dec 3, 2003, 5:00:28 PM12/3/03
to
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


signature.asc

Richard B. Johnson

unread,
Dec 3, 2003, 5:20:18 PM12/3/03
to
On Wed, 3 Dec 2003, 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. 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?
>

I'll jump into this fray first stating that it is really great
that the CEO of a company that is producing high-performance graphics
cards and acceleration software is interested in finding out this
information. It seems that some other companies just hack together some
general-purpose source-code under GPL and then link it with a secret
object file. This, of course, defeats the purpose of the GPL (which is
or was to PUBLISH software in human readable form).

It is certainly time for a definitive answer.

Maybe Linus knows the answer.

> 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!!
>

I have been told by lawyers who do intellectual property
law for a living that under US Copyright law, the INSTANT
that something is written anywhere in a manner that allows
it to be read back, it is protected by the writer's default
copyright protection. The writer may alter that protection or
even assign ownership to something or somebody else, but nobody
needs to put a copyright notice anywhere in text. Now, if you
intend to sue, before that suit starts, the text must be registered
with the United States Copyright Office. In that case, it still
doesn't need a copyright notice or the famous (c) specified by
the act. It just needs to be identified by the writer, like:

File: TANGO.FOR Created 12-DEC-1988 John R. Doe

Grin... from my VAX/VMS days.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.

Xose Vazquez Perez

unread,
Dec 3, 2003, 6:10:13 PM12/3/03
to
Arjan van de Ven wrote:

> there is no such exception, for example see:
>
> http://www.kernelnewbies.org/kernels/rh9/SOURCES/COPYING.module

and 'Proprietary kernel modules' in: http://people.redhat.com/rkeech/pkm.html

moral:
closed source modules sucks.

Jason Kingsland

unread,
Dec 3, 2003, 6:30:27 PM12/3/03
to
Kendall Bennett wrote:
>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?


The exception does not exist, at least not as a clearly stated license
ammendment or similar.

There was some email discussion on this topic with input from the various
Linux contributors some time back, but no firm conclusion. It's archived
here: http://people.redhat.com/rkeech/pkm.html

This led indirectly to the introduction of the GPL license flag for kernel
API calls, so that authors who specifically don't want their code used by
binary modules can mark it as such.

By inference, this essentially provided a defendable position that binary
loadable modules are OK so long as they don't use API calls explicitly
defined as GPL only. Otherwise why else would such a flag have been
introduced?

Many vendors use this as an excuse not to release their software under GPL.
They are distributing GPL derived works in a binary-only format and are in
violation of the Linux kernel copyright as far as I am aware.

This doesn't make it any more legal - but I suspect that it's a case of risk
assessment on a case by case basis.

One assessment could be that the Linux authors are not likely to sue for
copyright violation because they'll never get together and agree to enforece
the GPL in this scenario, due to such differing opinions.

There are many instances of companies either ignoring the GPL license for
their Linux-derived products, or at least not providing source for kernel
modules they develop to support their proprietary hardware.

Just look at where Linux is embedded it consumer electronics (cellphones,
DVD players etc) and how many of those are shipped with GPL license, source
code or the required offer of source code.

From time when a GPL violation is brought out into the open on Slahsdot,
this mailing list or elsewhere. There is never any concerted effort by Linux
authors to defend the copyright and insist on GPL compliance.

Part of the problem is that for Linux, copyright is not assigned back to any
one person or entity therefore it's more difficult for any individual to try
and 'fight the cause' of GPL compliance. Another problem is that Linux is
global, and many of the binary-only vendors are in the far-east where the
culture is perhaps less concerned about copyright law, US or otherwise.

So it seems that there is nothing do loose, anyone can take Linux and do
whatever they please with it and not have to be particularly worried about
contributing back to the community or complying with the rules of the
commons, because nobody is likely to enforce the requirements against them.

_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today!
http://www.msn.co.uk/messenger

Kendall Bennett

unread,
Dec 3, 2003, 6:40:22 PM12/3/03
to
"Richard B. Johnson" <ro...@chaos.analogic.com> wrote:

> > 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?
>
> I'll jump into this fray first stating that it is really great that
> the CEO of a company that is producing high-performance graphics
> cards and acceleration software is interested in finding out this
> information. It seems that some other companies just hack together
> some general-purpose source-code under GPL and then link it with a
> secret object file.

Well one of the primary reasons we are interested in researching this is
because we are in the process of preparing to release the SciTech SNAP
DDK under the GNU GPL license (dual licensed for proprietry developers),
and want to understand the ramifications of this approach. I must say I
am surprised to see that such a clause does not exist, since binary only
modules seem to be pretty abundant in the community.

Then again the whole 'derived works' clause in the GPL is a huge gray
area IMHO, and even just sitting there arguing with myself I can come up
with pretty good arguments in both directions for why a binary only
module is legal or not. Especially when the only reference to this in the
GNU GPL FAQ is about plugins, and they use a really silly distinction
about whether a plugin uses fork/exec or not. I mean if you use fork/exec
to start the plugin, yet the plugin uses RPC and shared memory to
communicate with the main process, that is the same as local procedure
calls and local memory IMHO.

> > 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!!
>
> I have been told by lawyers who do intellectual property law for a
> living that under US Copyright law, the INSTANT that something is
> written anywhere in a manner that allows it to be read back, it is
> protected by the writer's default copyright protection.

Yes of course, but if there is no notice in the file, who is the
copyright holder? Only the original author knows for sure, and for
someone to *use* that file without permission from the original author
would be inviting a lawsuit.

> The writer may alter that protection or even assign ownership to
> something or somebody else, but nobody needs to put a copyright
> notice anywhere in text. Now, if you intend to sue, before that
> suit starts, the text must be registered with the United States
> Copyright Office. In that case, it still doesn't need a copyright
> notice or the famous (c) specified by the act. It just needs to be
> identified by the writer, like:
>
> File: TANGO.FOR Created 12-DEC-1988 John R. Doe
>
> Grin... from my VAX/VMS days.

Right, but there are files in the source code with *nothing* at the top.
No copyright header, not notice of who wrote the file, nothing.

In my opinion, unless a specific source file has a copyright notice
attached to it and specifically says 'you are licensed to use this file
under the terms of the GNU GPL - see the COPYING file' etc, then that
file is *not* under the GNU GPL. What that means is that I would have
zero rights to use that file without direct permission from the author,
and realistically should not use it.

If there are lots of files like that in the Linux kernel, then that means
that none of us really have the right to use Linux on our machines!
Yikes. Considering that all GNU projects contain this type of header, I
have always just assumed the Linux kernel source code would too.
Especially now with this SCO debacle going on.

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! ~

-

Kendall Bennett

unread,
Dec 3, 2003, 6:40:25 PM12/3/03
to
arj...@redhat.com wrote:

Thanks for the link, that pretty much explains what I needed to know!

bill davidsen

unread,
Dec 3, 2003, 7:00:27 PM12/3/03
to
In article <Pine.LNX.4.53.0312031648390.3725@chaos>,

Richard B. Johnson <ro...@chaos.analogic.com> wrote:
| On Wed, 3 Dec 2003, 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. 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?
| >
|
| I'll jump into this fray first stating that it is really great
| that the CEO of a company that is producing high-performance graphics
| cards and acceleration software is interested in finding out this
| information.

Really? I guess I'm just suspicious, but when someone who might have an
interest in only providing a binary driver asks about the legality of
doing that, "great" is not my first thought.

| information. It seems that some other companies just hack together some
| general-purpose source-code under GPL and then link it with a secret
| object file. This, of course, defeats the purpose of the GPL (which is
| or was to PUBLISH software in human readable form).

Yes, I am a devout fundamentalist paranoid, but I've based my life on
the assumptions that I should treat others fairly and expect them to
screw me if they could, and both have served me well.

I do not mean to cast aspersions on the original poster, about whom I
know nothing. There are many companies who have provided full source
drivers, and I have rewarded them with my business. I have chosen less
performance video over binary module hardware, and would be very happy
if there were some guilt-free hardwaree to use. I'm just starting to do
video processing, I'd be *really* happy, ecstatic even.
--
bill davidsen <davi...@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Linus Torvalds

unread,
Dec 3, 2003, 7:10:18 PM12/3/03
to

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

Linus Torvalds

unread,
Dec 3, 2003, 7:30:20 PM12/3/03
to

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..

Kendall Bennett

unread,
Dec 3, 2003, 7:40:06 PM12/3/03
to
Linus Torvalds <torv...@osdl.org> wrote:

> 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.

Right, after following a few of the links and reading the previous
discussions, that is clear to me now ;-)

> 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.

Or what if a device driver is written such that it is completely binary
portable between different operating systems, such that the same binary
can work on Linux, OS/2, Windows, QNX, BeOS and multiple embedded
systems? Clearly I am talking about our SciTech SNAP drivers here, as
that is what they are. Would writing glue code to allow those modules to
be loaded inside the Linux kernel make the binary driver modules derived
works? Clearly the glue code would be Linux specific and hence need to be
GPL, but would it extend to the binary module? I can also come up with
some arguments both for and against this scenario, and I agree 100% that
it is a huge gray area.

To date we have not even attempted to load our SNAP drivers inside the
Linux kernel, even though it would be quite easy to do so, primarily
because of this gray area. We may need to write some kernel modules
shortly to support a few things that the SNAP drivers may need, but since
the user space drivers would interface to this kernel module via system
calls, only the kernel module would need to the GPL and the user space
driver that uses it would not. So we may never try to load the SNAP
drivers inside the kernel, but it is an interesting exercise to consider
the legality of whether it is possible.

Anyway loading SNAP drivers inside the Linux kernel, while interesting,
wasn't the reason I brought up this discussion. The primary reason is
that we are going to be releasing the SciTech SNAP DDK under the GNU GPL
soon, and I wanted to understand how this expection clause works. Since
it doesn't exist, it does open up a few questions ;-)

It is our position that drivers that would be built from our GNU GPL DDK
are in themselves separate works as they follow a clearly defined, binary
compatible interface and can be used with software building using a non-
GPL version of our SDK (the SDK is actually LGPL). The driver binary
itself on the other hand must be GPL, as it links against generic code
provided to the developer as part of the DDK, so full source to any
driver built with the GPL DDK must be provided. Even your own writings on
this issue would indicate that you would agree with me on that front.

The lowest level binary modules have a 'less public' interface, in that
we do not directly document it (well, at least not yet except for the
header files but some may consider that valid documentation). It does
evolve more quickly over time than the public SDK API, but even so the
drivers ABI is strictly maintained for backwards compatibility, even
though it does evolve. We have a clearly defined interface for evolving
the API while maintaining backwards compatibility, and even doing hot bug
fixes for existing binary drivers as necessary. But above the low level
driver is the public SciTech SNAP API, which evolves much, much more
slowly and is completely documented (both at the header file level and
external documentation level).

Does my position make sense?

Clearly the intention here is to make sure that the GPL version of our
DDK is available for free use by the Free Software community, but if
someone like Intel or NVIDIA wants to write a SNAP driver that they don't
provide source code for, they need to license a proprietry licensed
version of our DDK.

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! ~

-

Aaron Smith

unread,
Dec 3, 2003, 8:00:21 PM12/3/03
to

>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
>
>
My question is a natural extension of this point and subsequent posts,
When is a kernel so tainted it can no longer be considered GPL, or can
no longer be considered free software? I write software for astronomical
applications where some vendors give binary only drivers, or give you
restricted access to the source code so I will some times load 5 or 6
devices that are binary only or at least non GPL. So what taint is
allowable?

Thanks,
Aaron Smith
Virginia Astronomical Instrumentation Laboratory
Programmer

PS sorry if this is a stupid question.

David Lang

unread,
Dec 3, 2003, 8:10:22 PM12/3/03
to
there is no way to taint something so much that it's no longer covered by
the GPL (if it was that would mean that you have no legal way to have a
copy of it).

Remember that the GPL doesn't put any restrictions on what you do with the
code as long as you are not distributing it.

becouse of this you could take the kernel and include any propriatary code
in it that you want and run it. You don't even need to use modules, just
paste in th code and compile (make sure you have a legal right to the code
you are pasting in though :-)

the GPL comes in when you distribute it (and even here there are grey
areas, does it count as distributing code to put it on a companies
desktops for example?, but if you sell it or incude it in a product that
you sell you definantly do have to release the source)

if you are talking about the 'tainted' flag in the kernel, that is just a
flag that you should not expect to get support for this configuration
from the opensource developers.

does this answer your question?

David Lang

On Wed, 3 Dec 2003, Aaron Smith wrote:

> Date: Wed, 03 Dec 2003 19:52:26 -0500
> From: Aaron Smith <aw...@virginia.edu>
> To: linux-...@vger.kernel.org
> Subject: Re: Linux GPL and binary module exception clause?

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Aaron Smith

unread,
Dec 3, 2003, 8:30:13 PM12/3/03
to
Thank you for clarifiing that. Now I wont feel so guilty for modifying
my init scripts :-)

-Aaron Smith

Jamie Lokier

unread,
Dec 4, 2003, 12:00:07 AM12/4/03
to
David Lang wrote:
> becouse of this you could take the kernel and include any propriatary code
> in it that you want and run it. You don't even need to use modules, just
> paste in th code and compile (make sure you have a legal right to the code
> you are pasting in though :-)

To elaborate on this: most patches which apply to the Linux kernel are
clearly derived works of the kernel.[*]

You can write and apply such a patch , but if you distribute the patch
it must be licensed under the GPL.

Thus while _you_ may take a Linux kernel and include any proprietary
code you want in it, a vendor _may not_ send you a patch which applies
to the Linux kernel if the patch is not licensed under the GPL or a
compatible license. A vendor is not allowed to restrict your rights
in this way.

[*] Exceptions would be patches which are very small (<10 lines is
sometimes suggested, but it's not a hard boundary), and patches which
simply add code which is clearly not derived form the kernel, as Linus
described.

-- Jamie

Karim Yaghmour

unread,
Dec 4, 2003, 1:30:08 AM12/4/03
to

Hello Linus,

Linus Torvalds wrote:
> 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..

Since the last time this was mentioned, I have been thinking that this
argument can really be read as an invitation to do just what's being
described: first implement a driver/module in a non-Linux OS (this may even
imply requiring that whoever works on the driver/module have NO Linux
experience whatsoever; yes there will always be candidates for this) and then
have this driver/module ported to Linux by Linux-aware developers.

Sure, one could argue about "intent", but that's going to be really
difficult, especially if the right-hand doesn't know what the left-hand
is doing. IOW, can't this position be abused as much as, if not more
than, publishing an "approved" set of characteristics for non-GPL modules?

Just thinking aloud,

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 514-812-4145

Jason Kingsland

unread,
Dec 4, 2003, 10:30:18 AM12/4/03
to
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

Linus Torvalds

unread,
Dec 4, 2003, 11:10:17 AM12/4/03
to

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

Ihar 'Philips' Filipau

unread,
Dec 4, 2003, 12:10:23 PM12/4/03
to
Jason Kingsland wrote:
> 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.
>

GPL is about distribution.

e.g. NVidia can distribute .o file (with whatever license they have
to) and nvidia.{c,h} files (even under GPL license).
Then install.sh may do on behalf of user "gcc nvidia.c blob.o -o
nvidia.ko". Resulting module are not going to be distributed - it is
already at hand of end-user. So no violation of GPL whatsoever.

Licensing is least technical issue regarding modules.
But sure I would like to have open source drivers - at least then I
have chance to clean them up ;-)))

my 2 eurocents.

--
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
-- _ _ _
Because the kernel depends on it existing. "init" |_|*|_|
literally _is_ special from a kernel standpoint, |_|_|*|
because its' the "reaper of zombies" (and, may I add, |*|*|*|
that would be a great name for a rock band).
-- Linus Torvalds

Thierry Vignaud

unread,
Dec 4, 2003, 1:00:37 PM12/4/03
to
"Ihar 'Philips' Filipau" <fi...@softhome.net> writes:

> GPL is about distribution.
>
> e.g. NVidia can distribute .o file (with whatever license they have
> to) and nvidia.{c,h} files (even under GPL license).
> Then install.sh may do on behalf of user "gcc nvidia.c blob.o -o
> nvidia.ko". Resulting module are not going to be distributed - it is
> already at hand of end-user. So no violation of GPL whatsoever.
>
> Licensing is least technical issue regarding modules.
> But sure I would like to have open source drivers - at least then I
> have chance to clean them up ;-)))

offtopic anyway since nvidia already provide prebuild binaries for
linux at http://www.nvidia.com/object/linux.html ...

vi...@parcelfarce.linux.theplanet.co.uk

unread,
Dec 4, 2003, 2:30:24 PM12/4/03
to
On Wed, Dec 03, 2003 at 04:23:33PM -0800, Linus Torvalds wrote:

> 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.

FWIW, it would be very nice if somebody did hard and messy work and
produced lists of in-tree modules using given symbols. Ideally - automated
that, but that won't be easy to do (quite a few are used only via inlined
wrappers and in some cases - under an ifdef; many arch-specific exports
are of that sort).

Aside of "hey, nothing uses that at all" and "only core uses it"
we'd get a bunch of "hmm, we really should've exported higher-level function
instead" and "WTF does that lone driver use this function?". I'd played
with that for fs/* exports and so far results look interesting. I'm using
grep, but that's pretty much hopeless - we have literally thousands of
exported symbols and any manual approach will break on that.

Some approximation might be obtained by building all modules and
doing nm on them, with manual work for non-obvious cases. I've done that
on x86 (allmodconf + enabling whatever could be enabled, even if broken).
Statistics is interesting, to put it mildly.

First of all, there are ~3600 symbols used by some in-tree drivers.
~600 of them are have 10 users or more. ~2000 have only one or two users.
And we have ~7500 EXPORT_... in the tree. Now, that number is inflated by
duplicates between architectures (and other stats are deflated by incomplete
coverage). And yes, there are things that have every reason to be exported,
but only a few modules care to use them.

However, it certainly looks like a large fraction of export list
should go away. Moreover, we probably should introduce
EXPORT_FOR(symbol, module list)
and use it for stuff like jbd poking very deep in buffer.c guts - deeper
than anybody else. Ditto for ipv6 / ipv4 interaction - they really have
a special relationship and it makes no sense whatsoever to treat everything
in TCPv4 guts that happens to be shared with TCPv6 as public export. There's
a lot of cases like that and I suspect that they cover ~50-60% of the in-tree
imports.

Real interface is somewhere around 400-500 symbols and it can be
split into several more or less compact parts. Having more than an order
of magnitude more than that, and having it as a big pile... Not a good
thing(tm), IMO.

Paul Adams

unread,
Dec 4, 2003, 7:00:14 PM12/4/03
to
--- In linux-...@yahoogroups.com, Linus Torvalds

<torvalds@o...> wrote:
> - 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.

I am no more a lawyer than you are, but I have to
disagree. You
are not free to define "derivative work" as you
please. You
must use accepted legal definitions. At least in the
U.S., you
must consider what Congress had to say on this. They
said, "to
constitute a violation of section 106(2) [which gives
copyright
owners rights over derivative works], the infringing
work must
incorporate a portion of the copyrighted work in some
form; for
example, a detailed commentary on a work or a
programmatic musical
composition inspired by a novel would not normally
constitute
infringements under this clause."
http://www4.law.cornell.edu/uscode/17/106.notes.html

A work that is inspired by Linux is no more a
derivative work than
a programmatic musical composition inspired by a
novel. Having
Linux in mind cannot be enough to constitute
infringement.

Remember also that U.S. copyright law states:
"In no case does copyright protection for an original
work of
authorship extend to any idea, procedure, process,
system, method
of operation, concept, principle, or discovery,
regardless of
the form in which it is described, explained,
illustrated, or
embodied in such work."
http://www4.law.cornell.edu/uscode/17/102.html
Thus you cannot claim infringement because a work
merely shares
ideas or methods of operation with Linux.

The standard used in U.S. courts for determining if
software
violates a copyright includes a filtering procedure to
eliminate
unprotected aspects as described above. A standard
filter is that
you eliminate an element if "The element's expression
was dictated
by external factors, such as using an existing file
format or
interoperating with another program." Computer
Associates v.
Altai specifically discusses the need to filter
elements related
to "compatibility requirements of other programs with
which a
program is designed to operate in conjunction."
http://www.bitlaw.com/source/cases/copyright/altai.html
Code needed to interoperate with the Linux kernel thus
cannot be
considered as a factor in determining if the Linux
copyright is
infringed.

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.

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Oliver Hunt

unread,
Dec 4, 2003, 7:20:11 PM12/4/03
to

Paul Adams wrote:

Yes, but the if you want to write a kernel modules you need to #include
at least a few of the headers: you are including copyrighted work...

What (i think) linus is saying is that he, as the owner of the
copyright, would accept a ported driver as not being derived(as most of
the work would have been based on another system, not linux), but that
is his choice, he is allowed to relax the terms of use because it is his
copyright...

I'm not however ever a lawyer...

--Oliver
The Department Formerly Known as Cosc
University of Canterbury
New Zealand

Nick Piggin

unread,
Dec 4, 2003, 7:30:22 PM12/4/03
to

Paul Adams wrote:

Of course not, thought police aren't any good until a mind reader
is invented ;)

Seriously:
What about specifically a module that includes the Linux Kernel's
headers and uses its APIs? I don't think you could say that is
definitely not a derivative work.

Erik Andersen

unread,
Dec 4, 2003, 7:50:08 PM12/4/03
to
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--

Zwane Mwaikambo

unread,
Dec 4, 2003, 8:10:07 PM12/4/03
to
On Thu, 4 Dec 2003, Erik Andersen wrote:

> 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.

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

Erik Andersen

unread,
Dec 4, 2003, 8:10:10 PM12/4/03
to
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--

Larry McVoy

unread,
Dec 4, 2003, 8:30:09 PM12/4/03
to
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

Hua Zhong

unread,
Dec 4, 2003, 8:40:05 PM12/4/03
to
> But given that, neither Linus (nor any of you) get to say
> "well, that's fine for userland but drivers are derived works".

Indeed. Linus said nowadays kernel modules developed with Linux
specifically in mind are less likely to be considered "not a derived
work" as early days kernel modules.

However, how about user space programs designed specifically for Linux,
and even using Linux specific system calls?

It's definitely a grey area here, and it's not so clear that kernel-user
boundary is stronger than kernel-kernel boundary per se. :-)

Note kernel-user boundary is not just normal system calls. /proc, ioctl
(provided by kernel modules) are also part of it (which are system calls
too but they can be arbitrarily extended).

Linus Torvalds

unread,
Dec 4, 2003, 8:50:16 PM12/4/03
to

On Thu, 4 Dec 2003, Paul Adams wrote:
>
> A work that is inspired by Linux is no more a derivative work than
> a programmatic musical composition inspired by a novel. Having
> Linux in mind cannot be enough to constitute infringement.

But it does - you have to include the Linux header files in order to be
able to make any nontrivial module.

I'm not claiming that "thinking about Linux makes you tainted". It's not
about inspiration. But it's a bit like getting somebody pregnant: you have
to do a lot more than just think about it to actually make it happen, or
every high school in the world would be crawling with babies.

In other words: feel free to be inspired by Linux all you want. But if you
release a binary module that loads and works, you've been doing more than
just feeling inspired. And then you need to be _careful_.

Linus

David Schwartz

unread,
Dec 4, 2003, 9:10:08 PM12/4/03
to

> My personal view is that Linux should mandate GPL for all modules
> in 2.6 and
> beyond.

I'm baffled how you think this is a choice that can be made. The license is
the GPL itself and even the Linux kernel developers have no power to change
it.

DS

Linus Torvalds

unread,
Dec 4, 2003, 9:10:05 PM12/4/03
to

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

David Schwartz

unread,
Dec 4, 2003, 9:10:10 PM12/4/03
to

> 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.

There you go, *ONCE* *LOADED* it becomes an integral part. So it's the
*use* of it that makes it integral. Disitribution is prior to use.

> 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.

Except the kernel function calls are not copyrighted, only their
implementation is. If you really meant what you're saying, any program that
used 'malloc' would be a derived work of any implementation of 'malloc'.

> 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...

So long as it must be mixed with the original work (and isn't already),
it's not clear that it's a derived work as it sits. Again, otherwise any
program that used 'malloc' would be a derived work of any implementation of
'malloc'.

DS

Kendall Bennett

unread,
Dec 4, 2003, 9:10:19 PM12/4/03
to
Nick Piggin <pig...@cyberone.com.au> wrote:

> What about specifically a module that includes the Linux Kernel's
> headers and uses its APIs? I don't think you could say that is
> definitely not a derivative work.

You cannot copyright an API - people have been down that path before in
the proprietry software community and have not succeeded. You can
copyright the code in the header files, but does simply using the header
files to build a program mean that the driver is now infected? If the
header files include lots and lots of inline functions that ended up
compiled into the code, then maybe.

Then again, it appears that most developers are using wrapped to avoid
this situation, such that their private code does not include any Linux
headers, only the GPL'ed wrapper.

So we go in circles again.

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! ~

-

Kendall Bennett

unread,
Dec 4, 2003, 9:10:20 PM12/4/03
to
Erik Andersen <ande...@codepoet.org> wrote:

> 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.

But what about the case I stated earlier for a driver that is completely
binary portable between different operating systems. Hence the low level
portion of the driver is not Linux specific at all, and in fact not even
designed specifically with Linux in mind. That muddies the waters even
more, and even Linus has said he would believe such a driver to be OK.

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! ~

-

Jason Kingsland

unread,
Dec 4, 2003, 9:50:09 PM12/4/03
to

> My personal view is that Linux should mandate GPL for all modules in 2.6
and beyond.

"David Schwartz" wrote:
> I'm baffled how you think this is a choice that can be made. The license
is
> the GPL itself and even the Linux kernel developers have no power to
change it.

Modules are essentially dynamically linked extensions to the GPL kernel. In
some cases they can be shown to be independent, prior works where GPL can
reasonably be argued not to apply - which as Linus stated earlier on this
thread was the original intention of allowing binary-only modules.

But in most of the more recent cases the driver/module code is written
specifically for Linux, so it seems more appropriate that they would be
considered as derived works of the kernel. But those various comments from
Linus are being taken out of context to somehow justify permission for the
non-release of source code for binary loadable modules.

Linux is not pure GPL, it also has the Linus "user program" preamble in
copying.txt - that preamble plus other LKML posts from Linus are commonly
used as justifications for non-disclosure of source code to some classes of
modules.

But with all due respect, Linus is not the only author of Linux and his
words to tend to convey an artificial sense of authority or justification
for such attitudes. Here is a typical example:
http://www.linuxdevices.com/articles/AT9161119242.html

All I am suggesting is that the preamble could be extended to clearly state
the position for kernel binary-only modules, and that the upcoming 2.6
release might be an opportunity for a quorum of the Linux authors to agree
to revised wording.

Jason Kingsland

unread,
Dec 4, 2003, 11:00:28 PM12/4/03
to

On Thu, Dec 04, 2003 at 06:03:49PM -0700, Erik Andersen 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".

Larry McVoy adds:


> 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.


Actually, about two years ago a large company I previously worked at
performed a formal legal review of the GPL, as part of a due-dilligence
review whether to use Linux rather than a commercial OS in some of its
products.

One of the points raised was that the license clarification for user
programs was added by Linus to copying.txt well before most other authors
started working on the kernel - it can be traced back to a nascent version
of Linux to which most everyone else then submitted their code into later
on.

It was the opinion of the IPR lawyer reviewing the license that the "user
program" clarification is therefore a part of the core Linux license, is
legally binding and applies to all such subsequent code submitted by other
authors.

It's a subtle point, but I thought it would be worth a mention. Ultimately,
it would be for the courts to decide I guess, if any GPL copyright dispute
ever makes it that far.

Just goes to show that some companies are concerned about working
effectively with the GPL - it took several weeks of highly paid IPR lawyers
to formate a policy document which they considered acceptable use.

Peter Chubb

unread,
Dec 4, 2003, 11:30:16 PM12/4/03
to
>>>>> "Nick" == Nick Piggin <pig...@cyberone.com.au> writes:

Nick> Paul Adams wrote:


Nick> Seriously: What about specifically a module that includes the
Nick> Linux Kernel's headers and uses its APIs? I don't think you
Nick> could say that is definitely not a derivative work.

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

Note:


Paul> A standard filter is that you eliminate an element if "The
Paul> element's expression was dictated by external factors, such as
Paul> using an existing file format or interoperating with another
Paul> program." Computer Associates v. Altai specifically discusses
Paul> the need to filter elements related to "compatibility
Paul> requirements of other programs with which a program is designed
Paul> to operate in conjunction."
Paul> http://www.bitlaw.com/source/cases/copyright/altai.html


If you don't accept this, then maybe you have to start accepting SCO's
claims on JFS, XFS, &c.

(Disclaimer: I am not a lawyer)
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*

Erik Andersen

unread,
Dec 5, 2003, 12:10:05 AM12/5/03
to
On Thu Dec 04, 2003 at 05:58:38PM -0800, David Schwartz wrote:
> There you go, *ONCE* *LOADED* it becomes an integral part. So
> it's the *use* of it that makes it integral. Disitribution is
> prior to use.

Steven Spielberg doesn't care what you do to his movies in the
privacy of your own home. You can use them as a room dividers
for your hamsters if you want for all he cares. But if you try
modifying his movies, i.e. to remove the sex, nudity, and
violence and then distribute them, you will join Clean Flicks in
court [1].

Or maybe you feel like making a Harry Potter knockoff. Go ahead
and write whatever you want in the privacy of your own home. If
you dare to try distributing such a knock off novel, you will shortly
find Time-Warner sending a herd of lawyers your direction [2].

Similarly, nobody cares what kernel modules you feel like making
and loading in the privacy of your own home.

> So long as it must be mixed with the original work (and isn't
> already), it's not clear that it's a derived work as it sits.
> Again, otherwise any program that used 'malloc' would be a
> derived work of any implementation of 'malloc'.

The act of compiling a program and linking that program with a
library certainly does create a derivitive work of that library.
Try linking your program with the 30-day evaluation version of
Intel's Math Kernel Library and distributing the result without
paying them for a license. Try using Qt in a non-GPL closed
source product without paying Trolltech. Try using MS Visual
Studio to create and distribute your own competing compiler.
Guess how fast you would have herds of lawyers visiting to
discuss your opinions of what is and is not a derived work?

-Erik

[1] http://writ.news.findlaw.com/hilden/20020903.html
[2] http://slate.msn.com/id/2084960/

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

Nick Piggin

unread,
Dec 5, 2003, 12:10:07 AM12/5/03
to

Peter Chubb wrote:

>>>>>>"Nick" == Nick Piggin <pig...@cyberone.com.au> writes:
>>>>>>
>
>Nick> Paul Adams wrote:
>
>
>Nick> Seriously: What about specifically a module that includes the
>Nick> Linux Kernel's headers and uses its APIs? I don't think you
>Nick> could say that is definitely not a derivative work.
>
>As far as I know, interfacing to a published API doesn't infringe
>copyright.
>

So binary modules don't infringe copyright and aren't derived works?
If so then the way to control access to the kernel is to control the
"published API" ie. the api/abi exported modules, and exceptions for
GPL modules are useless. Hmm.

>
>Note:
>
>
>Paul> A standard filter is that you eliminate an element if "The
>Paul> element's expression was dictated by external factors, such as
>Paul> using an existing file format or interoperating with another
>Paul> program." Computer Associates v. Altai specifically discusses
>Paul> the need to filter elements related to "compatibility
>Paul> requirements of other programs with which a program is designed
>Paul> to operate in conjunction."
>Paul> http://www.bitlaw.com/source/cases/copyright/altai.html
>
>
>If you don't accept this, then maybe you have to start accepting SCO's
>claims on JFS, XFS, &c.
>

Not quite sure what you mean here. As far as I was aware, SCO doesn't
have any copyrights or patents on any code in the Linux Kernel so it is
not a similar situation. I haven't followed the SCO thing closely though.

Valdis.K...@vt.edu

unread,
Dec 5, 2003, 12:20:11 AM12/5/03
to
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.....

Hua Zhong

unread,
Dec 5, 2003, 12:30:13 AM12/5/03
to
> 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.

What's so fundamentally different about inline functions, or, IOW, a
finer format of macros?

It doesn't matter if the API is inline or not. What matters is if using
this API makes your program a derivative work. From this perspective,
it's just an interface, no matter how it's implemented.

Let's be frank: how many people really try to read the header file when
they use these APIs? They don't care if they are inlined or not. To them
they are just _APIs_.

David Schwartz

unread,
Dec 5, 2003, 1:40:11 AM12/5/03
to

> Or maybe you feel like making a Harry Potter knockoff. Go ahead
> and write whatever you want in the privacy of your own home. If
> you dare to try distributing such a knock off novel, you will shortly
> find Time-Warner sending a herd of lawyers your direction [2].

Yes, but they will cite the prohibition against *creating* derived works.

> Similarly, nobody cares what kernel modules you feel like making
> and loading in the privacy of your own home.

There's a difference between what you can and can't do and what you can and
can't get away with. You can get away with making a Harry Potter sequel in
the privacy of your own home because nobody would find about it, however
legally, you do not have the right to create the derived work. However, if
you did have the right to create the derived work, you'd automatically have
the right to distribute it to anyone who already owned the original work
from which it was derived.

> > So long as it must be mixed with the original work (and isn't
> > already), it's not clear that it's a derived work as it sits.
> > Again, otherwise any program that used 'malloc' would be a
> > derived work of any implementation of 'malloc'.

> The act of compiling a program and linking that program with a
> library certainly does create a derivitive work of that library.

Right, however, you have the right to create that derivative work.

> Try linking your program with the 30-day evaluation version of
> Intel's Math Kernel Library and distributing the result without
> paying them for a license. Try using Qt in a non-GPL closed
> source product without paying Trolltech. Try using MS Visual
> Studio to create and distribute your own competing compiler.
> Guess how fast you would have herds of lawyers visiting to
> discuss your opinions of what is and is not a derived work?

These cases are much more interesting, except for the MS VC case. In the MS
VC case, there's a EULA that courts are likely to consider part of the sales
contract. As for the others, I think you'd have a very good chance of
winning them. See, for example, ProCD v. Zeidelberg (sp?). In the absence of
a shrink wrap or clickthrough at least, it would seem you only have those
specific rights copyright grants you, and the right to restrict the
distribution of derived works is not one of those rights.

DS

David Schwartz

unread,
Dec 5, 2003, 1:40:12 AM12/5/03
to

> 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.

Linus Torvalds

unread,
Dec 5, 2003, 1:50:07 AM12/5/03
to

On Thu, 4 Dec 2003, David Schwartz wrote:
>
> Yes, but they will cite the prohibition against *creating* derived
> works.

So?

The same prohibition exists with the GPL. You are not allowed to create
and distribute a derived work unless it is GPL'd.

I don't see what you are arguing against. It is very clear: a kernel
module is a derived work of the kernel by default. End of story.

You can then try to prove (through development history etc) that there
would be major reasons why it's not really derived. But your argument
seems to be that _nothing_ is derived, which is clearly totally false, as
you yourself admit when you replace "kernel" with "Harry Potter".

Linus

Linus Torvalds

unread,
Dec 5, 2003, 2:10:10 AM12/5/03
to

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

Stefan Smietanowski

unread,
Dec 5, 2003, 2:40:12 AM12/5/03
to
Kendall Bennett wrote:

> Erik Andersen <ande...@codepoet.org> wrote:
>
>
>>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.
>
>
> But what about the case I stated earlier for a driver that is completely
> binary portable between different operating systems. Hence the low level
> portion of the driver is not Linux specific at all, and in fact not even
> designed specifically with Linux in mind. That muddies the waters even
> more, and even Linus has said he would believe such a driver to be OK.

You mean kind of like a program being compiled by a compiler?

The program isn't designed for a specific platform/cpu/os/whatnot but
when compiled it's specific to a platform/cpu/os/whatnot. With the
"program" being the low level stuff and the extra cruft all compilers
include being the glue.

// Stefan

Peter Chubb

unread,
Dec 5, 2003, 3:30:15 AM12/5/03
to
>>>>> "Nick" == Nick Piggin <pig...@cyberone.com.au> writes:

Nick> Peter Chubb wrote:

Nick> Not quite sure what you mean here. As far as I was aware, SCO
Nick> doesn't have any copyrights or patents on any code in the Linux
Nick> Kernel so it is not a similar situation. I haven't followed the
Nick> SCO thing closely though.

As I understand it, SCO is/was claiming that JFS and XFS are derived
works of the UNIX source base, because they were developed to match
the internal interfaces of UNIX, and with knowledge of the internals
of UNIX -- and they hold the copyrights of and are the licensor of UNIX.

I may be misunderstanding their points. And I am not a lawyer.

--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*

Adam J. Richter

unread,
Dec 5, 2003, 5:40:22 AM12/5/03
to
I am not a lawyer, so please do not rely on what I say as
legal advice.

Even for proprietary Linux kernel modules that do not contain
a byte of GPL'ed code, I see at least two levels of potential copyright
infringement. I think the conversation has largely missed the second,
and more important case: contributory infringment, but I really have
to start with the direct infringement to explain clearly.

The direct infringement occurs occurs when a user creates an
infringing work in RAM, which I think is restrictable for works that
are licensed rather than sold due to the US 9th circuit federal
appeals court decision MAI Systems Corp. v. Peak Computer [1]:

| [39] We have found no case which specifically holds that the copying of
| software into RAM creates a "copy" under the Copyright Act. However,
| it is generally accepted that the loading of software into a computer
| constitutes the creation of a copy under the Copyright Act. See
| e.g. Vault Corp. v. Quaid Software Ltd., 847 F.2d 255, 260 (5th
| Cir. 1988) ("the act of loading a program from a medium of storage
| into a computer's memory creates a copy of the program"); 2 Nimmer on
| Copyright, § 8.08 at 8-105 (1983) ("Inputting a computer program
| entails the preparation of a copy."); Final Report of the National
| Commission on the New Technological Uses of Copyrighted Works, at 13
| (1978) ("the placement of a work into a computer is the preparation of
| a copy"). We recognize that these authorities are somewhat troubling
| since they do not specify that a copy is created regardless of whether
| the software is loaded into the RAM, the hard disk or the read only
| memory ("ROM"). However, since we find that the copy created in the
| RAM can be "perceived, reproduced, or otherwise communicated," we hold
| that the loading of software into the RAM creates a copy under the
| Copyright Act. 17 U.S.C. § 101. We affirm the district court's grant
| of summary judgment as well as the permanent injunction as it relates
| to this issue.
[...]
| 5. Since MAI licensed its software, the Peak customers do
| not qualify as "owners" of the software and are not eligible for
| protection under § 117.

I believe this standard was applied specifically to operating
systems by Triad Systems Corp. v. Southeastern Express [2].

By the way, I believe the MAI decision was narrowed slightly
by the Digital Millennium Copyright Act[3], but only to allow third
party maintenance organizations to reboot computers that they maintain.

These decisions apparently limit the copyright exception
originally recommended by the CONTU panel [4] for making it legal to
run copyrighted programs in RAM [5].

Although I recnetly heard a copyright lawyer say that there
are a string of cases supporting the doctrine that copying to RAM is
restrictable by copyright, I should also point out that these are
cases that I turned up some time ago in a google search. This may be
an example of how a little knowledge can be a dangerous thing. I do
not, for example, know what legal references the Free Software
Foundation used to convince NeXT Computer that they had to release the
source code to their Objective C GCC object files.


The second, more practically restrictable, potential form of
infringement is contributory infringement by those who distribute
proprietary kernel modules, such as authors, FTP site maintainers,
vendors, and their employees. Even if proprietary Linux kernel module
is shipped as an object which has other uses besides being linked into
Linux, it invariably requires "glue" code to work in Linux. _Even
when the "glue" code is open source_, if it's only substantial use is
to form part of an infringing work in RAM, then it is a contributory
infringement device. Here is a diagram to help illustrate:

-----------------------------------
| Core Linux kernel: |
| Covered by GPL and other |
| compatible free software licenses |
-----------------------------------
|
|
|
|
-----------------------------------
| Glue code: |
| Perhaps released under |
| GPL-compatible license, but still |
| contributory infringement to |
| distribute, because it has no |
| substantial non-infringing use. |
-----------------------------------
|
|
|
|
-----------------------------------
| Proprietary object: perhaps used |
| in drivers for other OS's too. |
| May have substantial |
| non-infringing use, and be legal |
| to distribute, but still direct |
| copyright infringement by end user|
| to load into kernel. |
-----------------------------------


The glue code may be part of the proprietary module or may be
distributed as a separate middle layer module. This code usually has
no "substantial non-infringing use", thereby failing the test
established for contributory copyright infringement from the 1984 US
Supreme court decision, Sony Corporation of America v. Universal City
Studios, Inc. [6], which basically set the common law test for
contributory copyright infringement to be the same as the statutory
standard for contributory patent infringement [7].

Granted, it may be possible to write multi-purpose
GPL-compatible glue code, every byte of which has a substantial
non-infringing use. For those cases, distribution might not be
restrictable, but it would still be copyright infringement by the end
user to load the module into a running Linux kernel.

I am not claiming that these are the only possible legal
problems or potential copyright problems with proprietary kernel
modules. There are other possible infringement scenarios, such as
direct infringement in proprietary source code that is comingled with
GPL'ed source code, or direct infringement in object code that
contains some GPL'ed inline routines. Kernels running with
proprietary modules also might not be covered by the "free for GPL'ed
use" patent grants [8, 9, 10].

I must reiterate, however, that I am not a lawyer. So, please
do not rely on what I say as legal advice. The most consequential
action that anyone should take based on this message is to ask a
lawyer about it.


[1] MAI Systems Corp. v. Peak Ccomputer, Inc., 991 F.2d 511 (1993).
http://www.law.cornell.edu/copyright/cases/991_F2d_511.htm

[2] Triad Systems v. Southeastern Express, 64 F.3d 1330 (1995).
http://www.eff.org/IP/triad_v_southeastern_64f3d1330_decision.html

[3] The Digital Millenium Copyright Act of 1998.
www.loc.gov/copyright/legislation/dmca.pdf

[4] United States Code, Title 17 (Copyright), Section 117,
(Limitation on exclusive rights: computer programs)
http://www.bitlaw.com/source/17usc/117.html

[5] Final Report of the National Commission on New Technology Uses
[CONTU] of Copyrighted Works, chapter 3:
http://digital-law-online.info/CONTU/contu6.html

[6] Sony Corporation of America v. Universal City Studios, Inc.
("the betamax decision")
http://www.eff.org/Legal/Cases/sony_v_universal_decision.html

[7] For "substantial noninfringing use", see United States Code, Title 35
(Patents) Section 271 (Infringement of Patent), paragraphs (c) and (f)(2).
http://www.bitlaw.com/source/35usc/271.html

[8] "Yodaiken clarifies the Open RTLinux Patent License"
http://linuxdevices.com/articles/AT6164867514.html

[9] "The RTLinux Open Patent License, version 2.0"
http://www.fsmlabs.com/products/rtlinuxpro/rtlinux_patent.html

[10] "GPL patent grant for 19 patents"
http://www.advogato.org/article/89.html


Adam J. Richter __ ______________ 575 Oroville Road
ad...@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America

Russell King

unread,
Dec 5, 2003, 6:00:27 AM12/5/03
to
On Fri, Dec 05, 2003 at 01:09:00PM +1300, Oliver Hunt wrote:
> What (i think) linus is saying is that he, as the owner of the
> copyright,

Unfortunately, this statement isn't entirely correct.

Linus owns the copyright on parts of the kernel written by Linus, just
the same as I own copyright on the parts of the kernel written by me,
Red Hat own copyright on parts of the kernel written by their employees,
and IBM own copyright on parts of the kernel written by their employees.
etc.

No one person owns the overall copyright on the complete kernel.

This, in turn, means that no one person can change the terms and
conditions of the license under which the overall kernel is
distributed.

IANAL.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core

Helge Hafting

unread,
Dec 5, 2003, 6:10:11 AM12/5/03
to
Ihar 'Philips' Filipau wrote:

> GPL is about distribution.
>
> e.g. NVidia can distribute .o file (with whatever license they have
> to) and nvidia.{c,h} files (even under GPL license).
> Then install.sh may do on behalf of user "gcc nvidia.c blob.o -o
> nvidia.ko". Resulting module are not going to be distributed - it is
> already at hand of end-user. So no violation of GPL whatsoever.

Open source still win if they do this. Anybody interested
may then read the restricted source and find out how
the chip works. They may then write an open driver
from scratch, using the knowledge.

Helge Hafting

David Schwartz

unread,
Dec 5, 2003, 6:20:17 AM12/5/03
to

> 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.

I stand by my conclusions.

> 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.

Please tell me how you use the Linux kernel source code. Please tell me how
you run the Linux kernel source code without creating a derived work.

> 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".

Huh? What "resultant program"? Are you talking about an executable that's a
derived work of the Linux kernel source code?

Modules are derived works of the Linux kernel source code, not the kernel
executable. So the license that would be relevent would be a license that
restricts how you can use the source code or derived works of the source
code. License to run a program, when you have source code, is license to
compile that source code.

For example, 2b says:

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

You don't seriously think that's talking about derived works that are
derived from *executables*, do you?

> 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.

I download the Linux kernel sources from kernel.org. Please tell me what I
can do with them without agreeing to the GPL. Is it your position that I
cannot compile them without agreeing to the GPL? If so, how can running the
program be unrestricted? How can you run the linux kernel soruce code
without compiling 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.
>
> 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_.

That is a serious example of projection.

> 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"

You run a piece of source code by compiling it. If a header file is
protected by the GPL, permission to "run" it means permission to include it
in files you compile.

The GPL says:

0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,

The work that was placed under the GPL is the Linux kernel source. The
"program" is the source code. Please, tell me how you "run" the Linux kernel
source code other than by compiling it to form a derived work.

Perhaps you misunderstand the GPL to mean that a 'program' must be an
executable? Not only does section zero clearly refute that, but if it were
true, it would mean that a module is not a derived work from a GPL'd work!
It is a program that's placed under the GPL, and a module is not a derived
work from any other executable.

> 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.

The phrase "results in a GPL'd program" is one that I cannot understand. I
have no idea what you mean by it. You have the right to "run" the header
file, the GPL gives it to you. The way you "run" a header file is by first
compiling a source code that includes it into an executable.

> 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).

How can I run the kernel without compiling it? And how can I compile it
without creating a derived work? The GPL says:

5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.

Of course, the second sentence is utterly false. Fair use and necessary
step provisions do just that.

> 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?

I have no idea what you mean by a "NON-GPL'D BINARY". *Any* binary you
create from a kernel header file is, at least to some extent, a derived work
of that header file. However, the question for whether it would be covered
by the GPL is whether you exercised a privilege in creating that work that
you were only granted by the GPL.

Again, what I'm trying to say is that the term "program" in the GPL means
whatever it is that's placed under the GPL (which can be an executable
and/or source code). Of course, placing an executable under the GPL
effectively places its source code under the GPL (as soon as you distribute
it to someone else, as you are required to do, who is limited only by the
GPL).

In the case of the Linux kernel, the source code was initially placed under
the GPL. Once source code is placed under the GPL, your right to "run the
program" means a right to compile the source code. In the case of header
files, this means the right to include the header file in code files and
thereby produce and use derived works. (Whether or not you can distribute
those derived works is, of course, a whole different argument.)

So my point is that the GPL isn't really even relevant here. You have all
the rights you need without agreeing to it. "Activities other than copying,
distribution and modification are not
covered by this License; they are outside its scope." Including a header
file in your own class file is not copying, distribution, or modification of
that header file. It is use, mere use.

DS

David Schwartz

unread,
Dec 5, 2003, 6:40:12 AM12/5/03
to

> The direct infringement occurs occurs when a user creates an
> infringing work in RAM, which I think is restrictable for works that
> are licensed rather than sold due to the US 9th circuit federal
> appeals court decision MAI Systems Corp. v. Peak Computer [1]:

The GPL says:

Activities other than copying, distribution and modification are not

covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.

So how is running the program infringement of a license that clearly says
executing is unrestricted? How do you execute without copying into RAM?
(Again, a license to do X is automatically a license to do anything
necessary to do X.)

> The second, more practically restrictable, potential form of
> infringement is contributory infringement by those who distribute
> proprietary kernel modules, such as authors, FTP site maintainers,
> vendors, and their employees. Even if proprietary Linux kernel module
> is shipped as an object which has other uses besides being linked into
> Linux, it invariably requires "glue" code to work in Linux. _Even
> when the "glue" code is open source_, if it's only substantial use is
> to form part of an infringing work in RAM, then it is a contributory
> infringement device. Here is a diagram to help illustrate:

Except that the act of running the program is unrestricted. So the
"infringing work in RAM" does not and cannot exist.

> The glue code may be part of the proprietary module or may be
> distributed as a separate middle layer module. This code usually has
> no "substantial non-infringing use", thereby failing the test
> established for contributory copyright infringement from the 1984 US
> Supreme court decision, Sony Corporation of America v. Universal City
> Studios, Inc. [6], which basically set the common law test for
> contributory copyright infringement to be the same as the statutory
> standard for contributory patent infringement [7].

This argument is pure bootstrapping. If the glue code is a license boundary
(which is most likely its purpose) that is has no infringing use!

DS

Stefan Smietanowski

unread,
Dec 5, 2003, 7:20:11 AM12/5/03