lkml.org 
[lkml]   [2006]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: GPL issues
> 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...)

> 5. Userspace code that depends on interfaces you added to the kernel
> --> consult a lawyer (if this interface is something completely new,
> you can *probably* use your own license for the userland part; if the
> interface is more or less a wrapper of existing functionality, GPL)

An example could be helpful in clarifying the GPL license.

Suppose I use the linux-vrf patch for the kernel that is freely
available and use the extended setsocket options such as SO_VRF in an
application, do I have to release my application under GPL since I am
using a facility in the kernel that a standard linux kernel does not
provide?

Suppose my LKM driver adds a extra header to all outgoing packets and
removes the extra header from the incoming packets, should this driver
be released under GPL.? In a way it extends the functionality of
linux, if I do release the driver code under GPL because this was
built with linux in mind, Should I release the application which
adds intelligence to interpret the extra header under GPL?

Thanks,
Pramod
-
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/

\
 
 \ /
  Last update: 2006-04-12 09:03    [W:0.494 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site