Xref: utzoo news.admin:2981 news.sysadmin:801 comp.sources.wanted:4502 comp.sources.d:2431 comp.unix.xenix:2636 Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!killer!richardh From: richardh@killer.UUCP (Richard Hargrove) Newsgroups: news.admin,news.sysadmin,comp.sources.wanted,comp.sources.d,comp.unix.xenix Subject: Re: Please remove PD-YACC sources from your machine IMMEDIATELY Summary: what is AT&T targeting in its non-PD yacc war? Message-ID: <4765@killer.UUCP> Date: 10 Jul 88 15:45:13 GMT References: <3532@rpp386.UUCP> <135@dcs.UUCP> <235@pigs.UUCP> Organization: The Unix(R) Connection, Dallas, Texas Lines: 57 In article <235@pigs.UUCP>, haugj@pigs.UUCP (Joe Bob Willie) writes: > In article <135@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: > >2. If they are reacting to the name YACC, does this mean that they ARE > > moving towards considering the names of *NIX utilities their property > > which no-one else may use? If so, where does this leave such products > > as MINIX, MKS, etc.? If so, AT&T will have a long, lonely, and futile struggle (not to mention expensive). A good argument can be made that a lot of Unix command names have become generic. This ship sailed a long time ago. > > no, they seem to be aiming at the source itself, or possibly the ideas > contained in the source. i'm not certain. i don't know how this will > affect unix-like utilities. it may affect clones which are not exact > source ripoffs, but say, used the exact same algorithms. for example, > a yacc clone which built a lalr(0) parser identical to the real yacc > might be more in danger than one which built a lr(0) or lr(1) parser. > Ditto the above if they think they can copyright (or patent) an algorithm. (I think I'll patent addition with carry this week ;-). Now a technological implementation of an algorithm is a different matter altogether. I CAN patent a piece of hardware that implements addition with carry. And, even if independently developed, you can't use this implementation without my permi$$ion. However, you may patent a different implementation. I CAN copyright code that implements addition with carry (because I didn't want to buy the hardware that implements it :-) and you can't use my code without my permi$$ion. However, if you independently develop your own code that implements addition with carry (you don't want to buy the hardware either :-) you don't need my permission. But (and this is a grey area) if I copyright the visual and auditory interface, you CAN'T copy that (the classic example is a table of sines and cosines - obviously I can't copyright the information but I can copyright its representation). _Caveat_: I'm not a lawyer; don't make any important decisions based on the above opinions. If it's important, get valid legal advice. It would seem that if AT&T were concerned about names and algorithms that they would have attempted to stop the MKS yacc distribution since a) the tool is named yacc, and b) it demonstrates a very high degree of compatibility with Unix yacc (implying that the underlying algorithm(s) are the same). AT&T seems to be pursuing with a vengence the supposedly pd yacc code that got out a while back. I know both Austin Code Works and The C User's Group have removed versions of yacc at AT&T's behest. I believe both replaced it with Bison. However, one or more versions of yacc ported to the pc have gotten into the pc BBS base and will probably never be rooted out. Actually, at one time I had the pc-based yacc sources. While I could get them to compile, I couldn't get them to accept .y files that Unix yacc handled with no problem. I threw them away rather than try to track down the problem. Now I use MKS yacc. richard hargrove ...!{ihnp4 | codas | cbosgd}!killer!richardh --------------------------------------------