Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!decwrl!hal.com!hasse.hal.com!howard
From: how...@hasse.hal.com (Howard Gayle)
Newsgroups: alt.suit.att-bsdi
Subject: UC Berkeley Embroiled in Computer Software Lawsuit
Date: 22 Jan 1993 15:50:21 GMT
Organization: HaL Computer Systems, Inc., Campbell, California
Lines: 32
Message-ID: <1jp53tINN4bl@hal.com>
Reply-To: how...@hal.com (Howard Gayle)
NNTP-Posting-Host: hasse.hal.com
Summary: Science News & Comment article.
The News & Comment section of Science has an article about the
lawsuit:
Title UC Berkeley Embroiled in Computer Software Lawsuit
FullAuthor John Travis
Journal Science
Day 15
Month Jan
Year 1993
Pages 304-305
Volume 259
Number 5093
I think it's a good 1.5 page summary of the background and
issues. The inaccuracies are minor. Key quote:
"`We have done a very thorough analysis of the [NET2] source
code and found very direct copying...,' says [USL director
of corporate relations Larry] Lytle. Specifically, USL now
claims that more than 100 files, out of the more than 8000
in NET2, have code stolen from UNIX. `I think it will be
obvious to the court that they copied our kernel...,' says
Sanford Tannebaum, a vice president for USL."
--
Howard Gayle
HAL Computer Systems, Inc.
1315 Dell Avenue
Campbell, California 95008
USA
how...@hal.com
Phone: +1 408 379 7000 extension 1080
FAX : +1 408 379 5022
Newsgroups: alt.suit.att-bsdi
Path: sparky!uunet!spooky!witr
From: w...@rwwa.COM (Robert Withrow)
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <1993Jan24.221548.24252@rwwa.COM>
Sender: n...@rwwa.COM (News Administrator)
Nntp-Posting-Host: spooky
Reply-To: w...@rwwa.com
Organization: R.W. Withrow Associates
References: <1jp53tINN4bl@hal.com>
Distribution: usa
Date: Sun, 24 Jan 1993 22:15:48 GMT
Lines: 16
In article <1jp53tINN...@hal.com>, how...@hasse.hal.com (Howard Gayle) writes:
| [USL director of corporate relations Larry] Lytle [...] claims that more
| than 100 files, out of the more than 8000 in NET2, have code
| stolen [sic] from UNIX.
So. They claim that a *maximum* of 1.25% of the code was ``stolen'', and
since they say ``have [some] code stolen'', it probably means that the
only a fraction of these modules bears any similarity to the v32 code.
Let's be generous and say that 0.5% of the code has any real similarity.
And they think this is a strong case?
--
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: w...@rwwa.COM
R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Path: sparky!uunet!das.wang.com!ulowell!m2c!bu.edu!stanford.edu!agate!
spool.mu.edu!sdd.hp.com!sgiblab!sgigate!sgi!igor!jbass
From: jb...@igor.tamri.com (John Bass)
Newsgroups: alt.suit.att-bsdi
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <1993Jan26.221218.8133@igor.tamri.com>
Date: 26 Jan 93 22:12:18 GMT
References: <1jp53tINN4bl@hal.com> <1993Jan24.221548.24252@rwwa.COM>
Distribution: usa
Organization: Toshiba America MRI Inc, S. San Francisco, CA.
Lines: 87
Robert Withrow, w...@rwwa.COM writes:
> | [USL director of corporate relations Larry] Lytle [...] claims that more
> | than 100 files, out of the more than 8000 in NET2, have code
> | stolen [sic] from UNIX.
>
> So. They claim that a *maximum* of 1.25% of the code was ``stolen'', and
> since they say ``have [some] code stolen'', it probably means that the
> only a fraction of these modules bears any similarity to the v32 code.
> Let's be generous and say that 0.5% of the code has any real similarity.
>
> And they think this is a strong case?
and to carry this statistical lie to it's obvious conclusion, the 100 files
are less than 0.00000000001% of all files in the universe ... so what are they
bitching about?
The truth is that most of the 8000 files are for many contributed things
that have absolutely no relation to any AT&T product ... any more than
the current contents of various other archives across the net.
But 100 files is a significant number of the several hundred files that
represent the core unix directory trees on the tape! I was very eager to
get 386BSD downloaded, until I looked through the kernel source tree and
it was frankly obvious that much of it was:
1) derived from the AT&T copyrighted puesdo code in Bach's
"The Design of the UNIX Operating System" (see clock interrupt
routine plus the other files that DIRECTLY reference pages
from Bach).
2) Direct modification & re-write of AT&T source, complete with
original UNIX subroutine and variable names. Some times you
find they were just to lazy to remove/re-write UNIX code so
they simply deleted the UNIX code and left the comment:
UNIX_subr() {
/*
* code body deleted
*/
return(some_val);
}
(see the kernel acct code)
Both practices are clear copyright violations. UNIX was copyrighted in
the original Version 5 release that was made available to Berkeley back
in 1974/75 when Ken was teaching/working there for a while. Granted the
lawyers later had the copyrights removed because copyright case law on
software was unfavorable for a while ... but that doesn't invalidate the
original copyright or it's protection of later derived code ... or the
right of AT&T/USL to copyight later work as derived from this original
work.
Case law in the US clearly outlines what are acceptable "reverse engineering"
proceedures. UCB's efforts aren't even close. Mark Williams V6/V7 unix clone
and many BIOS vendors where held to and passed these standards. Why should
we now accept relaxing the standard so that public university can make a
practice of ripping-off vendors that supply their sources under non-disclosure?
It is VERY scary to consider hiring UCB grads with such a warped view of
what IS and IS NOT legal to incorporate into the product they may produce
for you. Given the effort that other major universities expend to prevent
plagiarism not even as blatant as this, it is hard to understand where the
grassroots support for UCB is comming from.
I think hiring managers should be boycot hiring UCB grads until they clean
up their act on plagiarism and require all existing students to attend a
class on intelectual property rights.
I also think that all faculty, staff, and student assistants that participated
and/or condoned this piracy should be removed or severely disciplined.
Call's to your State Assemblyman and Pete Wilsons office for a full inquiry
may well be in order. No university or other state employee should be able
to subject Calif tax payers to a possible multi-millon dollar settlement for
any such violation. Maybe we should push for legislation to exempt public
employees and their management from legal protection by the state and allow
their current and future assets to be available for such settlements. Maybe
if they were directly at risk they would think twice about crossing over the
line, or allowing their staff to put them at risk.
John Bass
DMS Design
jb...@dmsd.com
Path: sparky!uunet!das.wang.com!ulowell!m2c!bu.edu!stanford.edu!agate!
usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!
howland.reston.ans.net!paladin.american.edu!darwin.sura.net!newsserver.jvnc.net!
netnews.upenn.edu!gynko.circ.upenn.edu!rsk
From: r...@gynko.circ.upenn.edu (Rich Kulawiec)
Newsgroups: alt.suit.att-bsdi
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <106742@netnews.upenn.edu>
Date: 27 Jan 93 03:03:32 GMT
References: <1jp53tINN4bl@hal.com> <1993Jan24.221548.24252@rwwa.COM>
<1993Jan26.221218.8133@igor.tamri.com>
Sender: n...@netnews.upenn.edu
Distribution: usa
Organization: Ditka Policy Institute
Lines: 23
Nntp-Posting-Host: gynko.circ.upenn.edu
In article <1993Jan26.221218.8...@igor.tamri.com> jb...@igor.tamri.com (John Bass)
writes:
>I think hiring managers should be boycot hiring UCB grads until they clean
>up their act on plagiarism and require all existing students to attend a
>class on intelectual property rights.
>
>I also think that all faculty, staff, and student assistants that participated
>and/or condoned this piracy should be removed or severely disciplined.
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.
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.
"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.
---Rsk
Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!
ghost.dsi.unimi.it!batcomputer!rpi!usenet.coe.montana.edu!caen!spool.mu.edu!
yale.edu!qt.cs.utexas.edu!cs.utexas.edu!tamsun.tamu.edu!europa.tamu.edu!drs0587
From: drs0...@europa.tamu.edu (Dave Safford)
Newsgroups: alt.suit.att-bsdi
Subject: Re: UC Berkeley Embroiled in Computer Softwa
Date: 27 Jan 1993 15:18:56 GMT
Organization: Texas A&M University
Lines: 34
Distribution: world
Message-ID: <1k6950INNm4i@tamsun.tamu.edu>
References: <1993Jan26.221218.8133@igor.tamri.com>
Reply-To: drs0...@europa.tamu.edu
NNTP-Posting-Host: europa.tamu.edu
In article 8...@igor.tamri.com, jb...@igor.tamri.com (John Bass) writes:
>it was frankly obvious that much of it was:
>
> 1) derived from the AT&T copyrighted puesdo code in Bach's
> "The Design of the UNIX Operating System" (see clock interrupt
> routine plus the other files that DIRECTLY reference pages
> from Bach).
>
> 2) Direct modification & re-write of AT&T source, complete with
> original UNIX subroutine and variable names. Some times you
> find they were just to lazy to remove/re-write UNIX code so
> they simply deleted the UNIX code and left the comment:
>Both practices are clear copyright violations.
Hmm...
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???
Just because the code references Bach does not necessarily mean the
concepts or code came from AT&T.
2. The function stubs may have been derived from open sources, such as Bach.
I don't think it is *clear* that they violated copyright.
The relationships of code developed at AT&T and Berkeley is quite
complex, as in the good old days people cooperated rather than litigated.
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.
dave safford
Newsgroups: alt.suit.att-bsdi
Path: sparky!uunet!news.uiowa.edu!hobbes.physics.uiowa.edu!news.iastate.edu!
ux1.cso.uiuc.edu!sdd.hp.com!spool.mu.edu!darwin.sura.net!sgiblab!sgigate!odin!
twilight!sgi!igor!jbass
From: jb...@igor.tamri.com (John Bass)
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <1993Jan27.215738.12384@igor.tamri.com>
Organization: Toshiba America MRI Inc, S. San Francisco, CA.
References: <1993Jan24.221548.24252@rwwa.COM> <1993Jan26.221218.8133@igor.tamri.com>
<106742@netnews.upenn.edu>
Distribution: usa
Date: Wed, 27 Jan 93 21:57:38 GMT
Lines: 396
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
------------------------
r...@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.
lance...@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.
-------------------
m...@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.
------------------------
Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!sgiblab!darwin.sura.net!
newsserver.jvnc.net!netnews.upenn.edu!gynko!rsk
From: r...@gynko.circ.upenn.edu (Rich Kulawiec)
Newsgroups: alt.suit.att-bsdi
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <106921@netnews.upenn.edu>
Date: 28 Jan 93 01:20:00 GMT
References: <1993Jan26.221218.8133@igor.tamri.com> <106742@netnews.upenn.edu>
<1993Jan27.215738.12384@igor.tamri.com>
Sender: n...@netnews.upenn.edu
Distribution: usa
Organization: Ditka Policy Institute
Lines: 62
Nntp-Posting-Host: gynko.circ.upenn.edu
In article <1993Jan27.215738.12...@igor.tamri.com> jb...@igor.tamri.com (John Bass)
writes:
>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.
Now, why would you think that some folks are too young? I'm certainly not,
as I cut my teeth on my first Unix system around 1978. (I spent most of
the last decade at Purdue, where, thanks to many cooperative relationships
with AT&T and Berkeley, we were able to contribute a little to some of the
developments that have taken place in the Unix world. The history of
most of this is not folklore to me; it's an experience I lived through.
I know a few folks here and there on both sides of the issue. I watched
AT&T Unix go from v6 to v8, BSD from 3.0 to 4.3, and so on. And, as
someone who has seen all kinds of source code thanks to the cooperation
mentioned above, I have more than a passing interest in this litigation.)
>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.
I am telling you no such thing. I believe you're quite aware that everyone
here speaks for themselves unless they explicitly note otherwise; this
is doubly true in my case as Penn is not "my school". As to whether or
not I or anyone else here are capable of seeing blatant plagiarism, I
can only answer for myself -- and the answer is "Yes, I can."
I will point out, however, that your repeated assertions that plagiarism
took place are not proof: they are merely assertions. I am content,
for the most part, to sit back and wait to see what is revealed in
a court of law. As Holmes said, "To theorize in advance of the
facts is a capital mistake."
>> 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.
>
> [argument misinterpreting due process clause deleted ]
I stand by my statement. There is no reason, at this time, to treat
any UCB grad differently from any other grad vis-a-vis the AT&T-BSDI
matter. *Even if* Berkeley winds up on the losing end of all this,
there is no reason to penalize newly-graduating students who were
in grammar school when this started -- nor to penalize anyone, in fact,
who wasn't involved.
>One IS GUILTY from the time they pull the trigger,
>due process is only the means we use to protect those falsely accused.
Not in this country. One is guilty when one is found so by a court of law.
Due process is the means we use to protect everyone: guilty or innocent.
I suggest a reading of the case law on the topic; Gunther's "Constitutional
Law" (11th edition Foundation Press) includes a substantial section
on due process.
>The facts surrounding USL vs. UCB are in plain view.
Not by a longshot. There are many, many unanswered questions and missing
bits of information on both sides of the case...which is exactly why
this is not the time to leap willy-nilly to conclusions about who
has done what to whom and when. A more prudent course would seem to
be to wait...and watch.
---Rsk
Path: sparky!uunet!das.wang.com!ulowell!m2c!bu.edu!stanford.edu!agate!
spool.mu.edu!howland.reston.ans.net!usc!sol.ctr.columbia.edu!
The-Star.honeywell.com!umn.edu!gaia.ucs.orst.edu!news.orst.edu!miguel
From: mig...@roxanne.news.orst.edu (Miguel de Icaza)
Newsgroups: alt.suit.att-bsdi
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <MIGUEL.93Jan28113055@roxanne.news.orst.edu>
Date: 28 Jan 93 16:30:55 GMT
References: <1993Jan24.221548.24252@rwwa.COM> <1993Jan26.221218.8133@igor.tamri.com>
<106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com>
Distribution: usa
Organization: /usr/users/miguel/.organization
Lines: 35
NNTP-Posting-Host: roxanne.nuclecu.unam.mx
In-reply-to: jbass@igor.tamri.com's message of Wed, 27 Jan 93 21:57:38 GMT
> > * Paging BSD
>
> Sorry but I was using paging systems for more than 10 years prior to Berkeley
> getting their first VAX.
The point is not who invented Paging, but who implemented it on Unix.
32V didn't have any kind of Paging support.
> > * 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.
Ok, but it was faster.
What makes the difference between DOS 1.0 and DOS 5.0?, which one
would you choose?
DOS 1.0 doesn't have hd support, nor an in-kernel loader, nor ...
The point is that UCB made Unix a confortable place to live *before*
AT&T faced the fact and made SVR4.
> * Job control BSD
>
> Sorry ... this was copied from TENEX
Ok, in this case, Unix also was copied from a number of places, and
who was the first one integrating JC to Unix?
--
Saludos,
Miguel de Icaza
Path: sparky!uunet!walter!rutgers!newsserver.jvnc.net!yale.edu!spool.mu.edu!
sgiblab!sgigate!sgi!igor!jbass
From: jb...@igor.tamri.com (John Bass)
Newsgroups: alt.suit.att-bsdi
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <1993Feb2.204838.16992@igor.tamri.com>
Date: 2 Feb 93 20:48:38 GMT
References: <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com>
<MIGUEL.93Jan28113055@roxanne.news.orst.edu>
Distribution: usa
Organization: DMS Design
Lines: 91
In article <MIGUEL.93Jan28113...@roxanne.news.orst.edu> mig...@roxanne.news.orst.edu
(Miguel de Icaza) writes:
>> > * Paging BSD
>>
>> Sorry but I was using paging systems for more than 10 years prior to Berkeley
>> getting their first VAX.
>
>The point is not who invented Paging, but who implemented it on Unix.
>32V didn't have any kind of Paging support.
The 32V tape Berkeley started with was "hot off the presses" ... and represented
the initial porting effort for the VAX ... IE keep it simple and port V7
as is, then make it better AFTER it is stable. Heck ... Vaxes were only
months old at this time, and note that it was someone besides Berkeley that
did the truely hard work ... the cross architecture port of unix. Having
done this twice I can clearly say that bring up UNIX on a not fully debugged
C compiler for a new architecture is a major pain ... and in my mind is
what "Porting UNIX" is really all about. These guys that claim "19 UNIX
ports" when in effect they only wrote 19 sets of device drivers for
a new machine using existing Compilers and Machine support code ... don't
even know what it REALLY means to PORT UNIX. When I ported V7 UNIX to the
ONYX box it was 100hr weeks for 3 months finding a dozen or so compiler
bugs a day ... just code around the bug and toss the bug report to the
compiler guy. Finding bugs where the code reads correct is much harder.
It is my understanding that parallel work was done inside AT&T to provide
paging at the same time ... due to the 1-2 year latency it was not visable
external to AT&T for quite some time. I do know that when I was at AT&T Long
Lines in Dec 1980 looking at porting a more current OS to the ONYX Z8002
system that I was given a tape for System 4 that was about 6 months old
that included paging for the VAX and 3B? systems. I was told that AT&T had
implemented 5 (five) different paging policies and that after extensive
testing choose 1 (one) for inclusion into System 4 in the summer of 1980.
System 4 was never publicly released ... but the work was in all System 5
releases. Had BSD 4.1 not been available and widely used by university sites
... I assume the AT&T VAX paging work would have been made available much
earlier ... just like the "V6+ 50 fixes tape" that predated the V7 release.
>
>> > * 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.
>
>Ok, but it was faster.
>
>What makes the difference between DOS 1.0 and DOS 5.0?, which one
>would you choose?
>
>DOS 1.0 doesn't have hd support, nor an in-kernel loader, nor ...
>
>The point is that UCB made Unix a confortable place to live *before*
>AT&T faced the fact and made SVR4.
The 1K and 2K filesystem work was done about the same time, and as
I noted has higher locality and is significantly better in many cases,
especially when combined with bit mapped allocations, queue sorting, and
disk I/O request consolidation.
AT&T systems have been a "confortable place to live" long before SVR4.
In fact some of us consider any flavor of SVR2 or SVR3 to be preferable
to the monster created by SVR4.
An even stronger point is that the Sun OS is a much enhanced BSD port, and
what you find in SVR4 is Sun OS code that was provided by Sun to USL.
USL did the right thing in making sure that ANY file that contained
anything possibly derived from BSD by SUN contain the BSD copyright.
It's sad the UCB didn't extend this same recognition to USL/AT&T/BTL
in the Net2 and 386BSD releases.
>
>> * Job control BSD
>>
>> Sorry ... this was copied from TENEX
>
>Ok, in this case, Unix also was copied from a number of places, and
>who was the first one integrating JC to Unix?
I believe that JC in the Blit terminal code predates BSD JC ...
but granted nobody ported it to normal terminals. For dumb users
JC is a major liability since it vastly increases the "minimum state"
a new user must learn in order to recover to keyboarding or modem
errors. I personally have ***NEVER*** used it ... I favor multi-session
windows (Either Xterms or multi-screen sessions on an ASCII term) over
JC. For the experience computer hacker JC has some value ... general
users ... NOT! Windows/Multi-screens is a much easier thing to teach
to normal users since you don't have to teach PID's and all that relate
to them.
John
Path: sparky!uunet!newsgate.watson.ibm.com!news.ans.net!rpi!
zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!uflorida!bb
From: b...@beach.cis.ufl.edu (Brian Bartholomew)
Newsgroups: alt.suit.att-bsdi
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <38437@uflorida.cis.ufl.edu>
Date: 31 Jan 93 05:56:40 GMT
Sender: n...@uflorida.cis.ufl.edu
Organization: Univ. of Florida CIS Dept.
Lines: 26
Nntp-Posting-Host: beach.cis.ufl.edu
A couple of questions for John Bass:
Was AT&T (or WECO or BTL or whoever they were at the time)
legally able to write a non-disclosure contract, at a time
when they were prohibited from competiting in the software
market?
Is giving a University something presumabably for them to
learn from it but then telling them to hold to non-disclosure
and claiming trade secrecy protection coherent?
AT&T stopped their service of taking code and identifying what
was their property and what wasn't, even after CSRG asked them
repeatedly to sort out what was AT&T property in BSD. This
shows very strong non-defense of their copyrights, which makes
their copyright invalid. Comment?
Are you claiming AT&T had any trade secrets whatsoever left
after the Bach book, BSD book, and avalanche of academic U*IX
papers?
--
Another member of the League for Programming Freedom (LPF) l...@uunet.uu.net
-------------------------------------------------------------------------------
Brian Bartholomew - b...@math.ufl.edu - Univ. of Florida Dept. of Mathematics
Newsgroups: alt.suit.att-bsdi
Path: sparky!uunet!news.claremont.edu!ucivax!news.service.uci.edu!usc.edu!
howland.reston.ans.net!spool.mu.edu!agate!ames!sgi!igor!jbass
From: jb...@igor.tamri.com (John Bass)
Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit
Message-ID: <1993Feb3.011536.11454@igor.tamri.com>
Organization: Toshiba America MRI Inc, S. San Francisco, CA.
References: <38437@uflorida.cis.ufl.edu>
Date: Wed, 3 Feb 93 01:15:36 GMT
Lines: 94
In article <38...@uflorida.cis.ufl.edu> b...@beach.cis.ufl.edu (Brian Bartholomew)
writes:
>A couple of questions for John Bass:
>
> Was AT&T (or WECO or BTL or whoever they were at the time)
> legally able to write a non-disclosure contract, at a time
> when they were prohibited from competiting in the software
> market?
Ahh yes the consent decree argument that AT&T was not supposed to be
in the computer business. But by the same decree they were REQUIRED
to make all components of their switching systems available on an
equal basis. Since UNIX was part of the control system, it was then
by mandate required to be made available. The fact that vendors other
than those building computer based switches found a use for the software
is completely a separate issue.
> Is giving a University something presumabably for them to
> learn from it but then telling them to hold to non-disclosure
> and claiming trade secrecy protection coherent?
Lets be careful how we present this ... UNIX was not "given" to any
University. Each site asked for it, and it was granted under strict
non-disclosure license. AT&T did not allow general distribution of
the sources to students. Legal access to the sources is limited to
a few thousand people world wide, not the hundreds of thousands others
would like to represent.
The distribution of UNIX to universities by this example is a failed
experiment .... when UNIVERSITIES THINK THEY HAVE THE RIGHT TO RE_WRITE
IT LINE BY LINE and call it free from copyright. Especially when UNIX is
only major software product available in source form, and then is openly
plagiarized by a UCB .... I can understand why sources for MS-DOS, WINDOWS
EXCEL, MS_WORD, Lotus, Borland ... etc are not made available to any other
campus.
UCB (and the wild postings on the net) has set an example that no other
major vendor will forget ... don't dare let those university thieves have
your code!
If the schools want a successful commercial OS with which to teach future
OS principles ... things on campus will have to greatly change.
> AT&T stopped their service of taking code and identifying what
> was their property and what wasn't, even after CSRG asked them
> repeatedly to sort out what was AT&T property in BSD. This
> shows very strong non-defense of their copyrights, which makes
> their copyright invalid. Comment?
I don't understand what the basis is for your comments. It is one thing
for AT&T to help UCB when they are furthering the cause and not jepordizing
AT&T's rights in UNIX .... it is quite another to ask AT&T to cooperate with
UCB re-writing UNIX to remove AT&T's rights to it. I think AT&T's about face
in light of UCB changing goals is a stong defense for AT&T ... they did
not accept or condone this new goal of UCB re-writting their product.
I don't know how UCB would expect AT&T to react to "did we do enough yet"?
Certainly not favorably!
> Are you claiming AT&T had any trade secrets whatsoever left
> after the Bach book, BSD book, and avalanche of academic U*IX
> papers?
Ahh ... the trade secret arguement.
Go down to your local car dealer and order a service manual. It contains
a lot of good things ... at a fairly low level of detail from a consumers
point of view. From an engineers point of view it is very high level. It
has nothing about stress studies, metallurgy, tooling design, thermal
design, ... or a large number of other detailed technological issues
necessary to design and manufacture any car. If you did copy the car,
part for part, design for design ... your car would just be a copy -- not
a new design. Furthermore, when you got sued for making several of
them .... you would not have the engineering notes that detailed all
these complex design tradeoffs to justify your design as independently
developed. Many design tradeoffs are as personal to the designer as his
fingerprints.
All of the above references you present, only describe unix at the same
high relatively level. They are not detailed design documents. What is
in 386BSD goes far beyond these sources ... and includes design tradeoffs
that include the "finger prints" of the original UNIX development teams.
But even if these "finger prints" were missing, key design details as
presented by Bach, are present. This duplication of "the programs's
methodology and algorithm, including the sequence of processes adopted
by the programmer" by the UCB code taken from Bach Puesdocode forms not only
a moral, but legal challenge UCB's claim of authorship.
Research teams are held to a higher standard of authorship ... to take
or use anothers ideas without acknoledgement is what is called plagiarizm.
This moral standard goes beyond copyright law, by requiring full disclosure
of the source of all ideas.
John Bass
DMS Design