Re: Cherokee Nation Posts Open Source Legisation - Invites commentsfrom Community Members

[jmerkey]

The current Gadugi implementation has compiled the Linux kernel as a 
standalone elf64 module that loads as
an application on the Gadugi kernel, with the /arch portions stripped 
and mapped into Gadugi.  Gadugi has it's
own elf64 loader (non-GPL). The GPL language states that the "collective 
work" definition refers to code sections
which constitute part of a "whole" unpo which the "separate" work in based.

This is a collective work which is "not based upon Linux", Linux runs as 
a kernel app.  Provided the two
code bases remain separate, there are no GPL issues with the current 
language.  Gadugi is a separate
elf64 module with it's own loader, services, etc.  The fact that Linux 
is now "based on" another operating
system reverses the license language (thanks Richard S. for inserting 
this) and the GPL also states
that independent works are "separate" and not affected by this license. 

I realize there may be many people who take issue with this, but this is 
the laguage, and yes, GPL code can be taken and
used this way.  The two code bases are maintained seprately and not 
compiled together.  But Linux can be loaded
as as Elf application, and in this sense it is a "seperate" work and 
whole in itself.   



Stephen Pollei wrote:

> On Wed, 2005-01-12 at 09:18, root wrote:
> OK I've replied to this as well at
> http://www.gadugi.org/article.php?story=20041221121621283 ...
> I think that your understanding of the implications of the GPL seem to
> be dangerously flawed in some respects.
>  
>
> > There is no impact on the GPL and any Linux code covered under the GPL
> > remains as such.  The Ga-du-gi OS is defined under the current FSF 
> > definitions as a "collective work" not a "derivative work".  So all the
> > folks sending mail to LKML and gadugi.org that implies otherwise
> > are out in the weeds.  
> >    
>
> The below should also be at the above mentioned url...
>
> OK the extent of the fork has been mentioned.
> However you should note that both the GPL and LGPL only give conditional
> permission to include code licensed under those terms into "collective
> works". Your code that is under "/arch" sure sounds like it is
> interdependant with the rest of the kernel code. Further it is not a
> "separate work" and a kernel compiled with your "arch" changes can't be
> shipped into two independant separate binaries-- it forms one
> inseparable whole that contains incompatibily licensed code. The GPL
> doesn't give anyone permission to include code licensed under those
> terms in these conditions.
>
> It would be instructive for you to compare and contrast the GPL and the
> LGPL to notice that altogether not giving permission to create
> inseparable, dependent works that add restrictions was *intended*. If
> the developers wanted to allow you to do what it is you are attempting
> they would have choosen the LGPL or another license.
>
> You should note that the kernel developers would like to see more
> successful Linux forks -- you are in fact given an explicit license to
> create forks the GPL. However that is your only license to do so and if
> you choose to ignore it's boundaries after being repeatiibly and
> publicly warned, then you are likely to incure civil liabilites from
> being found a willful premeditated copyright infringer in a few
> jurisdictions around the world.
>
> I strongly suggest that instead of assuming that you seek competent
> legal advice or take an educational seminar, read a faq or two or
> otherwise education yourself to what the GPL implies.
>
> So please instead of complaining that people are "out in the weeds" or
> creating a "smoke screen". Maybe you should listen a little.
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0501.1/1425.html
> http://www.fsf.org/licenses/gpl.txt
> http://www.fsf.org/licenses/lgpl.txt
> http://patron.fsf.org/course-offering.html
> http://www.fsf.org/licenses/gpl-faq.html
>
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/