The following trivial patch exports the new vmalloc_to_page primitive to
the modules (following mingo's modifications to, at least, the v4l drivers).
Stelian.
===== kernel/ksyms.c 1.62 vs edited =====
--- 1.62/kernel/ksyms.c Mon Feb 18 18:09:54 2002
+++ edited/kernel/ksyms.c Wed Feb 20 12:08:42 2002
@@ -107,6 +107,7 @@
EXPORT_SYMBOL(kfree);
EXPORT_SYMBOL(vfree);
EXPORT_SYMBOL(__vmalloc);
+EXPORT_SYMBOL(vmalloc_to_page);
EXPORT_SYMBOL(mem_map);
EXPORT_SYMBOL(remap_page_range);
EXPORT_SYMBOL(max_mapnr);
--
Stelian Pop <[email protected]>
Alcove - http://www.alcove.com
Ingo,
On Wed, 20 Feb 2002, Stelian Pop wrote:
> The following trivial patch exports the new vmalloc_to_page primitive to
> the modules (following mingo's modifications to, at least, the v4l drivers).
>
> Stelian.
>
> ===== kernel/ksyms.c 1.62 vs edited =====
> --- 1.62/kernel/ksyms.c Mon Feb 18 18:09:54 2002
> +++ edited/kernel/ksyms.c Wed Feb 20 12:08:42 2002
> @@ -107,6 +107,7 @@
> EXPORT_SYMBOL(kfree);
> EXPORT_SYMBOL(vfree);
> EXPORT_SYMBOL(__vmalloc);
> +EXPORT_SYMBOL(vmalloc_to_page);
> EXPORT_SYMBOL(mem_map);
> EXPORT_SYMBOL(remap_page_range);
> EXPORT_SYMBOL(max_mapnr);
Hmm, what is this "vmalloc_to_page" and in what tree do we find it?
Is this a case of BitKeeper users getting ahead of the game?
I ask because I was preparing mail and patch to replace Arjan's
uvirt-to-kva-2.5.5-A0 (and those parts of your highmem-2.5.5-A0).
In brief, I contend that
unsigned long uvirt_to_kva(pgd_t *pgd, unsigned long adr)
is not appropriate or useful for mm/memory.c to provide, but
struct page *vvirt_to_page(unsigned long vadr)
is appropriate and useful for mm/vmalloc.c to provide.
Is that what your "vmalloc_to_page" is? If so, why are you also
marketing "uvirt_to_kva"? If not, sorry for all the confusion!
Thanks,
Hugh
On Wed, Feb 20, 2002 at 04:00:47PM +0000, Hugh Dickins wrote:
> Ingo,
>
> On Wed, 20 Feb 2002, Stelian Pop wrote:
> > The following trivial patch exports the new vmalloc_to_page primitive to
> > the modules (following mingo's modifications to, at least, the v4l drivers).
> >
> > Stelian.
> >
> > ===== kernel/ksyms.c 1.62 vs edited =====
> > --- 1.62/kernel/ksyms.c Mon Feb 18 18:09:54 2002
> > +++ edited/kernel/ksyms.c Wed Feb 20 12:08:42 2002
> > @@ -107,6 +107,7 @@
> > EXPORT_SYMBOL(kfree);
> > EXPORT_SYMBOL(vfree);
> > EXPORT_SYMBOL(__vmalloc);
> > +EXPORT_SYMBOL(vmalloc_to_page);
> > EXPORT_SYMBOL(mem_map);
> > EXPORT_SYMBOL(remap_page_range);
> > EXPORT_SYMBOL(max_mapnr);
>
> Hmm, what is this "vmalloc_to_page" and in what tree do we find it?
> Is this a case of BitKeeper users getting ahead of the game?
>
> I ask because I was preparing mail and patch to replace Arjan's
> uvirt-to-kva-2.5.5-A0 (and those parts of your highmem-2.5.5-A0).
>
> In brief, I contend that
> unsigned long uvirt_to_kva(pgd_t *pgd, unsigned long adr)
> is not appropriate or useful for mm/memory.c to provide, but
> struct page *vvirt_to_page(unsigned long vadr)
> is appropriate and useful for mm/vmalloc.c to provide.
>
> Is that what your "vmalloc_to_page" is? If so, why are you also
> marketing "uvirt_to_kva"? If not, sorry for all the confusion!
uvirt_to_kva got fixed. bad interface.
and replaced by vmalloc_to_page() which is the right one (eg returing
struct page).
Now if it should be EXPORT_SYMBOL or EXPORT_SYMBOL_GPL() I leave to Ingo
page = vmalloc_to_page(virt); is the right interface and you can find it
in the 2.5.5 kernel, along with the other highpte changes.
Ingo
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
> 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
On Wed, Apr 03, 2002 at 06:43:10PM +0100, 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.
>
> 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 kernel 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
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
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
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.
>
> 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, that's crap. The function in question can be trivially turned into
extern inline and removed from export list completely. _If_ such change
can be made illegal by exporting uninligned version with EXPORT_SYMBOL_GPL
- I'm going to fork the tree *now* and start replacing the stuff exported
that way with untainted clean reimplementations. As much as I despise
binary-only modules, any mechanism that allows games of that kind needs
to be killed. One shouldn't be able to prohibit equivalent transformations
of core code (and inlining a function _is_ such transformation) by pulling
the licensing crap.
> > > -EXPORT_SYMBOL_GPL(vmalloc_to_page);
> > > +EXPORT_SYMBOL(vmalloc_to_page);
> >
> 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
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?
On Wed, 3 Apr 2002, Linus Torvalds wrote:
>
> 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
>
>
On Wed, Apr 03, 2002 at 08:11:49PM +0100, Alan Cox wrote:
> > 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.
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.
> > 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
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.
> 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.
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
On Wed, 3 Apr 2002, Tigran Aivazian wrote:
>
> 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?
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
On Wed, Apr 03, 2002 at 08:03:52PM +0100, Tigran Aivazian wrote:
> 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
200% agreed. thanks for making the facts clear,
Andrea
On Wed, 3 Apr 2002, Alan Cox wrote:
>
> > 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 ?
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
> 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
> 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.
> 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
On Wed, Apr 03, 2002 at 11:10:19AM -0800, Linus Torvalds wrote:
> 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.
I told exactly that in the first email, when I was still talking about
technical things.
Andrea
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
<asm/pgtable.h> 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 similarity 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
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.
On Wed, 3 Apr 2002, Tigran Aivazian wrote:
> 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 hope it is obvious it was a joke? Perhaps to make the joke intention
clearer I should have suggested a better "symbol exporting protocol" from
kindergarten experience:
module -> kernel: export your symbols, please
kernel -> module: you export yours first and I'll export some of mine
which is not totally unlike the scheme suggested by bona fide
EXPORT_SYMBOL_GPL defenders, namely "if binary-only modules don't
contribute to the base kernel why should the base kernel let them use it's
symbols".
Regards,
Tigran
> 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
On Wed, 3 Apr 2002, Linus Torvalds wrote:
>
> On Wed, 3 Apr 2002, Tigran Aivazian wrote:
> >
> > 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?
>
> 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
>
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
On Wed, 3 Apr 2002 18:43:10 +0100 (BST), 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.
>
>You are
> - subverting a digital rights management system
> [5 years jail in the USA]
> - breaking a license
On the contrary, the GPL specifically gives me the right to modify the code
to make it more useful to me and distribute those modifications.
>but worse than that you are ignoring the basic moral rights of the authors
>of that code.
They didn't have to put their code under the GPL if they didn't want to
allow other people to use and modify it. You can't have it both ways --
there's no such thing as 'GPL but with a few extra restrictions I've added to
the code that everyone's contributed to'.
DS
> 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?
Thats a Keith Owens question - will it break current modutils ? I think
modutils compatibility for 2.4 must be sacrosanct
> allow other people to use and modify it. You can't have it both ways --
> there's no such thing as 'GPL but with a few extra restrictions I've added to
> the code that everyone's contributed to'.
Nor is there "GPL with a few things ignored".
On Wed, Apr 03, 2002 at 10:33:18PM +0100, Alan Cox wrote:
> > allow other people to use and modify it. You can't have it both ways --
> > there's no such thing as 'GPL but with a few extra restrictions I've added to
> > the code that everyone's contributed to'.
>
> Nor is there "GPL with a few things ignored".
Sure there is. I don't think the kernel's under one, though. They're
all over the place: For instance, the libgcc license is "GPL except
anything can use it if compiled with GCC". Various SSL-using programs
are distributed under "GPL but you can link it to OpenSSL anyway".
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
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 idea. 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
> 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
Alan Cox wrote:
> > 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)
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
--
#include </dev/tty>
On Wed, 3 Apr 2002 22:33:18 +0100 (BST), Alan Cox wrote:
>>allow other people to use and modify it. You can't have it both ways --
>>there's no such thing as 'GPL but with a few extra restrictions I've added
>>to
>>the code that everyone's contributed to'.
>Nor is there "GPL with a few things ignored".
Show me where the GPL says that you can prevent people from changing the
code to make it more useful to them. Show me where the GPL allows you to
build 'proprietary/unmodifiable' bits in to 'secure' your program against the
types of usage you don't like.
The GPL says, for example, " For example, if you distribute copies of such
a program, whether gratis or for a fee, you must give the recipients all the
rights that you have. You must make sure that they, too, receive or can get
the source code. And you must show them these terms so they know their
rights."
The GPL explicitly grants the right to modify in section 2. It says nothing
about not being allowed to remove 'security' or 'lockout' features. In fact,
it would be horrible if people could put any security or lockout features
into GPLed code.
The GPL says, "Each time you redistribute the Program (or any work based on
the Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further restrictions on
the recipients' exercise of the rights granted herein. You are not
responsible for enforcing compliance by third parties to this License."
What could be clearer? "It's GPL but you can't change it to do things the
original author specifically didn't want you to be able to do" is horseshit.
DS
On 3 Apr 2002, Gerd Knorr wrote:
> Alan Cox wrote:
> > > 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)
>
> 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
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
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
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
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
On Wed, 3 Apr 2002, Tigran Aivazian wrote:
> 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 ...
>
> 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
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
From: Tigran Aivazian <[email protected]>
Date: Wed, 3 Apr 2002 23:33:52 +0100 (BST)
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.
If such a misconception exists (incorrect or not), it would be helped
if the majority of people who do Linux kernel work and are working at
these companies didn't use [email protected] (or other anonymous) email
addresses in their postings here.
The Vger postmasters knows who you cowards really are, because we see
the final destination when your email bounces :-))))
On 3 Apr 02 at 19:39, Rik van Riel wrote:
> On Wed, 3 Apr 2002, Tigran Aivazian wrote:
> > 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 ...
> >
> > 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.
>
> 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 ;)
Well, now I feel really offended. Maybe my contributions are not so big
as yours, but I think that negating them completely is way too off.
Petr Vandrovec
(also) [email protected]
On Thu, 4 Apr 2002, Petr Vandrovec wrote:
> On 3 Apr 02 at 19:39, 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.
> >
> > Veritas was a bad example indeed ;)
>
> Well, now I feel really offended. Maybe my contributions are not so big
> as yours, but I think that negating them completely is way too off.
> Petr Vandrovec
> (also) [email protected]
I guess Davem's comments apply, I see lots of [email protected]
in my email archive but this is the first [email protected] that I
see:
$ grep -i Vandrov ~/mail/linux-kernel-Wk* | wc -l
343
$ grep -i petr@vmware ~/mail/linux-kernel-Wk* | wc -l
1
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
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.
On Wed, 3 Apr 2002 22:25:52 +0100 (BST),
Alan Cox <[email protected]> wrote:
>> 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?
>
>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.
[email protected] (Alan Cox) wrote on 03.04.02 in <[email protected]>:
> > 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.
Frankly, I believe that it is both illegal (by the GPL) and morally
bankrupt to add these "GPL only" symbols to the kernel *unless* you can
get agreement for them fro *all* kernel copyright holders.
Which I predict you won't get.
That is, except when you handle the "_GPL" as a meaningless adornment.
MfG Kai
On 4 Apr 2002, Kai Henningsen wrote:
> [email protected] (Alan Cox) wrote on 03.04.02 in <[email protected]>:
>
> > > 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.
>
> Frankly, I believe that it is both illegal (by the GPL) and morally
> bankrupt to add these "GPL only" symbols to the kernel *unless* you can
> get agreement for them fro *all* kernel copyright holders.
>...
Which part of the GPL do you mean with your "illegal (by the GPL)"?
Your statement sounds as if the GPL would require that you must be allowed
to link proprietary code with GPLed code - and that's the opposite of the
intention behind the GPL.
> MfG Kai
cu
Adrian
BTW: After reading COPYING I'm puzzled why binary-only modules are allowed
at all? Could anyone enlighten me where the permission is hidden?
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
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/description 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 help 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
On Thu, Apr 04, 2002 at 11:22:15AM +0100, Tigran Aivazian wrote:
> 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");
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
On 3 Apr 02 at 21:19, Rik van Riel wrote:
> On Thu, 4 Apr 2002, Petr Vandrovec wrote:
> > Petr Vandrovec
> > (also) [email protected]
>
> I guess Davem's comments apply, I see lots of [email protected]
> in my email archive but this is the first [email protected] that I
> see:
>
> $ grep -i Vandrov ~/mail/linux-kernel-Wk* | wc -l
> 343
> $ grep -i petr@vmware ~/mail/linux-kernel-Wk* | wc -l
> 1
I did not thought that I have to send changes in my CV and in positions
to you or to linux-kernel. I try very hard to not disclose this type
of information, because of I thought that nobody is interested in what
I do and where I do that, and that presenting myself with one constant
email address serves other to remember that this Petr is really still
same Petr, and not someone else. Maybe SubmittingPatches need chapter #0,
--
When you send patch first time, please include list of all your positions,
so we can track which companies participate on Linux kernel development
through you.
If you send patch later, please include list of changed positions, so
we can properly update list of this companies.
--
and into lklm FAQ:
--
Q: Can I use my [email protected], [email protected], [email protected] email addresses
for my posts?
A: No. Please use one you randomly choose from all email addresses you
have (and do this random selection each time you post message, so grep
through archive can reveal compaines supporting Linux kernel).
--
Petr Vandrovec
[email protected]
> Frankly, I believe that it is both illegal (by the GPL) and morally
> bankrupt to add these "GPL only" symbols to the kernel *unless* you can
> get agreement for them fro *all* kernel copyright holders.
Other way around. Remember the kernel is GPL not LGPL
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 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...
Regards,
Tigran
> 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.
> 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
On Thu, 4 Apr 2002, Tigran Aivazian wrote:
>...
> 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
>...
The COPYING file of Linux contains an explicit permission to use 'kernel
services by normal system calls' and that this 'does *not* fall under the
heading of "derived work"'. As stated in my previous mail in this thread
I'm still wondering where the allowance for binary-only modules to link
with the kernel is hidden.
> Regards,
> Tigran
cu
Adrian
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, Apr 04, 2002 at 02:31:48PM +0200, Adrian Bunk wrote:
> On Thu, 4 Apr 2002, Tigran Aivazian wrote:
> > 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
>
> The COPYING file of Linux contains an explicit permission to use 'kernel
> services by normal system calls' and that this 'does *not* fall under the
> heading of "derived work"'. As stated in my previous mail in this thread
> I'm still wondering where the allowance for binary-only modules to link
> with the kernel is hidden.
It isn't written down anywhere - this is one of the major problems here.
If you ask Linus, Linus will say "sure, it's fine to have binary-only
modules", but it's not explicitly documented in the license document
and as such everyone who contributes code to the kernel doesn't have
to agree to this.
Unfortunately, putting it into the license now could be construed as a
change of terms, which would require everyone whose code is exported via
EXPORT_SYMBOL to agree (and there's little chance of that happening...)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Thu, 4 Apr 2002, Russell King wrote:
> 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.
I wasn't actually missing that distinction and I am familiar with LGPL
reasonably well (had to study it as we do actually make use of it at
VERITAS). I was comparing LGPL with "Linux kernel flavour of GPL" rather
than LGPL with GPL.
>
> 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.
>
Yes, I know.
Regards,
Tigran
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
On Thu, 4 Apr 2002, Ingo Molnar wrote:
> 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.
Absolutely agreed. I've already seen it happen a few times that
a user needed _2_ binary-only modules, modules which weren't even
available for the same kernel version.
As it stands right now it is IMPOSSIBLE to support binary only
drivers and I can only see two ways out of this situation:
(1) don't allow binary only modules at all
(2) have a stable ABI for binary only modules and don't allow
these binary only modules to use other symbols, so people
in need of binary only modules won't be locked to one
particular version of the kernel (or have two binary only
modules locked to _different_ versions of the kernel)
kind regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Thu, 4 Apr 2002, Ingo Molnar wrote:
> 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.
After thinking about it for a while (and careful reading of your
explanation) I must conclude that your view is probably safer, i.e. in
the long term it is probably better for the Linux kernel to protect its
status along the lines you described, even if it is not as "smooth" or
"convenient to everyone" as the scheme I was talking about.
On the issue of what should be considered a derivative and what shouldn't,
from your email it seems (and it's not a bad thing, imho) that the Linux
kernel is protecting itself to make sure that "interesting" functionality
is either already in the kernel or exists as a GPL'd module.
To make this thought clearer, let's say that there is no GPL'd journalling
filesystem for Linux (i.e. reiserfs, ext3 and others suddenly
disappeared). Then, to make your thoughts consistent you would need to
disable the exported interfaces required for development of a journalling
filesystem. Because, otherwise, you would be working on a "lite" OS and
"interesting stuff will happen behind the closed doors". As I said, it is
not necesserily "bad", i.e. it may well be necessary for Linux's survival
and therefore I am all for it. I only thought that there is something
_technically_ unpleasant or "wrong" about it... Maybe "wrong" is the wrong
word, but you know what I mean.
Regards,
Tigran
On Thu, 4 Apr 2002, Ingo Molnar wrote:
>
> 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
>
I am amazed with the number of "lawyers" we have here. Maybe it's
just some semantics or property of translation, but it is not
illegal to violate a license.
The term "illegal" historically refers to laws. Laws are rules
enacted by governments.
A license is permission, granted by a property owner, usually
but not always, setting forth the conditions of use.
If I give you permission to use my driveway for parking guests
during your party, I am granting you a "non-exclusive license to
use my property under specified conditions". If you abuse that
license, I can sue you. However, the fact that you failed to
remove your vehicles after your party was not "illegal".
Individuals do not make laws. Governments do that. Individuals
can make contracts, issue licenses, and engage in all kinds of
commerce, but they cannot make laws. Therefore, the violation
of some contract, license, or other such agreement is not
illegal.
Please do not use this word when you are referring to a license.
The correct word, except where a contract is involved, is "tort".
In the case of a contract, the correct word is "breach". They
are not interchangeable. The recent attempts by the United States
Congress to turn "tort" into "unlawful" in the case of copy-protection
is an example of why we must protect these words.
The same applies to error messages and warnings issued by software.
There is no such thing as an "illegal operand" or "illegal" parameter.
The correct word is "invalid". Software does not make laws, therefore
has no right to use the word "illegal". Instead, software makes rules.
They do not have the power of law.
The GPL document is a "license". It does not have the power or
scope of "law". It is not even a "contract" because a contract
requires an agreement. The GPL document forces a license and
seems to imply some sort of an agreement, but an agreement cannot
be implied. It must be specifically stated and the parties to
that agreement must individually recognize that such an agreement
exists, usually by setting forth a signature by all parties to
that agreement.
Enforcement of a license is up to the property owner. If a licensee
violates the specifics, or even the intent of a license, the
property owner who issued that license, may bring civil action
against the violator. In the United States, (and it's different in
different states) such a civil action may prevail if the property
owner can show that he/she was harmed by the tort. For instance, if
you parked a truck on my property, rather than an automobile, you
may have violated either the wording or the intent of the license
issued, however it's unlikely that I would prevail in court bringing
an action against you unless your truck was so heavy it damaged my
property.
The intent of GPL "seems to be" to give contributors the credit
they deserve. It is not usually possible to foresee all possible
uses of a work at the time a license is granted. At the time
GPL was written, there was no possibility of "binary-only" modules
because there weren't even any modules.
If the contributors to Linux want the world to use Linux, they
need to understand that many companies cannot divulge or publish
their intellectual property (read supply source-code), even if
they wanted to. This could result in a stockholder lawsuit because
non-technical persons (stockholders) may think that their equity
value is being reduced by the company "giving away" intellectual
property that the stockholders paid for.
If you want Linux to be used in Airbus Industries, Boeing, etc.,
aircraft to replace those gawdawful flight-management systems now
used, you need to provide hooks so that "unpublished works" can
be linked into the Operating System. This is just an example, but
there is no way in hell that you will ever see the source-code for
such systems unless you worked for those companies. I personally
would rather have Linux in the FMS of the airplane I'm traveling on
then Win/CE.
There is an awful lot or energy being expended in an attempt to
exclude commercial and industrial use of Linux. This is very
counter-productive and may be quite harmful.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
> just some semantics or property of translation, but it is not
> illegal to violate a license.
Depends on the country you live in and the nature of the offence.
At 16:21 04/04/02, Rik van Riel wrote:
>Absolutely agreed. I've already seen it happen a few times that
>a user needed _2_ binary-only modules, modules which weren't even
>available for the same kernel version.
>
>As it stands right now it is IMPOSSIBLE to support binary only
>drivers and I can only see two ways out of this situation:
>
>(1) don't allow binary only modules at all
>
>(2) have a stable ABI for binary only modules and don't allow
> these binary only modules to use other symbols, so people
> in need of binary only modules won't be locked to one
> particular version of the kernel (or have two binary only
> modules locked to _different_ versions of the kernel)
Both or these aren't really practical once you think it through. Don't
forget that each binary module can be wrapped by an GPL-module which the
kernel cannot do anything at all about and the kernel would never even know
a binary only module was loaded because the GPL module does it. There is no
such thing as security... This kind of thing is already in use by at least
two companies I know of (i.e. using open sourced glue modules to binary
only code) so it is not just a theory I am making up...
Just my 2p.
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Thu, Apr 04, 2002 at 10:55:02AM -0500, Richard B. Johnson wrote:
>
> <snip>
>
> There is an awful lot or energy being expended in an attempt to
> exclude commercial and industrial use of Linux. This is very
> counter-productive and may be quite harmful.
>
> <snip>
>
Counter-productive to what ? Harmful to what ?
P.
On Thu, 4 Apr 2002, Richard B. Johnson wrote:
> The term "illegal" historically refers to laws. Laws are rules
> enacted by governments.
>
> A license is permission, granted by a property owner, usually
> but not always, setting forth the conditions of use.
(ianal, and my use of the word was incorrect. Thanks for the
clarification.)
Ingo
On Thu, 4 Apr 2002, Anton Altaparmakov wrote:
> Both or these aren't really practical once you think it through. Don't
> forget that each binary module can be wrapped by an GPL-module which the
> kernel cannot do anything at all about and the kernel would never even
> know a binary only module was loaded because the GPL module does it.
> There is no such thing as security... This kind of thing is already in
> use by at least two companies I know of (i.e. using open sourced glue
> modules to binary only code) so it is not just a theory I am making
> up...
there are countries where this might be considered a 'circumvention of a
technological measure' that controls access to a work. Law enforcement is
not the duty of the copyright holders. There is no such thing as a
burglar-safe house either.
Ingo
On Thursday, April 4, 2002, at 11:55 PM, Richard B. Johnson wrote:
>
> The term "illegal" historically refers to laws. Laws are rules
> enacted by governments.
>
> A license is permission, granted by a property owner, usually
> but not always, setting forth the conditions of use.
Breach of a software license involves an unlawful act under copyright
_law_. Your parking example doesn't involve copyright. If the conditions
of a software license are met, then you have no license and are dealing
with copyright _law_ - oh, they do have that in the US?
> The same applies to error messages and warnings issued by software.
> There is no such thing as an "illegal operand" or "illegal" parameter.
> The correct word is "invalid". Software does not make laws, therefore
> has no right to use the word "illegal". Instead, software makes rules.
> They do not have the power of law.
il?le?gal
adj.
1. Prohibited by law.
2. Prohibited by official rules: an illegal pass in football.
3. Unacceptable to or not performable by a computer: an illegal
operation.
Source: The American Heritage? Dictionary of the English Language,
Fourth Edition
~mc
On Thu, 4 Apr 2002, Tigran Aivazian wrote:
> 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 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...
Because we don't _HAVE_ an API, let alone ABI. What we have is 4000-odd
more or less randomly selected functions and variables that had been used
by some module at some point of history.
It's not an interface, it's a wide-open gut wound. Yes, set of syscalls
is also too large and chaotic, but it's nowhere near that bad.
Situation in the tree itself is also not pretty, but there we at least
can do global changes. With external stuff we don't have that, but
we can say "recompile and go ahead" - it reduces the set of changes we
can do without breakage, though. With external binary stuff, we
are fucking stuck - a lot of things _will_ break it.
Again, that wouldn't be a problem if we had a well-defined interface.
We don't.
Moreover, "well-defined" includes mechanisms in place that would resist
changes and prevent adding random stuff to the interface. Again, no
such thing.
And that's the real problem. If we can turn the thing into stable _sane_
API (and that will mean changes in 3rd-party code and a *lot* of resistance
from binary-only module authors) - wonderful. Until that happens any
talk about kernel/module boundary is crap. There's none. "You are allowed
to use this API without making your work a derivative" is all nice and
dandy. When there is something that resembles an API.
On Thu, Apr 04, 2002 at 08:26:50AM -0500, Ingo Molnar wrote:
> 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
adding export symbol here and there it's the same thing you did in the
redhat kernel and in your tux patches here:
diff -urN net-ref/net/netsyms.c net/net/netsyms.c
--- net-ref/net/netsyms.c Mon Feb 25 22:05:09 2002
+++ net/net/netsyms.c Tue Mar 26 19:56:32 2002
@@ -108,6 +108,8 @@
EXPORT_SYMBOL(sock_create);
EXPORT_SYMBOL(sock_alloc);
EXPORT_SYMBOL(sock_release);
+EXPORT_SYMBOL(sock_map_fd);
+EXPORT_SYMBOL(sockfd_lookup);
EXPORT_SYMBOL(sock_setsockopt);
EXPORT_SYMBOL(sock_getsockopt);
EXPORT_SYMBOL(sock_sendmsg);
@@ -324,6 +326,7 @@
EXPORT_SYMBOL(memcpy_fromiovecend);
EXPORT_SYMBOL(csum_partial_copy_fromiovecend);
EXPORT_SYMBOL(tcp_v4_lookup_listener);
+EXPORT_SYMBOL(cleanup_rbuf);
/* UDP/TCP exported functions for TCPv6 */
EXPORT_SYMBOL(udp_ioctl);
EXPORT_SYMBOL(udp_connect);
@@ -341,6 +344,7 @@
EXPORT_SYMBOL(tcp_getsockopt);
EXPORT_SYMBOL(tcp_recvmsg);
EXPORT_SYMBOL(tcp_send_synack);
+EXPORT_SYMBOL(tcp_send_skb);
EXPORT_SYMBOL(tcp_check_req);
EXPORT_SYMBOL(tcp_child_process);
EXPORT_SYMBOL(tcp_parse_options);
There is no difference at all with what you did above and with my
removal of the _GPL tag from the vmalloc_to_page and the above patch in
tux. According to Alan also the above if done in the US is equivalent
to:
- subverting a digital rights management system
[5 years jail in the USA]
- breaking a license
There's no difference at all, you're also exposing those GPL functions
to potential non GPL drivers out there, without asking all the authors
and contributors of such code first.
This shows how much Alan claim can hold legally, if it can then you're
in trouble in the first place. There's not such thing as a "legal"
kernel that defines the allowed EXPORT_SYMBOL, all kernel trees out
there can be modifed freely, they all have the same legal rights, you
haven't more right than me to add EXPORT_SYMBOL here and there for tux
and altering the EXPORT_SYMBOL has nothing to do with the licence of the
exported sourcecode. It's not that if you do it for tux then I cannot do
it for my own module (no matter if it's binary only or not, that still
is "subverting a digital rights management system" according to Alan).
And the whole point is that it doesn't matter if the module calls
vmalloc_to_page or tcp_send_skb directly via EXPORT_SYMBOL or not, still
the non GPL module can call it indirectly. See below:
For istance I can very well implement a kernel function under the GPL
into the kernel called vmalloc_to_page_for_nongpl, and then I can export
such function that incidentally goes to recall vmalloc_to_page. And
that's perfectly legal because vmalloc_to_page_for_nongpl is GPL and it can call
vmalloc_to_page. Now if you claim that that's not legal, then I claim
all binary only drivers out there are completly illegal, because they
all goes to recall shrink_cache indirectly, and nobody ever asked me if
shrink_cache can be recalled indirectly from a non GPL module.
So unless I've really the right to make all the GPL drivers out there
illegal to use in 2.4 and 2.2, then you can always write GPL wrappers,
to work around the _GPL tagged symbols and this in turn means the _GPL
tag is completly useless and it should be avoided and that we can export
whatever we need.
My understanding is that what the GPL forbids, is for Microsoft to take
your sched.c module and to put it into Windows, that's where BSD is very
bad about. The only thing that can be hidden is the part they wrote
themself, just like with device drivers, the hidden part is the device
driver, they cannot take the kernel and release a binary only statically
linked kernel, only their part can be hidden, your part has to remain
open and if they want to change it their changes must remain open. All
the other arguing about EXPORT_SYMBOL legal issues cannot hold legally I
think, they're emotional and about "moral abuse", not about anything
legal or logical or technical or priorly written anywhere.
Now if my understanding is wrong, I'd like to know of course, I'm not
expert here, but the only logical thing I'm sure about is that if it's
illegal for me to export my GPL wrapper then I've just the right to
make all non GPL drivers illegal, that is the only logical sure thing
that can be deducted. And yes, I'd be really happy if I'd that right.
Everybody should realize that binary only modules are inferior and that
it's a great pain to deal with them and they should be avoided to all
possible extents. I said, I ignore them, I never used a binary only
module in my life, and finally I will break them without care (not
intentionally though). The reason I'm looking into this issue is infact
that I _broke_ them with pte-highmem and so I wanted to teach those guys
that they've to use vmalloc_to_page instead if they want their driver to
work correctly with >800M of ram.
Andrea
On Thu, Apr 04, 2002 at 04:35:33PM +0100, Tigran Aivazian wrote:
> kernel is protecting itself to make sure that "interesting" functionality
I share your same concerns, but I think "interesting" is way too much
vague to hold any legal meaning, furthmore even assuming "important"
means something (obviously not true) it's not priorly written anywhere
that "important" functionality had to be threated in a different manner.
> not necesserily "bad", i.e. it may well be necessary for Linux's survival
I don't really worry about that, important things will defend by
themself, beacuse the GPL solution will be always superior of an order
of magnitude. For istance I would never use the proprietary soltuion
despite it's temporarly better, because it would even prevent me to do
further developement. The important thing is that we never include non
GPL code in the mainline kernel and that the 99% of the code is under
the GPL licence and that it can be intermixed freely (basically only
modulo bsdcomp and a few other very exceptions in their own files with
bold letters about the BSD thing).
The only cases that can live as binary only long term are the ones
speaking with the hardware, when the hardware specs are not published
(and even that often is beaten by the GPL solution).
I think the current way of doing things is fine, I'd simply remove the
_GPL thing from kernel and modutils and then I'd return working on
technical things.
Andrea
At 17:29 04/04/02, Ingo Molnar wrote:
>On Thu, 4 Apr 2002, Anton Altaparmakov wrote:
>
> > Both or these aren't really practical once you think it through. Don't
> > forget that each binary module can be wrapped by an GPL-module which the
> > kernel cannot do anything at all about and the kernel would never even
> > know a binary only module was loaded because the GPL module does it.
> > There is no such thing as security... This kind of thing is already in
> > use by at least two companies I know of (i.e. using open sourced glue
> > modules to binary only code) so it is not just a theory I am making
> > up...
>
>there are countries where this might be considered a 'circumvention of a
>technological measure' that controls access to a work. Law enforcement is
>not the duty of the copyright holders. There is no such thing as a
>burglar-safe house either.
I guess so. Sorry, IANAL and I live in a relatively free country so I
forgot about that place over the pond... (-:
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Thu, 4 Apr 2002, Andrea Arcangeli wrote:
> adding export symbol here and there it's the same thing you did in the
> redhat kernel and in your tux patches here:
it was done by first *asking* all maintainers/authors involved, including
the network folks and Linus. Plus at the time it was done no _GPL way to
signal internal components existed, i'd otherwise have used it to document
that this is an internal export only, for the fully GPL-ed TUX subsystem.
But i'd have no problem with making TUX a fully statically linked thing
either. [it's just so convenient to demand-link TUX as a part of the
kernel.]
> There is no difference at all with what you did above and with my
> removal of the _GPL tag from the vmalloc_to_page [...]
(lets stop this vmalloc_to_page() thing, as i said i agree with providing
it as a published export. It's a small-enough function to be a non-issue.)
> Now if my understanding is wrong, I'd like to know of course, I'm not
> expert here, but the only logical thing I'm sure about is that if it's
> illegal for me to export my GPL wrapper then I've just the right to make
> all non GPL drivers illegal, that is the only logical sure thing that
> can be deducted. And yes, I'd be really happy if I'd that right.
while i'm not a lawyer either, i think the question here is intent, like
in most matters of law/contract. If your intent is to make something that
is a derivative look like something that is not a derivative, you are on
the bad side. Eg. the GPL also uses intent in a form - eg. 'source code'
is not some arbitrary language or format, 'source code' is the preferred
form intended for development. In this sense it's not a GPL-conform
publication of source code to provide hex-encoded objects within C files,
even though C code matches the technical definition of 'source code'.
the other problem is that i think we really want to cooperate with people
who'd like to interface with the kernel in kernel-space, without making
their code a derivative of the kernel, along a well-defined API, even if
those people do not want to GPL their code for whatever reasons. But like
Alex mentioned it, Linux never had a 'well defined module API'. There was
no guarantee, no nothing, it's not an API in the GPL sense i think.
Ingo
[Cc-list trimmed, I guess everyone is on lkml anyway..]
On Thu, Apr 04, 2002 at 06:55:10PM +0200, Andrea Arcangeli wrote:
> further developement. The important thing is that we never include non
> GPL code in the mainline kernel and that the 99% of the code is under
> the GPL licence and that it can be intermixed freely (basically only
> modulo bsdcomp and a few other very exceptions in their own files with
> bold letters about the BSD thing).
Stuff like bsdcomp and the quota stuff are 2clause BSD now and thus fully
GPL-compatible.
"Richard B. Johnson" wrote:
> The term "illegal" historically refers to laws. Laws are rules
> enacted by governments.
As definition (a) in the OED makes clear.
But then the OED also says:
b. Lawless, irregular. Obs. rare.
1728 R. MORRIS Ess. Anc. Archit. 20 How preferable the Beauties of ancient Architecture are to the illegal Practices of our modern Builders.
So if bad architecture can be illegal, I guess bad operands can be too.
Nik
> >there are countries where this might be considered a 'circumvention of a
> >technological measure' that controls access to a work. Law enforcement is
> >not the duty of the copyright holders. There is no such thing as a
> >burglar-safe house either.
>
> I guess so. Sorry, IANAL and I live in a relatively free country so I
> forgot about that place over the pond... (-:
European copyright directive and existing UK law already forbid circumvention of
a copy protection device. They don't cover talking about security flaws,
arresting foreigners who didn't break a law in their own country, and they
permit reverse engineering for compatibility.
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
> adding export symbol here and there it's the same thing you did in the
> redhat kernel and in your tux patches here:
Nothing to do with me. I suspect Ingo and DaveM both discussed it however.
> vmalloc_to_page. Now if you claim that that's not legal, then I claim
> all binary only drivers out there are completly illegal, because they
That is a possible situation. No lawyer I've talked to is prepared to give
a definitive answer on the question of whether it is a derivative work. In
the UK case it recently got even more complex because a judge ruled that
loading a program into memory is clearly an act of copying.
Alan
On Thu, 4 Apr 2002, Andrea Arcangeli wrote:
> I don't really worry about that, important things will defend by
> themself, beacuse the GPL solution will be always superior of an order
> of magnitude. [...]
how do you do that if the GPL is not being honored? What if in 5 years
most of the distros ship heaps of binary-only drivers, filesystems,
storage solutions, and you'll need them just to be able to operate your
daily system. What if you cannot do certain changes to the kernel because
your system will not boot up without a certain binary-only module.
sure, today it's easy to say "i'm not using any 'stinkin binary-only
module". But tomorrow you might have no choice, because vendors will just
use binary-only modules to "support Linux". And while 'no module at all'
used to result in a GPL driver being developed quickly, are you sure
people will write a GPL replacement if there's a binary-only module
available? Even if there are such people, who will test the driver if the
binary-only driver is just 'good enough' for the majority of users? The
wide availability of binary-only modules was not an issue until now, so we
(well, a subset of the copyright holders) allowed it to a certain extent.
The reason why they werent an issue was simple: commercial entities saw
little value in Linux, so commercial kernel development was somewhere
between light and nonexistent.
These days Linux has already grown over a certain size, it's a big factor
in the server world, and it's a tiny but growing subset of the desktop
world as well - large enough to show up on the marketing radar of the
largest volume companies. So we are going to see much more development
that is not sympathetic (ie. neutral or even hostile) towards Linux as a
development community, so we have wear some protective gear against
'interesting' interpretations of the GPL and all related protection
measures we have. Believe me, those companies wouldnt mind if it costed
them $$$ to license the Linux source code, and if they had to sign NDAs to
see it, as long as they can be as secretive about the internal workings of
their technology as possible, and as long as they are able to say to users
that "we support Linux".
it's naive to think that our defenses (the GPL, API practices) that
guaranteed the 'fun' component of Linux development that you and i enjoyed
so much over the years can stay constant over time. New technologies
arise, laws change, even the interpretation of the constitution (of
certain countries) changes.
Ingo
[Truncated CC: list. Eveyone is on lkml AFAICS.]
At 18:55 04/04/02, Alan Cox wrote:
> > >there are countries where this might be considered a 'circumvention of a
> > >technological measure' that controls access to a work. Law enforcement is
> > >not the duty of the copyright holders. There is no such thing as a
> > >burglar-safe house either.
> >
> > I guess so. Sorry, IANAL and I live in a relatively free country so I
> > forgot about that place over the pond... (-:
>
>European copyright directive and existing UK law already forbid
>circumvention of
>a copy protection device. They don't cover talking about security flaws,
>arresting foreigners who didn't break a law in their own country, and they
>permit reverse engineering for compatibility.
>
>You only think this is a free country. Like the US the UK spends a lot of
>time explaining its a free country because its a police state.
Note the "relatively" in my statement. The UK is a _lot_ freer than other
countries are now / used to be... Heck, as you say the UK is freer than US
now (for how long is another question)!
And just ask us people coming from eastern European countries (I am born
Bulgarian) what used to happen to people who spoke against the former
communist governments when they were still in power... - Disappearing for a
few months into a working camp without any notification to relatives or
disappearing for ever without trace were not uncommon occurrences. That
doesn't happen in the UK (AFAIK)...
And yes, the UK isn't completely free, but then there is no such thing as
absolute freedom or you have anarchy. The only country that came close to
political freedom (well, for mature men anyway) was the ancient Greek
democracy...
But I am getting seriously off topic now so I will shut up.
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Thu, Apr 04, 2002 at 04:35:33PM +0100, Tigran Aivazian wrote:
> disappeared). Then, to make your thoughts consistent you would need to
> disable the exported interfaces required for development of a journalling
You assume EXPORT_SYMBOL is an exported, stable interface
that constitutes a GPL barrier. I disagree with
that and I think quite a few others do too.
That seems to be the core issue here...
On Thu, 4 Apr 2002, Arjan van de Ven wrote:
> On Thu, Apr 04, 2002 at 04:35:33PM +0100, Tigran Aivazian wrote:
> > disappeared). Then, to make your thoughts consistent you would need to
> > disable the exported interfaces required for development of a journalling
>
> You assume EXPORT_SYMBOL is an exported, stable interface
> that constitutes a GPL barrier. I disagree with
> that and I think quite a few others do too.
The fact that users have problems with different binary-only
modules not being available for the same kernel version seems
to prove that the "interface" EXPORT_SYMBOL "defines" isn't
stable.
If it was, we'd have an nvidia driver for 2.4, not a whole
serie for each 2.4.x kernel.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Thu, 4 Apr 2002, Richard B. Johnson wrote:
>...
> I am amazed with the number of "lawyers" we have here. Maybe it's
> just some semantics or property of translation, but it is not
> illegal to violate a license.
>
> The term "illegal" historically refers to laws. Laws are rules
> enacted by governments.
>
> A license is permission, granted by a property owner, usually
> but not always, setting forth the conditions of use.
>...
IANAL but my one-and-a-half-years-old copy of German copyright law says
(very shortened):
<-- snip -->
Zu den geschuetzten Werken ... gehoeren insbesondere:
- ... Computerprogramme
...
Wer in anderen als den gesetzlich zugelassenen Faellen ohne Einwilligung
eines Berechtigten ein Werk oder eine Bearbeitung oder Umgestaltung eines
Werkes vervielfaeltigt, verbreitet oder oeffentlich wiedergibt, wird mit
Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.
...
Handelt der Taeter ... gewerbsmaessig, so ist die Strafe Freiheitsstrafe
bis zu fuenf Jahre oder Geldstrafe.
...
<-- snip -->
A _very rough_ summary (I don't think I can really translate this legal
text correctly - there are perhaps people on this list who can make a
real translation) is:
If you copy a computer program in a case where it's not permitted by law
without the permission of the copyright holder the penalty is a fine or up
to three years prison. If you do this commercially the penalty is a fine
or up to five years prison.
> Cheers,
> Dick Johnson
cu
Adrian
On Thu, 4 Apr 2002, Arjan van de Ven wrote:
>
> On Thu, Apr 04, 2002 at 04:35:33PM +0100, Tigran Aivazian wrote:
> > disappeared). Then, to make your thoughts consistent you would need to
> > disable the exported interfaces required for development of a journalling
>
> You assume EXPORT_SYMBOL is an exported, stable interface
> that constitutes a GPL barrier. I disagree with
> that and I think quite a few others do too.
>
> That seems to be the core issue here...
Ok since the issue has been brought up by this thread I felt it was about
time I got this right (beeing a writer of binary "partly" drivers).
The way we have solved it is to divide our drivers into two parts : one
core system and one kernel abstraction layer, which between them has a
defined ABI. The core system (which contains the "intelligent" parts) is
licensed under our own license and therefore only shipped as a
pre-compiled object file (or a collection of several) while the kernel
abstraction layer (which uses the Linux kernel header files and their
"API") is licensed under LGPL and shipped as source which can be compiled
agains any kernel tree. In the end all is linked together as one module
in order to make it load into the kernel.
There are also other reasons why we've made this split and that is to
maintain the same source for several OS'es without too much hassle. If a
new OS comes along, only a new kernel abstraction layer is needed, and
only minor changes are needed for the core system.
Do you think this is a clean way of doing things having the previous
discussions in mind ?
Regards,
--
Steffen Persvold | Scalable Linux Systems | Try out the world's best
mailto:[email protected] | http://www.scali.com | performing MPI implementation:
Tel: (+47) 2262 8950 | Olaf Helsets vei 6 | - ScaMPI 1.13.8 -
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY | >320MBytes/s and <4uS latency
>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)
Do you really want to argue that someone can add a digital rights management
system into a GPL'd product, distribute it, and nobody else can modify that
digital rights management system?
This would mean that I could take the Linux kernel, make some changes to it,
and distribute it. I could add a digital rights management system that made
it impossible to use any of my changed code if you changed anything else at
all, or better yet, you couldn't use it unless you had a hardware dongle.
Is it your position that this would be okay with the GPL? That I could
effectively steal the hard work of all those Linux developers by using their
code in a proprietary product against their wishes as clearly expressed in
the GPL?
You're out of your mind on this one. The GPL gives you the right to modify
GPL'd code. And if you distribute it, you must also distribute the source so
that anyone else can modify it. You cannot contribute to GPL'd code,
distribute it, and restrict its use. That is *precisely* what the GPL was
supposed to prevent.
DS
>A GPL library can only be linked with other GPL-compatible code.
Where in the GPL did you find this provision?!
DS
On Thu, 4 Apr 2002, David Schwartz wrote:
> >A GPL library can only be linked with other GPL-compatible code.
>
> Where in the GPL did you find this provision?!
<-- snip -->
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
<-- snip -->
> DS
cu
Adrian
--
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox
On Fri, 5 Apr 2002 10:24:39 +0200 (CEST), Adrian Bunk wrote:
>On Thu, 4 Apr 2002, David Schwartz wrote:
>
>>>A GPL library can only be linked with other GPL-compatible code.
>>
>> Where in the GPL did you find this provision?!
>
><-- snip -->
>
>b) You must cause any work that you distribute or publish, that in
>whole or in part contains or is derived from the Program or any
>part thereof, to be licensed as a whole at no charge to all third
>parties under the terms of this License.
>
><-- snip -->
>
>> DS
Where does that limit what you can link to? This seems to be a limitation
only on what you can distribute or publish.
DS
> As it stands right now it is IMPOSSIBLE to support binary only
> drivers and I can only see two ways out of this situation:
Two different things "supporting" and "allowing". Currently it is that BOM
are "allowed". (I am not entering the discussion on whether this is good
or bad.) Note that you will not find too many volunteer hackers jumping
in to help "support" users with BOMs - the lk archives will reflect this.
If a vendor decides to release a BOM, then it is implicit in their decision
that by doing so, they have voluntarily denied to accept the support that
comes from having many different persons auditing their code, if it was
available. Hence the issue of "support" lies on their shoulders entirely.
> (1) don't allow binary only modules at all
>
> (2) have a stable ABI for binary only modules and don't allow
> these binary only modules to use other symbols, so people
> in need of binary only modules won't be locked to one
> particular version of the kernel (or have two binary only
> modules locked to _different_ versions of the kernel)
One of the great things about linux is that code quality and performance
have always taken precedence over keeping an interface carved in stone.
We've tried to not make radical inteface changes in stable relases, but
where necessary it has been done, and we were free to do so. If a vendor
with a BOM can't take the time to appropriately update their code and
release a new BOM, then it is clear that they don't really support linux.
If someone has chosen hardware for which a BOM is the only option, then
they need to investigate in detail that vendor's support policy, and get
things in writing if need be (e.g. large installation base, etc) detailing
just how current bugs and new drivers for future kernels will be handled.
If a vendor wants $$$ for such a written support policy, then you have to
factor that into the overall cost of what you are setting up.
If someone is stuck with _two_ unsupported BOMs that are for two different
kernels, then I'd have to say they didn't do their homework when choosing
the hardware and/or determining if the level of support the vendor was
offering was adequate for their particular application. Caveat emptor.
Paul.
> Do you really want to argue that someone can add a digital rights management
> system into a GPL'd product, distribute it, and nobody else can modify that
> digital rights management system?
Thats not what I said.
The GPL protects your right to do certain things to a work. A digital rights
mechanism that does not prevent anything the GPL permits doesn't clash with
the GPL. In other words it can enforce the GPL, it cannot enforce anything
further.
> =09You're out of your mind on this one. The GPL gives you the right=
> to modify
No you just aren't thinking about the larger picture
On Thu, 4 Apr 2002, Rik van Riel wrote:
>
> The fact that users have problems with different binary-only
> modules not being available for the same kernel version seems
> to prove that the "interface" EXPORT_SYMBOL "defines" isn't
> stable.
>
> If it was, we'd have an nvidia driver for 2.4, not a whole
> serie for each 2.4.x kernel.
Actually, I think you have the driver RPMs confused with the driver
itself. We supply prebuilt RPMs for all of the major RPM-based distros
with every driver release.
All of the source code that interacts with the Linux kernel is available
in the kernel driver tarball. This has allowed many people to run the
driver on the officially-unsupported 2.5 kernels, for instance.
The current driver supports all kernels from 2.2.12 through to 2.4.18
(at least).
--
Gareth Hughes
Linux OpenGL Engineer
NVIDIA Corporation
[email protected]
> > Do you really want to argue that someone can add a digital
> > rights management
> > system into a GPL'd product, distribute it, and nobody else can
> > modify that
> > digital rights management system?
> Thats not what I said.
It is precisely the principle you are defending.
> The GPL protects your right to do certain things to a work. A
> digital rights
> mechanism that does not prevent anything the GPL permits doesn't
> clash with
> the GPL. In other words it can enforce the GPL, it cannot enforce anything
> further.
The GPL permits you to modify and use GPL'd code however you wish provided
you don't distribute it. The GPL permits you to modify, use, and distribute
GPL'd code however you like provided you make the source available.
> > =09You're out of your mind on this one. The GPL gives you the right=
> > to modify
> No you just aren't thinking about the larger picture
You are not thinking in principles. A GPL'd package with a digital rights
management scheme you are prohibited from modifying is an abomination to the
principles the GPL was supposed to stand for. This is not free as in
freedom.
If the free software people will sacrifice freedom in exchange for coerced
openness, then someone else will have to stand for freedom.
DS
On Fri, 5 Apr 2002 20:27:18 +0100 (BST), Alan Cox wrote:
>> The GPL permits you to modify and use GPL'd code however you wish
>>provided
>>you don't distribute it. The GPL permits you to modify, use, and distribute
>>GPL'd code however you like provided you make the source available.
>(subject to the other conditions it lays down)
>In the US I believe so. In the UK at least loading the code into memory has
>been ruled an act of copying by a court.
Doesn't matter. The GPL only requires you to offer the source to people you
offer the executables to. So if I copy it and distribute it to myself, I only
have to give the source to myself. Guess what, I already have it. So I'm not
sure why it matters whether I'm copying or not. (See, for example, clause 6
of the GPL)
Do you really think the GPL stands for digital rights management systems
embedded in all your programs that you may not tamper with under threat of
law? This doesn't sound like freedom to me. If you contribute to a GPLed
project, then you get grant precisely the rights the GPL says you grant and
you may impose no restrictions other than those the GPL imposes.
The GPL imposes no restrictions on modifications whatsoever. What could be
clearer?
DS
> The GPL permits you to modify and use GPL'd code however you wish provided
> you don't distribute it. The GPL permits you to modify, use, and distribute
> GPL'd code however you like provided you make the source available.
(subject to the other conditions it lays down)
In the US I believe so. In the UK at least loading the code into memory has
been ruled an act of copying by a court.
> > No you just aren't thinking about the larger picture
>
> You are not thinking in principles. A GPL'd package with a digital rights
> management scheme you are prohibited from modifying is an abomination to the
> principles the GPL was supposed to stand for. This is not free as in
> freedom.
If you are prohibited from modifying the code then the code violates the GPL
so isnt GPL so isnt distributable as GPL.
[email protected] said:
> If such a misconception exists (incorrect or not), it would be helped
> if the majority of people who do Linux kernel work and are working at
> these companies didn't use [email protected] (or other anonymous) email
> addresses in their postings here.
> The Vger postmasters knows who you cowards really are, because we see
> the final destination when your email bounces :-))))
It's not that simple. Using a company email address implies that you accept
company standards of reliability for email. Sometimes it even means you
have to use Notes.
We know who we all work for, in the majority of cases. There are advantages
to not wearing your allegiance on your sleeve in technical fora too.
--
dwmw2
> You are not thinking in principles. A GPL'd package with a digital rights
> management scheme you are prohibited from modifying is an abomination to the
> principles the GPL was supposed to stand for. This is not free as in
> freedom.
How about reading my message instead of spouting off randomly. You obviously
aren't following