On Sunday, May 25, 2008 12:54 PM, James Chapman wrote: > 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. > You are right, of course: it is a kernel module. However, I want to split it in two parts. One part would be open source and would interface with the kernel. The other part would be a library that would only be used by the other part of the module and would not call any kernel API. The library would only contain self-sufficient math code. Think of it this way: my module has a function: int square( int x ) { return( x * x ) } Can I put it in a separate library to call from my module? Will it be illegal? > 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. > My proprietary library is not going to call any kernel APIs. The "shim" is not going to expose any proprietary hooks to any other module. In fact, to prevent any other module from using my library, I am willing to put a statement in the header file that using this library by other modules would be a copyright violation. Will that work? I know for a fact that there are Linux drivers that have proprietary code in them. How do they get around the legal issues? > 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. > You can see from my explanation above that my proprietary library doesn't need any cool features (or any other, non-cool features, for that matter) from the kernel. The kernel features will only be used by the GPL code. Therefore, the library does not need to be synched with the kernel. Besides, I wouldn't mind maintaining that library myself. > 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. > Are you admitting that it's OK to have non-GPL kernel code? If my way of doing it is illegal, then what is a legal way of doing it? > -- > James Chapman > Katalix Systems Ltd > http://www.katalix.com > Catalysts for your Embedded Linux software development >
