Brian F. G. Bidulock wrote:
John,
On Fri, 08 Aug 2003, John A. Boyd Jr. wrote:
Let me make another point about function calls.
A system call is a function call, but is a special case. In Linux as in other Unix-like operating systems, code calling a system call does not link to the kernel directly, but to a user-space library like 'libc'. The C headers encapsulating system calls are not kernel headers, but library headers. This is a level of isolation the GPL already permits as an exception, so the technical fact that kernel headers may be practically involved via inlining of, e.g., the system call prototypes, doesn't matter. Linus also permitted it explicitly in his added preamble to GPL V2.
GPL does not permit this. See excerpt from GPL in last note. Linus's note makes reference to LGPL that permits inlining 10 lines or less as well as linking.
Brian, with all due respect, you're greatly confusing things. The LGPL cannot and does not speak to matters pertaining to code licensed under the GPL. Linus' preamble serves to free certain uses from also being GPL and has nothing to do with the LGPL explicitly.
By the way, Linus' preamble is also outside the terms and conditions of the license proper. That doesn't make it worthless legally, it's just worthy of note, since a court will do what it wants with it.
But where function calls generally are concerned, any old-time C programmer knows that header files or any other form of source code is not needed for them. So, whether or not "copying" is involved in a function call depends on how the function call is written.
Read the LGPL for an explanation.
I was commenting here on a legal issue, Brian. I had reviewed parts of US Code Title 17, Copyrights, before writing this. Title 17 is the relevant statutory authority on this point. The LGPL is only a license agreement, i.e., a form of contract pertaining specifically to the use of a work to which copyright can be applied.
If I want to understand a point of law, I don't read a contract to do so; I consult the Constitution, statutory law, regulations, and/or case law. Besides, as I've noted, the LGPL is not relevant to this discussion.
I apologize if I'm wrong to say this, but I'm sensing a point of confusion on your part about what the roles of the GPL and LGPL are.
What's in the LGPL is off the point of when a preexisting GPL'ed work would make another work GPL or not. If the GPL applies to the new work, then the new work is not LGPL, and the LGPL is not relevant. If the GPL does not apply to the new work, then the author is free to license the work as they he or she sees fit, and doesn't have to use the LGPL, so the LGPL still isn't relevant to the question. The question is about the GPL, not the LGPL, and the LGPL only comes up because Dave chose it for LiS. He didn't have to use the LGPL; he could have made it proprietary, or used a BSD license, or anything he might have wanted to do.
Are we talking about the same thing? I don't think so.
I.e., in GPL terms, a system call _is not_ copying; a function call otherwise _might be_ copying, but inlining _is_ copying.
You are confusing GPL with Linus' statements about module access being effectively LGPL. The header files in user space that you are used to using have modified BSD licenses or are LGPL.
In the kernel sources is a file named COPYING. It is the legally applicable and binding license agreement for the Linux kernel source distribution. Linus added a preamble to that file from the stock GPL V2 file. I just grep'ed his file for "LGPL," and it doesn't occur in the file even once. I also diff'ed it with the stock GPL V2 yesterday, and the only difference is the preamble Linus included, and a few address line changes. So, it is GPL V2 except for the preamble.
So, what are you talking about, if not the kernel license?
--brian
-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
