"Derivative Work" for Software Defined

[Andre Hedrick]

On Tue, 7 Jan 2003, David Johnson wrote:

> On Tuesday 07 January 2003 10:15 pm, Andre Hedrick wrote:
> > 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?
> 
> It's an old twist that has already been addressed. First, the GPL attached to 
> the Linux kernel makes an exception for this case. Second, signal.h is a 
> standard POSIX header present on all Unix systems.
> 
> Is my helloworld.c program derivative of Linux? No, because it's not running 
> under Linux...

Well I feel dumb as a brick.  So if user-space is clean.

If one was to go through the pain of creating a set of headers from
scratch that happen to behave just like the one is the kernel snapshot
they are referrencing, as a manual to the API.  This obviously is
extracting the ideas in :

./linux-{snapshot_version}/include/{asm,linux,...}

and creating a new original work :

./new-work-{snapshot_version}/include/{asm,os,...}

These headers are now clean and original works?
If so, how does calling such functions which now are clean and will allow
one to load in to a kernel anything you want, behave between licenses?
Is the kernel/program a GPL object or is it an LGPL object ?

The latter seems to have some understand as clean.
The former is what?  Is this the grey zone or the exact boundary which
makes binary modules a problem?  If it is then regardless of the headers,
the vendor is in the wrong.  There are a bunch of business which are in
deep trouble.  If it is not then where is all the issues coming from?
(other than silly developers like me)

How does an embedded linux development kit vendor bypass the issues?
Do they thumb the nose?

Does calling or loading a GPL and non-GPL togather alter the non-GPL ?
Obvious linking it would.

How does loading v/s linking behave in address space?

People claim loading == linking.

cat /proc/kcore > vmlinuz ; gdb vmlinuz

Now the vendor of the binary module did not create this new object, 
the enduser did.
Is the vendor responsible for the enduser's creation of the combined work?

If the vendor prevents the existance of "/proc/kcore" does that thwart the
enduser's ability to create such an object ?

More and more this looks unfriendly to binary vendor, and the BSD's seem
the path to take.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

IANAL, but a Storage Technologist.

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