[PATCH] make LSM register functions GPLonly exports
Linus Torvalds
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Richard B. Johnson
> On Thu, Oct 17, 2002 at 09:51:06AM -0700, Crispin Cowan wrote:
> > My argument against the intent of this change is that no, I do not think
> > we should restrict LSM modules to be GPL-only. LSM is an API for loading
> > externally developed packages of software, similar to syscalls. There is
> > benefit in permitting proprietary modules (you get additional modules
> > that you would not get otherwise) just as there is benefit in permitting
> > proprietary applications (you get Oracle, DB2, and WordPerfect).
>
> My arguement is that I want this flag as a hint for authors of
> propritary security modules that I'm going to sue them if they
> use hook called from code I have copyright on. This includes such
> central parts as vfs_read/vfs_write.
There is no way of preventing authors from using "your" code once
you publish it. They just can't claim that they wrote it without
violating copyright law. Copyrights and Licensing are two different
independent things. See a Lawyer.
The attached 'C' program, when linked with any proprietary module,
will bypass all the "EXPORT_GPL_ONLY" and similar "SCREW_YOU" macros.
To prevent using this or other similar work-arounds to road-blocks
thrown in the way of users, you would have to get GNU 'ld' to prevent
partial linking and make sure that all old copies have been destroyed.
This, by example, shows that "GPL Only" is unenforceable. I suggest
that all the "GPL only" zealots try something new (like more good code),
rather than attempting to prevent honest workers from using code
they helped develop.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
Linus Torvalds
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 th emeaning 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.
Greg KH
>
> 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
The SELinux module uses almost every hook so far. A number of companies
and distros are currently auditing this module, and it will probably be
submitted for inclusion into the main kernel tree after they are
finished.
> - seen a number of people who still worry that the hooks degrade
> performance in critical areas
I have a set of patches to send you today that will solve that problem,
by allowing people who do not want the hook to compile them away into
nothingness. DaveM agrees with the proposed way of doing this.
> - the worry that people use it for non-GPL'd modules is apparently real,
> considering Crispin's reply.
I agree with this, and argue to mark the functions as
EXPORT_SYMBOL_GPL() to make some people feel a bit more warm and fuzzy
that these hooks will not be co-oped for non-GPL use (this includes me.)
In short, I like Christoph's patch.
> I will re-iterate my stance on the GPL and kernel modules:
Thank you for posting this. I know a lot of people appreciate it.
greg k-h
Ingo Molnar
On Thu, 17 Oct 2002, Linus Torvalds wrote:
> (In other words: for provably non-derived works, whatever kernel
> license we choose is totally irrelevant)
one more addition here: as long as those works do not copy any part of the
kernel, be that source code or binary code. Ie. they:
- dont play fancy games binary-patching the kernel or something to that
extent.
There's been a precedent created in the US just two days ago, at the
appelate level, that makes certain types of functionality-enhancing
'binary-patching' practices fall under the copyright of the patched work.
Ie. the GPL qualifies even if the main body of the work in question is not
derived from the kernel, but the work depends on modifying the kernel. So
it's a questionable practice even for non-derived bin-only modules to
patch the kernel or modify it in any not originally intended way.
and the well-known issues of:
- dont use inline functions in headers
- probably even the structure definitions in headers qualify
both can be independently created via the rules of reverse engineering.
(whatever they are in the country it's done - but be prepared for the US
to attempt to take jurisdiction over your acts, wherever you are ...)
Ingo