Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: GPL issues | Date | Fri, 14 Apr 2006 04:39:59 -0700 |
| |
> 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 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/
| |