Dave, I think the point here is that if LiS has this RTU of the Linux kernel code then so does a proprietary kernel module. In that case, LiS does nothing but get in the way of the RTU that the proprietary module had in the first place. Calling the lis_ function is just slower.
Also, you must understand that, writing in 1994, Linus is talking about his code (covered under LinusGPL). Other contributors since then have contributed pure GPL code to the kernel. Code that LiS is not permitted to use in this fashion. --brian On Wed, 06 Aug 2003, Dave Grothe wrote: > > Yes, but, observe the following. As everyone knows, if the GPL every > had to be argued in court it would make a plate of spaghetti look > simple by comparison. Maybe SCO and IBM will wade into that swamp. > 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 > [1]<[EMAIL PROTECTED]> > To: Christoph Hellwig > [2]<[EMAIL PROTECTED]> > Subject: Re: [PATCH] make LSM register functions GPLonly > exports > Date: Thu, 17 Oct 2002 10:08:19 -0700 (PDT) > Cc: Crispin Cowan > [3]<[EMAIL PROTECTED]>, Greg KH > [4]<[EMAIL PROTECTED]>, > [5]<[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 > / > [6]http://www.hp.com/go/opencall > > i n v e n t > > References > > 1. mailto:[EMAIL PROTECTED] > 2. mailto:[EMAIL PROTECTED] > 3. mailto:[EMAIL PROTECTED] > 4. mailto:[EMAIL PROTECTED] > 5. mailto:[EMAIL PROTECTED] > 6. http://www.hp.com/go/opencall -- Brian F. G. Bidulock � The reasonable man adapts himself to the � [EMAIL PROTECTED] � world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
