Kernel Programming Questions

James Chapman jchapman at katalix.com
Sun May 25 18:54:08 UTC 2008


Vadim Klishko wrote:
> On Sunday, May 25, 2008 9:37 AM, Greg KH wrote:
> 
>> On Sun, May 25, 2008 at 09:40:32AM +0100, James Chapman wrote:
>>> Is the optional "library" proprietary (binary only)? If so, think 
>>> carefully about GPL implications. Adding a simple GPL driver to expose 
>>> proprietary hooks isn't good...
> Yes, that was exactly the idea.
> 
>> It's not only, "not good", it's flat out illegal and violates the
>> license of the kernel.  Do not do this at all if you are thinking you
>> can keep something from being released under the GPL.
>>
> I thought there was a legal way of doing it as described here:
> http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs

You need to stop thinking of your code as a library. It's a binary 
kernel module.

Binary kernel modules are legal only if they use _standard_, non-GPL 
kernel APIs. You can't add a GPL shim/driver to expose new, proprietary 
hooks for use by non-GPL code either. As Greg said, that's illegal.

It is also worth bearing in mind that the effort needed to write and 
maintain binary modules can be significant. You can't make use of many 
cool features of the kernel because they are available only to GPL code. 
More importantly, keeping the binary module in sync with changing kernel 
releases takes a lot of effort.

Just to be clear, the only symbols that non-GPL kernel code can access 
are marked in the kernel sources using EXPORT_SYMBOL(). You cannot 
access any of the EXPORT_SYMBOL_GPL() symbols.

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development




More information about the devel mailing list