Re: GPL issues

["jdow" <jdow@earthlink.net>]

From: "David Weinehall" <tao@acc.umu.se>
> On Tue, Apr 11, 2006 at 10:45:55PM -0700, jdow wrote:
>> >On Tue, 2006-04-11 at 23:18 -0400, Mark Lord wrote:
>> >>Joshua Hudson wrote:
>> >>> On 4/11/06, David Weinehall <tao@acc.umu.se> wrote:
>> >>>> OK, simplified rules; if you follow them you should generally be OK:
>> >>..
>> >>>> 3. Userspace code that uses interfaces that was not exposed to 
>> >>userspace
>> >>>> before you change the kernel --> GPL (but don't do it; there's almost
>> >>>> always a reason why an interface is not exported to userspace)
>> >>>>
>> >>>> 4. Userspace code that only uses existing interfaces --> choose
>> >>>> license yourself (but of course, GPL would be nice...)
>> >>
>> >>Err.. there is ZERO difference between situations 3 and 4.
>> >>Userspace code can be any license one wants, regardless of where
>> >>or when or how the syscalls are added to the kernel.
>> >
>> >that is not so clear if the syscalls were added exclusively for this
>> >application by the authors of the application....
>> 
>> Consider a book. The book is GPLed. I do not have to GPL my brain when
>> I read the book.
>> 
>> I add some margin notes to the GPLed book. I still do not have to GPL
>> my brain when I read the book.
> 
> This is possibly the worst comparison I've read in a long long time...
> 
> It's rather a case of:
> 
> Consider a book.  The book is GPLed.  You take add one chapter to the
> book.  The resulting book needs to be GPLed.

I am with you this far.

> Now, instead of adding to that book, you "export" parts of the book by
> copying them into your book.  Your new book wouldn't work without the
> copied parts.  Your resulting book needs to be GPLed.

Nothing is exported except to the reader's brain aka user space. It
is not exported to a new book.

Exporting a new interface is equivalent to making the marginal notes.

You can still READ the book without GPLing your brain or your
application. You can make additional temporary marginal notes,
place data into the kernel which causes the kernel to disgorge
some data.

> Your "read the book"-case is only comparable to the case of building
> a userspace binary for local use that only uses existing interfaces,
> vs building one that uses exported private interfaces.  In both cases,
> since you're not distributing your modified version, you're free to
> do whatever you like.

Either you cannot have a non-GPL program on the kernel OR you can. It
makes no difference if the kernel is modified (the modification is GPL)
or the kernel is not modified. The modified kernel must be distributed
as source if requested. The application does not unless EVERY application
must be distributed with source.

There is apparently no argument with regards to applications that are
not GPL running on LINUX. Therefore there should be no argument with
an application that uses a newly exported API being GPLed.

If you are considering the potential case that the modification is made
to the kernel and then the source for that modification is also used in
user space in an application requiring the application to be GPLed then
you must first prove it was done in that order rather than the other order.
Code can also be released dual licensed. GPL for the kernel and private
for the user space, if it is done so by the owner or creator of the code
in question. Anything else is absurd on its face.

{^_^}   Joanne Dow