lkml.org 
[lkml]   [2003]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux GPL and binary module exception clause?
Date
On Friday 05 December 2003 11:05, David Dyck wrote:
> On Fri, 5 Dec 2003 at 07:06 -0800, Jesse Pollard <jesse@cats-chateau.net>
>
> wrote:
> > Quite simple. If you include the Linux kernel include files you get a
> > derived program that must be released under GPL if you distribute that
> > program.
>
> When I first read this out out of context, I wondered if you were saying
> that any executable that I write on my libc5 linux system (and those that
> were compiled on libc5 systems long ago - like my copy of Adobe acrobat,
> and RealNetworks real audio) must have been distributed under GPL?
>
> [ Please recall that the kernel header files were included in users
> programs (since /usr/include/asm and /usr/include/linux were symlinks
> into the kernel sources) and common include files like dirent.h,
> errno.h, and signal.h. This still works with libc5 and todays
> Linux 2.4.23. ]
>
> You must not be saying that, since Linus said:
>
> "There's a clarification that user-space programs that use the standard
> system call interfaces aren't considered derived works, but even that
> isn't an "exception" - it's just a statement of a border of what is
> clearly considered a "derived work". User programs are _clearly_
> not derived works of the kernel, and as such whatever the kernel
> license is just doesn't matter."
>
> And after re-reading more of the thread, you must be refering to modules
> that include kernel include files, right?

Mostly. Primarily. That is because the only executable that results IS the
kernel.

There is the fuzzy area where you write a user mode application that uses
some Kernel headers for the purpose of doing things like an ext2fs debugger.
The kernel headers are NOT released under LGPL, but all of the libc functions
and include files are. The syscall interfaces were explicitly excluded as
requiring GPL because the Linus quote.

Personally, I think it would be a good idea to have these specific ones under
the LGPL instead of GPL, and then use them in both kernel and user space
(which the LGPL also allows).

If the header is not LGPL (which allows propriatary programs to include
them), then you run a severe risk of forcing the user mode application into
GPL if it is distributed. I think this is more likely if the header includes
inline functions, and not in the case of those just defining the syscall data
structures/interface.

One area this would clarify would be if someone tried to write a propriatary
kernel debugger... It would run in user mode, but look at/poke at kernel
structures and functions in such detail that it SHOULD be a GPL program.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.025 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site