Re: [PATCH] USB: mark USB drivers as being GPL only

Christer Weinigel
2008-02-06T21:13:14Z

On Tue, 5 Feb 2008 13:46:08 +0200
"Pekka Enberg" <penberg@cs.helsinki.fi> wrote:

> Hi David,
>
> Marcel Holtmann writes:
> > > You driver was meant to be running as Linux kernel module and
> > > thus it is derivative work.
>
> On Feb 5, 2008 1:39 PM, David Newall <davidn@davidnewall.com> wrote:
> > It is precisely the fact that it is a loadable module, and does not
> > form part of the kernel, that removes the requirement to distribute
> > it under GPL.
>
> What makes you qualified to make that statement (without giving any
> evidence)? Are you're an expert on international copyright law?

Are you? You've made some very definite statements about copyright
law. Things that I've been told are definitely in a gray area and not
at all as clear cut as you and the FSF likes to say. FSF has a very
clear agenda, and taking what they say as the gospel is a big mistake.

If I link a binary .o file into a static kernel image, does that make it
a derivative work of the kernel? It most definitely violates the GPL
in that the total is a derivative work, but does it really make the .o
file a derivative work? What if I let the user do the linking at
runtime? But as Alan Cox wrote, how the linking is done doesn't decide
if it is a derivative work or not, copyright law does.

So what does make it a derivative work then?

If I use an in kernel API, but from a piece of code which is external
to the kernel, is that really a derived work? If you say it is, do you
realise that you are advocating something which is very close to an API
copyright, something which I think most open source people are very
adverse to. If API copyrights were valid, Wine, or editline, or
lesstiff would be in a lot of trouble.

Of course, the Linux headers don't only define an API, they also
contain a lot of inline code. But if I don't care about an extra jump,
I could write a glue layer between the Linux kernel and some
proprietary code that wraps all inline functions. In that case, is a
module written against that glue layer a derivative work of the kernel?

If I write a glue layer that allows me to run the same driver in
userspace via libusb and directly in the kernel, and give the user a
choice to link my binary .o file either the userspace or kernel space
glue, does that make my code a derivative work of the kernel? Most
probably not, it is independent of the kernel in that case.

So where is the line in the sand that makes it clearly a derivative
work? It's up to the courts to decide, and until there is a clear
and final court ruling it is a gray area. Lawyers can guess at what
the outcome might be, and some companies are apparently willing to take
the risk that it isn't as clear cut as you think.

/Christer