The symbol 'mcount' has EXPORT_SYMBOL_GPL attached to it. This is because
"things that use this symbol are too chummy with kernel internals to not be
derivative". However, the symbol may or may not actually be referenced by a
given module, depending on the setting of CONFIG_FTRACE. This leads to an
interesting result: The module may or may not be too chummy depending on a
variable outside its control, and the module source code doesn't have any say
in the matter. So we have a .c file that *is* a derivative work if the kernel
is built one way, and is *not* if the kernel is built another. Worse yet,
it *also* depends at runtime on the setting of /proc/sys/kernel/ftrace_enabled
But it's the SAME EXACT SOURCE. And since the source file isn't called
schrodinger.c, I believe the following patch is in order..
(As an aside, arch/um/kernel/gprof_syms.c already lists mcount as a
SYMBOL, not a SYMBOL_GPL - yet another inconsistency.
Signed-off-by: Valdis Kletnieks <[email protected]>
---
--- linux-2.6.25-rc2-mm1/kernel/trace/ftrace.c.dist 2008-02-16 23:34:36.000000000 -0500
+++ linux-2.6.25-rc2-mm1/kernel/trace/ftrace.c 2008-02-25 12:00:57.000000000 -0500
@@ -44,7 +44,7 @@ static struct ftrace_ops *ftrace_list __
ftrace_func_t ftrace_trace_function __read_mostly = ftrace_stub;
/* mcount is defined per arch in assembly */
-EXPORT_SYMBOL_GPL(mcount);
+EXPORT_SYMBOL(mcount);
notrace void ftrace_list_func(unsigned long ip, unsigned long parent_ip)
{
[ added Alan to CC ]
[email protected] wrote:
> The symbol 'mcount' has EXPORT_SYMBOL_GPL attached to it. This is because
> "things that use this symbol are too chummy with kernel internals to not be
> derivative". However, the symbol may or may not actually be referenced by a
> given module, depending on the setting of CONFIG_FTRACE. This leads to an
> interesting result: The module may or may not be too chummy depending on a
> variable outside its control, and the module source code doesn't have any say
> in the matter. So we have a .c file that *is* a derivative work if the kernel
> is built one way, and is *not* if the kernel is built another. Worse yet,
> it *also* depends at runtime on the setting of /proc/sys/kernel/ftrace_enabled
>
> But it's the SAME EXACT SOURCE. And since the source file isn't called
> schrodinger.c, I believe the following patch is in order..
>
> (As an aside, arch/um/kernel/gprof_syms.c already lists mcount as a
> SYMBOL, not a SYMBOL_GPL - yet another inconsistency.
>
The reason I added GPL is not because of some idea that this is all
"chummy" with the kernel. But because I derived the mcount code from
glibc's version of mcount. Now you may argue that glibc is under LGPL
and a non-GPL export is fine. But I've been advised that if I ever take
code from someone else, to always export it with GPL.
-- Steve
> The reason I added GPL is not because of some idea that this is all
> "chummy" with the kernel. But because I derived the mcount code from
> glibc's version of mcount. Now you may argue that glibc is under LGPL
> and a non-GPL export is fine. But I've been advised that if I ever take
> code from someone else, to always export it with GPL.
As I understand it if Vladis wants to submit his own change to the symbol
thats up to him, and he'll be liable for any fallout with the FSF, or
harm to Linux resulting, so long he's the one who signs it off.
If its FSF code perhaps it would be polite for Vladis to ask the FSF
first if he wants to do it nicely.
Alan
On Mon, Feb 25, 2008 at 06:19:57PM +0000, Alan Cox wrote:
> > The reason I added GPL is not because of some idea that this is all
> > "chummy" with the kernel. But because I derived the mcount code from
> > glibc's version of mcount. Now you may argue that glibc is under LGPL
> > and a non-GPL export is fine. But I've been advised that if I ever take
> > code from someone else, to always export it with GPL.
>
> As I understand it if Vladis wants to submit his own change to the symbol
> thats up to him, and he'll be liable for any fallout with the FSF, or
> harm to Linux resulting, so long he's the one who signs it off.
>...
Why isn't anyone distributing it liable if it is not legally correct?
> Alan
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Feb 25, 2008 at 09:27:10PM +0200, Adrian Bunk wrote:
> > As I understand it if Vladis wants to submit his own change to the symbol
> > thats up to him, and he'll be liable for any fallout with the FSF, or
> > harm to Linux resulting, so long he's the one who signs it off.
>
> Why isn't anyone distributing it liable if it is not legally correct?
They may well be, but they all get to sue Vladis in turn
Alan
On Mon, Feb 25, 2008 at 02:48:35PM -0500, Alan Cox wrote:
> On Mon, Feb 25, 2008 at 09:27:10PM +0200, Adrian Bunk wrote:
> > > As I understand it if Vladis wants to submit his own change to the symbol
> > > thats up to him, and he'll be liable for any fallout with the FSF, or
> > > harm to Linux resulting, so long he's the one who signs it off.
> >
> > Why isn't anyone distributing it liable if it is not legally correct?
>
> They may well be, but they all get to sue Vladis in turn
Being able to sue someone who has so many lawsuits that there's anyway
no money left for me sounds like a bad compensation for serving a few
years in jail... [1]
> Alan
cu
Adrian
[1] OK, realistically that's not enough for a jail sentence
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Feb 25, 2008 at 10:09:03PM +0200, Adrian Bunk wrote:
> Being able to sue someone who has so many lawsuits that there's anyway
> no money left for me sounds like a bad compensation for serving a few
> years in jail... [1]
If the FSF wrote the code then he should ask the FSF, that seems simple
enough to me.
On Mon, 25 Feb 2008 21:27:10 +0200, Adrian Bunk said:
> On Mon, Feb 25, 2008 at 06:19:57PM +0000, Alan Cox wrote:
(Following was actually Steve Rostedt writing):
> > > The reason I added GPL is not because of some idea that this is all
> > > "chummy" with the kernel. But because I derived the mcount code from
> > > glibc's version of mcount. Now you may argue that glibc is under LGPL
> > > and a non-GPL export is fine. But I've been advised that if I ever take
> > > code from someone else, to always export it with GPL.
Did the person giving that advice say that was OK, even with code that
originally had a more permissive license, such as the LGPL code from glibc?
> > As I understand it if Vladis wants to submit his own change to the symbol
> > thats up to him, and he'll be liable for any fallout with the FSF, or
> > harm to Linux resulting, so long he's the one who signs it off.
> >...
>
> Why isn't anyone distributing it liable if it is not legally correct?
Particularly since there isn't any *real* legal distinction between the EXPORT
and EXPORT_GPL - anybody who can cite actual case law, rather than just "we
kernel nerds think and our lawyers mumble" is invited to do so. In the case of
'mcount', we're specifically talking about a symbol that's only referenced
*because the kernel's include files and config tell it to*. It's not even a
reference the code includes - it's a reference included *BY THE COMPILER*.
I'd love to see how you'd argue this in court - "Your honor, this static piece
of source code is infringing on our copyright as a derivative work, even though
it in no way shape or form references the symbol, depending on a compiler flag,
which is out of the code author's control".
Based on that, I'd have to say that the actual abuse of the GPL, if any,
lies with the maintainers of GCC, since gcc is what created the reference to
the problematic symbol, not the authors of the actual source code.
> The reason I added GPL is not because of some idea that this is all
> "chummy" with the kernel. But because I derived the mcount code from
> glibc's version of mcount. Now you may argue that glibc is under LGPL
> and a non-GPL export is fine. But I've been advised that if I ever take
> code from someone else, to always export it with GPL.
>
> -- Steve
I don't know who told you that or why, but it's obvious nonsense, as this
issue shows. Exports should be marked GPL if and only if they cannot be used
except in a derivative work. If it is possible to use them without taking
sufficient protectable expression, they should not be marked GPL.
This was what everyone agreed to when GPL exports were created.
DS
> I don't know who told you that or why, but it's obvious nonsense, as this
> issue shows. Exports should be marked GPL if and only if they cannot be used
> except in a derivative work. If it is possible to use them without taking
> sufficient protectable expression, they should not be marked GPL.
>
> This was what everyone agreed to when GPL exports were created.
No it wasn't.
Alan
"David Schwartz" <[email protected]> writes:
> I don't know who told you that or why, but it's obvious nonsense,
Correct.
> Exports should be marked GPL if and only if they cannot be used
> except in a derivative work. If it is possible to use them without taking
> sufficient protectable expression, they should not be marked GPL.
This isn't very obvious to me.
The licence doesn't talk about GPL or non-GPL exports. It doesn't
restrict the use, only distribution of the software. One is free to
remove _GPL from the code and distribute it anyway (except perhaps for
some DMCA nonsense).
If a code is a derivative work it has to be distributed (use is not
restricted) under GPL, EXPORT _GPL or not _GPL.
One may say _GPL is a strong indication that all users are
automatically a derivative works, but it's only that - indication. It
doesn't mean they are really derivative works and it doesn't mean a
module not using any _GPL exports isn't a derivative.
I think introducing these _GPL symbols was a mistake in the first place.
--
Krzysztof Halasa
> One may say _GPL is a strong indication that all users are
> automatically a derivative works, but it's only that - indication. It
> doesn't mean they are really derivative works and it doesn't mean a
> module not using any _GPL exports isn't a derivative.
Actually I think the _GPL exports are really harmful - somebody
distributing a binary module may claim he/she doesn't violate the GPL
because the module uses only non-GPL exports. OTOH GPL symbols give
_us_ exactly nothing.
--
Krzysztof Halasa
On Tue, Feb 26, 2008 at 06:04:51PM +0100, Krzysztof Halasa wrote:
> Actually I think the _GPL exports are really harmful - somebody
> distributing a binary module may claim he/she doesn't violate the GPL
> because the module uses only non-GPL exports. OTOH GPL symbols give
They can claim that anyway. The can claim to be alien life forms too. Claim
is not the same as legal decision. From what I've seen its helped make binary
module abusers more cautious.
Alan
Alan Cox <[email protected]> writes:
>> Actually I think the _GPL exports are really harmful - somebody
>> distributing a binary module may claim he/she doesn't violate the GPL
>> because the module uses only non-GPL exports. OTOH GPL symbols give
>
> They can claim that anyway. The can claim to be alien life forms too. Claim
> is not the same as legal decision.
Sure but it may be now easier to convince the judge they are right. Of
course if they aren't using GPL exports - if they are, perhaps harder.
> From what I've seen its helped make binary
> module abusers more cautious.
Those not using _GPL exports?
--
Krzysztof Halasa
> > From what I've seen its helped make binary
> > module abusers more cautious.
>
> Those not using _GPL exports?
In general. To be honest there is very little binary only stuff left now
> "David Schwartz" <[email protected]> writes:
> > I don't know who told you that or why, but it's obvious nonsense,
> Correct.
> > Exports should be marked GPL if and only if they cannot be used
> > except in a derivative work. If it is possible to use them
> > without taking
> > sufficient protectable expression, they should not be marked GPL.
> This isn't very obvious to me.
It may not be obvious, but it is the design and purpose of marking exports
GPL.
> The licence doesn't talk about GPL or non-GPL exports. It doesn't
> restrict the use, only distribution of the software. One is free to
> remove _GPL from the code and distribute it anyway (except perhaps for
> some DMCA nonsense).
That's true. The DMCA doesn't prevent it, since marking symbols is *not* a
license enforcement mechanism.
> If a code is a derivative work it has to be distributed (use is not
> restricted) under GPL, EXPORT _GPL or not _GPL.
Of course.
> One may say _GPL is a strong indication that all users are
> automatically a derivative works, but it's only that - indication. It
> doesn't mean they are really derivative works and it doesn't mean a
> module not using any _GPL exports isn't a derivative.
Of course. (The only people who argue otherwise are the 'linking makes a
derivative work' idiots.)
> I think introducing these _GPL symbols was a mistake in the first place.
Perhaps, since people seem to be trying to refight the same battles again.
The agreement made when the feature was added was that EXPORT_GPL was not a
license enforcement mechanism but was an indication that someone believed
that any use of the symbol was possible only a derivative work that would
need to be distributed under the GPL.
> Actually I think the _GPL exports are really harmful - somebody
> distributing a binary module may claim he/she doesn't violate the GPL
> because the module uses only non-GPL exports.
Anyone can argue anything. That would be an obviously stupid argument.
Perhaps clearer documentation might be helpful, but the GPL speaks for
itself.
> OTOH GPL symbols give
> _us_ exactly nothing.
They serve as a warning and, as a practical matter, may make it a bit more
difficult to violate the license.
DS
"David Schwartz" <[email protected]> writes:
> The agreement made when the feature was added was that EXPORT_GPL was not a
> license enforcement mechanism but was an indication that someone believed
> that any use of the symbol was possible only a derivative work that would
> need to be distributed under the GPL.
But the above gives us nothing.
*If* any use of non-GPL symbols only by a binary module was ok then it
would make sense.
>> Actually I think the _GPL exports are really harmful - somebody
>> distributing a binary module may claim he/she doesn't violate the GPL
>> because the module uses only non-GPL exports.
>
> Anyone can argue anything. That would be an obviously stupid argument.
> Perhaps clearer documentation might be helpful, but the GPL speaks for
> itself.
Not sure if the court would share this opinion.
Defendant: my module doesn't use any GPL-only export!
Plaintiff: but using XXX normal symbol is a violation too!
D: so why have you created that _GPL thing exactly?
Additionally:
D: top of the COPYING file explicity states binary modules are ok.
This is of course fine if we consider normal use of non-GPL-only
symbols ok.
> They serve as a warning and, as a practical matter, may make it a bit more
> difficult to violate the license.
Technically only.
I have to agree with Alan that the list of non-GPL modules only is
quite tiny nowadays. Madwifi is in terminal state, ATI is opening the
docs and working on GPL driver, modem drivers are mostly thing of
the past, NVidias will probably be supported by the open source driver
soon even if they don't open their code.
Embedded devices have full Linux, not just modules.
--
Krzysztof Halasa
> "David Schwartz" <[email protected]> writes:
> > The agreement made when the feature was added was that
> > EXPORT_GPL was not a
> > license enforcement mechanism but was an indication that
> > someone believed
> > that any use of the symbol was possible only a derivative work
> > that would
> > need to be distributed under the GPL.
> But the above gives us nothing.
> *If* any use of non-GPL symbols only by a binary module was ok then it
> would make sense.
I don't buy your argument. It's essentially saying that a scheme that can't
detect all possible problems is useless, even if it can detect some
problems.
> >> Actually I think the _GPL exports are really harmful - somebody
> >> distributing a binary module may claim he/she doesn't violate the GPL
> >> because the module uses only non-GPL exports.
> > Anyone can argue anything. That would be an obviously stupid argument.
> > Perhaps clearer documentation might be helpful, but the GPL speaks for
> > itself.
> Not sure if the court would share this opinion.
> Defendant: my module doesn't use any GPL-only export!
> Plaintiff: but using XXX normal symbol is a violation too!
> D: so why have you created that _GPL thing exactly?
This is akin to "Maybe I was swerving, but I must have been driving safely
because I wasn't drunk". Everyone who drives drunk isn't safe, but it
doesn't follow that you're safe just because you're not drunk.
This is an obviously-wrong argument, and the fact that someone can make it
isn't interesting. People can make all kinds of obviously-wrong arguments.
Maybe this is a documentation issue.
The GPL exports mark symbols that someone felt could not be used in a
non-derivative work, "intimate details" if you like. But whether or not
something is a derivative work is a pure question of copyright law and the
nature of what was taken. (One could make an argument that not marking
symbols acts as some kind of estoppel against later arguing that just
minimally using that symbol can't make your work a derivative. It's possible
a judge might by that argument, but if so, how is that unreasonable?)
> Additionally:
> D: top of the COPYING file explicity states binary modules are ok.
I don't think anybody really knows what legal effect that will have. I can
speculate, but I don't know that my speculations are particularly
interesting. If anyone wants my analysis of that, feel free to email me
off-list.
> This is of course fine if we consider normal use of non-GPL-only
> symbols ok.
It's fine either way. Whatever you feel about non-GPL-only symbols, there's
nothing wrong with marking some symbols that, in the opinion of their
copyright holders, cannot be used by non-derivative works. If this is what
the GPL symbol marking does (which is what was agreed to when it was added)
then there's no harm.
> > They serve as a warning and, as a practical matter, may make it
> > a bit more
> > difficult to violate the license.
> Technically only.
All you can do in code is implement technical things. You cannot enforce or
implement the license because the GPL prohibits that.
> I have to agree with Alan that the list of non-GPL modules only is
> quite tiny nowadays. Madwifi is in terminal state, ATI is opening the
> docs and working on GPL driver, modem drivers are mostly thing of
> the past, NVidias will probably be supported by the open source driver
> soon even if they don't open their code.
>
> Embedded devices have full Linux, not just modules.
If you're arguing that GPL symbol export has outlived its usefulness, that
might be true. I don't really have an opinion one way or the other.
DS
"David Schwartz" <[email protected]> writes:
> This is an obviously-wrong argument,
Even if it's proven wrong in the end, the defendant may at least be
found acting in a good faith.
> All you can do in code is implement technical things.
The GPL itself is the weapon, not the technical measures which can be
legally trivially disabled (even if the modules are illegal).
> You cannot enforce or
> implement the license because the GPL prohibits that.
Not sure what do you mean. I was under impression that a copyright
holder can enforce GPL :-)
--
Krzysztof Halasa
> "David Schwartz" <[email protected]> writes:
> > This is an obviously-wrong argument,
> Even if it's proven wrong in the end, the defendant may at least be
> found acting in a good faith.
If they were in fact acting in good faith, they should be found to have been
acting in good faith. If you think this reasonably might result in
confusion, the solution is better documentation.
> > All you can do in code is implement technical things.
> The GPL itself is the weapon, not the technical measures which can be
> legally trivially disabled (even if the modules are illegal).
Right.
> > You cannot enforce or
> > implement the license because the GPL prohibits that.
> Not sure what do you mean. I was under impression that a copyright
> holder can enforce GPL :-)
I mean you can't enforce or implement the license in code because the GPL
specifically permits modification without exclusion. Someone cannot use the
GPL to force you to use code you do not wish to use. The GPL does not
contain any technical enforcement mechanism and would not permit one because
it would be a "further restriction" (it's a restriction, it's not in the
GPL, so it's further).
Perhaps some kind of technical rule that didn't prohibit anything the GPL
allowed might be a legitimate license enforcement scheme, not restricting
anything "further". That's a stretch, but the GPL symbol tagging doesn't
apply since it prohibits non-GPL modules from using those symbols even if
they are not distibuted. This is not a restriction found in the GPL, so it's
a "further restriction". (Which is fine. Not being able to remove any file
as 'root' is a restriction not found in the GPL too. The point is, these are
technical restrictions, not license enforcement mechanisms.)
DS
On Wed, Feb 27, 2008 at 12:13:31AM +0100, Krzysztof Halasa wrote:
> Additionally:
> D: top of the COPYING file explicity states binary modules are ok.
Nope.
Please stop pedalling complete fiction
Alan Cox <[email protected]> writes:
>> D: top of the COPYING file explicity states binary modules are ok.
>
> Nope.
Right. Must have been somewhere else.
--
Krzysztof Halasa