LinkSys and the GPL - again [LWN.net]

LinkSys and the GPL - again

Posted Oct 1, 2003 12:11 UTC (Wed) by torsten (guest, #4137) [Link]

"When taken in the context of Linus's comments on the GPL and binary modules ..."

For reference, Linus Torvalds states that as long as binary modules use only the public kernel API, they can be considered to be interacting with the kernel rather than linked with the kernel. If the kernel proper is modified, or the module is statically linked, these two acts are unquestionably linking.

Many people believe that all interaction should be considered linking, but this has little effect on the end-user. Companies can distribute binary-only kernel modules, not in conjunction with the kernel. End-users are allowed to load whatever modules they wish, binary or not. It's the use of binary modules in conjunction with the kernel that is questionable. That's partially this little spat comes from.

"There is another issue in the way that the binary modules were linked to the kernel. The binary modules make use of interfaces that are part of the code that are patched into the kernel."

This was Linksys' undoing. Had they done something like post generic kernel sources, there may still be some question as to how the linking was done. However, when compiling the provided sources, it is possible to enable the wireless networking such that you get a compile failure on kernel interfaces that were added to the kernel to support the Broadcom drivers.

This unquestionably falls into the realm of linking, and some kernel developers are calling for the GPL release of the Broadcom wireless drivers, arguing, that the Linux sources have adequately benefited Linksys, they should have no problem with this. There are other than FSF lawyers involved, as Erik Anderson has already lawyered-up and sent some nastygrams Linksys' way.

LinkSys and the GPL - again

Posted Oct 1, 2003 14:23 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

"For reference, Linus Torvalds states that as long as binary modules use only the public kernel API, they can be considered to be interacting with the kernel rather than linked with the kernel."

For reference, my cat states that the sky is pink. That doesn't make it true.

Linus' comments on the matter of binary-only modules do not affect the situation in any way. He elected not to collect copyright assignments, and is not in a position to make retroactive changes to the licence of the code.

His interpretation of the GPL is no more or less relevant than anyone else's.

Personally, I believe it's very clear that modules are obviously derived works of the kernel itself, and that binary-only modules are unlawful even if distributed as separate works.

According to Schrödinger, we are both right until such time as it comes to court and a result is actually observed.

LinkSys and the GPL - again

Posted Oct 2, 2003 2:12 UTC (Thu) by cate (subscriber, #1359) [Link]

"His interpretation of the GPL is no more or less relevant than anyone else's."

No. Everybody should read the COPYING in the kernel top directory. It is not the standard GPL COPYING, but it have two additional remarks, one about the version (only v2) and the other about module linking. This COPYING has surely more legal weight that the standard GNU COPYING. If you want to protect your code with normal GPL, you should explicit write it (i.e. in the header of your file.).

LinkSys and the GPL - again

Posted Oct 2, 2003 2:38 UTC (Thu) by andersee (subscriber, #7073) [Link]

"Everybody should read the COPYING in the kernel top directory."

Everyone including you it seems... So do take a moment and read it. The COPYING file does NOT discuss or make exceptions for kernel modules at all. It makes an exception for user programs that use kernel services by normal system calls. And limits things to the GPLv2. Nothing more. Nothing less.

I do not understand where people get the misguided idea that binary only kernel modules are permitted by this license. They arn't. The only conceivable justification is because Linus once said so. Well, Linus stopped being the sole copyright holder over 10 years ago, so the best he can do is make decisions about the code he wrote. Until the kernel COPYING file changes and every contributor to the kernel agrees to the new provisions, there is NO justification whatsoever for binary only kernel modules. As a contributor to the Linux kernel, I know I have no plans to re-license my contributions. And some people, such as Leonard Zubkoff, would have difficulty making posthumous licensing decisions. ergo, binary only kernel modules are not allowed, and the COPYING file is not going to be changing to permit them any time soon.

LinkSys and the GPL - again

Posted Oct 2, 2003 3:36 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

Copyright isn't held by dead people; it passes on with the estate. This merely makes it harder to find all the copyright holders than it already is; it doesn't make it impossible.

What makes it impossible to change the licence is not the fact that it is utterly impracticable to trace all copyright holders, but rather the fact that some of them are actually standing up and saying "NO" to the proposed change.

And the fact that it's considered necessary to make an explicit exception to the licence even for userspace programs using the syscall interface makes it entirely clear that it is considered similarly necessary to make an exception for modules using exported symbols.

An exception which has not, and can never be, granted.

LinkSys and the GPL - again

Posted Oct 10, 2003 5:40 UTC (Fri) by Wol (guest, #4433) [Link]

"Well, Linus stopped being the sole copyright holder over 10 years ago, so the best he can do is make decisions about the code he wrote."

Actually, this "change" to the GPL for linux was added about 10 years ago (if not more), and everybody who has contributed since can be presumed to have agreed to it.

If that clause was already there when you contributed to the kernel, then the law is pretty clear. You SHOULD have known what you were doing when you modified someone else's copyrighted work, and if you didn't then that's your problem. This is EXACTLY one of the arguments being used to shoot SCO down ...

Cheers,
Wol

LinkSys and the GPL - again

Posted Oct 2, 2003 2:57 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

"No. Everybody should read the COPYING in the kernel top directory. It is not the standard GPL COPYING, but it have two additional remarks, one about the version (only v2) and the other about module linking."

Your copy evidently differs from mine, which says this:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.

Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Linus Torvalds

The former exception is for userspace making use of the kernel via system calls, since without such an explicit exception even userspace would be considered a derived work. No such exception is made for modules, which are even more obviously derived than userspace is. It's been there since version 0.99.11, in July 1993. The COPYING file was first added, without any such comment, in 0.99.7 in March of that year.

The latter comment was added recently and is not a modification to the licence of the code; rather an editorial comment that, although you can go and fork the kernel and release it under GPLv3, Linus himself won't be accepting GPLv3 code. He does have the right to say that, but he does not have the right to remove section 9 of the GPL and prevent anyone else from releasing their code under GPLv3.

LinkSys and the GPL - again

Posted Oct 1, 2003 11:12 UTC (Wed) by rriggs (subscriber, #11598) [Link]

Wow. Excellent point.

This would seems to have implications for any embedded use of Linux -- binary modules would not appear to be permissible. And it impacts not only embedded use, but any distribution of kernel along with binary modules. This is probably a reason why IBM and other hardware manufacturers have refused to create their own Linux distribution.

Modules, GPL

Posted Oct 1, 2003 16:31 UTC (Wed) by jeff@uclinux.org (subscriber, #8024) [Link]

"This would seems to have implications for any embedded use of
Linux -- binary modules would not appear to be permissible"

A program is something which is "linked", an operation performed by
a linker which is a tool that resolves symbol address, etc, references.
That is, "linked" in this use has a specific meaning, not the general meaning
of connected to or related with or aggregated with. An example of
what I mean by aggregation here would be both works held in a filesystem.

Aggregation of works into physical media does not constitute linking, and
therefore does not cause the whole to be a derived work. It is clearly not
the intention of the GPL here to make the result of aggregation a derived
work. In the specific case of embedded systems, it is not different.
A FLASH device is another form of physical media and has no special
properties that suddenly make the things placed into it "linked", thus
causing the whole of it's contents to become a derived work under the GPL
if any part of it was to begin with. A FLASH used in this way is simply
a container for a filesystem.

In the case of kernel modules, they are clearly linked (specific meaning) to the
kernel as a whole. The linker is contained within the kernel proper, but none the
less linking is performed. There is no reason for the purposes of this discussion it
need be a seperate program, the end result is modules are linked to the kernel
symbols. There is one and only one reason binary modules are permitted of
which I am aware, and that is because Linus has made an exception and clearly
said that they are allowed, and the other copyright holders of the kernel seem to
have accepted this (by default). This exception does not apply if, for example,
the module is based on GPL'd code (eg, another driver so licensed) or if the
kernel needs to be modified specifically and only to allow the module to
function (again, because Linus makes this distinction).

This says aggregating modules, which fall into the exception Linus has given,
and the community has accepted, into a physical media does not automatically
make them derived works. Also, this includes FLASH media. Therefore, this is
not a reason that binary only modules would be disallowed in embedded applications.

We use them in many places, in fact. There are all sorts of reasons why, and silicon
vendors require it as often as not. That said, we are usually sucessful at convincing
them that there is no reason to keep the driver private. When not, extreme care
is necessary in meeting the first of the 2 conditions above which would invalidate
the exception Linus gave (GPL code in the module itself).

D. Jeff Dionne.
www.uClinux.org

Modules, GPL

Posted Oct 1, 2003 18:58 UTC (Wed) by yashi (guest, #4289) [Link]

> Linus has made an exception and clearly said that they are allowed

It seems to me that Linus has been changing his stance on kernel module and GPL.

from http://www.ussg.iu.edu/hypermail/linux/kernel/0210.2/0603.html

> The _only_ thing that allows for non-GPL modules is copyright law, and
> in particular the "derived work" issue. A vendor who distributes non-GPL
> modules is _not_ protected by the module interface per se, and should
> feel very confident that they can show in a court of law that the code
> is not derived.

Modules, GPL

Posted Oct 1, 2003 19:20 UTC (Wed) by jeff@uclinux.org (subscriber, #8024) [Link]

Yes, Linus wrote this...

"The _only_ thing that allows for non-GPL modules is copyright law, and
in particular the "derived work" issue. A vendor who distributes non-GPL
modules is _not_ protected by the module interface per se, and should
feel very confident that they can show in a court of law that the code
is not derived."

That is the condition I was talking about when I wrote this:

"...extreme care is necessary in meeting the first of the 2
conditions above which would invalidate the exception Linus
gave (GPL code in the module itself)."

And yes, the situation is one built on what has been done before and
not challenged. IMHO, Linus should have been more clear. There are
a number of ways to read this statement, and one has to look at the
context it was in. It was with respect to someone trying to insert code
into the kernel that would allow a binary only module to work... or at
least that is how I read it.

I suspect the sitiation will remain grey, and we will continue to have to
rely on his exception... and of course make sure binary modules are
clean of GPL code.

binary modules Modules and linking

Posted Oct 2, 2003 0:25 UTC (Thu) by dambacher (subscriber, #1710) [Link]

Hi everybody

IMHO now it's time for linus and all to write down this agreement to the kernel license file with the required comments, so that it is clear from now on that binary modules are allowed to link to the kernel

* if they don't themselve consist of GPL'ed code

and maybe include

* if they only link to interface provided by the stock kernel
(and therefore work with any unmodified copy of such a kernel version)

This would lead us from this grey part of the GPL and provieds means for business to provide binary drivers for special hardware (which maybe then includes the bcm4301) without leagal or other repressions.

Greetings
Ulf

binary modules Modules and linking

Posted Oct 2, 2003 1:09 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

"IMHO now it's time for linus and all to write down this agreement to the kernel license file with the required comments, so that it is clear from now on that binary modules are allowed to link to the kernel"

No, it is not time to do this. It would be a change in the licence, and would require unanimous approval of all copyright holders. All that Linus can do is offer an interpretation, which is no more relevant than anyone else's interpretation. Except perhaps RMS, as author of the GPL, who if I recall correctly was of the opinion that it does not permit binary-only modules.

If Linus tells you he thinks it's OK for you to distribute a binary-only module, all that means is that he, personally, won't sue you for it unless he changes his mind.

Conversely, if I tell you I think it's not, that means that I may do so at some point in the future, should I feel like it.

The fact that nobody's sued for it yet is certainly not the same as a hypothetical legal precedent where we sue and lose. It changes the situation no more than Linus' declaration does.

And it's still not relevant in this particular case. This is not 'mere aggregation' of a bunch of useful software onto a CD for distribution. The modules are not being distributed 'as separate works'. This is a larger work with a uniform purpose, based upon the Linux kernel.

binary modules Modules and linking

Posted Oct 2, 2003 8:37 UTC (Thu) by jeff@uclinux.org (subscriber, #8024) [Link]

Yes, I agree. That should be done.
Binary modules are the foundation of many uses, the situation
needs to be clarified. And as I wrote above, a FLASH is just a
container for a filesystem. But still dwm2 writes:

"This is not 'mere aggregation' of a bunch of useful software onto a
CD for distribution. The modules are not being distributed 'as separate
works'. This is a larger work with a uniform purpose, based upon the
Linux kernel."

Are you suggesting that anything in the FLASH is also "...based upon
the Linux kernel"? Not the case, mkcramfs is not a linker. Modules
are seperate _until_ they are loaded, even in the case of a FLASH
filesystem (given the 2 caveats I outlined). Seperate programs held
in the FLASH are just that, "purpose" is not relevant (a CD has a
"uniform purpose" also).

I fully agree though that if hooks have been inserted into the kernel in
this case for these modules (as the reports suggest), that they are
in violation of the exception. If the mangement software has been
linked with iptables code (as Erik suggests, but it is still possible
that they simply call the ioctl()s needed) that it would be as well.

binary modules Modules and linking

Posted Oct 2, 2003 9:03 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

Are you suggesting that anything in the FLASH is also "...based upon the Linux kernel"? Not the case, mkcramfs is not a linker. Modules are seperate[sic] _until_ they are loaded,

I fail to comprehend your reason for using the terms 'linking', 'link' and 'linker'. These terms do not exist in the GPL except once in the final paragraph of the COPYING file, where the LGPL is 'advertised'.

If you wish to make statements about the GPL, please do so in terms which are relevant to the GPL.

I assert, using the phrases used in paragraph five of section 2 of the GPL, that binary-only kernel modules cannot be reasonably considered independent and separate works in themselves since they cannot be created without Linux kernel headers, and have no reason for existence without a Linux kernel into which they can be loaded.

I further assert, in the knowledge that there will be argument regarding the former assertion, that in this case they are not being distributed as separate works but rather that the firmware on Linksys' product is a whole which is a work based on the Program.

To consider whether two articles can be considered independent and separate, it is useful to consider how each would fare in the absence of the other. In the case of this product, it is clear that it would be entirely useless if either the kernel image or the modules were absent, and they are clearly not independent.

Is that clearer?

I fully agree though that if hooks have been inserted into the kernel in this case for these modules (as the reports suggest), that they are in violation of the exception.

The exception of which you speak does not exist. The only exception in the COPYING file is that for userspace.

binary modules Modules and linking

Posted Oct 2, 2003 11:04 UTC (Thu) by jeff@uclinux.org (subscriber, #8024) [Link]

1. you didn't answer the question. Do you think the whole of the firmware
is a GPL violation?

2. Linux is in C, in that context if you read what I wrote you'll see that
I therefore talk about 2 concepts WRT derived works. a, you have
incorporated code (in this case GPL) from another source. b, you
link with code (in this case GPL) from another source. That's where,
it comes from... If you disagree with this interp of "derived work" that's
certainly ok, but it's not a case of my not using terms not relevant to
the GPL :-O

3. "...the firmware on Linksys' product is a whole which is a work based
on the Program" Again I ask does this mean you think embedded linux
must always use only Free Software, and specifically that this whole image
is a GPL violation? This can be shown to be false, a FLASH image is a
filesystem (in this case), which you well know.

4. The exception does exist, because people have relied on it with the
full knowledge of the community. I have said that it's status is grey.
The fact that it's validity is in dispute makes the exception no less real.
I assert there are good reasons for it to exist. As a HAM I'm outraged by
the restrictions on Software Defined Radio, but I still have to comply with
the law (and no, I had nothing to do with the firmware in this unit).
If the community makes a decision to enforce the GPL strictly WRT
drivers (binary modules), that is a different matter but it isn't so just
because you say it is. And you still will not get source for the driver
in this case because the FCC says you can't have it, and writing your
own is a crime. Wrong as that is. Which will mean the product will
have to be pulled, but this is not a reason to violate the license the
community decides on, mearly a reason to consider in policy makeing
(in favor of this IMHO reasonable exception).

5. "useful to consider how each would fare in the absence of the other...
Is that clearer?" No sorry, You can't have that one. My files read/written
by program X are not a derived work of program X. They would be under
that definition because I can define program X such that the files are
useless with it, and it need not be a closed format, digital signatures will
make that true also. That is a reason the definition of "derived" has to be
sharper, and why I offer "linking". It certainly is the standard test of what
a program contains... because it's what is in the program's memory space
as it's text and (static) data.

6. Up until recently (libc6) all userspace programs included the kenel headers.
Kernel headers are also included by programs built against uC-libc although
Erik's work on uClibc (without the -) has eliminated that (more or less).
Does this mean you think that all things linked with libc5 and uC-libc are
derived works of the kernel? Clearly not?

Free Software will win in the long run. We can't force others to share that
goal all at once, you have to do it by degrees, then we win. When I started
uClinux and uC-libc, there was _no_ embedded linux. We've come a long
way towards that goal, and I for one don't want to see a whole class of
device not use Linux because vendors will not let the drivers be free or
because a government agency will not... as long as we keep building the
foundation.

binary modules Modules and linking

Posted Oct 2, 2003 15:25 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

1. you didn't answer the question. Do you think the whole of the firmware is a GPL violation?

All such questions are meaningless and academic. There's no right answer until it's actually determined in a court of law. But since I'm volunteering an opinion on a similar question which I do intend to make real, I suppose it's only fair that I try to answer this one...

I'm fairly sure that any court would find that the Linksys firmware as a whole is 'a work based on the Program'. During normal operation, it runs entirely in kernel mode, forwarding packets between its two (or more) network interfaces. The code which performs those operations cannot reasonably be considered as anything other than a coherent whole.

The question of whether the ancillary userspace programs which allow occasional configuration should also be considered part of that whole is less clear. When taken in conjunction with the clear intent of the exception for userspace programs, I suspect a court would be likely to rule in the negative. I couldn't be entirely sure of that though.

2. ... If you disagree with this interp of "derived work" that's certainly ok, but it's not a case of my not using terms not relevant to the GPL

OK; then I shall interpret "mkcramfs is not a linker" as a statement that joining files onto a file system image does not make them derived works of each other, and I shall agree with you on that point.

3. ... Again I ask does this mean you think embedded linux must always use only Free Software, and specifically that this whole image is a GPL violation?

I've offered my speculation on this above. I suspect a court would rule that it is not, as long as the kernel modules are available under the terms of the GPL.

4. The exception does exist, because people have relied on it with the full knowledge of the community. I have said that it's[sic] status is grey.

You seem to be confused here with either trademark law, where you lose what you don't protect, or with estoppel. Neither are relevant in this case. Linus may personally be restrained by equitable estoppel if he were to attempt to sue for GPL violation with respect to a binary-only module. I certainly am not.

His statement that it might be OK holds no more weight than mine that it is not. They are both merely opinions, and neither is right or wrong until a court decides on the matter. His statement is no more an 'exception' than mine is, merely an interpretation. This is because neither are unanimously agreed by all the copyright holders, and hence noither can actually change anything.

What I suspect will carry more weight, ironically, is the exception which he actually did make for userspace. Since it was clearly opined that userspace needed such an exception in order to be considered other than a derived work, it cannot possibly by held that loadable modules, which are far more incestuously intertwined with the kernel itself, do not need such an exception to be made unanimously by all copyright holders. Such an exception does not exist and cannot now be made without unanimous consent.

5. ... That is a reason the definition of "derived" has to be sharper, and why I offer "linking".

That seems to be clearly incompatible with the definition which was intended by the original licence, since it was deemed necessary to explicitly make an exception for userspace; an exception which would not have been necessary if this were the intended meaning.

6. ... Does this mean you think that all things linked with libc5 and uC-libc are derived works of the kernel? Clearly not?

Due to the provisions of the exception which was made for userspace, I believe that they are not.

I for one don't want to see a whole class of device not use Linux because vendors will not let the drivers be free or because a government agency will not... as long as we keep building the foundation.

Then your goals differ violently from mine and those of many people with whom I've discussed the issue. I do want to see people refrain from using and benefiting from my code, if they are unable or unwilling to conform to its licence and release their derivative work as Free Software.

If I wanted people to feel free to take my code and use it in non-Free Software, then I could have released it under the BSD licence, or 'GPL but not if you really really don't feel like it', rather than the GPL.

I don't. I didn't.

binary modules Modules and linking

Posted Oct 3, 2003 16:04 UTC (Fri) by Gady (subscriber, #1141) [Link]

The entire discussion here centers around what is a "derived work" and what is a "mere aggregation" as in the last paragraph of section 2 of the GPL.

However, going back to Linus' comment about the terms for binary modules, we see that there is no way this comment can be interpreted except this: binary modules confirming with these coditions are considered an aggregation. A company which simply distributes a binary driver stand alone is undeniably complying with the GPL, hence these terms set by Linus are irrelevant. Thus this is the only possible interpretation of this comment.

While someone might claim that this is only Linus' interpretation of these two terms, this would not be quite so simple. Interpretations tend to take on a legal signifcance of their own with time. This is especially true if the interpretation stood the test in court, but even if this case, an interpretation made publicly and not openly refuted carries with it a certain legal weight. How much is of course for a court to decide, but this is certainly NOT just Linus' personal opinion.

binary modules Modules and linking

Posted Oct 3, 2003 17:47 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

The entire discussion here centers around what is a "derived work" and what is a "mere aggregation" as in the last paragraph of section 2 of the GPL.

And also the meaning of "as separate works" and "as part of a whole which is a work based on the Program."

A company which simply distributes a binary driver stand alone is undeniably complying with the GPL, hence these terms set by Linus are irrelevant.

It is not possible to create a kernel module without extensive use of the Linux kernel headers and interfaces, including many inline functions. It cannot be created as a work in isolation.

It was deemed necessary by Linus to make specific exception for userspace to use the ABI defined in those headers. Userspace makes little or no use of inline functions, uses a far smaller amount of the content of these headers than kernel modules do, and does not link dynamically to the kernel.

Such an exception would be redundant if the meaning of "derived work" intended by Linus and the original copyright holders did not, without such exception, include userspace programs using those headers and making system calls into the kernel.

The presence of the exception serves as a clarification, with relevance because it was present and accepted from the beginning, that the originally intended meaning of 'derived work' would, without the exception, have included userspace.

If userspace needs such an exception, it cannot possibly be found that kernel modules do not, since they are so much more closely based on the kernel.

It's clear that there is no exception for modules.

On what part of the above are you still confused?

Interpretations tend to take on a legal signifcance[sic] of their own with time. This is especially true if the interpretation stood the test in court, but even if this case, an interpretation made publicly and not openly refuted carries with it a certain legal weight.

How can it have been refuted without going to court? A court is the only form of proof that there can be. I shall assume you meant 'disputed' or 'rebuked'.

I believe you are thinking of the principle of equitable estoppel, to which I referred before. While that may restrain Linus himself from bringing a case against a distributor of binary-only modules, it doesn't affect third parties such as myself.

binary modules Modules and linking

Posted Oct 9, 2003 12:10 UTC (Thu) by AJWM (subscriber, #15888) [Link]

It is not possible to create a kernel module without extensive use of the Linux kernel headers and interfaces

While that may be true, it may also be irrelevant. Courts have ruled that mere use of header files does not constitute copyright infringement. Header files are more functional than expressive in nature, so a weaker standard applies. (Fair use may also apply.) This came up in the BSD vs ATT/ULS case, and was one of the reasons that the judge ruled that ATT ruled against ATT (there were other reasons, of course).

If that's the case, then a binary module (not derived from any GPL'd .c files, but possibly #including .h files) shipped by itself (think nVidia drivers) may well be allowable. That it is arguably non-functional without being loaded into the kernel is also irrelevant; copyright is about expression, not function.

binary modules Modules and linking

Posted Oct 10, 2003 6:54 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

"While that may be true, it may also be irrelevant."

I agree, since the GPL clearly requires, in some circumstances, that the source of even non-derived works must be released under the terms of the GPL.

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

binary modules Modules and linking

Posted Oct 10, 2003 5:58 UTC (Fri) by Wol (guest, #4433) [Link]

"The presence of the exception serves as a clarification, with relevance because it was present and accepted from the beginning, that the originally intended meaning of 'derived work' would, without the exception, have included userspace.

"If userspace needs such an exception, it cannot possibly be found that kernel modules do not, since they are so much more closely based on the kernel."

I think you will find that intended meaning of 'derived work' was NOT clear as to whether it included user space. The exception MAY NOT be needed, but was given in order to make the status of user space CLEAR and UNAMBIGUOUS whereas it was a grey area before.

Oh, btw, Linus opinion is more important than most peoples' over kernel copyright issues because he is a holder of copyrights in the kernel. Over and above that it is more important than ANYONE else because he is the holder of the kernel copyright. There is such a thing - it is separate from the individual copyrights that make up the kernel - and it overarches but does not override those individual copyrights. But as the owner of the overarching kernel copyright, a judge is bound to place far more weight on Linus' interpretation of the rules as they apply to the kernel, than he has to anybody else.

Cheers,
Wol

Modules, GPL

Posted Oct 2, 2003 10:34 UTC (Thu) by Ross (subscriber, #4065) [Link]

Yes, he has. However my understanding is that the last time this was debated they were going to utilize the tainting mechanism for modules to describe exactly which function calls non-GPLed modules were allowed to use. GPLed modules would be identified by using a macro to describe the license which non-GPLed modules were not allowed to use. Users would get link errors if GPL-only symbols were used by non-GPLed modules. And Linux stated that modules should not add new hooks, system calls, or other mechanisms to bypass this scheme.

Modules, GPL

Posted Oct 2, 2003 0:59 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

"There is one and only one reason binary modules are permitted of which I am aware, and that is because Linus has made an exception and clearly said that they are allowed, and the other copyright holders of the kernel seem to have accepted this (by default).

Your analysis seems very flawed here. Linus was no longer the sole copyright holder of the Linux kernel, long before the module loading mechanism was added. He is not in a position to make any changes to the licence without unanimous approval from the owners of the code, which he clearly does not have.

Furthermore, your assertion that the other copyright holders have accepted it is not entirely true. I do not accept it and I know other copyright holders who do not. We just haven't taken it to court yet. It's trademarks you lose by failing to defend them, not copyright.

Nothing makes binary-only modules legal. Especially when they're not distributed as separate works.

LinkSys and the GPL - again

Posted Oct 2, 2003 3:03 UTC (Thu) by zmower (subscriber, #3005) [Link]

Spelling it out:

"If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works."

If they've modified the main part of the kernel they fail the independant test. I'm not sure about the "separate works" part but logic tells me it is irrelevant having failed the first part.

"But when you distribute the same sections as part of a whole which is a work based on the Program,"

They've distributed an image of linux so the next part is applicable.

"the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."

So the whole of their kernel and the modules falls under the GPL.

It doesn't look good for Link Sys. And as they're lawyering up this is sad for the Free Software community as well. We don't need another SCO-scale case atm. The best compromise would probably be to right the very bad engineering mistake and make the source of the main kernel changes available. I wish the FSF the best of luck and hope for a speedy resolution.