Linux GPL and binary module exception clause?

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?

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

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

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

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:

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

to

Helge Hafting wrote:

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

What I think he means is that nvidia.c only contains glue code and
blob.o contains the secret parts just like the current driver from
nvidia.

// Stefan

Pat Erley

unread,

Dec 5, 2003, 8:20:11 AM12/5/03

to

On Thu, 4 Dec 2003 21:43:01 -0500
"Jason Kingsland" <Jason_K...@hotmail.com> wrote:

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

what I forsee happening is, if the mandation of modules is enforced, people will start writing modules that just export the module interfaces to userspace and start writing userspace drivers, which will just be slower and uglier than the binary only drivers being sent right now. I know about these drivers, I use an nforce2 motherboard. Fortunately, people have reverse engineered the network driver for this (and I do love forcedeth) and people have reverse engineered other drivers, or brute force hacked them. And I'm guessing people will have to continue to do this until linux becomes common on the desktop.

Pat Erley

Anders Karlsson

unread,

Dec 5, 2003, 8:40:28 AM12/5/03

to

Afternoon/Evening/Whatever,

However interesting a debate about the legal status of the GPL is, its
applications to various works, including but not limited to the Linux
Kernel, perhaps a forum like 'linux-legal' could be created to remove
such discussions from the more technical list that linux-kernel is.

I am surprised such a discussion flared up in the LKML as I normally
associate such discussions with the lower scoring threads on SlashDot
(no offence intended to SlashDot itself).

Just my $0.45... (inflation and currency devaluation taken into account)

--
Anders Karlsson <and...@trudheim.com>
Trudheim Technology Limited

signature.asc

Richard B. Johnson

unread,

Dec 5, 2003, 9:00:16 AM12/5/03

to

On Fri, 5 Dec 2003, Nick Piggin wrote:

>
>
> Paul Adams wrote:
>
> >--- 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.
> >
>
> 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.
>

When copyright law was developed, nobody thought of
"#include <filename.h>".

Let's guess what that means. To me, that is like a reference
to a written work, when you attribute something to some document
that was previously written and, incidentally, give appropriate
credit to the writer(s). In this context, it is clearly not
a copyright infringement to include the works of others with
appropriate credit being given.

It is just like; "See John Smith's article on frogs", referenced
in an article about frogs.

However, there are some who would claim that they don't want
their previous work referenced by others at all, in particular
those who might dirty their hands by making money with it.

The only known way to prevent others from referencing a previous
work is to not publish it at all. "Publish means to make public".
If you don't want others referencing your precious work, then
you need to keep it secret. It's just that simple. You can't have
it both ways. You can't say, "I publish this only for the eyes of
my friends who will work for free."

Now, I have seen some who write their own header files because
they think that including somebody else's creation might violate
some copyright law. This, in fact, might be a violation in
itself, to incorporate "whole cloth" the works of others in
a separate document does appear to violate US law. However,
referencing the unmodified original document, clearly
(as clear are any law could be interpreted) does not.

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

Maciej Zenczykowski

unread,

Dec 5, 2003, 9:00:18 AM12/5/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.

I'm not so sure about that. If Linus and a few core developers decide to
explicitly state that you can't use the Linux kernel with binary only
modules than you can't. They have the right under copyright to restrict
the usage of their contributions - if this means that they say "you can't
use our contributions to the kernel with any binary only ring 0 code" -
then you can't. And it is totally irrelevant whether your work is derived
or not. They can't force you to release your work as GPL - but they can
forbid you to utilise the linux kernel with non-GPL'ed work - which in the
end is quite close.

Or am I totally wrong here?

Cheers,
MaZe.

Ryan Anderson

unread,

Dec 5, 2003, 9:10:13 AM12/5/03

to

On Fri, Dec 05, 2003 at 03:16:27AM -0800, David Schwartz wrote:
> > 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.

You "use" the Linux source code by feeding it to a compiler. Or maybe
as a hideous fortune file. The output of that compiler is *clearly* a
derived work, and thus bound by the GPL.

So far, I don't see any reason why a module that uses an inline function
provided via a kernel header could be distributed in binary format without
being a "derived work" and thus bound by the GPL.

[snipping a bit]

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

Compile it.
Run the resulting executable (ignoring the case law that says copying
into ram is a copy under copyright law)
Read the source code.
Write a module using the source code (i.e, via headers)

If you want to distribute that module, you must, of course, follow the
GPL.

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

You don't run source code. Not even in Perl programs (though there, at
least, the distinction is more complicated.)

You compile source code. The resultant object code is then run.

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

Repeat after me: The GPL is a copyright license. It covers
distribution, not use. Distribution of any part of the "work" is
covered. Inline functions in headers are clearly part of the "work".

If you have a module that uses an inline function, there are two
options (note: not two legal options):
Distribute source
Distribute a binary

If you distribute a binary and refuse to provide the source under the GPL,
ask yourself this: What gave you the right to distribute the
compiled form of the inline functions you use?

Note: My use of "inline functions" as a bludgeoning device should not be
interpreted as an acknowledgement that the rest of the header files
constitute a published "API".

--

Ryan Anderson
sometimes Pug Majere

Ihar 'Philips' Filipau

unread,

Dec 5, 2003, 10:00:20 AM12/5/03

to

Stefan Smietanowski wrote:
> Helge Hafting wrote:
>
>> 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.
>
>
> What I think he means is that nvidia.c only contains glue code and
> blob.o contains the secret parts just like the current driver from
> nvidia.
>

Exactly.
Source code licensing from second parties is really pain in the ass.

At my previous job I had situation that piece of code was several
times. I beleive we were fourth company who bought it and incorporated
into applience. But ask anyone "what kind of rights do we have for this
stuff?" - no-one really can answer, since we-are-not-lawyers so better
to tell no-one how we use it. Probably we even had no rights to fix
bugs... who knows?..

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

Jesse Pollard

unread,

Dec 5, 2003, 10:10:15 AM12/5/03

to

On Friday 05 December 2003 05:16, David Schwartz wrote:
> > 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.

You compile it without modifications.

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

You don't have "an executable" unless it includes the kernel as the
executable.

It actually sounds like you are confusing Kernel mode with User mode.

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

It is if you are referring to the Kernel. Look at the include files. They are
licened under GPL.

Look at the include files for applications. They are licenced under LGPL.

The kernel include files are NOT.

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

compile them. Read them. run them.

You do not modify them. You do not combine them with propriatary executables
and distribute them without that executable and it's source becoming GPL.

Quite simple. If you include the Linux kernel include files you get a derived
program that must be released under GPL if you distribute that 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).
>
> 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.

It is not fair use to create and distribute derived works that use Kernel
include files without agreeing to the GPL.

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

Nope. You are confusing GPL with LGPL. Not the same thing.

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

Depends on where that class file ends up. If it is in a binary, that you
intend to distribute, then that binary, and its source is GPL.

Check the headers. If it says GPL, then anything compiled that uses that
header should be GPL when/if distributed.

Valdis.K...@vt.edu

unread,

Dec 5, 2003, 10:40:16 AM12/5/03

to

On Fri, 05 Dec 2003 03:25:47 PST, David Schwartz <dav...@webmaster.com> said:

> So how is running the program infringement of a license that clearly sa
ys
> executing is unrestricted? How do you execute without copying into RAM?

The copy into RAM has its own exemption in 17 USC 117(a)(1):

Sec. 117. - Limitations on exclusive rights: Computer programs

(a) Making of Additional Copy or Adaptation by Owner of Copy. -
Notwithstanding the provisions of section 106, it is not an infringement for
the owner of a copy of a computer program to make or authorize the making of
another copy or adaptation of that computer program provided:

(1) that such a new copy or adaptation is created as an essential step in the
utilization of the computer program in conjunction with a machine and that it
is used in no other manner, or

You're intentionally being obtuse. NOTHING IN THE GPL CONTROLS WHAT YOU DO
WITH IT ON YOUR MACHINE. You're *totally* free to write the most
non-GPL-compliant code and run it. What you're NOT allowed to do is then
DISTRIBUTE the resulting code to others.

Valdis.K...@vt.edu

unread,

Dec 5, 2003, 11:00:16 AM12/5/03

to

On Thu, 04 Dec 2003 22:34:37 PST, David Schwartz said:

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

Right. And getting the permission to create the derived work is contingent on your
agreeing that if it is distributed, the derived work is GPL.

> This supports my argument that you
> can create a derived work without agreeing to the GPL. Thanks.

It's quite possible and legal to *create* a derived work without agreeing to the
GPL. However, the only things you can legally *do* with the work are use it
on your own system, and brag about how cool your code is.

You most certainly can't distribute it as non-GPL.

Thierry Vignaud

unread,

Dec 5, 2003, 11:00:24 AM12/5/03

to

"Kendall Bennett" <Kend...@scitechsoft.com> writes:

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

wrappers are gpl-ed.
i do not think they offer so much "work" that their authors have the
right to tell "here's there's a boundary; our binary module can
legally use our wrapper".

Shawn Willden

unread,

Dec 5, 2003, 11:50:09 AM12/5/03

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 December 2003 07:03 am, Ryan Anderson wrote:
> Compile it.
> Run the resulting executable (ignoring the case law that says copying
> into ram is a copy under copyright law)

That case law can be safely ignored in the US, since it was superseded by
real law, passed in 1980. Per section 117 of Title 17 of the US Code:

- ----------------
(a) Making of Additional Copy or Adaptation by Owner of Copy. —

Notwithstanding the provisions of section 106, it is not an infringement
for the owner of a copy of a computer program to make or authorize the
making of another copy or adaptation of that computer program provided:

(1) that such a new copy or adaptation is created as an essential step
in the utilization of the computer program in conjunction with a machine
and that it is used in no other manner, or

- ----------------

So copies to disk and RAM that are "an essential step in the utilization of
the computer program" are non-infringing.

Shawn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0LRwp1Ep1JptinARAjrbAJ0RAa2axjrFABHgG1loqmxa6KTn0ACcCz1s
Q+DC9COjk+uv+FqdZ8kTg+g=
=N1sB
-----END PGP SIGNATURE-----

Arjan van de Ven

unread,

Dec 5, 2003, 12:00:31 PM12/5/03

to

> So copies to disk and RAM that are "an essential step in the utilization of
> the computer program" are non-infringing.

probably true for the US, most definitely not true in europe... it's
explicit in law here that copying from disk-to-ram and ram-to-cpu is
distributing in the "need a license" sense...

Shawn Willden

unread,

Dec 5, 2003, 12:10:13 PM12/5/03

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 December 2003 09:54 am, Arjan van de Ven wrote:
> probably true for the US, most definitely not true in europe... it's
> explicit in law here that copying from disk-to-ram and ram-to-cpu is
> distributing in the "need a license" sense...

That's very interesting. Thanks.

Shawn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0LpTp1Ep1JptinARAnaWAJ4493In8CAp0p+yMlCAb2pmyXYbbQCeN0Cy
KUV+3WM27hGEHFPTTYHN/uI=
=x1pq
-----END PGP SIGNATURE-----

David Dyck

unread,

Dec 5, 2003, 12:10:20 PM12/5/03

to

On Fri, 5 Dec 2003 at 07:06 -0800, Jesse Pollard <je...@cats-chateau.net>
wrote:

> Quite simple. If you include the Linux kernel include files you get a derived
> program that must be released under GPL if you distribute that program.

When I first read this out out of context, I wondered if you were saying
that any executable that I write on my libc5 linux system (and those that
were compiled on libc5 systems long ago - like my copy of Adobe acrobat,
and RealNetworks real audio) must have been distributed under GPL?

[ Please recall that the kernel header files were included in users
programs (since /usr/include/asm and /usr/include/linux were symlinks
into the kernel sources) and common include files like dirent.h,
errno.h, and signal.h. This still works with libc5 and todays
Linux 2.4.23. ]

You must not be saying that, since Linus said:

"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 after re-reading more of the thread, you must be refering to modules
that include kernel include files, right?

David

Linus Torvalds

unread,

Dec 5, 2003, 12:30:14 PM12/5/03

to

On Fri, 5 Dec 2003, Peter Chubb wrote:
>
> 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.

Yes, and I'm not claiming anything like that.

I claim that a "binary linux kernel module" is a derived work of the
kernel, and thus has to come with sources.

But if you use those same sources (and _you_ wrote them) they do not
contain any Linux code, they are _clearly_ not derived from Linux, and you
can license and use your own code any way you want.

You just can't make a binary module for Linux, and claim that that module
isn't derived from the kernel. Because it generally is - the binary
module not only included header files, but more importantly it clearly is
_not_ a standalone work any more. So even if you made your own prototypes
and tried hard to avoid kernel headers, it would _still_ be connected and
dependent on the kernel.

And note that I'm very much talking about just the _binary_. Your source
code is still very much yours, and you have the right to distribute it
separately any which way you want. You wrote it, you own the copyrights to
it, and it is an independent work.

But when you distribute it in a way that is CLEARLY tied to the GPL'd
kernel (and a binary module is just one such clear tie - a "patch" to
build it or otherwise tie it to the kernel is also such a tie, even if you
distribute it as source under some other license), you're BY DEFINITION
not an independent work any more.

(But exactly because I'm not a black-and-white person, I reserve the right
to make a balanced decision on any particular case. I have several times
felt that the module author had a perfectly valid argument for why the
"default assumption" of being derived wasn't the case. That's why things
like the AFS module were accepted - but not liked - in the first place).

This is why SCO's arguments are specious. IBM wrote their code, retained
their copyrights to their code AND THEY SEVERED THE CONNECTION TO SCO'S
CODE (and, arguably the connections didn't even exist in the first place,
since apparently things like JFS were written for OS/2 as well, and the
Linux port was based on that one - but that's a separate argument and
independent of my point).

See the definition of "derivative" in USC 17.1.101:

A "derivative work" is a work based upon one or more preexisting
works, such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which
a work may be recast, transformed, or adapted. A work consisting
of editorial revisions, annotations, elaborations, or other
modifications which, as a whole, represent an original work of
authorship, is a "derivative work".

And a binary module is an "elaboration" on the kernel. Sorry, but that is
how it IS.

In short: your code is yours. The code you write is automatically
copyrighted by YOU, and as such you have the right to license and use it
any way you want (well, modulo _other_ laws, of course - in the US your
license can't be racist, for example, but that has nothing to do with
copyright laws, and would fall under a totally different legal framework).

But when you use that code to create an "elaboration" to the kernel, that
makes it a derived work, and you cannot distribute it except as laid out
by the GPL. A binary module is one such case, but even just a source patch
is _also_ one such case. The lines you added are yours, but when you
distribute it as an elaboration, you are bound by the restriction on
derivative works.

Or you had better have some other strong argument why it isn't. Which has
been my point all along.

Linus

Jason Kingsland

unread,

Dec 5, 2003, 12:40:17 PM12/5/03

to

Linus wrote:
> There's a clarification that user-space programs that use the standard
> system call interfaces aren't considered derived works

If it said "user-space" or "non-kernel address space" in the Linux license
then I would agree.

But the exact wording is much more vague:

"user programs that use kernel services by normal system calls"

Any binary loadable kernel module can be considered a "user program"
Any interface defined in the kernel header files can be considered a "normal
system call"

This is why I think further clarification is warranted in future versions of
copying.txt - because we are needlessly giving away the source-code freedom
that GPL is intended to protect.

The proponents of binary-only kernel modules currently use the above as a
defense to argue their case for GPL non-compliance.

Linus Torvalds

unread,

Dec 5, 2003, 12:40:23 PM12/5/03

to

On Fri, 5 Dec 2003, Shawn Willden wrote:
>
> So copies to disk and RAM that are "an essential step in the utilization of
> the computer program" are non-infringing.

Absolutely. But you don't have the right to distribute them.

Put another way: nVidia by _law_ has the right to do whatever essential
step they need to be able to run Linux on their machines. That's what the
exception to copyright law requires for any piece of software.

And in fact you should be damn happy for that exception, because that
exception is also what makes things like emulators legal - software houses
can't claim that you can't use an emulator to run their programs (well,
they may _try_, but I don't know if it ever gets to court).

But what they do NOT have the right to do is to create derivative works of
the kernel, and distribute them to others. That act of distribution is not
essential _for_them_ to utilize the kernel program (while the act of
_receiving_ the module and using it may be - so the recipient may well be
in the clear).

So in order for nVidia to be able to legally distribute a binary-only
kernel module, they have to be able to feel damn sure that they can
explain (in a court of law, if necessary) that the module isn't a derived
work. Enough to convince a judge. That's really all that matters. Our
blathering matters not at all.

Now, personally, I have my own judgment on what "derivative works" are,
and I use that judgement to decide if I'd complain or take the matter
further.

And so _I_ personally think some binary modules are ok, and you've heard
my arguments as to why. That means that _I_ won't sue over such uses,
since in my opinion there is no copyright infringement IN THOSE CASES due
to me not considering them derivative.

My opinions are fairly public, and the stuff I say in public actually does
have legal weight in that it limits what I can do (if I say in public that
I think something is ok, I have a much harder time then making the
argument that it _isn't_ ok in front of a judge - this is what the
"estoppel" thing is all about).

But the thing is, my public opinions don't bind anybody else. So if Alan
Cox, or _any_ other kernel copyright holder, disagrees with me (and trust
me, people do), they have the right to complain on their own. Their case
would be weakened by my stance (simply because a defendant could point to
my opinions and the judge might be swayed by that).

And quite frankly, my largest reason for not complaining loudly has often
been that I'm lazy, and in several cases of sme people using GPL'd work
improperly I have been ready to join a lawsuit that somebody else
initiates. So far people have tended to back down.

Linus

Hua Zhong

unread,

Dec 5, 2003, 12:50:13 PM12/5/03

to

> So far, I don't see any reason why a module that uses an
> inline function provided via a kernel header could be distributed in
binary
> format without being a "derived work" and thus bound by the GPL.

Yeah, the same reason that XFS, NUMA, etc are derived works from Unix
since they must include Unix header files.

What, maybe there are no inline functions there? No problem. SCO could
make stuff like spinlocks inline. And suddenly you are derived works
now.

I just don't see how this actually works as you said.

Linus Torvalds

unread,

Dec 5, 2003, 1:00:16 PM12/5/03

to

On Fri, 5 Dec 2003, Jason Kingsland wrote:
>
> Any binary loadable kernel module can be considered a "user program"
> Any interface defined in the kernel header files can be considered a "normal
> system call"

I disagree. No definition of "system call" implies "any random function".
That's a technical term with a technical definition, and that technical
definition is in no way ambiguous when we are talking about a kernel.

Linus

Filip Van Raemdonck

unread,

Dec 5, 2003, 1:20:24 PM12/5/03

to

On Fri, Dec 05, 2003 at 09:35:52AM -0800, Hua Zhong wrote:
> > So far, I don't see any reason why a module that uses an
> > inline function provided via a kernel header could be distributed in
> > binary
> > format without being a "derived work" and thus bound by the GPL.
>
> Yeah, the same reason that XFS, NUMA, etc are derived works from Unix
> since they must include Unix header files.

Nope, they #include Linux header files - at least in their Linux version.
Even if one version does #include Unix headers, that does not mean
copyright to the rest of the code automatically belongs to the Unix
copyright holder.

And we're not even talking about source code; we're talking about
_binary modules_. Which do include object code which comes from GPLed
(inline) code; and are thus derived works.

Regards,

Filip

--
We have joy, we have fun,
we have Linux on our Sun.

Hua Zhong

unread,

Dec 5, 2003, 1:40:18 PM12/5/03

to

> Nope, they #include Linux header files - at least in their
> Linux version.

So what? By the same argument they are derived work of Linux too.

This is exactly the flaw of "once you include my code, you are derived
work of mine".

> Even if one version does #include Unix headers, that
> does not mean copyright to the rest of the code automatically belongs
> to the Unix copyright holder.

This is not a matter of copyright. This is a matter of "being derived or
not".

> And we're not even talking about source code; we're talking about
> _binary modules_. Which do include object code which comes from GPLed
> (inline) code; and are thus derived works.

I disagree.

It all depends on how significant the inlined code is compared to the
whole work of the module. For inline functions, I don't see why using
them would be a significant part - by definition "inline" means
"small/trivial", otherwise you would not have inlined them.

Otherwise, since SCO found a few lines of code copied from Unix in Linux
source, are we saying the whole million lines of code is derived from
Unix?

> Regards,
>
> Filip

Kendall Bennett

unread,

Dec 5, 2003, 1:50:13 PM12/5/03

to

Peter Chubb <pe...@chubb.wattle.id.au> wrote:

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

Clearly that is easy to work around, because all you need to do is have a
small GPL wrapper module that includes the Linux kernel headers and would
end up having GPL code linked into it, and build the wrapper such that it
makes calls via an API *you* define into your code. Then your code is
simply interfacing via your own API to the GPL wrapper module and none of
your code would be tainted.

At least via direct inclusion and use of Linux kernel API header files
anyway. There is still the issue of whether the specific binary module
code you are linking into the kernel is Linux specific or not and would
be considered a dervived work. If it is only for Linux and is not very
useful for other platforms, one could argue that it is a derived work and
hence should be GPL regardless of what API or GPL wrapper it uses.

Then again, if a module is completely Linux specific and the source for
it has no use outside of Linux, I doubt a vendor could care less about
keeping it proprietary anyway ;-)

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

Jeremy Fitzhardinge

unread,

Dec 5, 2003, 1:50:15 PM12/5/03

to

On Fri, 2003-12-05 at 09:19, Linus Torvalds wrote:
> But when you use that code to create an "elaboration" to the kernel, that
> makes it a derived work, and you cannot distribute it except as laid out
> by the GPL. A binary module is one such case, but even just a source patch
> is _also_ one such case. The lines you added are yours, but when you
> distribute it as an elaboration, you are bound by the restriction on
> derivative works.
>
> Or you had better have some other strong argument why it isn't. Which has
> been my point all along.

I tend to agree, but there is a counter-argument:

You can't copyright "facts". A header file contains facts about the
kernel within it, particularly once it has been compiled into machine
code. In machine code, it is simply things like integers (the sizes and
offsets of things, other constants), and encoded entrypoints (however
function calls back into the kernel end up looking). A binary
containing facts about the kernel is not a derived work of the kernel,
even if those facts came from headers in the kernel source.

To argue against this, you'd have to demonstrate that the original
author of the header file had some creative input into the machine code
of the module, on order for the module to be considered a derived work
of the header.

You could so far as saying that if every header put a chunk of text
(say, a piece of poetry) into each .o file which used that header, then
there'd be a much stronger case for saying the .o is derived from the
header.

I've had long complex arguments with legal types over whether function
names are creative ("flumulate_my_greeble" is the best function name
ever!) or mere facts (the function name is simply a cookie you need to
refer to to call a function - it doesn't matter what the name actually
is).

J

Kendall Bennett

unread,

Dec 5, 2003, 1:50:20 PM12/5/03

to

"David Schwartz" <dav...@webmaster.com> wrote:

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

Another point worth mentioning is that if the Linux kernel headers are
pure GPL, then user land programs that use the Linux kernel headers
themselves would also be pure GPL by extension if the above argument
holds water. Clearly the Linux developers would like to believe
otherwise, but there are many Linux user mode programs that will make use
of GPL kernel headers in their non-GPL programs. And some of that code
will include inline assembler and inline functions to make calls into the
kernel.

Likewise, by extension, any runtime library that uses GPL header files
from the kernel directly would have to also be pure GPL. This means glibc
folks. We all know glibc is LGPL, but if you link pure GPL code with LGPL
code the entire work must be *GPL*, not LGPL if it is considered a
derived work.

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 5, 2003, 1:50:21 PM12/5/03

to

"Jason Kingsland" <Jason_K...@hotmail.com> wrote:

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

I would agree that a module/driver written specifically for Linux would
fall under the GPL. By extension however, any user program written
specifically for Linux that does *not* run anywhere else would also fall
under the GPL. Clearly there are not many programs that fit into this
category, as most are portable to other platforms. However there are
clear instances of code that is Linux specific such as the installers
used by distro vendors to install their version of Linux. By extension if
Linux specific modules must be GPL, so too must Linux specific
installation programs.

Which means all the proprietry installers done by many distro vendors
that are not GPL would be in violation.

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

No, Linux is pure GPL. I always thought the same but Linus and others
have cleared this up in the last few days within this discussion. The pre-
amble at the top of the COPYING file is not legalese and not legally
binding. It is just Linus' interpretation of the GPL as it applies to
user programs, and as such is certainly not legally binding.

Kendall Bennett

unread,

Dec 5, 2003, 2:00:12 PM12/5/03

to

Linus Torvalds <torv...@osdl.org> wrote:

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

Right, and by extension of the same argument you cannot use kernel
headers to create non-GPL'ed binaries that run IN USER SPACE! Just
because a program runs in user space does not mean that it is not a
dervived work. There is nothing special about a user mode program
compared to a module just because it uses Linux system calls. The same
principles you apply to determine whether a module is a derived work also
apply to user space programs, *ESPECIALLY* if you consider that the GPL
kernel header files contains code (inline C or assembler) that probably
gets linked either directly or indirectly (through the C runtime library)
into *EVERY* Linux user mode program.

This exact reasoning is what RedHat (aka Cygnus) has been using for years
with the Cygwin toolkit for Windows. Although 99% of the code built with
the GNU compilers and Cygwin includes the glibc runtime library that is
LGPL, every program *must* include the C runtime library startup code or
it cannot function. *That* code is pure GPL, and by extension any program
using the Cygwin libraries is a derived work and must be GPL. If you
don't like that, by a commercially licensed version of Cygwin from
RedHat/Cygnus instead.

This is also IMHO why so few people outside of Red Hat contribute to
Cygwin, but that is a different issue ;-)

Jesse Pollard

unread,

Dec 5, 2003, 2:00:23 PM12/5/03

to

On Friday 05 December 2003 11:05, David Dyck wrote:
> On Fri, 5 Dec 2003 at 07:06 -0800, Jesse Pollard <je...@cats-chateau.net>
>
> wrote:
> > Quite simple. If you include the Linux kernel include files you get a
> > derived program that must be released under GPL if you distribute that
> > program.
>
> When I first read this out out of context, I wondered if you were saying
> that any executable that I write on my libc5 linux system (and those that
> were compiled on libc5 systems long ago - like my copy of Adobe acrobat,
> and RealNetworks real audio) must have been distributed under GPL?
>
> [ Please recall that the kernel header files were included in users
> programs (since /usr/include/asm and /usr/include/linux were symlinks
> into the kernel sources) and common include files like dirent.h,
> errno.h, and signal.h. This still works with libc5 and todays
> Linux 2.4.23. ]
>
> You must not be saying that, since Linus said:
>
> "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 after re-reading more of the thread, you must be refering to modules
> that include kernel include files, right?

Mostly. Primarily. That is because the only executable that results IS the
kernel.

There is the fuzzy area where you write a user mode application that uses
some Kernel headers for the purpose of doing things like an ext2fs debugger.
The kernel headers are NOT released under LGPL, but all of the libc functions
and include files are. The syscall interfaces were explicitly excluded as
requiring GPL because the Linus quote.

Personally, I think it would be a good idea to have these specific ones under
the LGPL instead of GPL, and then use them in both kernel and user space
(which the LGPL also allows).

If the header is not LGPL (which allows propriatary programs to include
them), then you run a severe risk of forcing the user mode application into
GPL if it is distributed. I think this is more likely if the header includes
inline functions, and not in the case of those just defining the syscall data
structures/interface.

One area this would clarify would be if someone tried to write a propriatary
kernel debugger... It would run in user mode, but look at/poke at kernel
structures and functions in such detail that it SHOULD be a GPL program.

Valdis.K...@vt.edu

unread,

Dec 5, 2003, 2:20:10 PM12/5/03

to

On Fri, 05 Dec 2003 10:44:02 PST, Kendall Bennett said:

> Right, and by extension of the same argument you cannot use kernel
> headers to create non-GPL'ed binaries that run IN USER SPACE! Just
> because a program runs in user space does not mean that it is not a
> dervived work.

That's a bad idea for technical reasons too - how often do we have to tell
people not to use kernel headers from userspace? glibc-kernheaders (and whatever
non-RedHat boxes call it) exists for a reason.

Interestingly enough, at least on my Fedora box, 'rpm -qi' reports glibc as LGPL,
but glibc-kernheaders as GPL, which seems right to me - linking against glibc gives
the LGPL semantics as we'd want, but forces userspace that's poking in the kernel
to be GPL as a derived work....

Kendall Bennett

unread,

Dec 5, 2003, 2:20:23 PM12/5/03

to

Jesse Pollard <je...@cats-chateau.net> wrote:

> It is if you are referring to the Kernel. Look at the include
> files. They are licened under GPL.
>
> Look at the include files for applications. They are licenced
> under LGPL.

Really? Have you looked at the include files for Linux? The standard C
include files that nearly every program uses will end up also *including*
Linux kernel header files in order to build programs for Linux. Not all
programs will end up including those files, but a very large portion
will.

If you don't believe me, do a grep under /usr/include/sys on your machine
for 'linux', and see how many of the header files include stuff from
/usr/include/linux. All the files under /usr/include/linux are part of
the kernel, so theoretically under the pure GPL, not LGPL.

Then again I say 'theoretically' because once again there is nary a
kernel header file in sight that actually *has* a GPL license header
attached! So who knows what license those files are *really* under.

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

-

Arjan van de Ven

unread,

Dec 5, 2003, 2:30:21 PM12/5/03

to

On Fri, 2003-12-05 at 20:09, Valdis.K...@vt.edu wrote:
\

> Interestingly enough, at least on my Fedora box, 'rpm -qi' reports glibc as LGPL,
> but glibc-kernheaders as GPL, which seems right to me - linking against glibc gives
> the LGPL semantics as we'd want, but forces userspace that's poking in the kernel
> to be GPL as a derived work....

but those headers do not have inlines etc etc
just the bare minimum of structures and defines (neither of which result
in code in the binary )

signature.asc

Kendall Bennett

unread,

Dec 5, 2003, 2:30:22 PM12/5/03

to

Valdis.K...@vt.edu wrote:

If glibc-kernheaders (used only if you do not have real kernel source
code installed) is GPL, and many of the standard Linux include files end
up including either headers from glibc-kernheaders (or the real Linux
kernel source if you have it installed and symlinked), then by extension
the glibc library built for Linux must be GPL as would all programs
linked against it.

Linus Torvalds

unread,

Dec 5, 2003, 2:30:31 PM12/5/03

to

On Fri, 5 Dec 2003, Kendall Bennett wrote:
>
> Right, and by extension of the same argument you cannot use kernel
> headers to create non-GPL'ed binaries that run IN USER SPACE!

This was indeed one of the worries that people had a long time ago, and is
one (but only one) of the reasons for the addition of the clarification to
the COPYING file for the kernel.

So I agree with you from a technical standpoint, and I claim that the
clarification in COPYING about user space usage through normal system
calls covers that special case.

But at the same time I do want to say that I discourage use of the kernel
header files for user programs for _other_ reasons (ie for the last 8
years or so, the suggestion has been to have a separate copy of the header
files for the user space library). But that's due to technical issues
(since I think the language of the COPYING file takes care of all
copyright issues): trying to avoid version dependencies.

> This exact reasoning is what RedHat (aka Cygnus) has been using for years
> with the Cygwin toolkit for Windows. Although 99% of the code built with
> the GNU compilers and Cygwin includes the glibc runtime library that is
> LGPL, every program *must* include the C runtime library startup code or
> it cannot function. *That* code is pure GPL, and by extension any program
> using the Cygwin libraries is a derived work and must be GPL. If you
> don't like that, by a commercially licensed version of Cygwin from
> RedHat/Cygnus instead.

And this is an area where I think the GPL just isn't the right license to
use - but on the other hand it obviously isn't my decision to make. I'm
not touching Cygwin with a ten-foot pole, and that has nothing to do with
licensing ;)

The GPL just doesn't make a lot of sense for library-like infrastructure.

Linus

David Schwartz

unread,

Dec 5, 2003, 3:00:23 PM12/5/03

to

> On Fri, Dec 05, 2003 at 03:16:27AM -0800, David Schwartz wrote:

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

> You "use" the Linux source code by feeding it to a compiler. Or maybe
> as a hideous fortune file. The output of that compiler is *clearly* a
> derived work, and thus bound by the GPL.

So, if you are permitted to "use" the Linux source code, you are permitted
to create derived works of it. Do we agree on that one simple issue?

> So far, I don't see any reason why a module that uses an inline function
> provided via a kernel header could be distributed in binary
> format without
> being a "derived work" and thus bound by the GPL.

Because the GPL can only bind a derived work if you had to agree to the GPL
to *make* that derived work. The law (at least in the United States) does
not give a copyright holder a separate right to restrict the distribution of
derived works, only to restrict their creation.

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

> Compile it.

The only way to compile a header file is to include it into a C file and
use that C file to make a derived work from that header file.

> Run the resulting executable (ignoring the case law that says copying
> into ram is a copy under copyright law)

> Read the source code.
> Write a module using the source code (i.e, via headers)
>
> If you want to distribute that module, you must, of course, follow the
> GPL.

Only if you needed rights granted under the GPL in order to create it. I
think you're missing my point. My point is that *if* you can create the
derived work without having to agree to the GPL, then you can distribute the
derived work without having to agree to the GPL.

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

> You don't run source code. Not even in Perl programs (though there, at
> least, the distinction is more complicated.)
>
> You compile source code. The resultant object code is then run.

The way you "run" a program, if that program is in C, is you compile it and
then execute it. If you have the right to "run" a header file (because it
was placed under the GPL), then you have the right to include it in C files
and compile them.

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

> Repeat after me: The GPL is a copyright license. It covers
> distribution, not use.

Right.

> Distribution of any part of the "work" is
> covered. Inline functions in headers are clearly part of the "work".

I'd rather not address two complex issues at once. If we agree that you can
include a header file that is (or is part of) a GPL'd work without to accept
the GPL's terms, we can then go on to address whether you need to accept the
GPL to distribute it. Without the first question understood, it's impossible
to address the second.

> If you have a module that uses an inline function, there are two
> options (note: not two legal options):
> Distribute source
> Distribute a binary
>
> If you distribute a binary and refuse to provide the source under
> the GPL,
> ask yourself this: What gave you the right to distribute the
> compiled form of the inline functions you use?

The facts that: Distributing a derived work is not a separate right. I had
the unrestricted right to create the derived work. The recipient of the
derived work is has unrestricted rights to use the original work. The
creation of the derived work is a necessary step in using the original work.

> Note: My use of "inline functions" as a bludgeoning device should not be
> interpreted as an acknowledgement that the rest of the header files
> constitute a published "API".

Except perhaps under the new DMCA, you can't make it necessary for a person
to violate your copyright in order to use something and then argue that
they've violated your copyright by using that something. This is precisely
equivalent to charging someone who purchased a book with making a copy
without authorization because they bounced a light off the book and produced
a copy on their retina.

If you have unrestricted right to use a header file, you have unrestricted
right to create derived works consisting of C files that include that header
file and the resulting object code. The question of whether you can
distribute that derived work is a non-issue, there is no right recognized
under copyright (at least in the United States) to restrict the distribution
of derived works, only their creation.

This will be my final post on this issue. I think I've made my position as
clear as I'm capable of making it. IANAL and have not discussed this with an
attorney. If I had to argue against the GPL in court, this is the line of
argumentation I'd take. Specifically, that you are not bound by the GPL
because everything you've done is use, fair use, and necessary steps for
use, so the GPL's distribution prohibitions don't apply.

Linus wrote:

>Put another way: nVidia by _law_ has the right to do whatever essential
>step they need to be able to run Linux on their machines. That's what the
>exception to copyright law requires for any piece of software.

So they need not agree to the GPL to *create* the derived work.

>But what they do NOT have the right to do is to create derivative works of
>the kernel, and distribute them to others.

Yes, they do. Since they have the right to create the derived work and have
not agreed to the GPL, the only thing that could restrict their distribution
is the law, not the GPL. Please show me the law that permits a copyright
holder to restrict the distribution of derived works.

>That act of distribution is not
>essential _for_them_ to utilize the kernel program (while the act of
>_receiving_ the module and using it may be - so the recipient may well be
>in the clear).

While he is correct that the distribution itself is not essential for use,
the creation of the derivative work is. However, once a derivative work is
created, no special rights to the *original* work are required to distribute
it to licensees of that original work.

DS

Filip Van Raemdonck

unread,

Dec 5, 2003, 3:10:10 PM12/5/03

to

On Fri, Dec 05, 2003 at 10:37:51AM -0800, Hua Zhong wrote:
> > Nope, they #include Linux header files - at least in their
> > Linux version.
>
> So what? By the same argument they are derived work of Linux too.
>
> This is exactly the flaw of "once you include my code, you are derived
> work of mine".

I'll rephrase what I wrote and what people have been saying all the time:

"Once you build a binary module, it contains our (inlined) code and thus
the binary module is a derived work."

> > And we're not even talking about source code; we're talking about
> > _binary modules_. Which do include object code which comes from GPLed
> > (inline) code; and are thus derived works.
>
> I disagree.
>
> It all depends on how significant the inlined code is compared to the
> whole work of the module. For inline functions, I don't see why using
> them would be a significant part - by definition "inline" means
> "small/trivial", otherwise you would not have inlined them.
>
> Otherwise, since SCO found a few lines of code copied from Unix in Linux
> source, are we saying the whole million lines of code is derived from
> Unix?

We have yet to see if they actually found code.

And no; we're not saying all code is a derived work. We're saying that if
there is a few lines of copied code, then the compiled kernel which
contains object code coming from these lines is a derived work. If.

Regards,

Filip

--
<rcw> debian comes in behind redhat, slackware, suse, and mandrake when
searching google for 'linux distribution'
<asuffield> try "best linux distribution"

Linus Torvalds

unread,

Dec 5, 2003, 3:20:16 PM12/5/03

to

On Fri, 5 Dec 2003, David Schwartz wrote:
>
> >But what they do NOT have the right to do is to create derivative works of
> >the kernel, and distribute them to others.
>
> Yes, they do. Since they have the right to create the derived work and have
> not agreed to the GPL, the only thing that could restrict their distribution
> is the law, not the GPL. Please show me the law that permits a copyright
> holder to restrict the distribution of derived works.

I'm not going to argue with you any more. I am not a lawyer, and clearly
you aren't one either (or you're a really really bad one).

The "show me the law" is USC 17. It's called "US Copyright Law". As a
copyright holder in the Linux kernel, I _do_ have the right to restrict
the distribution of derived works. That's what copyright law is all about.

Your arguments are just vacuous and stupid.

I _very_ much have the right to restrict the distribution of derived
works, and that is what a license is all about. Without a license to
distribute, you have NO RIGHT AT ALL to distribute a derived work. What's
so hard to understand about that? And the only rights you have are rights
granted to you in some license.

And that license in this case is the GPL. Which does NOT grant you rights
to redistribute derived works without the source being available under the
same license.

End of discussion. You can whine all you like, but whining has never
changed reality.

Linus

Hua Zhong

unread,

Dec 5, 2003, 3:40:05 PM12/5/03

to

> I'll rephrase what I wrote and what people have been saying
> all the time:
>
> "Once you build a binary module, it contains our (inlined)
> code and thus the binary module is a derived work."

Understood and that's what we disagree.

By the way, what's so different between code and data, anyway?

Are inline functions more important than macros and defs?

> > Otherwise, since SCO found a few lines of code copied from
> Unix in Linux
> > source, are we saying the whole million lines of code is
> derived from
> > Unix?
>
> We have yet to see if they actually found code.

We have. Some malloc function as I remember, and has been removed from
current Linux sources.

> And no; we're not saying all code is a derived work. We're
> saying that if there is a few lines of copied code, then the
> compiled kernel which contains object code coming from
> these lines is a derived work. If.

You are trying to hide the fact that the kernel "sources" actually
contained copyrighted code.

Binary modules do not _contain_ copyrighted (GPL'ed) code, they merely
_include_ it (by #inlucde), but the _compiled_ binary modules contain
compiled copyrighted (GPL'ed) code.

So you are saying, binary modules contain compiled GPL'ed code, so it's
derived work of GPL'ed code. But kernel sources contained copyrighted
(non-GPL'ed) code, but the sources were not derived work of that code,
only the compiled form was?

> Regards,
>
> Filip

Shawn Willden

unread,

Dec 5, 2003, 4:20:18 PM12/5/03

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 December 2003 01:14 pm, Linus Torvalds wrote:
> On Fri, 5 Dec 2003, David Schwartz wrote:
> > Please show me the law
> > that permits a copyright holder to restrict the distribution of
> > derived works.
>

> The "show me the law" is USC 17. It's called "US Copyright Law". As a
> copyright holder in the Linux kernel, I _do_ have the right to restrict
> the distribution of derived works. That's what copyright law is all
> about.

Actually, based on my understanding of Title 17 and the GPL (both of which
I just re-read), David *almost* has a point.

1. As David implies, Title 17 does not grant the copyright holder the
right to restrict distribution of derived works. Section 106[1] describes
the exclusive rights granted to copyright holders, and it only says that
they have exclusive rights to *prepare* derived works. So you cannot
create a derived work without permission from the copyright holder, but
once you have obtained permission to create it, you can distribute the
result. Maybe.

2. The copyright holder can grant permission to create derived works to
whomever (s)he likes, under whatever terms (s)he likes (modulo other
laws). So, the copyright holder can attach strings to the permission.
For example, the copyright holder could specify that you are allowed to
create a derived work, but only on the condition that you do not
distribute it.

3. The GPL understands points 1 and 2, which is why section 2 of the GPL
states:

You may modify your copy or copies of the Program or any
portion of it, thus forming a work based on the Program,
and copy and distribute such modifications or work under
the terms of Section 1 above, provided that you also meet
all of these conditions:

It then lists three conditions, the most important of which is the second,
which states that if the derived work is distributed, it must be
distributed under the terms of the GPL.

IANAL, but the language in Title 17 and the GPL seems pretty clear. If
someone creates a derived work and distributes it under any terms other
than the GPL, they have violated the agreement which gave them permission
to create the derived work, and thereby infringed on the copyright
holder's exclusive rights.

So, yeah, you *do* have the right to restrict distribution of derived
works, via a thunk in the GPL.

Oh, IANAL.

Shawn.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/0PWip1Ep1JptinARAjhXAJ9x66s2KNm8KK4+9bNDBKOQ6Hd6YQCghXFD
Ju6LimWjD6NJJqsG4u7Jr7g=
=vop3
-----END PGP SIGNATURE-----

Derek Fawcus

unread,

Dec 5, 2003, 5:40:18 PM12/5/03

to

On Fri, Dec 05, 2003 at 05:54:50PM +0100, Arjan van de Ven wrote:
>
> > So copies to disk and RAM that are "an essential step in the utilization of
> > the computer program" are non-infringing.
>

> probably true for the US, most definitely not true in europe... it's
> explicit in law here that copying from disk-to-ram and ram-to-cpu is
> distributing in the "need a license" sense...

Wrong (assuming you want to include the UK as part of Europe :-)

50C.--(1) It is not an infringement of copyright for a lawful user of
a copy of a computer program to copy or adapt it, provided
that the copying or adapting-

(a) is necessary for his lawful use; and
(b) is not prohibited under any term or condition of an agreement
regulating the circumstances in which his use is lawful

(2) It may, in particular, be necessary for the lawful use of a
computer program to copy it or adapt it for the purpose of
correcting errors in it.

... and the above is from a copyright regime which is in general quite
draconian.

OK - So now you get to argue about EULAs, but that's a seperate issue.

DF

gary ng

unread,

Dec 5, 2003, 5:50:20 PM12/5/03

to

As the copyright holder, you definitely have the right
to staple restrictions on derivative works. However, I
would say your idea(if I interpet them correctly) of
derivative work is a bit broad.

My understanding of derivative work is that it is
based on your work which is a form of expression(in
this case, I believe is the source code). If I don't
include/copy your source code, how can it be a
derivative work ? if you mean the function calls(or
should it be called kernel APIs) is copyrightable,
would it be that projects like WINE is infringing
Microsoft's copyright ?

The inclusion of kernel header is a complex issue. As
a header usually contains constant/function
definitions, structure definitions(in order to
properly working with the kernel) and sometimes inline
functions. inline functions is definitely a form of
expression which is copyrightable but for the others,
should they be classified as 'interface' than
copyright materials ? If they are copyrightable
material, I believe things like FAT should be removed
from linux as the FAT layout(thus the structure in say
C) seems to be copyrightable too.

So I would say that if a driver writer creates their
own header files which specifies the same
constant/function definitions in order to interface
with linux, I don't think their works are derivative
work of linux.

In fact, it can be argued that these are exceptions
cover in the DMCA like what the xbox-linux project
stated :

"Everything done on this project is for the sole
purpose of writing interoperable software under Sect.
1201 (f) Reverse Engineering exception of the DMCA"

the drivers would then be the "interoperable software"
for linux.

All these are just my limited understanding and
interpretation of copyright and I believe unless the
whole thing is challenged and decided in court, there
is really no real answer. May be the SCO case can make
this clear.

regards,

gary

On Friday 05 December 2003 01:14 pm, Linus Torvalds
wrote:
> On Fri, 5 Dec 2003, David Schwartz wrote:
> > Please show me the law
> > that permits a copyright holder to restrict the
distribution of
> > derived works.
>
> The "show me the law" is USC 17. It's called "US
Copyright Law". As a
> copyright holder in the Linux kernel, I _do_ have
the right to restrict
> the distribution of derived works. That's what
copyright law is all
> about.

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

Linus Torvalds

unread,

Dec 5, 2003, 6:20:16 PM12/5/03

to

On Fri, 5 Dec 2003, gary ng wrote:
>
> As the copyright holder, you definitely have the right
> to staple restrictions on derivative works. However, I
> would say your idea(if I interpet them correctly) of
> derivative work is a bit broad.

Ahhah! But that's how these things work. Everybody wants more than they
may be entitled to, and you don't concede a thing.

Until somebody comes up with a good counter-argument, at which point you
say "Yes, that is ok".

And I'd like to point out that this is exactly how we _do_ work. This is
why certain binary-only modules are accepted: we're bitching and moaning
about how hard those nvidia-caused problems are to debug, but we're not
actually suing nvidia.

See? The basic _assumption_ is that all modules are derived works. But
once you get to specifics, the answer may well be "oh, in your case you
can show preexisting work on other operating systems, and you have a good
case that your code isn't actually derived from the kernel, so as long as
you realize that we'll never be able to support or care about your module,
we won't bother you".

It's a bit like haggling. You ask for the world ("I'll let you have that
camel for a thousand dinars _and_ your first-born"), and you listen to the
counter-arguments ("but that camel looks a bit diseased, and is blind in
one eye"), and maybe you settle it amicably ("ok, how about we trade you
that goat"), or maybe you don't. And if somebody ends up stealing your
camel rather than settling your differences, you might have to go to court
("cut off his hands").

Linus

Maciej Zenczykowski

unread,

Dec 5, 2003, 7:10:10 PM12/5/03

to

> Another point worth mentioning is that if the Linux kernel headers are
> pure GPL, then user land programs that use the Linux kernel headers
> themselves would also be pure GPL by extension if the above argument
> holds water. Clearly the Linux developers would like to believe

Problem being that user space programs are not supposed to use the kernel
headers - they're supposed to use the glibc headers anyway. In fact the
latest kernel source headers don't work in userspace period. And the user
space glibc 'kernel' headers are released and distributed seperately and
contain much less code than the actual kernel kernel headers.

Cheers,
MaZe.

gary ng

unread,

Dec 5, 2003, 7:20:08 PM12/5/03

to

That is basically the case. The only difference in the
case of linux(or may be most open source project) is
that, there is no one person or entity(there is
usually more than copyright holder) can say to for
example nvidia that 'ok, your work is not derivative
work' as there is no legal binding in saying so,
unlike a license/contract from Microsoft to them.

So as I said, may be the SCO case can make things more
'formal' rather than this 'you say, I say'.

regards,

gary

ps. As a linux user, personally I like to see it the
way you see it as that can solve a lot of those driver
issues but it(driver is derivative work) really is not
convincing for me.

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

Filip Van Raemdonck

unread,

Dec 5, 2003, 7:20:06 PM12/5/03

to

On Fri, Dec 05, 2003 at 12:26:39PM -0800, Hua Zhong wrote:
> >
> > "Once you build a binary module, it contains our (inlined)
> > code and thus the binary module is a derived work."
>
> Understood and that's what we disagree.
>
> By the way, what's so different between code and data, anyway?

For one, as long as it's code, you are clearly the only copyright holder
and you can more or less do what you want (including distributing).[1]
Once compiled it includes object code to which others have copyright, so
you must take care not to violate their rights.

> > > Otherwise, since SCO found a few lines of code copied from
> > Unix in Linux
> > > source, are we saying the whole million lines of code is
> > derived from
> > > Unix?
> >
> > We have yet to see if they actually found code.
>
> We have. Some malloc function as I remember, and has been removed from
> current Linux sources.

Which was OK to include as it was released previously under a BSD license.

But, to answer the "million lines of code" question: most of that code was
written before that inclusion. And may not even have had anything to do
with the included lines, afterward. So, no, that does not make all of it
(in code form) a derived work.

There may or may not have been developed code related to these lines
afterwards, for which one might argue that that part of the code is a
derived work. It mostly depends on how badly the later code needs the
included lines - but not much I guess since these lines are not even there
anymore.

> > And no; we're not saying all code is a derived work. We're
> > saying that if there is a few lines of copied code, then the
> > compiled kernel which contains object code coming from
> > these lines is a derived work. If.
>

> Binary modules do not _contain_ copyrighted (GPL'ed) code, they merely
> _include_ it (by #inlucde), but the _compiled_ binary modules contain
> compiled copyrighted (GPL'ed) code.
>
> So you are saying, binary modules contain compiled GPL'ed code, so it's
> derived work of GPL'ed code. But kernel sources contained copyrighted
> (non-GPL'ed) code, but the sources were not derived work of that code,
> only the compiled form was?

Binary modules are by their very nature already compiled, so they already
include the GPLed object code.

And the aggregate kernel sources with the ancient unix code included is
indeed a derived work. But the kernel source, apart from that ancient
unix code and which does not need it, is not.

Neither is the source code for binary modules, as long as it doesn't
actually contain kernel code itself. But once compiled, the rules of the
game are set.

Regards,

Filip

[1] Depending on how the code looks. For example, if it needs to patch
kernel source code it is modifying GPLed code, and in that case it is
a derived work even in source code form.

--
Hardware, n.:
The parts of a computer system that can be kicked.

David Woodhouse

unread,

Dec 5, 2003, 7:20:09 PM12/5/03

to

On Thu, 2003-12-04 at 01:25 -0500, Karim Yaghmour wrote:
> 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.

So you have a loadable module made of two sections; a GPL'd wrapper
layer clearly based on the kernel, and your original driver. The latter
is clearly an identifiable section of that compound work which is _not_
derived from Linux and which can reasonably be considered an independent
and separate work in itself.

The GPL and its terms do not apply to that section when you distribute
it as a separate work.

But when you distribute the same section as part of a _whole_ which is a
work based on the Linux kernel, the distribution of the whole must be on
the terms of the licence, whose permissions for other licensees extend
to the entire whole, and thus to each and every part regardless of who
wrote it.

For the precise wording which I've paraphrased above, see §2 of the GPL.

Note that 'is this a derived work' is only part of the question you
should be asking yourself. The GPL makes requirements about the
licensing even of works which are _not_ purely derived.

Some claim that copyright law does not allow the GPL to do such a thing.
That is incorrect. I can write a work and license it to you under _any_
terms I see fit. I can, for example, license it to you _only_ on
condition that you agree to release _all_ your future copyrightable
work, including works of fiction and other completely unrelated things,
under terms I decree.

You either do that or you don't have permission to use my work. Whether
your own work is derived or not is completely irrelevant; if you don't
agree to the terms of _my_ licence, you don't get to use _my_ code.

--
dwmw2

Larry McVoy

unread,

Dec 5, 2003, 9:40:05 PM12/5/03

to

On Sat, Dec 06, 2003 at 12:08:31AM +0000, David Woodhouse wrote:
> You either do that or you don't have permission to use my work. Whether
> your own work is derived or not is completely irrelevant; if you don't
> agree to the terms of _my_ licence, you don't get to use _my_ code.

If and only if, as has been pointed out here many times, your license is
enforceable.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Larry McVoy

unread,

Dec 5, 2003, 10:10:08 PM12/5/03

to

On Thu, Dec 04, 2003 at 05:58:18PM -0800, Linus Torvalds wrote:
> 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.

Linus, you are a purple 3 legged frog. So there. It is written and it
shall be so :)

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

I'll followup on this below.

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

Exactly my point. The addition is not part of the license and given your
other arguments, userland is 100% GPLed as a result.

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

It's one that _you_ apparently will never contest in court but the
amount of code in the kernel that you wrote is quite small. You are the
leader but that doesn't mean you speak for everyone. There seem to be
differing opinions. In this case, that may be a good thing.

In my opinion, you are playing with fire and playing well into SCO's
hands. I haven't read the original Unix license but I have heard that
it had a somewhat similar viral effect, like the GPL does. I've heard
that it claims ownership of derived works, which I doubt is true.
But I've also heard that it claimed certain distribution rights for
derived works and that I do believe. It's entirely plausible that a
commercial entity would have a license which says "you can't build on
my work and give to someone who hasn't also obtained a license from us".
Makes perfect sense and is quite likely.

However, if someone did take derived code (which is now covered by the
viral license) and add it illegally to Linux, it is entirely reasonable
for the license holder to say that all of Linux now has the virus. Just
as reasonable as someone saying "hey, that's the Linux XYZ driver in
Solaris, Solaris is now GPLed".

There seems to be this sentiment (a pleasant one) in this community that
if you do the wrong thing and then undo it, all is forgiven. That's not
how the license reads. The GPL doesn't say "if you uncombine the work you
are no longer obligated to obey the GPL". Neither would any other license.

Roll forward a bit and see how this plays out in court. Suppose there is
code in Linux that is derived from Unix. Remember, if Unix licenses had
the same viral effect as the GPL, all it takes is a function or two and
the rest of the code is GPL-ed (or in this case, Unix-ed). If you are
arguing that an API isn't a boundary for the GPL you are going to look
bloody two faced when you go and argue that an API is a boundary for Unix.

And all of this discussion is nicely indexed by Google for SCO's lawyers
to dig through and say "see, the leader of Linux doesn't think that
boundaries apply. Linux is now covered *completely* by the SCO Unix
license. Pay up".

I'm not a lawyer but I am someone who pays lawyers to figure this stuff
out and I've explored precisely this area. I sure hope that what I've
learned is true because if what you are saying is true we are all likely
to be screwed.