From: "john smith" <john.smith77@gmx.net> To: "Linux Kernel Mailinglist" <linux-kernel@vger.kernel.org> Subject: Kernel modul licensing issues Date: Sun, 30 Nov 2003 13:30:28 +0100 (MET) [thread overview] Message-ID: <19703.1070195428@www59.gmx.net> (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 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! +++
next 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=19703.1070195428@www59.gmx.net \ --to=john.smith77@gmx.net \ --cc=linux-kernel@vger.kernel.org \ --subject='Re: Kernel modul licensing issues' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).