[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2446 bytes --] Hi folks I have some licensing issues with the linux GPL and the implications on a project which incorporates partial non-GPL code which I want to release as linux kernel module. I am well aware that there are many threads concerning binary only and non-GPL kernel modules but I cannot deduce a clear statement for my specific case from what I have already read. That's why I kindly ask you about your interpretation of the GPL in the following case. I have implemented a proprietary algorithm in user space which I'm not allowed to release under the GPL. From a _technical_ point of view I could compile the code as kernel module which offers a certain API. Note that the kernel module would have only very limited dependency on the kernel, i.e. apart from memory allocation functions (kmalloc, kfree, vmalloc, vfree) and potentially some "locks" (spinlock, big reader lock or rcu) the code is totally independent from the kernel. In particular it is not required to apply any patches against the kernel sources. From what I have read I'd conclude that it is ok to release such a kernel module under a non-GPL license since it can hardly be considered derived work and of course otherwise proprietary drivers also could not be released as non-GPL kernel modules. Well, the story continues. Assuming that having the algorithm implemented as non-GPL kernel module I want to implement a front-end which makes use of the algorithm's API and release this code under GPL. The frontend would have some more dependencies on the kernel code compared to the algorithm module (though I'd still consider it "edge" code) and it might involve small additions to existing kernel files (3 or 4 small functions maybe). As far as the interaction with the algorithm API is concerned the frontend submits kernel data structures to the algorithm module _but_ since the algorithm has no declaration of kernel structures it does neither use nor modify the kernel data. It's just stored and returned to the user via certain API functions. So, given this scenario is it ok that the GPL frontend uses the non-GPL algorithm API without the requirement of making the algorithm GPL too? Thank you very much for your help. John -- Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS! Ideal für alle, die gerne MMS verschicken: 25 FreeMMS/Monat mit GMX TopMail. http://www.gmx.net/de/cgi/produktemail +++ GMX - die erste Adresse für Mail, Message, More! +++
John wrote: >I have some licensing issues with the linux GPL and the implications >on a project which incorporates partial non-GPL code which I want >to release as linux kernel module. > > Wrong mailing list. You must find a lawyer, and he'll answer your questions. >I have implemented a proprietary algorithm in user space which I'm not >allowed to release under the GPL. From a _technical_ point of view I >could compile the code as kernel module which offers a certain API. >Note that the kernel module would have only very limited dependency >on the kernel, i.e. apart from memory allocation functions (kmalloc, >kfree, vmalloc, vfree) and potentially some "locks" (spinlock, big >reader lock or rcu) the code is totally independent from the kernel. > RCU is a patented algorithm - mention that to your lawyer. Your creation must not be derived from the kernel (because creating derived works is an exclusive right of the copyright owner, and you don't have and won't get a permission), and it must not infringe the RCU patents. >As far as the interaction with the algorithm API is concerned the >frontend submits kernel data structures to the algorithm module _but_ >since the algorithm has no declaration of kernel structures it does >neither use nor modify the kernel data. It's just stored and returned >to the user via certain API functions. > You have written an algorithm module that is tightly coupled to the Linux kernel, and you think it's not derived from the kernel, correct? As a non-lawyer, it'd say that's wrong. "Derived work" is a legal term, your lawyer might be able to figure out if your combination is a derived work. The drivers that are more or less accepted as not-derived run on multiple operating systems - e.g. the nvidia ethernet driver uses the same source code for Windows and Linux, and nvlib.o works on Linux and FreeBSD. -- Manfred P.S.: You might need a team of lawyers: the definition of derived work differs from country to country.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2808 bytes --] Hi Manfred Thanks for your reply. You wrote: > Wrong mailing list. > You must find a lawyer, and he'll answer your questions. Of course, the company I'm working for will contact their lawyers before releasing anything for linux. The reason because I'm asking here is to get an idea of your attitude regarding binary kernel modules in this specific scenario and your interpretation of the GPL in my case. I'd be glad if we can support linux but if it's not possible due to unclear legal interpretations of the GPL we certainly won't. > RCU is a patented algorithm - mention that to your lawyer. > Your creation must not be derived from the kernel > (because creating derived works is an exclusive right of > the copyright owner, and you don't have and won't > get a permission), and it must not infringe the RCU patents. Thanks for this information. I guess we can live without rcu. > You have written an algorithm module that is tightly coupled to the > Linux kernel, and you think it's not derived from the kernel, correct? > As a non-lawyer, it'd say that's wrong. Well, the algorithm has been developped totally independent from linux. It also works under other OS's without any adjustments apart from alloc and locking stuff. The fact that it receives kernel data as input IMO does not make it tightly coupled to the linux kernel since the algorithm does not even know or care what it receives as input (at least as far as kernel data is concerned). It basically considers kernel data: char[] > "Derived work" is a legal term, your lawyer might be able to figure out > if your combination is a derived work. As you stated later the interpretation differs from country to country and though I'm no lawyer (and haven't talked to one myself yet regarding this issue) I very much doubt that the interpretation is that clear even for a "fixed" country. > The drivers that are more or less accepted as not-derived run on > multiple operating systems - e.g. the nvidia ethernet driver uses the > same source code for Windows and Linux, and nvlib.o works on Linux > and FreeBSD. Well, the same holds for the algorithm module since it simply does not need any kernel support apart from alloc and locking (as I already stated). Only the frontend is different from OS to OS. I'd appreciate it very much if you and others contribute their opinion to this topic. Basically, I believe that if we're not allowed to release the algorithm as binary kernel module then you'd surely find a reason why nvidia and others in fact also infringe the GPL. Regards, John -- Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS! Ideal für alle, die gerne MMS verschicken: 25 FreeMMS/Monat mit GMX TopMail. http://www.gmx.net/de/cgi/produktemail +++ GMX - die erste Adresse für Mail, Message, More! +++
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --] On Mon, 01 Dec 2003 01:27:58 +0100, john smith said: > Well, the algorithm has been developped totally independent from > linux. It also works under other OS's without any adjustments apart > from alloc and locking stuff. > > The fact that it receives kernel data as input IMO does not make it > tightly coupled to the linux kernel since the algorithm does not even > know or care what it receives as input (at least as far as kernel data > is concerned). It basically considers kernel data: char[] You're probably "in the clear" if that's what's really going on, and can probably go a route similar to NVidia (GPL interface to a binary module). The part I'm not having warm fuzzies about is that the only application that comes to mind that could take a char[] and be totally kernel-independent and that would make sense in the kernel rather than out in userspace is a crypto transform - and that's because closed source crypto is usually not taken seriously. Consider what Matt Blaze did to Clipper, which was even more closed source than what you're doing.... Of course, if you're not doing crypto, then you can apply the usual cost/benefit analysis of doing it closed source versus the payoff for an attacker to crack it.... [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1907 bytes --] Hi Valdis > You're probably "in the clear" if that's what's really going on, and > can probably go a route similar to NVidia (GPL interface to a binary > module). I just had a quick look at the current version of nvidia's linux driver (http://download.nvidia.com/XFree86/Linux-x86/1.0-4496/NVIDIA-Linux-x86-1.0-4496-pkg2.run). The source code of the kernel front-end is _not_ GPL. It provides both definition for the OS independent symbols used in the binary object (!= kernel module) nv-kernel.o and the necessary linux kernel module code (and of course it makes use of the API nv.h provided by the binary object). So, the nvidia kernel module consists of the binary object directly linked to the objects compiled from the _non-GPL_ sources. > The part I'm not having warm fuzzies about is that the only > application that comes to mind that could take a char[] and be totally > kernel-independent and that would make sense in the kernel rather than > out in userspace is a crypto transform - and that's because closed > source crypto is usually not taken seriously. I totally agree with you and I can reassure you that the algorithm has nothing to do with crypto. > Of course, if you're not doing crypto, then you can apply the usual > cost/benefit analysis of doing it closed source versus the payoff for > an attacker to crack it.... Hm, not sure what you mean by "crack it". Maybe you mean that it's possible to apply "binary analysis methods" against the implementation provided in the binary and then reimplement the algorithm as open source? Well, in that case we have to deal with it but that's not my job :) Regards, John -- Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS! Ideal für alle, die gerne MMS verschicken: 25 FreeMMS/Monat mit GMX TopMail. http://www.gmx.net/de/cgi/produktemail +++ GMX - die erste Adresse für Mail, Message, More! +++