lkml.org 
[lkml]   [2001]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Controversy over dynamic linking -- how to end the panic (long)
>> 3. A kernel module loaded at runtime, after kernel build, *is not*
>> to be considered a derivative work.
>
> It doesn't much matter
> under the GPL, anyway, so long as the in-code kernel image isn't
> "copied or distributed".

Broadly agree - thanks for someone pointing out the obvious
here. Perhaps an analysis from a clause by clause reading
would be useful.

This seems to me to be the nub of the argument. There are three
questions to be considered:

1. Is development of a kernel module distributed under terms
other than under the GPL (for instance, binary only) a
breach of the license?

2. If not, is distributing such a kernel module (under its
own license) along with the kernel (otherwise correctly,
under its license) a breach of the GPL?

3. Is running the kernel, and loading such a kernel module,
a breach of the kernel's license?

In order:

1. This hinges on whether the driver is covered by the GPL
(definition of "Program" in 0). As the driver is clearly
not the kernel, the test is whether it is a derived work,
under copyright law. If we have already excluded (somehow,
and I can't find it explicitly) inclusion of kernel headers
from making a 'derived work', or if copyright law would
not dictate that such inclusions made a 'derived work'
(and I think that would be reasonably safe in a project
of non-trivial size), then one could safely say that
(1) would not be a breach of the license. Putting kernel
headers under LGPL or other ammended GPL would clarify the
matter beyond dispute.

2. To answer (2), we assume that (1) does not apply, and that
a kernel module is (thus) not a derived work, and that the
GPL does not apply to it. Reading license section (2):
"If identifiable sections of that work are not derived
from the Program, and can be reasonably considered independent
and separate works in themselves, then this License, and its
terms, do not apply to those sections when you distribute
them as separate works." and further "In addition, mere
aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a
volume of a storage or distribution medium does not bring the
other work under the scope of this License." clearly shows
that if the distribution of the driver alone is not in
breach of the GPL (as it is not a derived work), then,
as a work that is not a derived work, it can be distributed
with the kernel.

3. The license states "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."
Now it is reasonably easy to argue that loading linux kernel, and
linking with arbitrary kernel modules after running the kernel
is not distribution. It could easilly be argued that it is
not copying, any more than playing a CD whose contents
are (temporarilly) copied into buffers on the CD player is
copying. There is a possibility that the 'work' is being
modified. However, the work modifies itself in several ways
(it unzips the image) as part of its normal running. Further,
the header from Linus says "NOTE! 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". Note the
use of the words 'user programs' not 'user mode programs'. But
in anycase, insmod is a user program and a user mode program,
which uses normal system calls (documented in libraries),
albeit to change the behaviour of the kernel. But crucially,
let us assume this argument fails, and 'insmod' actually
performs modification of the work. The only obligations
on modifiers seem to be under section (2), which obligies
modifiers to do things with modified files (none), and
on distribution (none, of the modified work). An implication
of this reading is that you are free to modify the linux
kernel (or any other GPL program) in any way you want,
and retain whatever copyright you want on such modifications,
so long as you neither copy nor distribute the result (though
arguably you could distribute the modifications if you did not
distribute any part of the original). I believe that (at least
without the parenthesised element) is entirely within both the
letter and the spirit of the GPL - it is /not/ designed to
keep you from developing (under copyright or otherwise)
your own modifications, it's designed to keep you from denying
or restricting rights of distribution of the GPL'd code if
you distribute stuff yourself. This is set out clearly
in the preamble.

Areas of doubt:

A. Are all contributed patches / files /always/ under a license
no more restrictive than 'COPYING' - including Linus'
preamble.

B. Is it clear that inclusion of kernel headers when compiling
a progam does not make that program a derived work of the
kernel.

Implications:

A. It would be worth Linus publicising the fact (or some URL
be added to Linux kernel postings) that patches by default
will be assumed to be under the 'COPYING' license.

B. It would be worth someone clearing up the status of the
license on header files.

C. It would be preferable if people read the COPYING file
before commenting on license issues.

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

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:1.507 / U:0.368 seconds]
©2003-2011 Jasper Spaans. Advertise on this site