Submitted by Jeremy Andrews on Thursday, April 04, 2002 - 16:20
Another interesting debate recently ensued on the lkml, this time with kernel guru Alan Cox in the middle. The topic was related to the GPL (hence the emotions involved), though specifically referring to the changing of an EXPORT_SYMBOL_GPL flag to EXPORT_SYMBOL. Among the questions raised is whether this infringes upon a developer's rights...
Much of the debate follows, involving many kernel notables, including Andrea Arcangeli, Alan Cox, Rik van Riel, Ingo Molnar, and Linus Torvalds. Many good points are raised on both sides of the issue, making for an interesting read...
--------------------------------------------------------------------------------
From: Andrea Arcangeli
Cc: linux-kernel-mailing-list
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 18:21:18 +0200
On Wed, Feb 20, 2002 at 11:01:27AM -0500, Arjan van de Ven wrote:
> Now if it should be EXPORT_SYMBOL or EXPORT_SYMBOL_GPL() I leave to Ingo
It has to be EXPORT_SYMBOL. Requiring non GPL drivers to walk pagetables
by hand is pointless. we should definitely recommend those driver
authors to use vmalloc_to_page, in particular if the drivers are not
GPL.
To see it in another way If we make vmalloc_to_page linkable only by GPL
drivers, then we should do the same with all the other functionalities
too starting from map_user_kiobuf etc...
Infact I'm not really sure the _GPL tag makes sense in the first place.
If an interface shouldn't be used by a binary only module, why should it
be used by a GPL module? It doesn't make any sense to me, of course
I'm looking at it from a technical prospective. If your grand plan is to
forbid a non GPL module to call vmalloc/kmalloc/alloc_pages, then the
non GPL module developer will be in great pain I see, but that still
doesn't make any sense to me because the rule is that binary only
modules are legal. Not that I will ever use binary only modules myself,
not that I will ever do anything to help binary only modules, but I
don't either do anything to explicitly hurt them, I just ignore them.
--- 2.4.19pre5aa1/kernel/ksyms.c.~1~ Sun Mar 31 03:37:18 2002
+++ 2.4.19pre5aa1/kernel/ksyms.c Wed Apr 3 17:53:29 2002
@@ -114,7 +114,7 @@
EXPORT_SYMBOL(kfree);
EXPORT_SYMBOL(vfree);
EXPORT_SYMBOL(__vmalloc);
-EXPORT_SYMBOL_GPL(vmalloc_to_page);
+EXPORT_SYMBOL(vmalloc_to_page);
#ifndef CONFIG_DISCONTIGMEM
EXPORT_SYMBOL(contig_page_data);
EXPORT_SYMBOL(mem_map);
Andrea
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 18:43:10 +0100 (BST)
> EXPORT_SYMBOL(vfree);
> EXPORT_SYMBOL(__vmalloc);
> -EXPORT_SYMBOL_GPL(vmalloc_to_page);
> +EXPORT_SYMBOL(vmalloc_to_page);
The authors of that code made it GPL. You have no right to change that. Its
exactly the same as someone taking all your code and making it binary only.
You are
- subverting a digital rights management system [5 years jail in the USA] - breaking a license
but worse than that you are ignoring the basic moral rights of the authors
of that code.
Alan
From: Andrea Arcangeli
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 20:13:22 +0200
On Wed, Apr 03, 2002 at 06:43:10PM +0100, Alan Cox wrote:
> The authors of that code made it GPL. You have no right to change that. Its
> exactly the same as someone taking all your code and making it binary only.
>
> You are
> - subverting a digital rights management system
> [5 years jail in the USA]
> - breaking a license
>
> but worse than that you are ignoring the basic moral rights of the authors
> of that code.
The vmalloc_to_page function is been patched into the kernel without any
special restriction or requirement for such code, there is not a single
comment about a change of licence (infact it's probably been cut and
pasted from one of the dozen of device drivers doing that by hand
previously, just changing the retval to a struct page, so changing the
licence would been probably illegal from your part in the first place).
Now from your comment it seems with your _GPL tag you meant to give
special licence to the function, that is not obvious at all, I don't
find it written anywhere, not even in your above email, so I recommend
you to licence your code properly ASAP if you don't want to use the
standard licence of the kernel code (like bsdcomp and other piece of
sourcecode deos).
Also please realize that you are ridicolous posting emails like the
above, any real lawyer will laught at you if you pretend me to go in
jail for 5 years in the US because you think such a "_GPL" four letters
in ksyms.c enforce in a court a different licence in a function in
memory.c covered by the usual kern
el license (like map_user_kiobuf),
despite there is not a single line of english out there written by the
author to confirm your assumption. Not even a kernel hacker can guess
you meant to change the licence of the code if you don't even write a
line about a change of licence anywhere, period. Not even there is
written anywhere in the kernel that such _GPL tags are meant to change
the licence.
Infact it's the other way around, if the author of vmalloc_to_page
wanted really to change the licence as it seems while reading your above
email (not confirmed yet), as soon as he documents his request properly,
I will tell him that I refuse him to do that, I'm one of the authors of
memory.c so that is my right to enforce it, as it was my right for Linus
to refuse my code if I wanted to use a difference licence. The reason I
refuse a change of licence for a basic functionality in memory.c, is
that those are lawyers tricks that can only hurt linux. If everybody
that writes a function starts crying like you did above it will be a
true mess, and at the very least such kind of tricks should be put in a
separate file.
So if you want to change the module licensing and avoid binary only
drivers, go and ask all the copyright holders to agree on that, once you
have the agreement Linus can release a new kernel tarball with the new
licence for all the normal kernel code, i.e. pure GPL. But for the core
kernel code it must be possible to intermix it without worrying about
licensing issues, so no special licences within memory.c, I will enforce
that, period.
If there's any expert out there that can check the correctness of what I
said I'd be grateful, thanks.
Andrea
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 20:11:49 +0100 (BST)
> The vmalloc_to_page function is been patched into the kernel without any
> special restriction or requirement for such code, there is not a single
Untrue.
> comment about a change of licence (infact it's probably been cut and
> pasted from one of the dozen of device drivers doing that by hand
All of them GPL none of them exporting it to non GPL users. That code is
and always was GPL. Nor is it an interface for random binary authors. That
vmalloc handling code took a lot of work, binary authors can go and write
their own.
> have the agreement Linus can release a new kernel tarball with the new
> licence for all the normal kernel code, i.e. pure GPL. But for the core
Every single line of code I ever submitted to Linus is -pure- GPL. It bears
a GPL header. That includes my part of the vmalloc_to_page work. It has
never been available to non GPL modules. You took code I and many others
own and exposed it as a library for non GPL users. If they use it that way
they are violating copyright law, and they *will* get cease and desist
letters.
Anyone using any code of mine in the kernel with non GPL code does so on
the basis of the legal doctrine of what is or is not a derivative work,
and they do so on their own legal assessment. Taking code I am one of the
authors of and making it convenient for people like veritas to use in non
GPL code is quite different. Its theft plain and simple.
Alan
From: Andrea Arcangeli
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 21:23:15 +0200
On Wed, Apr 03, 2002 at 08:11:49PM +0100, Alan Cox wrote:
> Untrue.
Please, go ahead and tell me _where_ the conditions for copying and
using such code are been written and why such code licence is different
from map_user_kiobuf. I check the memory.c file in 2.4.19pre5 and
nothing is written about those special restrictions.
> All of them GPL none of them exporting it to non GPL users. That code is
> and always was GPL. Nor is it an interface for random binary authors. That
> vmalloc handling code took a lot of work, binary authors can go and write
such vmalloc_to_page function takes 5 minutes to rewrite, that's not
lots of work in my vocabulary but anyways "how hard the code is to
write" doesn't matter with the rest of the discussion.
> Every single line of code I ever submitted to Linus is -pure- GPL. It bears
> a GPL header. That includes my part of the vmalloc_to_page work. It has
> never been available to non GPL modules. You took code I and many others
> own and exposed it as a library for non GPL users. If they use it that way
> they are violating copyright law, and they *will* get cease and desist
> letters.
>
> Anyone using any code of mine in the kernel with non GPL code does so on
> the basis of the legal doctrine of what is or is not a derivative work,
> and they do so on their own legal assessment. Taking code I am one of the
> authors of and making it convenient for people like veritas to use in non
> GPL code is quite different. Its theft plain a
nd simple.
What is plain and simple is that since you didn't wrote a single line
about it, there cannot be any licence difference between your
vmalloc_to_page in 2.4.19pre5 and map_user_kiobuf.
Furthmore exposing the function to binary only devices, doesn't mean I
will even link a binary only device with it, and nevertheless I won't
because I don't use binary only drivers, but again this is not the main
topic.
Andrea
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 21:05:58 +0100 (BST)
On Wed, 3 Apr 2002, Alan Cox wrote:
> Taking code I am one of the authors of and making it convenient for
> people like veritas to use in non GPL code is quite different. Its
> theft plain and simple.
Alan,
I don't want to try your patience but I have to emphasize that:
yes, it should be authors decision (completely agree with you there!)
whether a symbol is exported or not and whether it should be exported to
all modules or only to some "internal/kernel" modules. But this is a
technical issue, nothing to do with legalities/licenses or author's likes
or dislikes of binary modules.
But if the author's decision is based on a statement similar to "I spent N
hours writing this function, it's okay to let GPL modules use it but no
way I'll let the nasty veritas-like people use it", then I feel something
is wrong somewhere. Then perhaps we could even refine the API to have
EXPORT_SYMBOL_FRIENDS(sym,list_of_friends)
where only "friends" can use the symbol and even then only if they first
call (an exported function):
register_export_payment(sym, sum);
where 'sum' depends on the number of hours spent on writing sym().
I feared that perhaps I misunderstood the meaning of EXPORT_SYMBOL_GPL but
in the other "instance" of this thread Linus did confirm that it was
correct.
Regards,
Tigran
PS. unimportant detail for curious listeners on linux-kernel -- Veritas
doesn't actually need vmalloc_to_page exported in any manner or form.
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 22:22:00 +0100 (BST)
> is wrong somewhere. Then perhaps we could even refine the API to have
>
> EXPORT_SYMBOL_FRIENDS(sym,list_of_friends)
>
> where only "friends" can use the symbol and even then only if they first
> call (an exported function):
Swap "friends" from people to code then its interesting
eg I'd love to be able to do
EXPORT_SYMBOL_TO(sym, "i2o*.o");
for the i2o code and know that nobody is going to try and use those routines
for non i2o stuff thinking "that looks handy".
I'm not sure if its that managable, _INTERNAL works for a lot of things from
my point of view. Knowing what is and isnt claimed to be an interface helps
so much. Complicating it seems to have few extra payoffs
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 22:26:34 +0100 (BST)
On Wed, 3 Apr 2002, Alan Cox wrote:
> eg I'd love to be able to do
> EXPORT_SYMBOL_TO(sym, "i2o*.o");
>
> for the i2o code and know that nobody is going to try and use those routines
> for non i2o stuff thinking "that looks handy".
yes, I did imply two parts: serious (the "to some modules only") and
joking (the one where kernel decides whether a module is "worthy" based on
its license). Arjan also pointed out in a private email that such
interface would be helpful in splitting things into multiple modules.
>
> I'm not sure if its that managable, _INTERNAL works for a lot of things from
> my point of view. Knowing what is and isnt claimed to be an interface helps
> so much. Complicating it seems to have few extra payoffs
>
I agree. The only thing where I disagree is that I think EXPORT_SYMBOL_GPL
is not really useful if understood literally, but if it is understood as
EXPORT_SYMBOL_INTERNAL then it should be called EXPORT_SYMBOL_INTERNAL.
I.e. not _INTERNAL + _GPL but only _INTERNAL.
Why is EXPORT_SYMBOL_GPL not so useful?
Because it relies too much on human emotions rather than logic and reason.
Even reason and logic are vanity and of no real value, how much less are
emotions and feelings... Worse than that, it relies on arbitrary temporal
(and temporary) definitions of what is "added functionality" and what can
binary modules be allowed to use "because it was already there". This
is the trend that I am seeing and I feel such trend is not to the benefit
of Linux. Ok, granted, there must be some alleys and exploits that the
commercial vendors can take advantage of and we should be careful about it
but I still believe that exporting or not exporting symbols based on
_license_ is fundamentally wrong.
Exporting based on some sort of subsystem registration (like dri core only
to dri drivers etc) would be a nice ide
a. But until that is implemented
(and really needed) a simple boundary provided by EXPORT_SYMBOL and
EXPORT_SYMBOL_INTERNAL (if _GPL gets renamed to it) is, imho, sufficient.
Regards,
Tigran
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 22:48:20 +0100 (BST)
> commercial vendors can take advantage of and we should be careful about it
> but I still believe that exporting or not exporting symbols based on
> _license_ is fundamentally wrong.
_INTERNAL is basically the same thing in effect anyway. It clearly states
the symbol is an internal part of a GPL product so it would be very hard
for someone to argue their work was not derivative if they used one
> (and really needed) a simple boundary provided by EXPORT_SYMBOL and
> EXPORT_SYMBOL_INTERNAL (if _GPL gets renamed to it) is, imho, sufficient.
BTW thinking about compatibility. There is no reason the view insmod sees
can't remain the same. EXPORT_SYMBOL_INTERNAL can just do the same symbol
magic as before.
It also helps me with the kernel-doc stuff if EXPORT_SYMBOL_INTERNAL is
used and in 2.5 we go mark most of the random internal kernel symbols with it
because we can begin to generate complete docs of public export interfaces
and their functionality
--------------------------------------------------------------------------------
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 20:03:52 +0100 (BST)
On Wed, 3 Apr 2002, Alan Cox wrote:
> > EXPORT_SYMBOL(vfree);
> > EXPORT_SYMBOL(__vmalloc);
> > -EXPORT_SYMBOL_GPL(vmalloc_to_page);
> > +EXPORT_SYMBOL(vmalloc_to_page);
>
> The authors of that code made it GPL. You have no right to change that. Its
> exactly the same as someone taking all your code and making it binary only.
Dear Alan,
You know how much I respect you and your words so I don't need to write
long a apologetic introduction if I wish to correct your statement.
Namely, you are saying that Andrea changed some code from being GPL to
non-GPL. That is so obviously not true that I am even surprized that I
need to point this out explicitly (especially to you; as Jesus said to
Nicodemus, are you a teacher in Israel and knowest not these things?)
The line of code:
EXPORT_SYMBOL(vmalloc_to_page);
is just as much under GPL license as the line of code:
EXPORT_SYMBOL_GPL(vmalloc_to_page);
So, Andrea's patch is not changing any license of any line of Linux kernel
code. He is just correcting a _technical_ mistake. Authors are allowed to
make mistakes and others are allowed to fix them. I don't see any problem
with that (even the wicked US legal system won't jail anyone for it :)
Therefore your comparison to "taking all your code and make it binary
only" is not valid.
Now, of course, I understand that the above is trivial and do not pretend
to assume that you don't know this. Therefore, let's look a little bit
deeper, to understand your assumptions. In order for your statement to be
valid technically, you have to assume that some parts of Linux kernel are
under GPL and others are not, i.e. some entry points (allowed for modules)
differ from other entry points wrt to license. That would be a badly
broken design and I appeal to yours and Linus' common sense about it. What
I understood the intention of EXPORT_SYMBOL_GPL was (from your email
mentioning the internal helpers etc) is that it is for internal helper
functions used by some parts of the kernel which happen to be
modularizable, but not for general consumption of 3rd party modules. So,
really, the name EXPORT_SYMBOL_GPL is a _misnomer_.
Let us therefore rename it to EXPORT_SYMBOL_INTERNAL and that would solve
all confusion and also prevent people who wish to make technically-wrong
decisions based on their personal dislike of binary-only modules (Arjan,
with all respect and sympathy to you, that is you).
I cc'd Linus because I do believe the above to be honest and correct. If I
am wrong, please say what is wrong.
Just my 2 pence.
Regards,
Tigran
From: Linus Torvalds
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 11:10:19 -0800 (PST)
Well, you're all wrong, bthththt...
Removing the .._GPL() is in this case correct, but not for any of the
reasons mentioned, but simply because even Ingo agreed that it shouldn't
be _GPL since it's explicitly meant for drivers that shouldn't have any
knowledge whatsoever about the VM internals. GPL or not.
The fact that the code was back-ported from 2.5.x and that the _GPL still
is there too is just a mistake, partly because I've not gotten any updates
from Ingo..
Linus
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 20:19:29 +0100 (BST)
Ok, but isn't it easier to rename _GPL -> _KERNEL (or _INTERNAL) if,
indeed, that is the meaning thereof? Then, in the future, one wouldn't
have to decide on a case by case basis like we had now (and appeal to
Caesar :) because the intention would be clear from the name?
From: Linus Torvalds
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 11:24:50 -0800 (PST)
I agree, that is really the meaning of the _GPL thing, and it would
probably also make people react less rabidly to the whole thing.
Linus
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 22:05:44 +0100 (BST)
On Wed, 3 Apr 2002, Linus Torvalds wrote:
> I agree, that is really the meaning of the _GPL thing, and it would
> probably also make people react less rabidly to the whole thing.
Ok, so that would cover the 2.5.x (and future stable) kernels. Does
Marcelo also agree that it should be the case in the 2.4.x kernel?
Regards,
Tigran
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 22:25:52 +0100 (BST)
Thats a Keith Owens question - will it break current modutils ? I think
modutils compatibility for 2.4 must be sacrosanct
From: Keith Owens
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 04 Apr 2002 16:43:19 +1000
On Wed, 3 Apr 2002 22:25:52 +0100 (BST),
Alan Cox wrote:
>Thats a Keith Owens question - will it break current modutils ? I think
>modutils compatibility for 2.4 must be sacrosanct
Trivial change to modutils, keeping backwards compatibility, so
EXPORT_SYMBOL_GPL == EXPORT_SYMBOL_INTERNAL.
When the flamers and lawyers agree on what they really mean by
EXPORT_SYMBOL_GPL or its replacement and everybody agrees on what the
keyword should be, let me know and I will roll a new modutils.
Otherwise, leave me out of this flamewar.
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 11:22:15 +0100 (BST)
On Thu, 4 Apr 2002, Keith Owens wrote:
> When the flamers and lawyers agree on what they really mean by
> EXPORT_SYMBOL_GPL or its replacement and everybody agrees on what the
> keyword should be, let me know and I will roll a new modutils.
> Otherwise, leave me out of this flamewar.
Let's look at the possible design for 2.5 first, then 2.4.
The meaning of EXPORT_SYMBOL_INTERNAL is that it can be used to export
symbols by base kernel subsystems (static or modular) to other base kernel
subsystems which can be compiled as a module. So, if the symbol is thus
exported by what is thought of as "base kernel" then only modules that
claim to be "base kernel" should use it. Similarly, if it is exported by a
driver, then only modules closely associated with that driver (for drivers
split in multiple modules) should be able to use it.
In other words, exporting symbols should not be based on the consumer's
license because that is technically inappropriate criterion.
As for implementation, perhaps EXPORT_SYMBOL_INTERNAL could look like:
EXPORT_SYMBOL_INTERNAL(runqueue_lock, "scheduler");
and the corresponding module that implements a "scheduler" can claim its
rights by:
MODULE_CLASS("scheduler");
A module should be able to belong to multiple classes, of course, i.e. it
could provide both "scheduler" to get runqueue_lock and "filesystem" to
get register_filesystem().
So, modutils would check module's classes and resolve or deny the
corresponding symbol. And EXPORT_SYMBOL(sym) would mean "disable class
check by modutils for this symbol".
I am not suggesting to throw away MODULE_LICENSE from .modinfo, only that
it should have nothing to do with exporting symbols (i.e. it should be
like author/des cription etc fields).
Now, all the above does not look like 2.4 matter, it should probably be
implemented in 2.5. As for 2.4 perhaps it should be a simple matter of
changing the actual name EXPORT_SYMBOL_GPL to EXPORT_SYMBOL_INTERNAL which
would place INTERNAL_ instead of GPLONLY_ in .kstrtab. And the thing that
would link with it in the module should not be MODULE_LICENSE but be a
new macro:
MODULE_SYMBOLS_INTERNAL;
A module that doesn't make any special claims (for compatibility) gets
only those exported by EXPORT_SYMBOL, whilst a module that claims access
to MODULE_SYMBOLS_INTERNAL gets also those exported by
EXPORT_SYMBOL_INTERNAL.
There should be no "licensing implications" but simply the (documented)
fact that if a proprietary module writer is stupid enough to make a
MODULE_SYMBOLS_INTERNAL claim his module will break far more often both
with respect to existence _and_ semantics/implemention of those entries
exported only "internally". But that is their own problem -- we should
neither he
lp them nor prevent them from doing their work and earning their
living. That is my opinion. If the vendor has so many resources to spend
on monitoring Linux kernel development (and therefore inevitably getting
involved and _helping_ with it!) to stay uptodate with every
implementation of internal symbols, then that is fine -- so much the
better for Linux. But if they want to write stable and maintainable
modules then they will never put MODULE_SYMBOLS_INTERNALS. We should
be always convincing proprietary software writers by our technical
superiority rather than by making their lives tough based on a whim of
whoever chooses which license to allow exporting his symbol to.
Simple, ethical and makes everyone happy, or, at least those who
understand that the design of a Unix-like operating system should be
driven by technical superiority rather than by using marketroid's weapons
against them (he who lifts up the sword shall fall by the sword).
Regards,
Tigran
From: Arjan van de Ven
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 05:35:59 -0500
I sort of get the impression that this is overdesign. Either you're a
"core subsystem" or a "external driver". I don't see much of a point
of protecting core subsystems from eachother; they are (assumed to be) part
of the upstream kernel source anyway so they are subject to peer review by
the subsystem maintainers... Since such core subsystems use very initimate
knowledge of "bzImage internals" I can even see the point in using a
rather strict "modversions like" system to make 100% sure that the
core subsystem modules and the base kernel match (random cookie that is
generated for each build and not available outside the build environment
??).
I say "external driver" even though the source can be in the
kernel tree; for this that doesn't make much of a difference,
most "drivers" don't need to know about core internal things and can
be compiled outside the tree already; they're in tree for convenience (and
for easing doing mass API changes etc etc etc).
Greetings,
Arjan van de Ven
--------------------------------------------------------------------------------
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 20:38:20 +0100 (BST)
> The fact that the code was back-ported from 2.5.x and that the _GPL still
> is there too is just a mistake, partly because I've not gotten any updates
> from Ingo..
So Linus is allowed to arbitarily export other peoples contributions ? I
think we need to clear this one up and understand what people think the
actual rules are around here. As I understand it the original code was
a) extracted from bttv and is code which I and DaveM partly wrote
b) was submitted by Gerd who did the extra work and kept it as _GPL when he
first exported it. (in 2.4 its relevant to expose it as we have the V4L1
not V4L2 interface)
Nobody seems to have remembered to ask permission around here
Alan
From: Linus Torvalds
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 11:25:58 -0800 (PST)
On Wed, 3 Apr 2002, Alan Cox wrote:
> So Linus is allowed to arbitarily export other peoples contributions ?
Those "other people" _are_ me and Ingo, in fact.
And yes, I damn well have the right to abritrarily export my own
contributions, thank you very much.
Linus
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 20:44:51 +0100 (BST)
> Those "other people" _are_ me and Ingo, in fact.
>
> And yes, I damn well have the right to abritrarily export my own
> contributions, thank you very much.
If its a rewrite of the old stuff then yes. But in that case the right
people -were- consulted.
From: Linus Torvalds
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 11:39:14 -0800 (PST)
On Wed, 3 Apr 2002, Alan Cox wrote:
>
> If its a rewrite of the old stuff then yes. But in that case the right
> people -were- consulted.
What is "rewrite"?
The thing has it's roots in mm/memory.c (and even more so just
which really forces the whole structure of the function)
so long ago that it isn't even funny. Coupled with the fact that the
15-line functionality has been changed by various VM/kmap changes (and by
the preempt changes) so many times that it bears little resemblance to
whatever it was before.
It's a question akin to the one whether BSD was based on the original AT&T
UNIX sources and thus under AT&T copyright.
Copyrights simply aren't that black-and-white.
There's also the issue of reasonableness - those fifteen lines can only be
written so many ways, and sure, we could ask NVIDIA & co to write their
own version, but if it bore a surprising simila
rity to the one in the
kernel, I can't really blame them. Except they'd probably get it wrong,
and they'd _certainly_ be blamed when we introduce something new like the
highmem page tables or preemption stuff.
Linus
--------------------------------------------------------------------------------
From: Gerd Knorr
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: 3 Apr 2002 20:35:06 GMT
Alan Cox wrote:
> So Linus is allowed to arbitarily export other peoples contributions ? I
> think we need to clear this one up and understand what people think the
> actual rules are around here. As I understand it the original code was
> a) extracted from bttv and is code which I and DaveM partly wrote
> b) was submitted by Gerd who did the extra work and kept it as _GPL when he
> first exported it. (in 2.4 its relevant to expose it as we have the V4L1
> not V4L2 interface)
No.
I've only submitted the 2.4.x backport to Marcelo, and the only reason
I've export it as _GPL there is that it is _GPL in 2.5.x. Having that
symbol without _GPL in 2.4 and with _GPL in 2.5 would be very bad style
and would upset people who start using that function in 2.4 and notice
later on that it is exported more strict in 2.5 ...
I'll happily submit a patch to Marcelo to remove the _GPL once it is
gone in Linus 2.5 tree.
The 2.5.x code (which I grabbed for the backport) was submitted by Ingo
and updated by Linus says my BK tree changelog. Ingo obviously did
*not* a simple cut&paste of DaveM's code from bttv. The 2.5.x
vmalloc_to_page() function handles pte-highmem and preemtable kernels,
that code was never in bttv.
> Nobody seems to have remembered to ask permission around here
Ingo is happy with removing _GPL, Linus too, where exactly is the
problem?
Gerd
From: Richard B. Johnson
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 17:17:00 -0500 (EST)
On 3 Apr 2002, Gerd Knorr wrote:
> No.
This is getting pretty tired.
This is truly amazing. Think about it. For years Linux enthusiasts
have been trying to take over the world. They wanted everybody to use
it. They wanted everyone to accept it as the greatest thing since
COBOL.
Now, the world is starting to take notice. Linux is actively and
publicly supported by the likes of Intel, IBM, and other major
players. So what happens?
We now have developers, contributors, and others who are saying;
"Whoa, now! I don't want just 'anybody' to use __my__ code!!".
Well, you can't have it both ways. If you want the world to use
Linux, then the companies that spend their money making programs
and drivers that work with Linux are going to have to be able
to keep their own hard-earned code from their competitors, or the
companies that hire the Engineers that write the code will soon
be out-of-business, their work having been stolen by others.
I have first-hand experience. Microsoft made a lot of money,
getting into the consumer market, with Flight Simulator. This
was written my myself and several other contributors to the
"PROGRAM EXCHANGE", a long ago defunct BBS System. Before the
Internet was commonplace we had BBS Systems. I was so proud
of the assembly-language state-machine and others were so proud
of the Turbo-Pascal GUI that we _had_ to publish it. The fact
that thieves existed was not a consideration.
So grow up. This whole
"EXPORT_THIS_SYMBOL_ONLY_IF_YOU_WILL_ME_YOUR_FIRST_BORN()"
is unmitigated bullshit.
A symbol should be exported when there is a technical need for
it to be exported. None of us want a bloated kernel with 20 interfaces
into a kernel-mode memory allocator any more than we want as many
memcpy() functions. If you can't allow somebody to use (meaning
intercace-with) "your" code then kindly send a patch that removes it.
In a few days it will be replaced with something that probably works
better, written by somebody who would be proud to have others interface
with it.
Cheers,
Dick Johnson
From: Rik van Riel
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 19:24:07 -0300 (BRT)
On Wed, 3 Apr 2002, Richard B. Johnson wrote:
> Well, you can't have it both ways. If you want the world to use
> Linux, then the companies that spend their money making programs
> and drivers that work with Linux are going to have to be able
> to keep their own hard-earned code from their competitors, or the
> companies that hire the Engineers that write the code will soon
> be out-of-business, their work having been stolen by others.
That's the perfect argument for making some symbols GPL-only,
after all Redhat, SuSE, Conectiva, etc. wouldn't want to have
vmware and Veritas use their work without giving anything back ...
regards,
Rik
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5]
do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 23:33:52 +0100 (BST)
On Wed, 3 Apr 2002, Rik van Riel wrote:
> after all Redhat, SuSE, Conectiva, etc. wouldn't want to have
> vmware and Veritas use their work without giving anything back ...
>
Rik,
I don't know about vmware (probably applies too) but more than one person
at Veritas can be justly offended by your implication that Veritas
employees have not contributed anything useful to the Linux kernel.
I hope I understood you incorrectly and you weren't implying anything of
the kind.
In fact, the very existence of any "issue" here is due to the fundamental
impossibility to "measure" such contributions by inventing some
constraints on exporting symbols to modules.
Regards,
Tigran
From: Rik van Riel
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 19:39:04 -0300 (BRT)
On Wed, 3 Apr 2002, Tigran Aivazian wrote:
> I don't know about vmware (probably applies too) but more than one person
> at Veritas can be justly offended by your implication that Veritas
> employees have not contributed anything useful to the Linux kernel.
>
> I hope I understood you incorrectly and you weren't implying anything of
> the kind.
Indeed, Veritas has contributed significantly to kernel development,
but I can't remember ever seeing anything but troubled users from
companies like nvidia or vmware.
Veritas was a bad example indeed ;)
regards,
Rik
From: Chris Wedgwood
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 21:59:02 -0800
On Wed, Apr 03, 2002 at 07:39:04PM -0300, Rik van Riel wrote:
Indeed, Veritas has contributed significantly to kernel development, but I can't remember ever seeing anything but troubled users from companies like nvidia or vmware.
Considering the fact we are much more likely to hear complaints when
things are broken and people are seeking a fix than praise otherwise,
I think this is a little unfair. For the vast numbers of nvidia users
I don't think there are that many problems reported and I'm not
convinced the CURRENT nvidia drivers are necessarily doing anything
bad[1].
--cw
[1] People are welcome to provide code to prove me wrong. I use the nv hardware at times and it works very well, the machines don't suffer filesystem corruption, crashes or memory leaks.
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 13:06:28 +0100 (BST)
> I think this is a little unfair. For the vast numbers of nvidia users
> I don't think there are that many problems reported and I'm not
> convinced the CURRENT nvidia drivers are necessarily doing anything
> bad[1].
Its very hard to tell. Most people I ask cannot reproduce their crashes with
the Nvidia driver unloaded. Equally many of them only got one crash in weeks
anyway.
Some of the stuff is more clear - the business about 4Mb pages on Athlon for
example. That may be a hardware, a driver or even a subtle interaction with
something elsewhere in the kernel - eg the memcpy prefetching bug I fixed
in 2.4.19-pre4-ac4
It doesn't alter the fact that its undebuggable by the community, and that is
the real problem. Fortunately the open source nvidia driver work seems to be
at the point it can just about play Quake2/3
--------------------------------------------------------------------------------
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Wed, 3 Apr 2002 20:35:09 +0100 (BST)
> Namely, you are saying that Andrea changed some code from being GPL to
> non-GPL. That is so obviously not true that I am even surprized that I
> need to point this out explicitly (especially to you; as Jesus said to
> Nicodemus, are you a teacher in Israel and knowest not these things?)
He removed the marker to make it clear that is not meant to be used by
non GPL modules and is an internal helper function. Its really to my
mind no different to changing the text of the license - someone elses license -
to delete the linking rules. Even if the change is not valid is misleads
and confuses and is extremely impolite.
> EXPORT_SYMBOL(vmalloc_to_page);
> is just as much under GPL license as the line of code:
> EXPORT_SYMBOL_GPL(vmalloc_to_page);
>
> So, Andrea's patch is not changing any license of any line of Linux kernel
> code. He is just correcting a _technical_ mistake. Authors are allowed to
He's misleading people and contributing to future infringements. The _GPL
marker is correct, and it is there to assist people like Veritas by telling
them "excuse me this one is not for you". Note that there are higher level
interfaces using it which genuinely do seem to be needed by seperate works
and are not EXPORT_SYMBOL_GPL, as well as others like the Video4Linux buffer
helper logic which is very much a support library.
> make mistakes and others are allowed to fix them. I don't see any problem
> with that (even the wicked US legal system won't jail anyone for it :)
Actually it does. EXPORT_SYMBOL_GPL is a digital rights management system
subverting it is a US offence. Now if anyone was to go cart Andrea off to
jail for that I'd be pretty pissed off. Its stupidity factor is stunningly
high but it doesn't change the reality. Nor for that matter should anyone
forget that stupid laws can be used for good as well as evil some times 8)
> I understood the intention of EXPORT_SYMBOL_GPL was (from your email
> mentioning the internal helpers etc) is that it is for internal helper
> functions used by some parts of the kernel which happen to be
> modularizable, but not for general consumption of 3rd party modules. So,
> really, the name EXPORT_SYMBOL_GPL is a _misnomer_.
It makes it clear what it is usable by. I don't as such consider it a
misnomer. Now EXPORT_SYMBOL_INTERNAL would be a godsend for a lot of other
stuff. It would help binary folks and a lot of GPL driver folks know that
they were sticking their nose in the wrong spot and might get burned. At
that point they can make an intelligent assessment. Maybe they do need to
stick their noses in, maybe they should look at the right approach.
However _GPL and _INTERNAL are two different things. Linus has said he won't
allow people to go around removing existing symbols people rely on. Its not
quite my own viewpoint but Linus argues quite reasonably that he has at least
a moral reason to not go around screwing people and its his toy.
modprobe -w mynewdriver.o Warning: This driver appears to use kernel internal interfaces that are very likely to change over time. [... list of symbols ...]
sound good. Its sort of a lint for driver authors. I support the addition
of _INTERNAL as _well_ as _GPL completely. Although maybe at that point its
time to think about EXPORT_SYMBOL(name, attributes) before Keith Owens goes
missing in a combinatorial explosion.
Alan
--------------------------------------------------------------------------------
From: Ingo Molnar
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 04:33:05 -0500 (EST)
On Wed, 3 Apr 2002, Linus Torvalds wrote:
> Removing the .._GPL() is in this case correct, but not for any of the
> reasons mentioned, but simply because even Ingo agreed that it shouldn't
> be _GPL since it's explicitly meant for drivers that shouldn't have any
> knowledge whatsoever about the VM internals. GPL or not.
indeed. I had and still have no strong feelings either way, a patch to
remedy this was promised by me but not sent. I made it _GPL for pure
technical reasons: i saw no non-GPL drivers in 2.5 that used it, and at
first sight the functionality looked internal enough to warrant the _GPL
export. But in any case, while i might have written some of the patches,
the principal author of the final interface is Linus. Hopefully this is
the end of this story.
Ingo
--------------------------------------------------------------------------------
From: Alan Cox
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 12:54:06 +0100 (BST)
> There should be no "licensing implications" but simply the (documented)
> fact that if a proprietary module writer is stupid enough to make a
> MODULE_SYMBOLS_INTERNAL claim his module will break far more often both
> with respect to existence _and_ semantics/implemention of those entries
Using any internals of the Linux kernel has licensing implications.
> exported only "internally". But that is their own problem -- we should
> neither help them nor prevent them from doing their work and earning their
So why are you trying to put me out of business by allowing people to use
my code in ways the GPL doesn't permit. That cuts both ways.
From: Tigran Aivazian
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 13:01:47 +0100 (BST)
On Thu, 4 Apr 2002, Alan Cox wrote:
> > exported only "internally". But that is their own problem -- we should
> > neither help them nor prevent them from doing their work and earning their
>
> So why are you trying to put me out of business by allowing people to use
> my code in ways the GPL doesn't permit. That cuts both ways.
That would be the case _only_ under yet another interpretation of GPL.
Strange thing about GPL is that there are so many interpretations to
choose from :)
It is your interpretation that matters, not mine, so how can I convince
you? But I am entitled to an opinion that your interpretation is, in some
sense, wrong. Namely, in the sense that it is inconsistent with the
similar situation in the case of libraries or even system calls. I don't
see why expo
rting kernel symbols should be so radically different and
extremely sensitive to the nature of the consumer's license for some
symbols but not for others...
Regards,
Tigran
From: Russell King
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 13:40:46 +0100
On Thu, Apr 04, 2002 at 01:01:47PM +0100, Tigran Aivazian wrote:
> Namely, in the sense that it is inconsistent with the
> similar situation in the case of libraries or even system calls.
A GPL library can only be linked with other GPL-compatible code. A LGPL
library can be linked with any GPL-compatible or GPL-incompatible code.
The LGPL has specific clauses in it that allows you to link GPL-incompatible
code (see LGPL paragraph 5). It seems that you're missing that distinction.
This is why glibc and other libraries are LGPL, not GPL. If glibc was GPL,
all the binary-only applications in user space would have to supply their
own C library.
--
Russell King
From: Ingo Molnar
Subject: Re: [PATCH 2.5.5] do export vmalloc_to_page to modules...
Date: Thu, 4 Apr 2002 08:26:50 -0500 (EST)
On Thu, 4 Apr 2002, Tigran Aivazian wrote:
> [...] Namely, in the sense that it is inconsistent with the similar
> situation in the case of libraries or even system calls. I don't see why
> exporting kernel symbols should be so radically different and extremely
> sensitive to the nature of the consumer's license for some symbols but
> not for others...
Tigran, the difference is very very fundamental, please think about it,
and please try to ignore the fact that you are working for Veritas.
Internal modules of the GPL kernel are just a technical modularization of
a complete and unified GPL-ed work. We want it to stay consistent, we want
*our* work to be fully and completely debuggable, supportable and we want
to be able to understand and develop any part of it. This is our intent.
the moment you start to argue 'but why cannot we just add this set of
EXPORTs and put our binary-only modules here and there' you are in essence
questioning our freedom to specify the license of our work. You are
abusing the internal modularization mechanizm to put in code that we
cannot debug, cannot read and cannot develop and cannot support in any
reasonable way. It's like exchanging kernel/sched.o with your binary-only
implementation and not publishing the source code of it. If you want to
play such games then you have to implement the other 4 million lines as
well, nobody prevents you to do that.
system calls are a published, honored, maintained interface. User-space
applications are indpendent works not derived from the GPL-ed kernel in
any way. Hence the exception.
historically we have also chosen to to provide a different type of API
towards more or less clearly separate works, like independently developed,
non-GPL hardware drivers. Let yourself not be confused by the fact that
the same technical mechanizm is also used to demand-link separate smaller
parts of the kernel work as well.
The impact of binary-only modules on the kernel's development architecture
is not zero but not overly significant either, so most of us are pretty
pragmatic about that, as long as binary-only module vendors are not
abusing this mechanizm to impact the integrity of the kernel and create
clearly derived works without obeying the rules of the GPL. And it's clear
that internal symbols are just that: internal, still part of the kernel
work. [and directly resulting from that, they obey the GPL.]
I consider 'abuse' for example a kernel derivative with a 'modified'
scheduler. The day it will be possible to put a binary-only sched.o into
the kernel i'll stop doing Linux. I am not here to develop some 'lite'
version of the OS, where all the interesting stuff happens behind closed
doors. I'm not here either to see the quality of the OS degrade due to
sloppy programming in widely used binary-only modules, without being able
to fix it.
The GPL right now protects our work from being abused in such a way - it's
illegal to provide a binary-only sched.o and compile a kernel product from
that, because the resulting kernel is still one work and the whole work
must still be under the GPL. It's equally illegal to recover the location
of sched.o in the final kernel image and runtime relink it with a
binary-only sched.o. It's equally illegal to accomplish the same over the
internal module interface.
Think about it, every separate .o in the Linux kernel can be equivalently
expressed in terms of a EXPORT-ed module interface, GPL-ed header files
and a closed-source module. There is a good reason why the GPL forbids
such freely defined 'module interfaces' to be added. Think of the GPL as
the price you pay for being able to use the Linux kernel's source code or
being allowed to link to it - you are not forced in any
way to do that.
and no, you have no *right* to link a binary-only sched.o to the Linux
kernel - even if you develop a sched.c 'separately' - and intuitively feel
that it's somehow a separate work, the end result is still a derivative of
the kernel. And this violation of the license is illegal in most
countries, it's even a crime in some countries.
Ingo
视频教程列表
文章教程搜索
C语言程序设计推荐教程
C语言程序设计热门教程
|
QQ：2693987339(点击联系)购买教程光盘
:
