Re: Must modules be GPL'ed?

Theodore Y. Ts'o (tytso@mit.edu)
Tue, 23 Apr 1996 19:09:18 -0400


Date: Tue, 23 Apr 1996 12:51:56 +0200 (MET DST)
From: Hans Lermen <lermen@elserv.ffm.fgan.de>

IMHO modules _must_ be GPL'ed. The main points I see are:

1. The inlined kernel functions _are_ part of the kernel code.
( as you already pointed out )

This is an issue, but in most cases the inlined kernel calls don't do
all that much (memcpy, strcpy, etc.) and so could be easily
re-implemented.

2. The modules in fact don't get _loaded_ but _linked_ into the kernel.
Insmod is just a tiny linker, which in principal mimics ld.

There is a really big question whether or not "linking" makes a
difference with respect to the GPL or not. The FSF claimes that it
does, but copyright law simply doesn't work that way --- in effect, what
the FSF is trying to imply is very much akin to an Interface Copyright.

If I write code which happens to make calls to GPL'ed code, but I don't
actually *use* GPL code, there is no way that the FSF or any other
entity would manage to get ownership rights (which is required for
copyright to have any meaning) to code that does not contain any GPL
code at all. This should not be taken as legal advice, but I have had a
law professor from Rutgers take a look at the situation, and he was
willing to agree that the FSF was in space about their interpretation of
how the GPL works.

Not at all. Modules are _pure kernel code_, they live in kernel space,
they run in kernel space, they have direct access to the kernel resources
without need of syscall interface (as would have user processes).

Not true; modules are restricted by symbols listed in ksyms.c. So in
effect, ksyms.c forms an "official modules interface" between the kernel
and modules, just as the syscall interface is the official interface
between kernel code and user-level code.

- Ted