First, if we're voting again, I agree with Dave over Linus' apparent disagreement, with all due respect to Linus, in this regard: avoiding inlining is not a sufficient condition for avoiding GPL, but it is a necessary one in technical terms. Code that is inlined is code that is included in the work in question, and thus certainly makes it derivative. (That's a legal opinion, though I'm not a lawyer, but one who has been involved with this very legal issue as a "party with standing.")
The whole notion of "derivative" is a little odd in these discussions. Is my X.25, dating back to 1980, a "derivative work" of Linux because it uses an inline function for spin locks? (It doesn't, it uses the LiS abstraction.) Doesn't seem intuitive, does it?
For that matter, can LiS be considered a "derivative work" given that it is implementing a specification (STREAMS) that was in existence quite before the Linux project ever started? There is no sense in which anybody started with Linux and then "derived" LiS.
The very portability of LiS should be technical proof that it is not "derivative" of Linux.
If LiS uses kernel inline functions does that give Linus standing to claim full GNU coverage for LiS, even though it is a separate module? And is that standing transitive to binary STREAMS drivers that access the kernel only through LiS? If linked in with LiS? If implemented as separate modules? Or do Linus' own statements on the subject negate any such claim? And what about kernel subsystems written and copyrighted by others?
Is a plate of spaghetti easier to untangle than all of this?
But on the subject of what would be sufficient, I want to ask you a question, Dave. From a legal perspective, was is a good idea to obsolete the system call interfaces? I suspect that having them there in usable form, even if not normally used, would support the legal case that the appropriate barrier has been observed, as a matter of due diligence.
I don't see the distinction. LiS is a file system and can give any semantics to "read" and "write" that it sees fit. It could interchange their intuitive meanings, and though confusing to the point of being useless, it is a matter for the file system implementor to decide.
And following from that thought, it occurs to me that the Linux kernel does not fully support a pure syscall relationship with the current LiS, notably in the case of FATTACH/FDETACH, which are syscalls in most Unix kernels but are not allocated in the Linux kernel. I don't really want to go there myself, but it would seem to me that providing a full syscall barrier would require that these be added to the kernel.
I think that read, write and ioctl are a sufficient system call barrier.
I think that if the question ever came up in court, one seeking to show LGPL but not GPL coverage would have to demonstrate due diligence towards meeting the explicit requirements of the LGPL as exclusive from the GPL. Thus, this effort must be made and documented if that is the desired end. If it then fails, it would probably satisfy a court that every reasonable attempt was made.
Actually, being the primary copyright holder for LiS, the licensing terms are just what I say they are and need no justification. LGPL was handy and compatible with the Linux environment, and was agreed to by all of the original authors of LiS. It is always the plaintiff that has the burden of proof. So it would have to be up to Linus, or others, to prove that LiS violates the kernel's GNU license in some way. It would be guaranteed to get tangled given the different, somewhat contradictory, statements that Linus has made on the subject over the years.
-- Dave
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
