From: jbass@igor.tamri.com (John Bass)
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Organization: Toshiba America MRI Inc, S. San Francisco, CA.
Distribution: usa
Date: Wed, 27 Jan 93 21:57:38 GMT

I picked 3 of the many postings and letters to respond to. If this doesn't
get the point across we will have to start the trial here by taking each
and every source module and picking it apart until people get the idea
that Berkeley screwed up big time.

Unfortunately, it appears that most the respondants are to young to have
any actual memory of the events first hand ... and are just parroting
the folklore they have learned.

Many of the others just lack critical thinking and social skills necessary
to properly evalutate to issues and respond in a responsible way.

Right and wrong are not decided by what's in each persons best interest, but
by what is in the best interest of the community as a whole. Debate is
fine, but crying over spilled milk is not.  The debate on the issues of
copyright and ownership of software goes on, but Congressional leadership
and Judicial decree have left us with case law that is more than clear on
how to view this case. These rights are inline with necessary protection
of not only individual rights of authorship, but businesses needs as well.

Protection of these rights is absolutely necessary to protect not only
the computer industry, but the entire technical, information, publishing
and entertainment industries as well. No matter how much the newbies want
free/low cost UNIX, 386BSD is a direct violation of AT&T/USL property
rights.

To strip AT&T of the right to protect it's UNIX property is wrong, no matter
how much you may hate AT&T or the Bell System. To bully their employees,
or picket their booths or offices, or any other action regarding their
attempt to protect their investment of more than 10,000 man years and
$5,000,000,000 expenses to develop, support, and market this product --
is simply as flawed and wrong as the UCB team that plagiarized UNIX
components for the Net2 and 386BSD releases. UCB has not, will not, can
not EVER invest this amount of man power or dollars to make a software
product -- if not for any other reason than the people of California will
not allow their taxes to be spent competing unfairly with private business.

John Bass
DMS Design

------------------------


rsk@gynko.circ.upenn.edu (Rich Kulawiec) writes:

> I think maybe we should wait to see how the case turns out before deciding
> what to do.   At this point, it is at best unclear who did what to who when,  
> so calls for punitive measures seem rather premature...especially since
> we don't know who'll be on the receiving end of those measures just yet.

Sorry but I don't agree ... it may take 3-7 years to resolve USL vs. State
of California ... the legal process is not fast when the defendant has lots
of $$$ to jerk the process around.

Even by UCB academic standards this is plagiarism. The fact the state/UCB
is caught in a rather poor situation and doesn't want to admit to blame
in the face of rather large damage claims is completely another issue.
Caught with their pants down, any act to dicipline the members involved
will only be seen as an admission of guilt. Letting the guilty escape UCB
and avoid due process prior to settlement makes little sense.

If you are telling me that the Faculty/Staff at Penn are not capable 
of seeing blatant plagiarism ... then maybe we need to be concerned about
your school as well. (and ditto for MIT and the several other schools who
faculty/staff wrote scathing responses).

> In the interim, I'll give UCB grads the same consideration in hiring that
> I give to everyone else; to do any less would be unfair.

A group of men stand up in a crowd of police officers and judges, shoot
someone in front of the TV camera's of every network world wide. In legal
terms they are ONLY ALLEGEDLY GUILTY of the crime until the last appeal
is settled -- many years later. If this group was acting on the behalf
of XYZ organization ... do we withhold condemnation of XYZ until the
last appeal is settled? One IS GUILTY from the time they pull the trigger,
due process is only the means we use to protect those falsely accused.

The facts surrounding USL vs. UCB are in plain view. Many parts of the
UCB distribution contain un-mistakable UNIX procedure names, variable
names, and code sequences from V7 code that predates any UCB development
effort or release ... that are not found in Bach or any other document
available without signing a non-disclosure agreement for UNIX code.

In addition, case law for acceptable reverse engineering requires the
team doing the disassembly to produce only general specifications which
are void of all details specific to the original vendors design. It also
requires that the design team producing the clone have no previous contact
with details with the internal design of the original product. IE the
new design team can not have been part of the disassembly effort, or have
had any exposure the internals of the original product.

SO NET2 and 386BSD are tainted in 3 way's:

	1) some of it's major modules are direct modifications of AT&T
	   files and code. IE They contain EXACTLY the same character
	   strings as a finger print.

	2) some of it's major modules are directly derived from Bach,
	   copyrighted 1986 by Bell Telephone Laboratories, Inc ...
	   otherwise known as part of AT&T.

	3) All the UCB people working on the project had both prior and
	   concurrent access to AT&T source.

The primary example of item 1 are all the files with the code body deleted
comments which match UNIX source. This is a direct admission both design
framework and specific files were derived from AT&T code. It is further
very evident in the tty design and code, and less evident in the filesystem,
except the BIO routines which are largely identical in design and implementation
to AT&T UNIX.

The primary example of item 2 are the several places where Bach is referenced
and the following code has identically the same outline as the puesdo code
in Bach.

This fact is not disputed as far as I know.


> "Condoning this piracy", by the way, is not a legal infraction.  One's
> 1st Amendment rights allow one to condone even the most heinous crimes
> without penalty.  Of course, such opinions may be unpopular, but those
> are the very sorts of opinions that the 1st Amendment was intended
> to protect.

Here you are wrong ... the management, staff and faculty of UCB bear the
responsibility for the actions of their charges when they should have been
supervising those actions ... especially when they were directly involved.
This includes not only the contractual obligation they accepted regarding
the UNIX license ... but all state and federal laws regarding copyrights,
plus enforcement of academic standards.

Given the nature and scope of the disclosure they were negligent not to
obtain a 3rd party review and sanction of counsel prior to making the
release public.

---------------------------------

Dave Safford writes:

> 1. Bach documented V.2/V.3, which contained *much* code from BSD 4.1/4.2.
>    Some of Bach's pseudo code (certainly ALL of the network stuff) was
>    derived/copied from code that originated at Berkeley. Are you saying 
>    that this is now under AT&T copyright, and unavailable to BSD??? 

Actually SUN/BSD kernel merger was done by AT&T for SVR4.  For all
releases up to and including SRV3.2 the contributions by UCB are pretty
much limited to VI and a few utilities.

The system description documented by Bach are those of the AT&T UNIX
kernel SVR2 as noted by Bach on page xii of the preface. This kernel
contains no UCB code I am aware of.

Of the nearly 500 pages in the book, only 7 pages divoted to sockets
discuss BSD features. There are only a few other minor references.

>    Just because the code references Bach does not necessarily mean the 
>    concepts or code came from AT&T.

Sorry, but you are reaching for straws with this position. Bach only
lists a few internal kernel procedure names, and fewer variable names.
386BSD has many UNIX procedure and variable names that go beyond Bach.
In addition certain other UNIX code sequences and data structures are found
in 386BSD that are referenced, but not detailed, by Bach ... such as timeout
handling in the clock interrupt routine and the acct routines.

There are several dozen places ***that I saw in a quick review*** where
the Berkeley code unmistakably contains UNIX V7 code fragments and/or direct
coding from the Bach puesdocode. I'm sure the USL team had no problems
finding many more.

> 2. The function stubs may have been derived from open sources, such as Bach.

The function stubs for acct are not in Bach at all. In addition, while
Bach can be purchased an many book stores and is the text of choice for
many OS classes (clear available) ... it is still plagiarizm to reduce
the puesdocode to C and call it your own.

From the Oxford American Dictionary we have:

	Plagiarize: to take and use (another persons ideas or writings
	or inventions) as one's own.

Nowhere in their files is even ONE copyright by AT&T ... how can any
rational person faced with the evidence ... still ignore the situation?
I don't see how UCB can claim copyright on all these files without
also acknowledging the source without being guilty of plagiarizm. QED
   
> I don't think it is *clear* that they violated copyright.

My God ... how did you reach this falsehood? ... by reliance on all
the trash postings in this group?  LOOK FOR YOURSELF!

> The relationships of code developed at AT&T and Berkeley is quite
> complex, as in the good old days people cooperated rather than litigated.

It's not complex at all .... UCB license under non-disclosure sources
from AT&T ... UCB modifies AT&T sources and freely distributes the
modified sources. At no time has any vendor I am aware of cooperated with
such a blatant disregard for property ... every sane business would litigate.

> Let's let the courts decide before going off on such tirades.
> I certainly wouldn't hire anyone that has your tendency to presume an entire 
> group of people guilty without proof.

The proof required is quite visable to anyone with access to V6 or V7
UNIX sources.  And still visable (but with reservation) by anyone holding
a copy of Bach and 386BSD.

Having worked with UNIX internals since 1975 and having done a number of
UNIX ports (including having held several vendor's UNIX contractor's
source licenses for machines in my own office) ... there is "no tendency to
presume" ... I can SEE IT.

If you lack the resources to do so yourself .... then you also lack the
resources to make your judgement of my position OR USL's and should say
so.

lancelot@spock.uucp (Thor Lancelot Simon) responds to???:

>>If 50 people a day come to their booth and say "The USL suit against BSDI
>>is making you look _really_ _bad_", that will get noticed.  If you staff
>>a booth at a trade show, its your _job_ to tell your employer when people
>>are saying stuff like that.
>>
>>But resist the urge to say "You're all a bunch of assholes!!!"  The people
>>you talk to didn't cause this and don't deserve to take the heat for it.
>
> It is a shame nobody thought to organize pickets.  That might be the right
> blend of nice and nasty for the occasion.

Which I think fairly represents the ignorant tide of hate toward USL. It's
sort of like getting upset at the police for impounding the BMW some guy
at the airport gave you the keys for the preceeding day (after hijacking
it and killing the driver just to catch a plane on time).

The problem is that a number of ignorant self prclaimed experts have made too
many trash posting on the topic. I'll pick on just one ... who was probably
in diapers 1975 when I was writing my first unix drivers.

-------------------

mike@vlsivie.tuwien.ac.at (Michael Gschwind) writes:

> Wait a moment! Who copied design, algorithms, data structures,... from
> whom? UCB from ATT/USL? Or ATT/USL from ATT? I would think the latter
> was the case rather than the fromer!!! Unix as we know it today is a
> UCB product (mostly, ie the parts that make UNIX usable!), not an ATT
> one.  I bet you would not want to work on a PDP-11/V-32 unix - nor
> would I (except for historical/amusement reasons). Many of the things
> we so much like where written outside ATT and then filtered back in to
> ATT unix or were rewritten by ATT.

Damn yes wait a minute ... you are so off base that you are attempting
to re-write history. For all releases up to and including SVR3.2 the
BSD contribution to UNIX as found in AT&T releases was limited to
VI and a few minor utilities. SVR4 does contains a number of features from
SUN based on BSD that were merged by AT&T to make SVR4. SVR4 represents
much less than 3-5% of the installed base, and BSD derived kernels are less
than 10-15% of the installed base.

UNIX as we know it today is anything BUT a UCB product!

Almost nothing prior to SVR4 was taken from outside AT&T. My file
locking, which became the defacto standard for many years, is a good
example ... NIH kept it out of AT&T product for many years. When it
was put in to conform to the "public standards" they re-engineered it,
but it still represented one of the few outside ideas incorporated into
their product.

Get your facts straight ... or keep quiet!

> SO what we like about UNIX (just some features - some of them 
> are pretty outdated and we don't like them any more (eg vi), but 
> they were at the time a MAJOR step!):
> 
>  * written in C			ATT
>  * lex,yacc				ATT

clearly Bell Lab's & AT&T ... (suprised you didn't claim Microsoft or Borland)

>  * Paging				BSD

Sorry but I was using paging systems for more than 10 years prior to Berkeley
getting their first VAX.

"The Working Set Model for Program Behavior" P.J. Denning, Communications
of the ACM, Volume 11, No 5, May 1968 pp. 323-333 is not the first, but
one of the most significant pieces of research that define paging designs
over the last 25 years. This predates BSD by MANY years! A very nice research
community public OS for the XDS940 (Xerox Data Systems) broke a lot of ground
in this area. The second significant system was TENEX on the PDP10's.

The publicly available XDS940 sources spawned several very sucessful early
timesharing companies such as Tymshare (on XDS940 systems) and ITS
(originally CTS based out of Minn.) on CDC3300's and CDC3170's for the
California State University system at Northridge (CSUN). CTS/ITS actually
converted the XDS940 assembly language the whole system was written in to
CDC3300 assembly language ... which made dissasembling their objects very
easy with the XDS940 source and internal documentation available.

TEXEX was "the research operating system of choice" until the late `70's.
Much of the networking design was evolved on this platform during the
early years of ARPANET.

>  * Fast File System 			BSD

Sorry, but I have never classed their filesystem as fast .... faster than
the orginal V6/V7 filesystem on larger machines like VAXen yes, but not fast.

Most of their design approaches can be found in other filesystems that predate
the BSD work by 5 years or more. The major speed up factor ... clusters ...
which does multiple sector I/O requests was just industry practice. IBM's
of the day made blocking factors specifiable by file. Timesharing systems
like DEC's RSTS for the PDP-11 also had clusters years before BSD.

Other BSD design practices, like the cyclinder group concept, are
simply conceptually flawed. They made some false asumptions about average
queue depth and file locality, that at best only apply to overloaded
educational systems with small quota's. Compared to other designs with
clusters and bitmapped allocation, the BSD filesystem design is 15-20%
slower due to excessive head travel enforced by the cylinder group balancing
policy. This policy probably reduces the life expectancy of the drives
head carriage by the same margin.

>  * Job control			BSD

Sorry ... this was copied from TENEX

>  * csh (just a personal plug ;)	BSD 
>  * vi (eek - but better than ed)	BSD

Sorry ... but these are just a derivates of the V6 unix shell and ed.
EVERBODY at the time was hacking sh and ed to make their own command
interface and visual editors ... the berkeley ones were neither the
first or the best .... just the most widely distributed.

>  * IPC/networking/sockets		BSD 
>  * sendmail 				BSD

The original UNIX network and mail code was done in several places ... stuff
ported from TENEX, Univ of Champagne - Ill (sp?), UCLA, and BBN. UNIX's
have been on the ARPANET since before 1975 as both clients and servers.
FTP, Telnet, mail on V6 systems all predate BSD by years.

>  * termcap 				BSD
>  * curses 				?BSD?

Original work done at Berkeley ... later work done by same person while
working for AT&T ... resulting in terminfo.

>  * dbx 				?BSD?

This one I don't know ...

> AT&T Unix was a good thing, but for its time - much of the
> improvement, ie. that which made it into a `product' did not come from
> AT&T (Unix got wuite a bit bigger and less elegant in the process - I
> doubt that the inventors would want to be associated with the
> cancerous beast that UNIX is today - for that reason the started out
> anew with Plan9 if I understand things) - and the point where the
> input of AT&T code stopped is easily discernable with the last source
> license UCB took for UNIX - which is way back when, if I understand
> things correctly...

You are certainly free to hold your own opinions on much of this,
although most of us in the industry differ.

BSD being basicly V7/V32 based was extended greatly by UCB ... but
the enhancements on the commercial side are much more interesting
as UNIX grew through System 3, System 5, SVR2, & SVR3.x to SVR4.

Every major UNIX product shipping is based barrows heavily from these
later releases, if not based on atleast SVR3.2.

> So the people who are writting PD unixes - oops, UNIX is TM - who are
> writting POSIX conformant operating systems are ripping USL off?

Legal UNIX clones have been around for nearly 10 years ... starting with
Mark Williams V6 knockoff. This is partly why I and 4 dozen others sat
through many frustrating hours on the /usr/group/stds committee's.
What we did wasn't either perfect or complete ... but a starting point
for many others in the POSIX effort.

Anyone can design an advanced state of the art OS that maintains this
API ... and I encourage it.

> Isn't it more the case that USL is ripping the CS community off by selling a
> system of which they very lttle wrote/invented?

Sorry, but you have this exactly backwards, very little of the 386BSD design
and frame work is UCB's. Very little of the kernel code is AT&T's, BUT
nearly all 386BSD the kernel code is derived/plagiarized from AT&T's.
And this was no accident ... a lot of (poorly directed) effort was
necessary to complete the job.

------------------------