Re: Kernel modul licensing issues

Re: Kernel modul licensing issues

[john smith]

[-- 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! +++

Re: Kernel modul licensing issues

[Valdis.Kletnieks]

[-- 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 --]

Re: Kernel modul licensing issues

[john smith]

[-- 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! +++

Re: Kernel modul licensing issues

[Manfred Spraul]

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.

Kernel modul licensing issues

[john smith]

[-- 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! +++