But that is why LiS is LGPL, it vastly simplifies licensing considerations and encourages porting of existing STREAMS drivers from other platforms.
-- Dave
> From [EMAIL PROTECTED] Mon Dec 12 04:32:37 1994
> From: [EMAIL PROTECTED] (Linus Torvalds)
> Date: Mon, 12 Dec 1994 13:16:56 +0200
> In-Reply-To: Richard Stallman's message as of Dec 8, 18:16
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: must loadable Linux kernel modules be GPL'ed?
>
> Richard Stallman: "Re: must loadable Linux kernel modules be GPL'ed?" (Dec
8, 18:16):
> >
> > If I port this driver as a loadable Linux
> > kernel module and just distribute the object, does the GPL/LGPL
require
> > me to distribute the source for the driver as well?
> >
> > The GPL does require this.
>
> The loadable module interface is considered to be an extension of the
> system calls, and as such, loadable modules are not really covered by
> the GPL. A few caveats, however:
>
> - adding a new entry-point to the list already in the kernel in order
> to get your loadable module to work would be considered linking
> against the kernel, and as such violates the GPL.
>
> The entrypoints have been specifically chosen to be suitable as
> entrypoints: if you have a specific need, contact me and I may add it
> to the list. I won't export functions which I consider "internal" to
> the kernel, though.
>
> I'd prefer to force the loadable modules under the GPL, but I don't
> really feel I have the moral right to do that. But I *do* have the
> moral right to export only what I consider general "library" routines,
> so that the loadable modules interface would be similar to a LGPL'd
> interface (I might actually make that the official standpoint.. So
> far the issue hasn't really come up, and I'm not going to advertise
> that use of the loadable modules too heavily as I'd prefer free
> modules)
>
> - I won't guarantee that all entry-points and kernel data structures
> will remain the same. As such, you can write a driver, but any
> company that feels that linux is worth writing a driver for should be
> aware that it is likely to need recompilation every once in a while
> (we're working on versioning, not quite there yet).
>
> Of course, a company might do a driver only for one specific version
> of linux, but the question is whether that would be worth it for the
> company. I won't go out of my way to make it easy to do things like
> that.
>
> I'll have to make some decision about the exact legal stand of loadable
> drivers some day, but you can essentially assume that you *can* use the
> linux kernel as a LGPL'ed library, but only as far as the officially
> exported functions are concerned.
>
> Linus
At 02:20 AM 8/6/2003 Wednesday, Francois-Xavier KOWALSKI wrote:
David Grothe wrote:
[...]
One important point. If you are conditionally turning such functions as lis_spin_lock() into direct inline uses of kernel functions (via defines) then you are creating a licensing ambiguity where there was none before. If only LiS calls kernel functions then only LiS is susceptible to the viral nature of the kernel's GNU license. Any separately loaded STREAMS driver that accesses the kernel only via LiS is safe since it does not use any kernel inlines.
If you, via your optimization patch, introduce direct kernel inlines into STREAMS driver code then you have extended the viral properties of the kernel's GNU license into STREAMS drivers themselves. This would violate a design principle for LiS. LiS must act as an environmental and licensing buffer between STREAMS drivers and the kernel.
In that regard I would really prefer to see the optimized locking functions (for example) continue to pass the file and line number information to functions in lislocks.c and then conditionally have those functions not use the information. The LiS spin lock and semaphore structures should be the same whether the optimized LiS is being used or not.
This protection has been explicitly declared as non-applicable by L. Torvalds: "Using function pointers won't save you from the GPL". Exact quote below.
Direct inlining is also good when there is a deadlock on a system using crash-dump feature: the crash-dump backtrace of the offending process(es) contains the exact location of the lock, rather than the lis wrapper code. I strongly vote _for_ inlining of functions.
Best regards.
-- FiX
From: Linus Torvalds <[EMAIL PROTECTED]> To: Christoph Hellwig <[EMAIL PROTECTED]> Subject: Re: [PATCH] make LSM register functions GPLonly exports Date: Thu, 17 Oct 2002 10:08:19 -0700 (PDT) Cc: Crispin Cowan <[EMAIL PROTECTED]>, Greg KH <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>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
-- Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 OpenCall Business Unit -- OCBU / //_/ Telnet: 779-6327 Signalling Products / http://www.hp.com/go/opencall i n v e n t
