Re: Linux GPL and binary module exception clause?

[Karim Yaghmour <karim@opersys.com>]

David Woodhouse wrote:
> 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.

I didn't exactly specify how the interfacing would be done because that's
besides the point I'm trying to make (in fact, it's the later part of my
email which was most important). But here's two other ways to do it just
for the sake of discussion:
a) Hard-wired assembly in the driver that calls on the appropriate address
with the proper structure offsets etc. No headers used here.
b) User-space interrupt callbacks. Start app -> mlockall -> open GPL
driver -> use ioctl to pass callback address -> open /dev/mem -> ...
I've skipped a few things, but the essentials are there. Basically, you
get the interrupts in user-space and can access whatever you want through
/dev/mem.

Sure the above isn't as powerful as a properly coded driver for Linux,
but it should work for a few things.

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

Right, but my argument has little to do with the GPL. In fact, as I
said before (http://www.embeddedtux.org/pipermail/etux/2003-October/000415.html),
I don't personally think the GPL has all the answers to this issue. Not
just that, but I don't really see myself debating with any kernel developer
what the law says he has the right to do or not do with his code. It just
seems to me that the copyright holder has the upper hand here. What I'm
really looking for is to understand how to apply the GPL to binary-only
modules given the copyright holders' interpretation. So far, I have heard
the following (this is a summary, so please correct me if you think I've
miss-characterized your take on this):

Linus Torvalds: modules API not a GPL barrier, must prove your work is not a
derived work - preexisted Linux. Ex.: NVidia is clearly not a derived work.
Alan Cox: Unclear if Linus can dictate terms for binary-only modules since
he's not the only copyright owner. Talk to your lawyer.
Russell King: Linus isn't the only copyright owner and hence can't change
the terms outright.
Theodore Ts'o: Modules API constitutes license barrier.
David Woodhouse: There's no such barrier and applications tightly packaged
with the kernel (i.e. embedded systems) _may_ be subject to derived work
clauses of the GPL.
etc.

Frankly, I don't know what to make of all this. I wish I could collect the
input of all kernel developers to come up with a table of X owns N% of
kernel copyright and his statement about binary-only modules is best
characterized as A, B, C, or D, or ... where each of these is an already
stated position about such modules. We could then come up with a weighed
percentage of validity for each of A, B, C, ... The exercise may not have
any legal weight, especially since as Linus stated a judge may just give
him more credence than any other kernel developer, but it would at least
tell kernel developers where they all stand on this issue.

As it stands now, however, it seems to me that any kernel developer
attempting to enforce the GPL across the modules API would have quite a
few problems. Mainly because:
1) There is no clear consensus among the copyright holders as to how
the GPL is to be interpreted across the modules API.
2) Established technical practice has been that hardware manufacturers
do indeed ship drivers with different licenses than those of the host
OS.

I had mentioned #2 elsewhere before
(http://www.embeddedtux.org/pipermail/etux/2003-October/000415.html) and
it has been discussed in this thread by other folks in slightly different
words. However, it may be that #1 could end up causing the most damage in
the case where a kernel developer, or a few, try to prosecute a real case
of binary-only module infringement on the GPL.

In sum, I agree with Jonathan Corbet's assessment that it's about time
that kernel developers agree where the axe falls. Not just for outsiders,
but also for themselves.

Cheers,

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145