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
