archive mirror
 help / color / mirror / Atom feed
From: "john smith" <>
To: "Linux Kernel Mailinglist" <>
Subject: Kernel modul licensing issues
Date: Sun, 30 Nov 2003 13:30:28 +0100 (MET)	[thread overview]
Message-ID: <> (raw)

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

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.


Neu bei GMX: Preissenkung für MMS-Versand und FreeMMS!

Ideal für alle, die gerne MMS verschicken:
25 FreeMMS/Monat mit GMX TopMail.

+++ GMX - die erste Adresse für Mail, Message, More! +++

             reply	other threads:[~2003-11-30 12:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-30 12:30 john smith [this message]
2003-11-30 13:23 Manfred Spraul
2003-12-01  0:27 john smith
2003-12-01  0:57 ` Valdis.Kletnieks
2003-12-01 10:58 john smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: Kernel modul licensing issues' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).