Non-GPL kernel modules using GPL ones

Question

The company I work for is developing a closed source kernel module (.ko file). This module has to make calls to functions which are contained in a gpl2 module. Basically we have a situation like this:

// GPL 2 kernel module  (gpl.c -> gpl.ko)
void a_function(void)
{
// ...
}
EXPORT_SYMBOL(a_function)


// Closed Source module (closed.c -> closed.ko)
a_function();

Is this legal? Are we violating the GPL2 license in this example? Please note that closed.c is not including any gpl2 header file.

Answer 1

1st: You need to talk to a lawyer about this; probably your company's legal department.

2nd: The important question is what piece of code is derived from which other code.

Unfortunately there are almost any number of answers for this question.

Some would hold that all kernel modules are derived works of the kernel, so have to be GPLed regardless of header inclusion.

Alternatively your closed module derives from the GPL module, and the GPL module derives from the kernel, so the closed module has to also be GPL.

Answer 2

There is GPL_ONLY flag for modules, that should not be used within non-GPL modules. So if the module you're talking about isn't GPL_ONLY, you can use it.

But even these which are GPL_ONLY can be used if you access them via user-space drivers, which are possible in 2.6.23. That's exactly what happened to USB subsystem. http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers

Not exactly addressing legal issue, but gives you some idea: http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html

Answer 3

IANAL so you really should seek qualified legal opinion. However this approach is certainly going against the spirit of the license and won't win you any friends in kernel land.

However you could consider a different split. One approach is to have a fully GPL'ed module and put all your "secret company IP" in a user space driver. This is an approach I took when the company I worked for wasn't keen on exposing the details of our FPGA to the world. All the decisions and register settings where decided in user space and the kernel side of the driver just loaded values in on IRQs. With careful design you can manage any real time issues you may have and have a nice clean separation between your closed driver and the kernel. I believe this is easier with newer kernels with support for user space drivers although I don't think they support DMA properly yet (I had to code a user space DMA kernel module to support DMA directly between the chipset and user space).

However (again) I would really recommend you consider what it is your trying to protect. Closed drivers may be OK for embedded applications where you have tight control over the kernel version and the hardware. But if this driver is being considered for anything more generic (i.e. selling hardware people will plug into their own systems) then closed source drivers will only prove to be a source of constant pain and maintenance headaches.

Answer 4

There is an opinion held by some key kernel developers (but not Linus himself) that any non-GPL'd module is a violation of the kernel's license.

When some developers ripped the Belkin driver from the Linksys router, reverse engineered it, and published the result, Belkin could not stop them because of the counterthreat of bringing this license interpretation before the court as a defense.

Answer 5

Countless other drivers have used an open-source "shim" to bridge a closed-source object file with the open-source kernel. This is considered by most kernel developers to be a violation, at least in spirit, of the GPL.

In my opinion, it depends whether you distribute the software. If you are running this purely on software-as-a-service, that should be allowed. If you are distributing an embedded device or boxed product, it's a no-no.

Move whatever functionality you need out of the kernel, or open source your kernel components. That's what everyone else (honest) does, and it isn't generally that tricky, because anyone who has significant amounts of kernel-space "intellectual property", either has a bad business model or an incompetent engineering team.

* the above is my opinion *