Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Roy Murphy]

'Twas brillig when Keith Owens scrobe:
>EXPORT_SYMBOL_GPL 
>
>Some kernel developers are unhappy with providing external interfaces
>to their code, only to see those interfaces being used by binary only 
>modules. They view it as their work being appropriated. Whether you 
>agree with that view or not is completely irrelevant, the person who 
>owns the copyright decides how their work can be used. 

The GPL takes its strength and power from Copyright Law.  Copyright law 
allows certain exclusive rights to authors.  Among these are: 
distribution, public performance and the preparation of derivative 
works.  Copyright Law (at least in the US) reserves certain rights to 
the Public, notably the right to make Fair Uses.  Because of Fair Use, 
the statement above "the person who owns the copyright decides how 
their work can be used." is demonstrably false in a US Copyright 
context.

Some elements of authorship are copyrightable, other elements are not.  
One clear exception in US Copyright Law is "methods of operation" which 
are not copyrightable.  The canonical example of this the pattern of a 
standard transmission shift.  The pattern, intimately tied to the 
manner in which the device is used, has been standardized because its 
design could be copied and used by all manufacturers.

Exported interfaces are "methods of operation" in the sense of US 
Copyright Law.  Copyright Law affords no protection to "methods of 
operation".  The GPL, which gains its strength from Copyright Law, also 
has no rights in this area.  If a GPLed module does not want other code 
using its interfaces, they should not be exported.

This is an example of overreaching copyright control which is just as 
aggregious as CSS on DVDs.
 

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Arjan van de Ven]

> Exported interfaces are "methods of operation" in the sense of US
> Copyright Law.  Copyright Law affords no protection to "methods of
> operation".  The GPL, which gains its strength from Copyright Law, also
> has no rights in this area.  If a GPLed module does not want other code
> using its interfaces, they should not be exported.

I think you're missing one thing: binary only modules are only allowed
because of an exception license grant Linus made for functions that are
marked EXPORT_SYMBOL(). EXPORT_SYMBOL_GPL() just says "not part of this 
exception grant"....

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Taral]

On Thu, Oct 18, 2001 at 04:17:02PM +0100, Arjan van de Ven wrote:
> 
> > Exported interfaces are "methods of operation" in the sense of US
> > Copyright Law.  Copyright Law affords no protection to "methods of
> > operation".  The GPL, which gains its strength from Copyright Law, also
> > has no rights in this area.  If a GPLed module does not want other code
> > using its interfaces, they should not be exported.
> 
> I think you're missing one thing: binary only modules are only allowed
> because of an exception license grant Linus made for functions that are
> marked EXPORT_SYMBOL(). EXPORT_SYMBOL_GPL() just says "not part of this 
> exception grant"....

Fine. I (the hypothetical binary driver maker) will just make two
modules -- one which is MODULE_LICENCEd GPL, and the other which is not.
The first will re-export your interfaces as unrestricted ones which the
second can use. Are we going to start insisting on a transitivity of
this restriction? If so, then it's possible that a large number of
interfaces might go...

I also think this is somewhat ridiculous. If I (the binary module maker)
distribute a program which effectively replicates the functionality of
insmod without the licence checking, and distribute that program with my
module, am I violating any restrictions? I don't think so, since it's
the end-user that ends up linking the kernel to the module. No linked
products are actually distributed...

-- 
Taral <taral@taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Alan Cox]

> I also think this is somewhat ridiculous. If I (the binary module maker)
> distribute a program which effectively replicates the functionality of
> insmod without the licence checking, and distribute that program with my
> module, am I violating any restrictions? I don't think so, since it's
> the end-user that ends up linking the kernel to the module. No linked
> products are actually distributed...

You are arguably obtaining services by deception, and possibly also
violating a content management system.

However the MODULE_LICENSE isn't aimed at people like that. In fact I've had
totally positive responses from people who ship well known binary modules
and understand why we want them to get bugs related to their code.

The people bright enough to hack insmod generally are also bright enough to
realise why its a bad idea.

Alan

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Taral]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Sun, Oct 21, 2001 at 04:22:47PM +0100, Alan Cox wrote:
> You are arguably obtaining services by deception, and possibly also
> violating a content management system.
> 
> However the MODULE_LICENSE isn't aimed at people like that. In fact I've had
> totally positive responses from people who ship well known binary modules
> and understand why we want them to get bugs related to their code.
> 
> The people bright enough to hack insmod generally are also bright enough to
> realise why its a bad idea.

I'm not arguing against MODULE_LICENSE. I'm arguing against
EXPORT_SYMBOL_GPL. I fully agree with the person who mentioned that
calling certain interfaces "restricted" and basing that restriction on
the licence of the interface user is an abuse of copyright.

More reasonable would be to have header files that looked like this:

#ifndef GPL_COMPATIBLE_LICENSE
#error This header file is restricted to GPL-compatible code only.
#endif

-- 
Taral <taral@taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[David Woodhouse]

taral@taral.net said:
>  Fine. I (the hypothetical binary driver maker) will just make two
> modules -- one which is MODULE_LICENCEd GPL, and the other which is
> not. The first will re-export your interfaces as unrestricted ones
> which the second can use.

You seem to have missed the point that it is already considered to be 
unacceptable to add GPL'd code to the kernel, exporting functionality which 
is required for non-GPL'd modules. 

--
dwmw2

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Roy Murphy]

'Twas brillig when Taral scrobe:
>You're quite right. Module insertion is linking. And distributing a 
>kernel with binary-only modules already inserted would be a GPL 
>violation. What modules do is let people do the link at the last stage 
>-- the end user. The GPL does not restrict what end-users do with your 
>code if it doesn't involve redistribution. 

The point was made earlier that a module might include some code expanded from
a macro in a kernel header file.  Producers of binary 
modules could adopt a "clean room" approach (as the first cloners of 
the IBM PC BIOS did) and have one group write a technical specification 
for any necessary kernel headers and have a second group implement 
substitute headers from the specification.

>I also think this is somewhat ridiculous. If I (the binary module 
>maker) distribute a program which effectively replicates the 
>functionality of insmod without the licence checking, and distribute 
>that program with my module, am I violating any restrictions? I don't 
>think so, since it's the end-user that ends up linking the kernel to 
>the module. No linked products are actually distributed... 

In the US it may be a violation of the DCMA prohibition on 
circumvention of "effective access controls" (and perhaps violations of 
corresponding laws in some European countries).  Though that's a whole 
'nother huge legal morass.
 

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Roy Murphy]

'Twas brillig when Arjan van de Ven scrobe:
>I think you're missing one thing: binary only modules are only allowed
>because of an exception license grant Linus made for functions that are
>marked EXPORT_SYMBOL(). EXPORT_SYMBOL_GPL() just says "not part of 
>this exception grant"....

With all respect to Linus, I don't believe that module insertion is an 
exclusive right granted to authors that is within Linus' legal power as holder
of the Copyright to the kernel to grant or to restrict.  Does Microsoft have
a legal right to disallow any third-party drivers from 
registering themselves with the OS?  Does Linus?
 

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Arjan van de Ven]

On Thu, Oct 18, 2001 at 11:43:15AM -0500, Roy Murphy wrote:
> 'Twas brillig when Arjan van de Ven scrobe:
> >I think you're missing one thing: binary only modules are only allowed
> >because of an exception license grant Linus made for functions that are
> >marked EXPORT_SYMBOL(). EXPORT_SYMBOL_GPL() just says "not part of 
> >this exception grant"....
> 
> With all respect to Linus, I don't believe that module insertion is an 
> exclusive right granted to authors that is within Linus' legal power as holder
> of the Copyright to the kernel to grant or to restrict.  Does Microsoft have
> a legal right to disallow any third-party drivers from 
> registering themselves with the OS?  Does Linus?

I'm sorry. "module inserting" is LINKING. A kernel module does, in my
oppinion, NOT fall under the gpl stated "mere aggregation" boundary of the
GPL, it is compiled with kernel headers, contains kernel _code_ from these
headers etc etc, and is for all intents and purposes part of the GPL program
"kernel" once loaded. It uses normal function calls etc etc, symbols are
resolved using normal linking mechanisms etc etc.

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Tim Bird]

Arjan van de Ven wrote:
> 
> On Thu, Oct 18, 2001 at 11:43:15AM -0500, Roy Murphy wrote:
> > With all respect to Linus, I don't believe that module insertion is an
> > exclusive right granted to authors that is within Linus' legal power as holder
> > of the Copyright to the kernel to grant or to restrict.  Does Microsoft have
> > a legal right to disallow any third-party drivers from
> > registering themselves with the OS?  Does Linus?
> 
> I'm sorry. "module inserting" is LINKING. A kernel module does, in my
> oppinion, NOT fall under the gpl stated "mere aggregation" boundary of the
> GPL, it is compiled with kernel headers, contains kernel _code_ from these
> headers etc etc, and is for all intents and purposes part of the GPL program
> "kernel" once loaded. It uses normal function calls etc etc, symbols are
> resolved using normal linking mechanisms etc etc.

"module inserting is linking" is true for almost
any other operating system which supports loadable modules
(including Windows), and really has no bearing on Mr. Murphy's 
argument.  The stronger argument is with the kernel header
files being GPL, to the degree that they contain macros
containing actual code, which expand into binary code
actually in the compiled module.

However, Mr. Murphy's point is correct.  The law
supports the idea that certain INTERFACES may create
a legitimate boundary between different code bases
to distinguish them (as not being derivative works
of each other).  This is true no matter what the FSF
thinks of static linking vs. dyamic linking, or what
Linus has said about permissibility of non-GPL
loadable modules.
I don't think even the interface creator can decide
whether a particular interface meets the criteria for
isolating or not the calling program from being a derivative
work. It's really up to a judge.

However, the EXPORT_SYMBOL_GPL facility may play a
role in indicating to a judge or jury the intent of the
original developer with regard to the interface.  This
is unlikely to have as big an impact on the legality
of using the symbol from a non-GPL module as other factors
that come into play here.

Please don't misinterpret me.  I'm glad Linus made his
exception (even though it may not exactly jibe with
copyright law and the GPL license), and I see value
in having developer's express their licensing intent
for their published interfaces.  It's just dangerous
to assume this holds much legal weight.

____________________________________________________________
Tim Bird                                  Lineo, Inc.
Senior VP, Research                       390 South 400 West
tbird@lineo.com                           Lindon, UT 84042

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Taral]

On Thu, Oct 18, 2001 at 11:49:21AM -0400, Arjan van de Ven wrote:
> I'm sorry. "module inserting" is LINKING. A kernel module does, in my
> oppinion, NOT fall under the gpl stated "mere aggregation" boundary of the
> GPL, it is compiled with kernel headers, contains kernel _code_ from these
> headers etc etc, and is for all intents and purposes part of the GPL program
> "kernel" once loaded. It uses normal function calls etc etc, symbols are
> resolved using normal linking mechanisms etc etc.

You're quite right. Module insertion is linking. And distributing a
kernel with binary-only modules already inserted would be a GPL
violation. What modules do is let people do the link at the last stage
-- the end user. The GPL does not restrict what end-users do with your
code if it doesn't involve redistribution.

In short: Copyright holders have the right to attempt to restrict their
interfaces. But end-users also have the right to ignore those attempts.
That is, unless the DMCA comes into play.

-- 
Taral <taral@taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Jan-Benedict Glaw]

On Thu, 2001-10-18 11:43:15 -0500, Roy Murphy <murphy@panix.com>
wrote in message <3bcef893.4872.0@panix.com>:
> 'Twas brillig when Arjan van de Ven scrobe:
> >I think you're missing one thing: binary only modules are only allowed
> >because of an exception license grant Linus made for functions that are
> >marked EXPORT_SYMBOL(). EXPORT_SYMBOL_GPL() just says "not part of 
> >this exception grant"....
> 
> of the Copyright to the kernel to grant or to restrict.  Does Microsoft have
> a legal right to disallow any third-party drivers from 
> registering themselves with the OS?  Does Linus?

They do, but they won't use it. They want to *sell* windows and they're
(more or less) willing to decode their blue screens produced by 3rd
vendor's drivers. However, GPL people may (or may not) be willing to
spend time in searching bugs in other company's drivers. However, *I* am
not willig to do other people's job, especially if *they* earn money
therefor... 

MfG, JBG

-- 
Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[David Lang]

so what will the export_symbol_gpl stuff do with the BSD license? it may
or may not have source avilable so is it allowed to use the exported
symbols or not?

for the tainting module process there is the same problem.

knowing the license the code was released under does not tell you if the
source is available or not.

David Lang


 On Thu, 18 Oct 2001, Jan-Benedict Glaw wrote:

> Date: Thu, 18 Oct 2001 18:07:06 +0200
> From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
> To: linux-kernel@vger.kernel.org
> Subject: Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL
>
> On Thu, 2001-10-18 11:43:15 -0500, Roy Murphy <murphy@panix.com>
> wrote in message <3bcef893.4872.0@panix.com>:
> > 'Twas brillig when Arjan van de Ven scrobe:
> > >I think you're missing one thing: binary only modules are only allowed
> > >because of an exception license grant Linus made for functions that are
> > >marked EXPORT_SYMBOL(). EXPORT_SYMBOL_GPL() just says "not part of
> > >this exception grant"....
> >
> > of the Copyright to the kernel to grant or to restrict.  Does Microsoft have
> > a legal right to disallow any third-party drivers from
> > registering themselves with the OS?  Does Linus?
>
> They do, but they won't use it. They want to *sell* windows and they're
> (more or less) willing to decode their blue screens produced by 3rd
> vendor's drivers. However, GPL people may (or may not) be willing to
> spend time in searching bugs in other company's drivers. However, *I* am
> not willig to do other people's job, especially if *they* earn money
> therefor...
>
> MfG, JBG
>
> --
> Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481
> -
> 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/
>

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[John Alvord]

On Thu, 18 Oct 2001 15:38:36 -0700 (PDT), David Lang
<david.lang@digitalinsight.com> wrote:

>so what will the export_symbol_gpl stuff do with the BSD license? it may
>or may not have source avilable so is it allowed to use the exported
>symbols or not?
>
>for the tainting module process there is the same problem.
>
>knowing the license the code was released under does not tell you if the
>source is available or not.
Linus said that all existing entry points would remain untagged. Thus
existing modules would not be affected.

john

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[David Lang]

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

 On Thu, 18 Oct 2001, John Alvord wrote:

> Date: Thu, 18 Oct 2001 17:46:18 -0700
> From: John Alvord <jalvo@mbay.net>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL
>
> On Thu, 18 Oct 2001 15:38:36 -0700 (PDT), David Lang
> <david.lang@digitalinsight.com> wrote:
>
> >so what will the export_symbol_gpl stuff do with the BSD license? it may
> >or may not have source avilable so is it allowed to use the exported
> >symbols or not?
> >
> >for the tainting module process there is the same problem.
> >
> >knowing the license the code was released under does not tell you if the
> >source is available or not.
> Linus said that all existing entry points would remain untagged. Thus
> existing modules would not be affected.
>
> john
>

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Reid Hekman]

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

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[David Lang]

I use this example becouse the question came up a week or so ago and I
don't remember seeing the issue resolved.

the problem posted is that a BSD no adv licence is GPL compatable and
source may be available and therefor BSD no adv modules should not taint
the kernel, on the other hand it's possible to have a BSD no adv licensed
module that the source is not available for and therefor it should taint
the kernel.

just knowing the license doesn't tell you if the source is available
(which is the stated goal of the taint stuff)

if instead of MODULE_LICENSE there was a MODULE_SOURCE tag this would not
be an issue, and the EXPORT_SYMBOL_GPL would obviously be a seperate
issue. as it is they both use the MODULE_LICENSE tag which confuses the
intent of both of them.

if BSD no adv is considered a non-tainting license then what's to stop all
the binary-module vendors from useing it in their modules? it doesn't
requrire that they give the source to anyone so it's no risk to their IP
but it avaids the 'bad press' of the kernel announcing that useing their
stuff taints the kernel.

on the other hand if BSD no adv is considered a taining license then you
are going against the statement that it's compatable with the GPL and you
are telling module programmers who release the source that BSD isn't good
enough they can only work with the linux kernel if they change to the GPL
(or one of the other approved licenses)

again my point is that knowing the license is not enough by itself to know
if the kernel should be considered tainted, so let's not try to do it this
way.

or if the intent really is to force everything to be GPL then just say so
rather then claiming that that's not your intent.

David Lang



On Fri, 19 Oct 2001, Reid Hekman wrote:

> Date: Fri, 19 Oct 2001 07:44:43 -0500
> From: Reid Hekman <reid.hekman@ndsu.nodak.edu>
> To: David Lang <dlang@diginsite.com>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL
>
> 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
>

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Reid Hekman]

David Lang wrote:

> I use this example becouse the question came up a week or so ago and I
> don't remember seeing the issue resolved.


I wish it was easy, but legality/copyright/property rights are not 
always easy topics


> the problem posted is that a BSD no adv licence is GPL compatable and
> source may be available and therefor BSD no adv modules should not taint
> the kernel, on the other hand it's possible to have a BSD no adv licensed
> module that the source is not available for and therefor it should taint
> the kernel.
> 
> just knowing the license doesn't tell you if the source is available
> (which is the stated goal of the taint stuff)


Good point. Anybody else want to chime in here? For linux-kernel's 
purposes at least, a BSD licensed piece of code with no source is about 
as useful as ice-cream to an eskimo. Of course creating BSD licensed 
binaries from closed source is kind of silly. Say we see an external 
module (one not distributed with the kernel source) that identifies 
itself as BSD licensed loaded into somebodies' kernel then ask the 
provider for source and he refuses. Rightfully that kernel should have 
been marked tainted. Is their anything in the licensing that would allow 
us to say that specifying a BSD license in the MODULE_LICENSE tag refers 
to source distribution? Or is that implied?


> if instead of MODULE_LICENSE there was a MODULE_SOURCE tag this would not
> be an issue, and the EXPORT_SYMBOL_GPL would obviously be a seperate
> issue. as it is they both use the MODULE_LICENSE tag which confuses the
> intent of both of them.


What's in a name? If it's called MODULE_LICENSE or MODULE_SOURCE if it's 
defined to mean availability and licensing of module source, that's the 
important distinction. Further, EXPORT_SYMBOL_GPL is a separate issue 
regardless, it allows us a definite way to specify "private" interfaces.

 
> if BSD no adv is considered a non-tainting license then what's to stop all
> the binary-module vendors from useing it in their modules? it doesn't
> requrire that they give the source to anyone so it's no risk to their IP
> but it avaids the 'bad press' of the kernel announcing that useing their
> stuff taints the kernel.


If it becomes public knowledge that a binary-module vendor distributes 
modules marked as BSD licensed but the source is unavailable that would 
be bad PR for them. First they would probably be ignored by 
linux-kernel. They should also be branded as liars for disingenuosly 
marking their products.

 
> on the other hand if BSD no adv is considered a taining license then you
> are going against the statement that it's compatable with the GPL and you
> are telling module programmers who release the source that BSD isn't good
> enough they can only work with the linux kernel if they change to the GPL
> (or one of the other approved licenses)


I don't think anybody wants to disallow linking of GPL compatible code 
with Linux. Given that the FSF thinks that BSD-no-adv is compatible, I'd 
tend to agree with them. If MODULE_LICENSE is to be used as your 
"MODULE_SOURCE" idea is (which I think it is), it's not an issue. As far 
as programmers releasing BSD source, they seem to be OK with it, check 
the source yourself: http://lxr.linux.no/search?string=MODULE_LICENSE.

> again my point is that knowing the license is not enough by itself to know
> if the kernel should be considered tainted, so let's not try to do it this
> way.


Making access control mandatory with source code availability is hard. 
Nobody said this was a be-all, end-all solution, it simply helps screen 
those that would take advantage of people's limited time and effort. It 
depends partly on respect and good-will, so if a vendor wants to violate 
that trust and flaunt arrogance to the folks of the linux community, so 
be it.

> or if the intent really is to force everything to be GPL then just say so
> rather then claiming that that's not your intent.
> 
> David Lang

The intent is to more clearly define the gracious exception that has 
been made for binary-only module vendors. If we decide to disallow the 
use of BSD licensed code (when everybody else in the world can use it) 
that's our loss. In the end we want to respect other people's copyrights 
and have our's respected in turn.

Regards,
Reid

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Keith Owens]

On Fri, 19 Oct 2001 13:07:37 -0700 (PDT), 
David Lang <david.lang@digitalinsight.com> wrote:
>the problem posted is that a BSD no adv licence is GPL compatable and
>source may be available and therefor BSD no adv modules should not taint
>the kernel, on the other hand it's possible to have a BSD no adv licensed
>module that the source is not available for and therefor it should taint
>the kernel.

Do not cc: me on this thread.

Check module.h and insmod.c before making statements like that.  The
BSD no advert license is not considered GPL compatible in the kernel.
Only Dual BSD/GPL is non-tainting, because the code is also available
under the GPL.  Anybody taking advantage of the BSD no adv license to
create a binary only module will be tainted.

That causes a problem for some modules in the kernel tree that have the
BSD no advert license.  Ideally these should be changed to dual BSD/GPL
but that may not be possible.  Since their source code is always
available, we might change them to

  "BSD without advertisement clause, source is in the kernel tree"

and add that string to the non-tainting list.  BSD no advert code that
is not in the kernel tree can either switch to dual BSD/GPL or be
tainted, at the choice of the supplier.

The affected code in the kernel tree is

drivers/net/bsd_comp.c
drivers/net/pcmcia/wavelan_cs.c
drivers/net/ppp_deflate.c
drivers/net/slhc.c
drivers/net/strip.c
drivers/scsi/advansys.c
drivers/scsi/dpt_i2o.c
drivers/scsi/pci2000.c
drivers/scsi/pci2220i.c
drivers/scsi/u14-34f.c
fs/nls/nls_cp1251.c
fs/nls/nls_cp1255.c
fs/nls/nls_cp437.c
fs/nls/nls_cp737.c
fs/nls/nls_cp775.c
fs/nls/nls_cp850.c
fs/nls/nls_cp852.c
fs/nls/nls_cp855.c
fs/nls/nls_cp857.c
fs/nls/nls_cp860.c
fs/nls/nls_cp861.c
fs/nls/nls_cp862.c
fs/nls/nls_cp863.c
fs/nls/nls_cp864.c
fs/nls/nls_cp865.c
fs/nls/nls_cp866.c
fs/nls/nls_cp869.c
fs/nls/nls_cp874.c
net/ipv4/netfilter/ipchains_core.c

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Alan Cox]

> and add that string to the non-tainting list.  BSD no advert code that
> is not in the kernel tree can either switch to dual BSD/GPL or be
> tainted, at the choice of the supplier.

BSD no advertising with no patent issues (and therefore compliant) linked
with GPL code ends up as GPL anyway, so I don't see the problem in using
the dual BSD/GPL tag

Alan

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Alan Cox]

> exclusive right granted to authors that is within Linus' legal power as holder
> of the Copyright to the kernel to grant or to restrict.  Does Microsoft have
> a legal right to disallow any third-party drivers from 
> registering themselves with the OS?  Does Linus?

If they are derivative works - yes.

MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Keith Owens]

That has been a lot of uninformed and confused comment on l-k about
MODULE_LICENSE and EXPORT_SYMBOL_GPL.  I will try to make this as
simple as possible, to improve the signal to noise ration on this list.

Don't bother cc'ing me on any replies.  Also I don't care what your
view of the GPL is or should be.

MODULE_LICENSE

MODULE_LICENSE() allows kernel developers to identify kernels that have
been tainted by modules whose source code is not generally available.
No source code means that only the supplier can debug the problem so
send the bug report to them, not l-k.  Precisely which license string
indicates that source is freely available is still being fine tuned.

A module without a license must be assumed to be proprietary.  Not all
existing modules have a MODULE_LICENSE() yet but most do, the rest are
not far behind.  For code that is not in the standard kernel tree, it
is up to the supplier to set the license string accordingly.  I
recommend that binary only modules contain a string like :-

  MODULE_LICENSE("Proprietary.  Send bug reports to joe.bloggs@somewhere")

Modutils marks the kernel as tainted when it loads a module without a
GPL compatible MODULE_LICENSE(), reporting the license string so users
know where to send bug reports.  Oops reports the tainted status of the
kernel.  Kernel developers can decide if they want to look at tainted
bug reports or not.  End of story.

Somebody raised the red herring of linking proprietary code into the
kernel.  If you compile and link code into the kernel and do not
provide the source then you cannot distribute the resulting kernel.  To
do so is a breach of GPL conditions, read the GPL if you don't believe
me.  There is nothing to stop you building your own kernel with binary
only code and using it internally, but any bugs are your problem and
you cannot distribute the result.

EXPORT_SYMBOL_GPL

Some kernel developers are unhappy with providing external interfaces
to their code, only to see those interfaces being used by binary only
modules.  They view it as their work being appropriated.  Whether you
agree with that view or not is completely irrelevant, the person who
owns the copyright decides how their work can be used.

EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
available to modules with a GPL compatible license.  This is
independent of the kernel tainting, but obviously takes advantage of
MODULE_LICENSE() strings.

EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus
has spoken.  I believe the phrase involved killer penguins with
chainsaws for anybody who changed existing exported interfaces.

System calls are not affected and cannot be, that is yet another red
herring.  Anybody who thinks otherwise does not understand the GPL.
System calls define how user space code accesses the kernel, nobody
pretends that a binary only user space program cannot use a syscall.

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Alexander Viro]

On Thu, 18 Oct 2001, Keith Owens wrote:

> EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus
> has spoken.  I believe the phrase involved killer penguins with
> chainsaws for anybody who changed existing exported interfaces.

... and if somebody thinks that replacing

int foo(void *bar);
plus
EXPORT_SYMBOL(foo);

with

int __foo(void *bar, int baz);
static int foo(void *bar)
{
	return __foo(bar, 0);
}
plus
EXPORT_SYMBOL_GPL(__foo);

is going to save you from aforementioned killer penguins, keep in mind
that there are worse and slower ways to go and you might not like learning
them first-hand.

				Al "have pincer, will travel" Viro

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Kai Henningsen]

kaos@ocs.com.au (Keith Owens)  wrote on 18.10.01 in <8658.1003375433@kao2.melbourne.sgi.com>:

> EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
> available to modules with a GPL compatible license.  This is
> independent of the kernel tainting, but obviously takes advantage of
> MODULE_LICENSE() strings.

Incidentally, an argument can be made that using EXPORT_SYMBOL_GPL  
actually renders your code incompatible with the GPL, insofar as it  
violates the "additional restriction" clause. Which doesn't matter as long  
as it's *only* your code (author can always do different things), but  
*does* matter if you add *other* people's GPL code (such as the rest of  
the kernel), because it's *their* GPL that you're breaking ...

MfG Kai

Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL

[Nils Philippsen]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

On Fri, 2001-10-19 at 09:16, Kai Henningsen wrote:
> kaos@ocs.com.au (Keith Owens)  wrote on 18.10.01 in <8658.1003375433@kao2.melbourne.sgi.com>:
> 
> > EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only
> > available to modules with a GPL compatible license.  This is
> > independent of the kernel tainting, but obviously takes advantage of
> > MODULE_LICENSE() strings.
> 
> Incidentally, an argument can be made that using EXPORT_SYMBOL_GPL  
> actually renders your code incompatible with the GPL, insofar as it  
> violates the "additional restriction" clause. Which doesn't matter as long  
> as it's *only* your code (author can always do different things), but  
> *does* matter if you add *other* people's GPL code (such as the rest of  
> the kernel), because it's *their* GPL that you're breaking ...

[IANAL]

Not the least -- there is no such thing as code "(in)compatible with the
GPL" -- you can alter (or write) GPLed code to do (or don't do) anything
you want when it comes to the GPL. The additional restrictions provision
in the GPL you talk about means restrictions in licensing, not technical
ones. For what it's worth I could alter the glibc to not work when used
by a process called "acroread" or "vmware" or whatever (not that that
would make sense) and still be in full compliance with the GPL as long
as I adhere to the GPL when distributing it.

Nils
-- 
 Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg //
+49.7152.209647
nils@wombat.dialup.fht-esslingen.de / nils@redhat.de /
nils@fht-esslingen.de
        Ever noticed that common sense isn't really all that common?

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]