RE: Non-GPL export of invalidate_mmap_range

David Schwartz
2004-02-20T01:06:15Z

> Christoph Hellwig <hch@infradead.org> wrote:

> And the "But when you distribute..." part is what the Linus doctrine rubs
> out. Because it is unreasonable to say that a large piece of work such as
> this is "derived" from Linux.

I think you misunderstand how the Linux kernel uses the term "derive". By a
"derived work", the GPL is invoking the legal copyright principle of a
"derivative work". You can google this term to get a better understanding of
it. The term "derived work" does not imply that the work is wholly derived.
Rather, it means that some part of the protected expression of the original
work is present in the work.

In the specific case of Linux kernel modules, the question is whether some
part of the protectable expression in the Linkx kernel is present in the
module. This is a major issue for compiled modules distributed in object
form because the compilation process, through header files, puts pieces of
the header files in the resultant object.

If the distributed work is in source code form, however, the argument
becomes much different. You are not likely to find pieces of the kernel code
present in the source code that's distributed. However, one possible
argument is that the module is a "sequel" to the kernel. It takes the
framework the kernel creates and builds on it. I can't write and sell a Star
Trek novel for just this reason, it would be derived from previous such
novels because it borrows their universe.

Another possible argument is that the module code is so intertwined with
kernel code that you can't consider the module by itself a work at all.

In the present case, we have a shim that is distributed in source form. The
main module works with other operating systems and doesn't contain much
Linux-specific code. So the module itself is not a derived work of Linux.
The shim is probably a derived work, but the shim is open source.

So if there's a license issue, I don't know what it is.

DS