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
--------------------------------------------