![]() | |||||||||||||
Messages in this thread |
> 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 07:03 [W:0.181 / U:0.000 seconds] ©2003-2008 Jasper Spaans | |||||||||||||