Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Reid Hekman <reid.hekman@ndsu.nodak.edu>]

David Lang wrote:

> so are you saying that BSD licened modules are not going to be allowed to
> use any future entry points (assuming they are all put under the the
> export_symbol_gpl limits)?
> 
> saying that existing stuff will not change doesn't answer the problem
> about licences that may have source avilable (tainting) but may not. if
> you assume either way you will cause a bunch of problems.
> 
> David Lang
> 


That's nonsense. OK, with a strict interpretation on the use of the 
MODULE_LICENSE and depending on the implementation of license strings, 
old BSD licensed code could taint a kernel, but according to 
http://www.gnu.org/licenses/license-list.html modified BSD licensed code 
or code falling under the similar X11 license is GPL compatible. 
Therefore if you distribute or contribute source for a module that is 
BSD licensed, and MODULE_LICENSE is implemented in a remotely sane way 
you will be able to install a BSD licensed module without tainting the 
kernel.

>  On Thu, 18 Oct 2001, John Alvord wrote:

>>Linus said that all existing entry points would remain untagged. Thus
>>existing modules would not be affected.
>>
>>john


The GPL includes as derivative works any code, when compiled or 
executed, that is linked with GPL covered code, calls functions or 
shares data structures. Simply fork()ing or exec()ing is not a 
derivative work. FSF states that linking and simply calling main() and 
returning is a border case(1). From that we can extrapolate a number of 
things. Simply doing a syscall is not a derivative work. As I have read 
in the past, Linus, for practical reasons, has stated that modules using 
published interfaces need not qualify as derivative works. Also, 
"modules" in the generic sense, say plugins for example, when written to 
link with GPL code need not be GPL themselves. So long as they are GPL 
compatible, they can be linked without violating the license. Hence, 
MODULE_LICENSE strings may include GPL compatible source distributing 
licenses, eg. newBSD or X11.

MODULE_LICENSE & EXPORT_SYMBOL_GPL are good things. MODULE_LICENSE 
provides an easier way to screen binary only modules from submitted 
bugs. It doesn't prevent someone from running a tainted kernel and it 
also doesn't prevent someone on linux-kernel from investigating the bug 
report if they want to. MODULE_LICENSE also has the potential to educate 
users. EXPORT_SYMBOL_GPL throws a speed bump in front of potentially 
dangerous subsystem modules. The Linux Security Module interface is the 
most recent example of this(2). If modules are allowed to insert hooks 
willy nilly into the kernel, eventually large proprietary functionality 
could result, unfairly taking advantage of Linus' practical foresight. 
EXPORT_SYMBOL_GPL allows us a simple way to define "public" interfaces 
that binary only module writers can use and which symbols are off 
limits. There is no restriction on fair use, as you can still remove the 
  disabling GPL compatible exports for internal, non-released code. 
Also, we are afforded more leeway in the future. If general consesus is 
that we need to let a proprietary vendor use a GPL symbol, we can always 
remove the restriction. Alternatively, if a vendor realizes he could 
write a better module if only he could use GPL-compatible-only symbols 
he may think twice and release the source. In the end, thats a solution 
I can live with.

Regards,
Reid

1. From GNU GPL FAQ: 
http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense

2. http://lwn.net/2001/1004/kernel.php3