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.
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
'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.
> 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"....
'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?
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.
On Thu, 2001-10-18 11:43:15 -0500, Roy Murphy <[email protected]>
wrote in message <[email protected]>:
> '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 . [email protected] . +49-172-7608481
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
[email protected] Lindon, UT 84042
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 <[email protected]>
> To: [email protected]
> Subject: Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL
>
> On Thu, 2001-10-18 11:43:15 -0500, Roy Murphy <[email protected]>
> wrote in message <[email protected]>:
> > '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 . [email protected] . +49-172-7608481
> -
> 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/
>
On Thu, 18 Oct 2001 15:38:36 -0700 (PDT), David Lang
<[email protected]> 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
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 <[email protected]>
> To: David Lang <[email protected]>
> Cc: [email protected]
> Subject: Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL
>
> On Thu, 18 Oct 2001 15:38:36 -0700 (PDT), David Lang
> <[email protected]> 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
>
[email protected] (Keith Owens) wrote on 18.10.01 in <[email protected]>:
> 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
On Fri, 2001-10-19 at 09:16, Kai Henningsen wrote:
> [email protected] (Keith Owens) wrote on 18.10.01 in <[email protected]>:
>
> > 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
[email protected] / [email protected] /
[email protected]
Ever noticed that common sense isn't really all that common?
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
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 <[email protected]>
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
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 <[email protected]>
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
'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.
[email protected] 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
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 <[email protected]>
> To: David Lang <[email protected]>
> Cc: [email protected]
> 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
>
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
On Fri, 19 Oct 2001 13:07:37 -0700 (PDT),
David Lang <[email protected]> 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
> 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
> 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
> 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.
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 <[email protected]>
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