John, The terms and conditions of the license, like any simple contract, defines its own body of law.
--brian On Sat, 09 Aug 2003, John A. Boyd Jr. wrote: > Hi Brian, > > Brian F. G. Bidulock wrote: > > John, > > > > "This General Public License does not permit incorporating your program into > > proprietary programs. If your program is a subroutine library, you may > > consider it more useful to permit linking proprietary applications with the > > library. If this is what you want to do, use the GNU Library General > > Public License instead of this License." -- GPL Version 2, June 1991 > > > > GPL does not permit linking. > > > The first sentence just restates the prohibition against copying. > The word "incorporating" means "copying." It is copying which this > forbids in the first sentence you include here. > > The next two sentence are a recommendation, not a requirement. > I.e., it does not say "you are not permitted ...," it says "you may > consider it more useful ...". > > If a GPL'ed library is a shared library, no copying would be involved > in linking to it. If the library is static, however, copying would > certainly be involved. That's why this in only a recommendation, and > worded as it is, i.e., not as a prohibition. > > Again, the GPL leaves the definition of copying to copyright law (it > says so explicitly); the text you include here is only interpreting in > order to recommend using a different license in one particularly risky > situation. > > > > > "When a "work that uses the Library" uses material from a header file > > that is part of the Library, the object code for the work may be a > > derivative work of the Library even though the source code is not. > > Whether this is true is especially significant if the work can be > > linked without the Library, or if the work is itself a library. The > > threshold for this to be true is not precisely defined by law. > > > Yes, I've pretty much said this. A court will not apply a "threshold" > necessarily; case law in other areas has asserted that the court can > use both qualitative and quantitative criteria. > > It's worth noting, though, that what is "precisely defined by law" is > generally a moving target, since court rulings are taken as advancing > the precision of statutory law and regulations. I'd guess the author > of this whole passage knew that, so that this can only be taken as > interpretive text, not normative text. A court would understand that > (and that applies to the following paragraph as well). Licenses can > have as much interpretive text as they want; it's actually encouraged, > I'm told. > > > If such an object file uses only numerical parameters, data > > structure layouts and accessors, and small macros and small inline > > functions (ten lines or less in length), then the use of the object > > file is unrestricted, regardless of whether it is legally a derivative > > work. (Executables containing this object code plus portions of the > > Library will still fall under Section 6.)" -- LGPL Version 2.1, February 1999 > > > > LGPL permits inlining at 10 lines or less. > > > Brian, this is from the LGPL, so it doesn't even speak to the issue > being discussed, namely, whether or not a work is GPL vs LGPL. This > is about whether a work is LGPL vs proprietary. > > Even so, this makes the point that inlining will be interpreted legally > as copying. > > > --brian > > > > On Fri, 08 Aug 2003, John A. Boyd Jr. wrote: > > > > > >>The difference between linkage by function call and linkage by inlining > >>is that inlining involves copying of a portion of the work linked to, > >>while linkage by function call most certainly does not. > >> > >>Put another way, inlining is both linkage at the level of SOURCE CODE, > >>as opposed to linkage in binary (which is what function call linkage > >>is), and it requires copying of source codee into the work linking. > >> > >>By the terms of the GPL, then, linkage by inlining makes the work doing > >>the inlining a "work based on the Program" and thus it becomes GPL'ed as > >>a whole (Linus' preamble to GPL V2, which is the only change to GPL V2, > >>doesn't affect this). By contrast, work linking by function does not > >>require access to any portion of the source code of the work linked to, > >>nor does it require copying of that work in any way, shape, or form. > >> > >>The three actions that cause application of the GPL are copying, > >>distribution, and modification of a prior GPL work in whole or part. > >>The GPL leaves the definition of copying to copyright law, and a > >>reasonable interpretation of that law does include inlining (though > >>I can't speak to US case law without doing some research). > >> > >>An OS subsystem like LiS doesn't itself do any distribution of the > >>kernel with which it interacts, nor does it modify that kernel, so it > >>is exempt from GPL'ing on those points, and it is only copying which is > >>of concern. And on the issue of copying, which the GPL leaves to > >>copyright law to interpret, it is indeed reasonable to expect that > >>a court will see these two mechanisms differently. > >> > >>-John > >> > >>Brian F. G. Bidulock wrote: > >> > >>>Dave, > >>> > >>>This statement from the link you gave is incorrect: > >>> > >>> "Thirdly, if a STREAMS driver writer makes his/her driver loadable as a > >>> separate module, not linked with LiS, and if he/she uses only LiS > >>> constructs without utilizing any inline code from any kernel header > >>> files then that driver is completely free of any possible reach of the > >>> full GPL of the kernel." > >>> > >>>It makes no difference whether the code is called via LiS or inlined. > >>> > >>>What makes you think that linkage by function call rather than inlining > >>>affords any additional protection whatsoever? > >>> > >>>Either the module writer had the right to inline it (under Linus GPL) or > >>>LiS did not have the right to wrapper it (under pure GPL). > >>> > >>>So, the STREAMS module writer is able to inline all of the code that LiS > >>>inlines (except fattach). LiS is just currently requiring that STREAMS > >>>modules run slower than necessary, and to no purpose. > >>> > >>>It might be time to start that Linux STREAMS Lite (LSL) branch that does > >>>not include overheads for ports (that do not openly exist) nor include > >>>performance reductions without purpose... > >>> > >>>Anyone interested? > >>> > >>>--brian > >>> > >>> > >>>On Thu, 07 Aug 2003, Dave Grothe wrote: > >>> > >>> > >>> > >>>>Here is a summary of these issues published some time ago. It includes > >>>>some opinion from our attorneys. > >>>>http://www.gcom.com/home/support/whitepapers/linux-gnu-license.html > >>>> > >>>>The only addition at this point in time might be that the fattach code of > >>>>LiS uses some exported kernel functions in the VFS section of the kernel > >>>>which was written by Al Viro. If someone wants to argue that the simple > >>>>act of using those functions imports the viral nature of the GPL into LiS > >>>>then LiS can be made compliant by simply de-implementing the fattach > >>>>functionality. > >>>> > >>>>For the sake of protecting Gcom code (in some cases written a decade prior > >>>>to the onset of the Linux project) from any arguable claim of GPL > >>>>infringement I am prepared, if necessary, to fork a version of LiS with all > >>>>fattach functionality removed, leaving code that only uses parts of the > >>>>kernel that fall under the Linux LGPL. > >>>> > >>>>-- Dave > >>>> > >>>>At 12:52 AM 8/7/2003 Thursday, Brian F. G. Bidulock wrote: > >>>> > >>>> > >>>>>Dave, > >>>>> > >>>>>On Wed, 06 Aug 2003, Dave Grothe wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Because LiS is LGPL, anyone can link proprietary object modules with > >>>>>>it. Those modules do not have to be STREAMS drivers. They can be modules > >>>>>>that accomplish a port to some other operating system environment. No > >>>>> > >>>>>LGPL > >>>>> > >>>>> > >>>>>>license violation there. > >>>>> > >>>>>The module linking with LiS does not violate LiS's LGPL, it is LiS that > >>>>>violates the Linux kernel GPL for code that is pure GPL. For kernel > >>>>>code that is LinusGPL, the module had the right to use in the first > >>>>>place, and LiS did nothing, except, in this case, make the module run > >>>>>slower because it did not permit the module to inline functions that can > >>>>>be inlined in proprietary code under LinusGPL. > >>>>> > >>>>> > >>>>> > >>>>>>LiS is intentionally structured in such a way as to make such things > >>>>>>possible, and even halfway straightforward. > >>>>> > >>>>>In that case, it appears that LiS might in fact be in violation of > >>>>>licensing of the Linux kernel to which it links. If there are any pure > >>>>>GPL parts of the kernel that are used by it, it is necessary that LiS be > >>>>>GPL not LGPL. If there are no pure GPL parts (just LinusGPL parts) then > >>>>>LiS offers no more capability than the Linux kernel itself. > >>>>> > >>>>>I think we need to straighten this out. Logically LiS cannot afford the > >>>>>protection claimed. GPL software cannot be made LGPL software by > >>>>>wrapping the functions. If that were the case, all GPL software would > >>>>>be LGPL software using simple wrappers (even macros) and compiler flags > >>>>>(to suppress inline functions). We can take this discussion up with > >>>>>someone from the FSF and on the lkml if the above is not obvious and > >>>>>apparent. > >>>>> > >>>>>--brian > >>>>> > >>>>> > >>>>> > >>>>>>-- Dave > >>>>>> > >>>>>>At 12:01 AM 8/6/2003 Wednesday, Brian F. G. Bidulock wrote: > >>>>>> > >>>>>> > >>>>>>>Dave, > >>>>>>> > >>>>>>>I should hope nobody else has a proprietary port. Would that not be a > >>>>>>>violation of the LGPL license (and the GPL licenses of some components)? > >>>>>>> > >>>>>>>This begs a question: a significant contribution made under LGPL should > >>>>>>>not be propagated to your proprietary QNX port, anyway. The reason > >>>>>>>being that to do so would break the licensing terms under which the > >>>>>>>contribution was offered. > >>>>>>> > >>>>>>>Another thought is to start a branch dividian LiS, rip the "portable" > >>>>>>>out proceed from there. > >>>>>>> > >>>>>>>Other thoughts? > >>>>>>> > >>>>>>>--brian > >>>>>>> > >>>>>>> > >>>>>>>On Tue, 05 Aug 2003, Dave Grothe wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>At 12:03 AM 8/5/2003 Tuesday, Brian F. G. Bidulock wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Also, I am confused with your comments regarding Linux kernel-isms. > >>>>>>>>>Does LiS run on anything other than Linux? > >>>>>>>> > >>>>>>>>I have a proprietary port to QNX. There may be others that I don't > >>>>> > >>>>>know > >>>>> > >>>>> > >>>>>>>>about. I want LiS to be able to serve as a base for *portable* > >>>>> > >>>>>STREAMS as > >>>>> > >>>>> > >>>>>>>>well as *Linux* STREAMS. > >>>>>>>> > >>>>>>>>Also, any changes should be tested by doing a build in user mode. The > >>>>>>> > >>>>>>>user > >>>>>>> > >>>>>>> > >>>>>>>>mode code should always be the debug version since it is used for > >>>>> > >>>>>testing > >>>>> > >>>>> > >>>>>>>>STREAMS algorithms in user space. > >>>>>>>> > >>>>>>>>Also, see my response to Matt concerning licensing considerations. > >>>>>>>> > >>>>>>>>-- Dave > >>>>>>>> > >>>>>>>> > >>>>>>>>_______________________________________________ > >>>>>>>>Linux-streams mailing list > >>>>>>>>[EMAIL PROTECTED] > >>>>>>>>http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams > >>>>>>> > >>>>>>>-- > >>>>>>>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 > >>>>> > >>>>>-- > >>>>>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 > >>>> > >>>> > >>>>_______________________________________________ > >>>>Linux-streams mailing list > >>>>[EMAIL PROTECTED] > >>>>http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams > >>> > >>> > >> > >>_______________________________________________ > >>Linux-streams mailing list > >>[EMAIL PROTECTED] > >>http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams > > > > > > > _______________________________________________ > Linux-streams mailing list > [EMAIL PROTECTED] > http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams -- 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
