In anticipation of you removing fattach functionality from LiS, I think it's appropriate for me to say that if someone wants to use the code in LiS to do a separate "distribution" dependent on LiS which again provides it, no one needs my permission to do so. I won't be doing it, not only because I am not actively using LiS myself, but also because it would be a lot of trouble. It's enough trouble just syncing this code with the kernel's changes, it would be even more trouble syncing it with both the kernel and LiS separately.
I should tell you that the FIFO/pipe & FD passing code has similar issues, so for completeness, if you're removing fattach for this purpose, you should remove FIFOs/pipes and FD passing as well, or at least look very closely at them.
-John
David 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
