Non-GPL kernel modules using GPL ones [closed]

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

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 2

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.