> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
