"Derivative Work" for Software Defined

[Andre Hedrick]

New twist:

user_space.c                              kernel_space.c
#include <signal.h>                       #include <kernel/signal.h>
        #include <kernel/signal.h>                #include <asm/signal.h>
                #include <asm/signal.h>

Where does "signal.h" from the compiler obtain its included references?

#include <signal.h>
        #include <kernel/signal.h>
                #include <asm/signal.h>

Each of thes are successive including works to create a combined work.

How can the user space cascading series of inclusions, be different than a
kernel space cascading series of inclusions ?

If this is the case then every user space program is a derived work forced
it become GPL.  This logic has to be true.  How could the user space
"signal.h" not taint user space if it derives it s operational/functional
nature from the cascading inclusions?

If user space is not tainted, how is kernel space tainted?
Is there a magical ether to was away the taint?

If there is, then what stops one from washing all the license out of
kernel space?

If it does not, then it means the cascading inclusions do not taint.
This new logic means anthing calling kernel inclusions can not be tainted.

So now the GPL taint is gone ??

Wash, rinse, repeat : now with copyright.

Does this mean copyright taint is gone ??

Does that make the classic "hello.c" copyright tainted for using the
headers?

If user space passing of headers which were included from the kernel they
were executed against, makes user space clean, why kernel space?

This is a very fun puzzle which looks like the case for binary modules and
derived works is a pile of dung.

Anybody with answers?

Andre Hedrick
LAD Storage Consulting Group

IANAL, but a Storage Technologies.


--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3