> One thing that is clear in the GPL: If you link the kernel with something
> else to an executable, the resulting blob (and therefore the
> sources to the
> proprietary part) must be GPL.
Actually, that is *far* from clear.
First, the GPL cannot set its own scope. The GPL could say that if you
stored a program in the same room as a GPL program, the program must be GPL.
So *nothing* the GPL says will answer this question -- the question is, can
the GPL attach by linking?
The contrary argument would be that linking two programs together is an
automated process. There is no creative input in the linking process. So it
does not legally produce a single work, but a mechanical combination of the
two original works.
The proof that the executable is not a work for copyright purposes is this
simple -- could a person who took two object files out of the box and linked
them together claim copyright in the new derivative work he just produced? I
think the answer would be obvious -- the executable is not a new work, it's
just the two original works combined.
Note that this does not mean that *designing* a program specifically to
link to another program can't make it a derivative work of the work you
designed it to go with. Just that the linking itself cannot always do so
automatically.
In any event, to give my answer to the original question -- if a kernel
module and a userspace program are developed together, and are not both
derived from an API that is independent of the Linux kernel, then they are
probably going to be considered a single work.
On the flip side, you should be okay if you develop an API for a kernel to
communicate with user space and then develop a user space program that could
work on any kernel (Linux or not, theoretically) that supported that API.
This should ensure that the user space program is derivative only from the
API and not from the Linux kernel.
Note that you will not be okay if the API looks like what just happen to be
Linux kernel internals. The API itself must be independent of the Linux
kernel internals.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
