C.2 Notices on Binary Kernel Modules
Recurring controversy has
erupted over loadable kernel modules not distributed under the terms
of the GPL. Many companies already ship such binary modules and many
industry players contend that such modules are permitted. Yet many
Linux kernel developers have come out rather strongly against this
practice. Here are some messages sent to the Linux kernel mailing
list by Linus Torvalds and Alan Cox that provide some insight as to
the use of binary modules.
C.2.1 First Posting by Linus in Kernel Interface Thread
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Kernel interface changes (was Re: cdrecord problems on
Date: 1999-02-05 7:13:23
In article <36bab0c7.394438@mail.cloud9.net>,
John Alvord <jalvo@cloud9.net> wrote:
>On Thu, 4 Feb 1999 22:37:06 -0500 (EST), "Theodore Y. Ts'o"
><tytso@MIT.EDU> wrote:
>>
>>And as a result, I've seen more than a few MIT users decide to give up
>>on Linux and move over to NetBSD. I think this is bad, and I'm hoping
>>we can take just a little bit more care in the 2.2 series than we did in
>>the 2.0 series. Is that really too much to ask?
Yes. I think it is. I will strive for binary compatibility for
modules, but I _expect_ that it will be broken. It's just too easy to
have to make changes that break binary-only modules, and I have too
little incentive to try to avoid it.
If people feel this is a problem, I see a few alternatives:
- don't use stuff with binary-only modules. Just say no.
- work hard at making a source-version of the thing available (it
doesn't have to be under the GPL if it's a module, but it has to be
available as source so that it can be recompiled).
- don't upgrade
- drop Linux
>I suggest we treat binary compatibility problems as bugs which need to
>be resolved during the 2.2 lifetime. Even with all care, some changes
>will occur because of mistakes... if we cure them, there will be
>limited impact to users.
It's often not mistakes. Things sometimes have to change, and I
personally do not care for binary-only modules enough to even care. If
people want to use Linux, they have to live with this. In 2.2.x, the
basics may be stable enough that maybe the binary module interface won't
actually change. I don't know. That would be good, but if it is not to
be, then it is not to be.
I _allow_ binary-only modules. I allow them because I think that
sometimes I cannot morally require people to make sources available to
projects like AFS where those sources existed before Linux. HOWEVER,
that does not mean that I have to _like_ AFS as a binary-only module.
Quite frankly, I hope AFS dies a slow and painful death with people
migrating to better alternatives (coda, whatever). Or that somebody
makes an AFS client available in source form, either as a clone or
through the original people.
As it is, what has AFS done for me lately? Nothing. So why should I
care?
Linus
C.2.2 Second Posting by Linus in Kernel Interface Thread
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Kernel interface changes (was Re: cdrecord problems on
Date: 1999-02-07 8:15:24
In article <79g5bu$spd$1@palladium.transmeta.com>,
H. Peter Anvin <hpa@transmeta.com> wrote:
>
>* Linus Torvalds has no interest whatsoever in developing such a
> plug-in ABI. Someone else is welcome to do it.
No, it's even more than that.
I _refuse_ to even consider tying my hands over some binary-only module.
Hannu Savolainen tried to add some layering to make the sound modules
more "portable" among Linux kernel versions, and I disliked it for two
reasons:
- extra layers decrease readability, and sometimes make for performance
problems. The readability thing is actually the larger beef I had
with this: I just don't want to see drivers start using some strange
wrapper format that has absolutely nothing to do with how they work.
- I _want_ people to expect that interfaces change. I _want_ people to
know that binary-only modules cannot be used from release to release.
I want people to be really really REALLY aware of the fact that when
they use a binary-only module, they tie their hands.
Note that the second point is mainly psychological, but it's by far the
most important one.
Basically, I want people to know that when they use binary-only modules,
it's THEIR problem. I want people to know that in their bones, and I
want it shouted out from the rooftops. I want people to wake up in a
cold sweat every once in a while if they use binary-only modules.
Why? Because I'm a prick, and I want people to suffer? No.
Because I _know_ that I will eventually make changes that break modules.
And I want people to expect them, and I never EVER want to see an email
in my mailbox that says "Damn you, Linus, I used this binary module for
over two years, and it worked perfectly across 150 kernel releases, and
Linux-5.6.71 broke it, and you had better fix your kernel".
See?
I refuse to be at the mercy of any binary-only module. And that's why I
refuse to care about them - not because of any really technical reasons,
not because I'm a callous bastard, but because I refuse to tie my hands
behind my back and hear somebody say "Bend Over, Boy, Because You Have
It Coming To You".
I allow binary-only modules, but I want people to know that they are
_only_ ever expected to work on the one version of the kernel that they
were compiled for. Anything else is just a very nice unexpected bonus if
it happens to work.
And THAT, my friend, is why when somebody complains about AFS, I tell
them to go screw themselves, and not come complaining to me but complain
to the AFS boys and girls. And why I'm not very interested in changing
that.
Linus
C.2.3 Post by Alan Cox in Kernel Hooks Thread
This is a response to a posting by Theodore
Ts'O.
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
Date: 2000-11-09 14:26:33
> Actually, he's been quite specific. It's ok to have binary modules as
> long as they conform to the interface defined in /proc/ksyms.
What is completely unclear is if he has the authority to say that given that
there is code from other people including the FSF merged into the tree.
I've taken to telling folks who ask about binary modules to talk to their legal
department. The whole question is simply to complicated for anyone else to
work on.
Alan
C.2.4 First Post by Linus in Security Hooks License Thread
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH] make LSM register functions GPLonly exports
Date: 2002-10-17 17:08:19
Note that if this fight ends up being a major issue, I'm just going to
remove LSM and let the security vendors do their own thing. So far
- I have not seen a lot of actual usage of the hooks
- seen a number of people who still worry that the hooks degrade
performance in critical areas
- the worry that people use it for non-GPL'd modules is apparently real,
considering Crispin's reply.
I will re-iterate my stance on the GPL and kernel modules:
There is NOTHING in the kernel license that allows modules to be
non-GPL'd.
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.
The module interface has NEVER been documented or meant to be a GPL
barrier. The COPYING clearly states that the system call layer is such a
barrier, so if you do your work in user land you're not in any way
beholden to the GPL. The module interfaces are not system calls: there
are system calls used to _install_ them, but the actual interfaces are
not.
The original binary-only modules were for things that were pre-existing
works of code, ie drivers and filesystems ported from other operating
systems, which thus could clearly be argued to not be derived works, and
the original limited export table also acted somewhat as a barrier to
show a level of distance.
In short, Crispin: I'm going to apply the patch, and if you as a copyright
holder of that file disagree, I will simply remove all of he LSM code from
the kernel. I think it's very clear that a LSM module is a derived work,
and thus copyright law and the GPL are not in any way unclear about it.
If people think they can avoid the GPL by using function pointers, they
are WRONG. And they have always been wrong.
Linus
C.2.5 Second Post by Linus in Security Hooks License Thread
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH] make LSM register functions GPLonly exports
Date: 2002-10-17 17:25:12
On Thu, 17 Oct 2002, Linus Torvalds wrote:
>
> If people think they can avoid the GPL by using function pointers, they
> are WRONG. And they have always been wrong.
Side note: it should be noted that legally the GPLONLY note is nothing but
a strong hint and has nothing to do with the license (and only matters
for the _enforcement_ of said license). The fact is:
- the kernel copyright requires the GPL for derived works anyway.
- if a company feels confident that they can prove in court that their
module is not a derived work, the GPL doesn't matter _anyway_,
since a copyright license at that point is meaningless and wouldn't
cover the work regardless of whether we say it is GPLONLY or not.
(In other words: for provably non-derived works, whatever kernel
license we choose is totally irrelevant)
So the GPLONLY is really a big red warning flag: "Danger, Will Robinson".
It doesn't have any real legal effect on the meaning of the license
itself, except in the sense that it's another way to inform users about
the copyright license (think of it as a "click through" issue - GPLONLY
forces you to "click through" the fact that the kernel is under the GPL
and thus derived works have to be too).
Clearly "click through" _has_ been considered a legally meaningful thing,
in that it voids the argument that somebody wasn't aware of the license.
It doesn't change what you can or cannot do, but it has some meaning for
whether it could be wilful infringement or just honest mistake.
Linus
|
