John, I think we could quite easily ask the FSF for their interpretation of their licenses on these points.
On Wed, 06 Aug 2003, John A. Boyd Jr. wrote: > Hi Dave... 8^) > > David Grothe wrote: > > At 01:47 PM 8/6/2003 Wednesday, John A. Boyd Jr. wrote: > > > >> 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? > > > I think the concepts can be understood intuitively if the basics are > understood. > > In US law, ideas require patent or trade secret protection; neither > applies to open intellectual property. What does apply is copyright, > which is protection of an expression. The concept of a spin lock is an > idea; an implementation of spin locks is an expresision. > > If you ported your old X.25 implementation of spin locks, then to the > extent that it is the same, it is a derivative work (it is the same > work if not modified at all, but derivative if modified, beginning with > the prior expression). > > > 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 specification could be considered an expression in its own right, > were it "published" in that form. Indeed, that is the case to some > extent. The important point is that LiS is not a derived specification, > or even the same specification - it is an implementation of the > specification, and thus an original expression of a different sort. > > Apples have to be compared to apples where this issue of expression is > concerned, and as far as I know, LiS as an implementation of STREAMS is > original, though it seeks to comply with a common, effectively open > specification. Last I checked the specification was not "open". Which specification are you looking at that gives everyone permission to implement it? For example, the OpenGroup specifications explicitly state that they do not convey any rights of implementation whatsoever. > > Nothing in copyright law could prevent this, If you have legal access > to a copy of those original specifications (e.g., SVR4 STREAMS > manuals and the like), then what you can't do automatically do (unless > a license grants you rights to derivative work) is publish the same > material again, but you can use it to implement something that complies > with it. I don't think so, particularly when the specification forbids you access to the rights to use the specification to implement, as more recent OpenGroup specifications do. > > The specification itself, as expression in copyright terms, has more to > do with things like man pages. In that regard, those I wrote some time > ago were entirely original; they were written from my code and the rest > of LiS, not (so much) from prior specifications, except for gauging > compliance. Brian's pages, by contrast, are derivative works at the > same level because they include my prior work essentially verbatim. > > > The very portability of LiS should be technical proof that it is not > > "derivative" of Linux. > > > To some extent, this is indeed true, but not necessarily so. Portions > of Linux could be copied into LiS and used portably, to the extent that > they are portable themselves. And if that is done, it makes LiS a > derivative work. Do you mean like LiS inlining pure GPL functions? Yes that would make LiS a derivative work and subject to the GPL on the functions it uses. [snip] --brian -- 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
