Re: GPL issues

[Kyle Moffett <mrmacman_g4@mac.com>]

On Apr 11, 2006, at 23:18:04, 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.

Not necessarily, there may be grey area.  The new splice() syscall,  
for example; does any other software have a syscall that even  
remotely resembles it?  Could a piece of software that uses the splice 
() syscall be said to stand on its own as a separate work?  Those are  
the questions you should be asking.  For that particular case, the  
answers are probably yes; _especially_ if the program in question has  
an abstraction library for file IO.  Now let's discuss a binary  
program specifically designed to read and write several sysfs files.   
Does any other operating system have anything like sysfs?  Could that  
program be said to stand on its own?  Would it work without  
linux-2.6?  It doesn't even work on linux-2.4!  Would that be  
considered a "derivative work"??  I don't know the answers to these  
questions, and I suspect it would depend a _lot_ on what the software  
did with those interfaces, how it used the functionality, etc.

A program that doesn't use more than standard SysV/UNIX/POSIX/ANSI/ 
etc functionality, or provides an abstraction layer so that it works  
on more than just Linux is definitely OK.  It stands distinct from  
the kernel; does not strictly depend on a particular version of a  
particular operating system.  A module that links directly into the  
kernel and messes with its internals is most certainly NOT ok.  The  
grey area in between is exceptionally unclear.  I don't think we can  
state for certain until a legal case comes up in the courts, but  
let's just hope it never comes to that.

Cheers,
Kyle Moffett

-
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/