[maemo-developers] Corporate ownership of open source projects [LWN]

[From: ed at okerson.com]

> ed at okerson.com wrote:
>> A possible interim solution is to use one like nVidia has used for years
>> for their closed video card drivers.  Provide a binary object that
>> implements all the core functionality of the chip, with a public API.
>> Then have an open source kernel module wrapper that calls the funcions
>> in
>> the public API of the binary module.  Then the open source part can be
>> compiled for any kernel version and simply link in the closed object.
>
> It is almost like this but not exactly. There is cx3110x open source
> glue part cx3110x.ko (see http://cx3110x.garage.maemo.org/), so far so
> good, but unfortunately the closed part (umac.ko) is full kernel module
> not linkable object file so it too depends on kernel version and sadly
> even specific kernel configuration, see
> https://garage.maemo.org/pipermail/cx3110x-devel/2007-December/000007.html

So close, and yet so far away.  I would say that umac.ko should definately
be reworked so it is not distributed as a complete kernel module, but just
an object, umac.o, that can be linked to an open source driver, perhaps
even hooked directly to cx3110x.ko.

> I don't understand where the line in GPL vs binary only code in kernel
> lies.  I'd say that using struct sk_buff should make it derived work of
> linux kernel and subject to GPL but of course IANAL.

Having been there and done that before, the line is in where the core
functionality of the module is from.  If the module is developed
completely from scratch for the purpose of driving a specific piece of
hardware, or derived from a closed driver for the same hardware on a
different OS, then it is tolerated as a closed source driver for Linux. 
Simply using Linux structures that are required to interface to the
kernel, in this case sk_buff, is not sufficient to call the driver a
derived work from open source, and the GPL does not apply.

Ed Okerson