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
