From: howard@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: howard@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 howard@hal.com Phone: +1 408 379 7000 extension 1080 FAX : +1 408 379 5022 Newsgroups: alt.suit.att-bsdi From: witr@rwwa.COM (Robert Withrow) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <1993Jan24.221548.24252@rwwa.COM> Sender: news@rwwa.COM (News Administrator) Nntp-Posting-Host: spooky Reply-To: witr@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 <1jp53tINN4bl@hal.com>, howard@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: witr@rwwa.COM R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA Newsgroups: alt.suit.att-bsdi From: jsparkes@bcars68a.bnr.ca (Jeff Sparkes) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <1993Jan25.221304.11440@bcars6a8.bnr.ca> Sender: usenet@bcars6a8.bnr.ca (Use Net) Nntp-Posting-Host: bcars68a Organization: Bell-Northern Research Ltd, Ottawa, Ontario, Canada References: <1jp53tINN4bl@hal.com> <1993Jan24.221548.24252@rwwa.COM> Distribution: usa Date: Mon, 25 Jan 1993 22:13:04 GMT Lines: 26 In article <1993Jan24.221548.24252@rwwa.COM> witr@rwwa.com writes: >In article <1jp53tINN4bl@hal.com>, howard@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? The 8000 and 100 are from the entire NET2 release. How many files are for the kernel, and how many of that 100 are in that subset. USL could be talking about a much higher percentage. These numbers don't give enough detail.... Maybe lines of code or percentages of files "stolen" would be a better count. Disclaimer: I am not on the USL side, I just hate to see the "facts" abused. -- -- Jeff Sparkes jsparkes@bnr.ca Bell-Northern Research, Ottawa (613)765-2503 You know, a muffin can be *very* filling. Newsgroups: alt.suit.att-bsdi From: peltz@cerl.uiuc.edu (Steve Peltz) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit References: <1jp53tINN4bl@hal.com> <1993Jan24.221548.24252@rwwa.COM> <1993Jan25.221304.11440@bcars6a8.bnr.ca> Message-ID: Sender: usenet@news.cso.uiuc.edu (Net Noise owner) Organization: Computer Based Education Research Lab - University of Illinois Distribution: usa Date: Tue, 26 Jan 1993 00:32:57 GMT Lines: 9 Of course, how many of those files include a big long copyright notice, followed by one #define or #include...or are programs about as complex as hello.c (the non-gnu-programming-standards version, that is), where the obvious way of writing it is trivial. I mean, my vanilla strcmp() implementation is probably going to be pretty similar to theirs, along with a whole bunch of diddly utility functions in the standard libraries. -- Steve Peltz Internet: peltz@cerl.uiuc.edu PLATO/NovaNET: peltz/s/cerl Newsgroups: alt.suit.att-bsdi From: witr@rwwa.COM (Robert Withrow) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <1993Jan26.191232.28187@rwwa.COM> Sender: news@rwwa.COM (News Administrator) Nntp-Posting-Host: spooky Reply-To: witr@rwwa.com Organization: R.W. Withrow Associates References: <1jp53tINN4bl@hal.com> <1993Jan24.221548.24252@rwwa.COM> <1993Jan25.221304.11440@bcars6a8.bnr.ca> Distribution: usa Date: Tue, 26 Jan 1993 19:12:32 GMT Lines: 19 In article <1993Jan25.221304.11440@bcars6a8.bnr.ca>, jsparkes@bcars68a.bnr.ca (Jeff Sparkes) writes: | USL could be talking about a much higher percentage. These numbers don't | give enough detail.... Maybe lines of code or percentages of files | "stolen" would be a better count. But Heck! This lawsuit is looking sillier and sillier. There may not be much detail in those figures, but it is still obvious that they are griping about a *very small percentage* of the code. As in relatively easy to rewrite using your favorite ``clean'' technique. If this report is anywhere *near* being true, why doesn't the judge require them to settle on that basis? This is like claiming infringement for using the word ``the'' from the Gettysburg address. Unless they are claiming that it is *impossible* to write *any* unix kernel that doesn't infringe... -- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA From: bill@triangle.cs.uofs.edu (Bill Gunshannon) Newsgroups: alt.suit.att-bsdi Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <11551@prijat.cs.uofs.edu> Date: 28 Jan 93 18:28:02 GMT References: <1jp53tINN4bl@hal.com> <1993Jan24.221548.24252@rwwa.COM> <1993Jan25.221304.11440@bcars6a8.bnr.ca> <1993Jan26.191232.28187@rwwa.COM> Sender: news@prijat.cs.uofs.edu Distribution: usa Organization: Department of Computing Sciences Lines: 20 Nntp-Posting-Host: triangle.cs.uofs.edu In article <1993Jan26.191232.28187@rwwa.COM>, witr@rwwa.COM (Robert Withrow) writes: |> |> Unless they are claiming that it is *impossible* to write *any* unix kernel |> that doesn't infringe... |> You mean like Kodak is claiming for photo-CD??? I am not surprised by the claims made by any major corporation any more. We will have to see what the courts decide. And that, unfotunately, is not likely to be based on sound technical points as much as which lawyer is more eloquent. bill -- Bill Gunshannon | "There are no evil thoughts, Mr. Reardon" Francisco bill@cs.uofs.edu | said softly, "except one; the refusal to think." | #include From: jbass@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, witr@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 jbass@dmsd.com From: rsk@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: news@netnews.upenn.edu Distribution: usa Organization: Ditka Policy Institute Lines: 23 Nntp-Posting-Host: gynko.circ.upenn.edu In article <1993Jan26.221218.8133@igor.tamri.com> jbass@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 Newsgroups: alt.suit.att-bsdi From: jbass@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 ------------------------ 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. ------------------------ From: rsk@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: news@netnews.upenn.edu Distribution: usa Organization: Ditka Policy Institute Lines: 62 Nntp-Posting-Host: gynko.circ.upenn.edu In article <1993Jan27.215738.12384@igor.tamri.com> jbass@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 From: miguel@roxanne.news.orst.edu (Miguel de Icaza) Newsgroups: alt.suit.att-bsdi Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: 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 Newsgroups: alt.suit.att-bsdi From: scs@iti.org (Steve Simmons) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: Sender: usenet@iti.org (Hela USENET News System) Nntp-Posting-Host: hela.iti.org Organization: Industrial Technology Institute References: <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> <1993Feb2.204838.16992@igor.tamri.com> Distribution: usa Date: Tue, 2 Feb 1993 21:52:06 GMT Lines: 35 jbass@igor.tamri.com (John Bass) writes: >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. While it's good that USL did this, it's worth noting that doing anything else would be a violation of the copyright held and licence granted by UCB. USL "did the right thing", but there's no indication they're doing it out of sheer goodheartedness. >It's sad the UCB didn't extend this same recognition to USL/AT&T/BTL >in the Net2 and 386BSD releases. It has been claimed in this newsgroup (among other places) that the V32 code which reached UCB as the starting point for BSD had no copyright on it. If memory serves, the person who posted that statement here claimed to have been an AT&T employee at the time, and was give the job of removing the copyright before shipping to UCB. The stated motive was a belief on AT&Ts part that one could not simultaneously hold something as trade secret and keep it under copyright. I make no statement as to whether or not that belief was true. I've not rechecked the briefs to be sure, but UCB/BSDI seem to be claiming that their code descends exclusively from that original non-copyright work and other original work outside of AT&T/USL. If such is true, putting an AT&T copyright on it would be rather silly. Ah, the Onyx. I remember it fondly. -- "I went to the doctor and the doctor and the doctor said `Kid, it was something that you ate or drank or something that you did. And it's all in your head, but it's spreading on down to your toes.'" Loudon Wainwright, "The Doctor" Newsgroups: alt.suit.att-bsdi From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <1993Feb2.232053.18533@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University (Ogden, UT) References: <1993Jan27.215738.12384@igor.tamri.com> <1993Feb2.204838.16992@igor.tamri.com> Distribution: usa Date: Tue, 2 Feb 93 23:20:53 GMT Lines: 148 In article <1993Feb2.204838.16992@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: >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. I think you have made the case for the derivation of modern pagers in the BSD releases from BSD work, not AT&T work. Since the BSD pager is what went into SunOS, and the SunOS pager went into SVR4, the argument that modern UNIX's paging dervies from Berkeley rather than AT&T work is supported. >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. I think you'll find that any code in Net/2 or 386BSD (which is not being litigated by USL,as opposed to the BSDi product BSD/386, which is) provided to BSD by Sun and derived from BSD code contain the BSD copyright 8-). The contention you appear to be trying to make here, that 386BSD contains USL sources is partially true -- it has the cpio sources that USL released into the public domain to try and bolster support for their archiving format. It says so in the comments near the AT&T copyright in the code. The reason there are not many USL/AT&T/BTL copyrights in 386BSD is that there is not that much code that USL/AT&T/BTL has contributed to the user community, and as such, most of the USL/AT&T/BTL code is not freely redistributable under the Berkeley copyright. The only exception to the rule of including only software distributable under the Berkeley copyright is the inclusion of the GNU compilers and utilities. The Copyright notices in 386BSD's source files include Genentech, Intel, Carnegie-Mellon, MIT, Lawrence Livermore, Lawrence Berkeley, and many other individuals and corporations (not even including new contributions, of which there have been a great many), including AT&T for at least cpio. Unless you can *prove* origin of the code does not match the copyright notices on it (rather than simply alleging that this is the case), you are blowing smoke. I know several groups involved in software forensics, and have been trying to get them to tackle this problem as a case study; as has been suggested, this is done by a comparison of coding style and parse-tree comparison. The concept of clean-room coding being a requirement rather than simply a practice that has been adopted in several instances is bullshit. What you are saying in requiring a "clean-room" approach is that you support either the "contamination theory" or the "From God to [company] to the world theory". I can't buy off on the first because it is tautilogical in nature; you have to accept the conclusion as an axiom. I can't buy off on the second because I *don't believe* that programmers from [company] are intrinsically better at solving problems than programmers not from [company]. There is always someone who can write better code. That's why programming is still called an "art" by the majority of it's best practitioners (this may not have been the case if Knuth hadn't dicked around with tek since 1973 instead of finishing his series of reference books formalizing the art, but he did, and the point is moot). I'm not saying that clean-room practices weren't observed, or that developement wasn't entirely independant; only that no one has the right to *demand* clean room practices unless there is an initial assumption of guilt *and* that the work in question is derivative. >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. The underlying mechanism for multiscreening a VT330/VT340 using a LAT-based DEC-Server 200 is a job-control mechanism. The same is true of Wyse-60 multiscreens on SCO Xenix with Arnet/Computone/etc. boards. Your pointing at windows and multiscreening equates to pointing to other job-control mechanisms. You seem to be admitting it's utility at the same time you are dispariging it's use. The complaint seems to be with the implementation of the user interface rather than the utility of the soloution. Regardsless of whether you *like* it or not, the question regarded it's origin. I do agree that the BLIT terminal seems to predate it, but I'd like firmer dates to be sure. I'd be more likely to believe Xerox PARC originated the concept pre BSD than the BLIT terminal doing so. --- Regarding the topic under discussion, I do not agree with your assessment of infringement. I have been working with UNIX systems for over 10 years, and have had access to the most recent sources from WECO/AT&T/USL since V6 and Berkeley sources since 4.0 either through my employer or through one university or another, or both. It is my contention that Net/2 and 386BSD do not contain any USL proprietary sources not provided by USL for public redistribution. Since you seem to be coming down on the other side of the fence, to be blunt, you should put up or shut up. A lot of people have expressed this sentiment, and the burden of proof is on the accuser. USL is *definitely* well within their rights in protecting their intellectual property and in enforcing the terms of their license to UCB's CSRG for the 32V code. Their contentions do not involve 386BSD, nor do they involve UCB except as pertains to an alleged violation of their license agreement with WECO, something yet to be proven. I find it unacceptable for you to state that UCB has made no contribution to advancement in the art or science, and trying to bolster this by picking specific instances where something may have been attributed to BSD when it should have possibly been attributed elsewhere. You can not argue the general class based on instances within that class. USL's product has benefitted greatly from research conducted at UCB and elsewhere using UCB-derived code. I would much prefer to have the court record to read than to argue with you or anyone else regarding opinions based on an assumption of guilt of copyright infringement without a legal decision to that effect, but if you post under that assumption, then I have no choice but to argue that barring a decision to that effect, no infringement has occirred. Regards, Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. -- ------------------------------------------------------------------------------- "I have an 8 user poetic license" - me Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial ------------------------------------------------------------------------------- From: gwh@soda.berkeley.edu (George William Herbert) Newsgroups: alt.suit.att-bsdi,comp.unix.bsd Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Date: 29 Jan 1993 18:41:51 GMT Organization: Dis- Lines: 78 Sender: gwh@soda.berkeley.edu Message-ID: <1kbtpf$e9h@agate.berkeley.edu> References: <1993Jan26.221218.8133@igor.tamri.com> <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> NNTP-Posting-Host: soda.berkeley.edu Summary: Challenge to John Bass. In article <1993Jan27.215738.12384@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: >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. Please do so. I'm not going to be personally satisfied until I see this sort of evidence, and lacking any access to AT&T source, I can't do it myself. >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. Ad homoneim, John. Stick to either facts or philosophy of intellectual protection. >Many of the others just lack critical thinking and social skills necessary >to properly evalutate to issues and respond in a responsible way. See above. >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, I hereby challenge you to demonstrate publically that any code from Berkeley's Net/2 distribution is close enough to any AT&T version that it's plagarism and copyright infringement. Note that "general form" wont' cut it, under any interpretation of copyright law as I understand it. I want to see procedures that are the exact same, or just have had variable names altered, or something similar. Or a damn good argument as to why two pieces of code that do the same thing, but are written from scratch by two seperate people at different places, are covered under one copyright, and examples thereof. Even more annoying is your insistance that UCB computer science graduates might be "tainted" by the "blatant CSRG copyright violations", especially since you at the same time are insisting that holding USL employees to task for what we believe are wrongdoings of their company is morally wrong. I smell a significant morality bias here, and I don't like it. And, as to wether UCB has ever invested the manpower to build software products, well, you're wrong. I can think of a couple off the top of my head. Sounds to me like you're speaking from a position of ignorance about UCB's activities over the last fifteen years. There are perfectly professional ways to argue USL's case; so far, you aren't doing any of them. You allege that USL is right, but refused to provide the evidence that, if provided, WILL change at least my (and almost certainly every other rational Usenet readers) opinion on the case. The evidence will come out sooner or later and I'd prefer it be sooner; either CSRG lied about legally making BSD AT&T-Free, or USL is lying about how close the similarities are. In either case, some pretty serious shit is going to come down on someone when the evidence is available. The code will tell, but as of yet it hasn't. So let the code speak. -george william herbert gwh@lurnix.com gwh@soda.berkeley.edu Newsgroups: comp.unix.bsd,alt.suit.att-bsdi From: daveb@Ingres.COM (Dave Brower, DBMS hack, [510] 748-3418) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <1993Jan29.200419.7285@pony.Ingres.COM> Followup-To: alt.suit.att-bsdi Originator: daveb@lotus In-reply-to: gwh@soda.berkeley.edu (George William Herbert) Reply-To: daveb@lotus (Dave Brower, DBMS hack, [510] 748-3418) Organization: Ingres, an ASK Company References: <1993Jan26.221218.8133@igor.tamri.com> <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> <1kbtpf$e9h@agate.berkeley.edu> Date: 29 Jan 93 20:04:18 GMT Lines: 57 John Bass notes that there may be some copyright and/or trade secret problems in the Net2 code caused by what appear to be "cut, paste, and delete" operations. These may be very significant, and I'm in no position to form an opinion based on the facts or the law. However, he does drag in a few other points that are much more debatable. One is a claim of infringement on the Bach book, and the other is a claim of plagiarism. I'd like to believe the claim based on Bach is a non-issue. As you can't copyright ideas, only code, and there is only pseudo-code in Bach, I don't see any way any there can be infringement on Bach in the Net2 source. Indeed, I don't see any way to infringe Bach in a real set of _any_ source unless you copy him word for word in comments. As to "plagiarism", I submit this is also a straw-argument without bearing on the BSDI or Net2 release. Plagiarism is an issue of academic morality, and has _nothing_ to do with business arrangements, copyright, or trade-secret law. BSDI and Net2 are not academic vehicles, and considering them as such is facetious. Considering the moral side of plagiarism, there is a strong argument that any Software Engineer who, within the scope of binding copyright and trade-secret regulation, doesn't borrow and reuse the ideas of existing working systems is a fool. The legal distinctions are in where the borrowing and use falls with respect to the copyrights, trade-secret protection, and patent interest. Thus the major issue regarding Net2 and the suit are the factual claims that some files in Net2 violate the copyright of V32, or any valid trade-secret restrictions not made moot by Bach and other open literature. AT&T has not yet released the details of the points of claim, so for now we can only offer conjecture about the merits. It's far from clear to me how copyright could, would or should be applied to non-functional code fragments like those cited by Bass. It's further not clear to me that the "structure and naming" claim could/would/should be enforceable, as it seems very close to the murky "look-n-feel" debate. It _is_ clear that the CSRG is/was playing intentionally close to the line, and that reasonable people can disagree where they landed. The final ruling will happen in court or in a settlement. It won't be in the court of public or net opinion. It's disingeuous to pull Bach and plagiarism into the public discussion about the legality. Bach isn't part of the complaint, and plagiarism isn't a legal issue. I'd like to think we all regret it's down to lawyers arguing. cheers, -dB -- Windows/NT - the VMS of the 90s From: brad@optilink.COM (Brad Yearwood) Newsgroups: alt.suit.att-bsdi,comp.unix.bsd Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <14162@optilink.COM> Date: 31 Jan 93 05:44:27 GMT References: <1993Jan26.221218.8133@igor.tamri.com> <106742@netnews.upenn.edu> <1kbtpf$e9h@agate.berkeley.edu> Organization: Optilink Corporation, Petaluma, CA Lines: 80 In article <1kbtpf$e9h@agate.berkeley.edu>, gwh@soda.berkeley.edu (George William Herbert) writes: > In article <1993Jan27.215738.12384@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: > > > >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, I hereby challenge you to demonstrate publically that any > code from Berkeley's Net/2 distribution is close enough to any > AT&T version that it's plagarism and copyright infringement. > We should also ask Mr. Bass to provide some substantiation for his claim of 10KMY and $5G as relates to V7 or 32V. The consequences of this have great entertainment potential. Did AT&T really pay their software people $500K/year as might be inferred from your figures, or were the developers just capitalized on a scale never before or since seen? These dollar and man-year figures are only remotely approachable as you move into the era of USG/USL and Sys. V. What is at issue is NOT Sys. V, it is V7 and 32V. Support and marketing expenses cannot be at issue, because AT&T did _nothing_ to support or market V7 or 32V. After making a lot of phone calls, if you were persistent, you could eventually find someone in AT&T who had the authority to quote a fee of something like $22K, exchange license paperwork, take your check, and send you a tape. Support consisted of man pages, two eventually published issues of BSTJ, and the fact that Bell Labs' librarian would send you copies of some relevant papers, whether you were a licensee or not. I made the calls and got the quote in the relevant era, and I know what I'm talking about. You cannot tell me that I am "to [sic] young" or parroting folklore. --- breaking away now from the direct Berkeley/USL issues --- What measures should universities be required to take to avoid "unfair" competition? Should they be required to burn or lock in vaults any software which they develop? Or perhaps they should be required to take the time- honored approach of bestowing exclusive commercial rights for tax-funded developments to a well-connected coterie of nominally private interests? Or perhaps university people should be prohibited from writing any code at all - they should be required to deliver cleanroom specifications to cost-plus contractors if an actual implementation is needed. Perhaps graduate students should be shot upon delivery of their dissertations, lest they compete "unfairly" with industrial researchers. (_What_ industrial researchers? Good question.) If you want to speculate about taxpayer dollars and Unix, then let's talk about SVID compliance being specified in government procurements, and how this might have locked out viable products, perhaps more cost-effective than Sys. V, which happened to be proprietary both in specification and in implementation, or which met some published specification other than the one which AT&T happened to have the only available implementation of. USL, their overpaid pugnacious twerp CEO, and their overreaching lawyers are pissing in the Unix soup, and it's starting to taste worse than merely stale. Maybe they're doing the world a favor by implicitly promoting a new generation of hopefully-innovative proprietary software (like NT), and clever/independent or innovative free software (like Linux and hopefully Hurd). I have not stripped AT&T of any right by voting with my wallet against them by slam-dunking my Universal Card. I still (foolishly, and against certain direct investment interests) keep my long-distance service with them out of gratitude for their (apparently fading) support of fundamental and applied research, including the original Unix. They don't even make real telephones any more - they sell crappy imported junk with previously unthinkable defects, like a tone dialer which isn't phone-line-powered (won't function when the battery poops out). Brad Yearwood brad@optilink.com {uunet, pyramid}!optilink!brad Petaluma, CA From: imp@boulder.parcplace.com (Warner Losh) Newsgroups: alt.suit.att-bsdi,comp.unix.bsd Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: Date: 3 Feb 93 02:44:20 GMT References: <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> <1kbtpf$e9h@agate.berkeley.edu> Sender: news@boulder.parcplace.com Organization: ParcPlace Boulder Lines: 12 In article <1kbtpf$e9h@agate.berkeley.edu> gwh@soda.berkeley.edu (George William Herbert) writes: >refused to provide the evidence that, if provided, WILL change at >least my (and almost certainly every other rational Usenet readers) Both of them? Why bother :-) Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety. From: Herve.Schauer@hsc-sec.fr (Herve Schauer) Newsgroups: alt.suit.att-bsdi Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Date: 29 Jan 1993 21:37:12 +0100 Organization: Herve Schauer Consultants, Paris, France Lines: 12 Distribution: usa Message-ID: <1kc4hoINN32e@itesec.hsc-sec.fr> References: <1993Jan26.221218.8133@igor.tamri.com> <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> NNTP-Posting-Host: itesec.hsc-sec.fr In article <1993Jan27.215738.12384@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: > (...) [ Lot's of very strong stuff against BSD, supporting AT&T/USL ] May be Toshiba (Toshiba America MRI) have interests in USL ? HERVE -- Email : Herve.Schauer@hsc-sec.fr Phone: +33(1)46388990; Minitel: +33(1)46382525; Fax: +33(1)46380505; Postal mail: Herve Schauer Consultants,142 Rue de Rivoli,75039 Paris Cedex01 From: torek@horse.ee.lbl.gov (Chris Torek) Newsgroups: alt.suit.att-bsdi Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Date: 3 Feb 1993 23:18:45 GMT Organization: Lawrence Berkeley Laboratory, Berkeley CA Lines: 46 Message-ID: <28816@dog.ee.lbl.gov> References: <1993Jan26.221218.8133@igor.tamri.com> <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> NNTP-Posting-Host: 128.3.112.15 I intend to stay out of this as much as possible, but I thought I should at least back up Chris Demetriou a bit. I, for one, would be less inclined to dismiss John Bass's arguments off-hand if he paid more attention to facts and less to rhetoric: In article <1993Jan27.215738.12384@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: >[Some form of copying] 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. Since net.2 did not include bio code (just the names and parameter types of interface routines, which can be found in various books and non-secret documentation), this evidence for copying is difficult to see. Even (for purpose of argument only) granting that the design is copied, this says nothing about implementation, no implementation being given. >Given the nature and scope of the disclosure [CSRG] were negligent not to >obtain a 3rd party review and sanction of counsel prior to making the >release public. Since they *did* obtain a third-party review and legal counsel, I find this statement most peculiar. (On the other hand, perhaps Mr. Bass has been referring to 386BSD, rather than UCB's net.2 release. I have no direct experience with this myself, and will refrain from comments.) Not that the following has anything to do with the USL/BSDI/UCB suit, but: >... I have never classed [the BSD FFS] filesystem as fast .... faster than >the orginal V6/V7 filesystem on larger machines like VAXen yes, but not fast. I also find it interesting to note that at last week's USENIX, the various log-structured file system papers basically said `we cannot beat FFS's block allocation'. Indeed, EFS (which is just FFS with McVoy-style transfer combination) beat not only the LFS times, but even the raw disk performance, in Margo Seltzer's measurements. (Note that it was necessary to fix one line in ffs_alloc.c. A logic test was reversed, preventing contiguous block allocation.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov Newsgroups: alt.suit.att-bsdi From: jbass@igor.tamri.com (John Bass) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <1993Feb8.012931.14244@igor.tamri.com> Organization: DMS Design References: <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> <28816@dog.ee.lbl.gov> Date: Mon, 8 Feb 93 01:29:31 GMT Lines: 63 In article <28816@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes: >>Given the nature and scope of the disclosure [CSRG] were negligent not to >>obtain a 3rd party review and sanction of counsel prior to making the >>release public. > >Since they *did* obtain a third-party review and legal counsel, I >find this statement most peculiar. I had been informed that the third-party was from inside the org ... but I conflicting statements as who ... can anyone say for sure who advised the UCB lawyers? (and please say how you know) >I also find it interesting to note that at last week's USENIX, the >various log-structured file system papers basically said `we cannot >beat FFS's block allocation'. Indeed, EFS (which is just FFS with >McVoy-style transfer combination) beat not only the LFS times, but even >the raw disk performance, in Margo Seltzer's measurements. > >(Note that it was necessary to fix one line in ffs_alloc.c. A logic >test was reversed, preventing contiguous block allocation.) Speed of raw transfer rates are nearly the same for all filesystems with the same physical I/O size ... especially on drives with read-ahead, write-behind. A critical design flaw of FFS/EFS is the attempt to balance cylinder groups, this causes extensive head motion that could otherwise be avoided with the locality imparted from a single bit-mapped allocation scheme (the V7 freelist design is poor on large address space machines .. the PDP11's didn't have enough memory to handle an effective bitmap allocation scheme). A filesystem that tries to keep the traffic within 30 cylinders will out perfom one that forces seeks across the entire disk (track-to-track seeks vs average seek -- plus rotational latency). For a certain class of educational work loads (such as UCB ERNIE 8 years ago) small quota's, large number of accounts, short file lifes, small files, and very high disk queue depth's this was a minor issue. LFS suffers in part from the same flaw with it's concentration on writes assuming most reads are cached. LFS on machines without the massive sprite disk cache will suffer greatly from this lack of locality. Not only is the entire disk active, but with a smaller cache the effectiveness of localizing blocks in a file is reduced. On sprite machines, if the cache gets flushed re-read performace should be much poorer than FFS/EFS on look-ahead buffered drives. Given the design goals and environments for both FFS/EFS and LFS they made reasonable tradeoff's ... unfortunately less attention was paid to how some of these tradeoff's performed or scale in other environments. Certainly developers attempting to implement LFS style filesystems on machines with less than 4mb of disk cache are most suprised about how critical the sprite sized buffer cache is to the design. As a side note, give FFS/EFS a sprite sized buffer cache (and fix the buffer lookup algorithms) and you will be surprised at how fast it can be. Two final notes ... the write speed of LFS is largely due to the exteremly large write request sizes so they can get a reasonable percentage of the raw disk write bandwidth. V7/Sys5 & FFS/EFS filesystems are largely CPU bound due to poor single block algorithms in BIO and SPL handling on many machines - to get any significant filesystem performance requires a complete overhaul -- doing file-at-a-time operations vs block-at-a-time operations and reducing the locking overhead ... especially on MP systems. John Bass Newsgroups: alt.suit.att-bsdi From: bzs@world.std.com (Barry Shein) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit In-Reply-To: jbass@igor.tamri.com's message of Mon, 8 Feb 93 01:29:31 GMT Message-ID: Sender: bzs@world.std.com (Barry Shein) Organization: The World References: <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> <28816@dog.ee.lbl.gov> <1993Feb8.012931.14244@igor.tamri.com> Date: Mon, 8 Feb 1993 04:01:13 GMT Lines: 40 From: jbass@igor.tamri.com (John Bass) [responding to Chris Torek] >>Since they *did* obtain a third-party review and legal counsel, I >>find this statement most peculiar. > >I had been informed that the third-party was from inside the org ... >but I conflicting statements as who ... can anyone say for sure who advised >the UCB lawyers? (and please say how you know) >>I also find it interesting to note that at last week's USENIX, the No, AT&T was involved. I have a better idea, until you know what the hell you are talking about howsabout sitting on your hands? Floating out maliciously damaging lies as speculation is not excusable, not excusable at all. >>various log-structured file system papers basically said `we cannot >>beat FFS's block allocation'. Indeed, EFS (which is just FFS with >>McVoy-style transfer combination) beat not only the LFS times, but even >>the raw disk performance, in Margo Seltzer's measurements. > >LFS suffers in part from the same flaw with it's concentration on writes >assuming most reads are cached. LFS on machines without the massive sprite >disk cache will suffer greatly from this lack of locality. Not only is the >entire disk active, but with a smaller cache the effectiveness of localizing >blocks in a file is reduced. On sprite machines, if the cache gets flushed >re-read performace should be much poorer than FFS/EFS on look-ahead buffered >drives. For the love of god John can't you even be bothered to read the paper before babbling like this? No, the results cited had NOTHING to do with what you are fabricating off the top of your head. I read the paper, and I attended the talk. What a moron. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD Newsgroups: alt.suit.att-bsdi From: scs@iti.org (Steve Simmons) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: Sender: usenet@iti.org (Hela USENET News System) Nntp-Posting-Host: wotan.iti.org Organization: Industrial Technology Institute References: <106742@netnews.upenn.edu> <1993Jan27.215738.12384@igor.tamri.com> <28816@dog.ee.lbl.gov> <1993Feb8.012931.14244@igor.tamri.com> Date: Mon, 8 Feb 1993 14:47:00 GMT Lines: 13 jbass@igor.tamri.com (John Bass) writes: >LFS suffers in part from the same flaw with it's concentration on writes >assuming most reads are cached. LFS on machines without the massive sprite >disk cache will suffer greatly from this lack of locality. John, I suggest you get and read the papers. At least on of them addresses this issue. -- "I went to the doctor and the doctor said `Kid, it was something that you ate or drank or something that you did. And it's all in your head, but it's spreading on down to your toes.'" Loudon Wainwright, "The Doctor" Newsgroups: alt.suit.att-bsdi From: witr@rwwa.COM (Robert Withrow) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <1993Jan29.181036.4196@rwwa.COM> Sender: news@rwwa.COM (News Administrator) Nntp-Posting-Host: spooky Reply-To: witr@rwwa.com Organization: R.W. Withrow Associates References: <1jp53tINN4bl@hal.com> <1993Jan24.221548.24252@rwwa.COM> <1993Jan26.221218.8133@igor.tamri.com> Distribution: usa Date: Fri, 29 Jan 1993 18:10:36 GMT Lines: 27 In article <1993Jan26.221218.8133@igor.tamri.com>, jbass@igor.tamri.com (John Bass) writes: I think it would be pointless to rebut your assertions in detail, not because I think they are either right or represent strong arguments, but because I think there is an insignificant probability that either of us would be swayed. Thus I only have two comments. | 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. If this is your position then logically you would also have to take the position that USL should publicly state which are these 7900 files and also clearly state that they are making no claims on them and that as far as they are concerned anyone can make any use of them desired. Instead, in court, USL has alleged that then *entire* NET-2 release is their property. In addition, you make various assertions containing phrases such as ``frankly obvious'' and ``clear copyright violation'' and ``clearly outlines'', about things that are nowhere near as clearcut as you seem to think. Nor is it obvious which side of this argument has ``warped view of what IS and IS NOT legal''. -- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA From: greywolf@Autodesk.COM ( Cmdr. I. Node) Newsgroups: alt.suit.att-bsdi Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Message-ID: <18505@autodesk.COM> Date: 29 Jan 93 22:40:36 GMT References: <1993Jan26.221218.8133@igor.tamri.com> Distribution: usa Organization: Autodesk, Inc. Lines: 163 I've been watching this go by, and it's become impossible to sit on my hands any further. /* jbass@igor.tamri.com (John Bass) writes: * * Robert Withrow, witr@rwwa.COM writes: * * > ... * > 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 ^^^^^^^^^^^^^^^ Not. He's probably not too far off the mark. Give him .5% either way. Not enough of a difference to make a big deal of. * files are less than 0.00000000001% of all files in the universe ... so * what are they bitching about? Straw man. What's this got to do with the issue at hand? * 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). This is a problem? Deriving code from published algorithms wasn't per se illegal, last I looked. * 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. The way I look at it was that this research was funded by DARPA, a *government* agency, funded by the taxes of the *people*. It hardly seems reasonable that this research and its results should NOT be readily available! * * 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? I've been watching your tone of voice for about two or so weeks, now, and I have a question for you: Do you or your company have a vested interest in UNIX Source Code remaining restricted and proprietary? I can imagine that there are a lot of companies who have (had) a really comfy agreement with USL/AT&T/whatever-the-entity-was-at-the-time who would REALLY LOVE to see the source licensing scam continue. * * 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. It is VERY scary to consider hiring droids with such a morally imposing view of what IS and IS NOT The Right Thing to do. Given that other major universities -- most of them, in fact -- use BSD, which originated at (surprise!) UC Berkeley, it's not difficult to understand the grass roots support at all. * * 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 think you should take a look at the Affirmative Action rules being followed by most employers. Points, and points of view (numbers mine): * * [1]: I also think that all faculty, staff, and student assistants that * participated and/or condoned this piracy should be removed or severely * disciplined. * 1. As a country, we are doing something similar to a sect of people who probably don't deserve it, simply because of happenings in the Middle East over the last millennium or so. * * Call's to your State Assemblyman[2] and Pete Wilsons[3] office for a full (call is?) [7] * 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 [4]. Maybe if they were directly at risk * they would think twice about crossing over the line [8], or allowing their * staff to put them at risk. * 2. My state assemblycritter just might agree with my points of view. 3. Pete Wilson should be removed from office before he can do any more harm to this state than he already has. Due to the way he cut the budget, along with trimming education and all he managed to shut down the CSRG at UCB, and they've done more to promote the state of UNIX *and* internetworking in the last seven years than the folks who worked so hard to make System V into a product% have done in twice that time. 4. Exempting public employees from legal protection and allowing their current and future assets to be available for such settle- ments illustrates perfectly what has happened to the concept of "Unreasonable (Search and) Seizure" in the last twenty years. 5. Notice that System V Release 4 has lots of BSD stuff in it. Who has stolen what from whom? 6. Do you *really* feel that making UNIX (BSD) freeware will have a significant effect on the state of the UNIX market as it stands today? Certainly not instantly. Over a long period of time, maybe. If UNIX is available as freeware, it will provide some competition to USL/SVR4, and hopefully it will put some pressure on them to actually listen to their customers' problem reports. 7 (not related, but so what?) Where did you (not) learn the difference between possessives, plurals and contractions? 8. What line are they not supposed to cross over? * * John Bass * DMS Design * jbass@dmsd.com */ /*** End of excerpt from jbass@igor.tamri.com (John Bass) ***/ I pray that not many people with your opinions on these matters are in a position to significantly exercise them. None would be a better match, but in light of the fact that we do not have a perfect world (understatement), not many is the best I can do. I agree with whomever said this: "When it comes down to craftsmanship and legal harassment, I side with the craftsman." That was well put. As one who has used both BSD and Missed 'em V over the course of nearing a decade, I think BSD had their heads on straighter. Sysadministrating MVRx is a royal pain, and I sincerely hope that BSDI prevails in this action. ----- %: product: In this case, the functional opposite of a working tool. ----- From: bb@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: news@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) lpf@uunet.uu.net ------------------------------------------------------------------------------- Brian Bartholomew - bb@math.ufl.edu - Univ. of Florida Dept. of Mathematics Newsgroups: alt.suit.att-bsdi From: jbass@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 <38437@uflorida.cis.ufl.edu> bb@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 From: jms@tardis.Tymnet.COM (Joe Smith) Newsgroups: alt.suit.att-bsdi Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit Summary: Major software in source form. Message-ID: <3363@tardis.Tymnet.COM> Date: 7 Feb 93 04:23:53 GMT References: <38437@uflorida.cis.ufl.edu> <1993Feb3.011536.11454@igor.tamri.com> Organization: BT Tymnet, San Jose, CA Lines: 14 In article <1993Feb3.011536.11454@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: >Especially when UNIX is only major software product available in source form, You need to modifiy that sentence to "the only major software product I am personally aquainted with that is available in source form". DEC's TOPS-10 product came with 100% source code. The operating system, the utilities, the compilers, the whole shebang. The entire world is not UNIX vs. MS-DOS. -- Joe Smith (408)922-6220 BTNA GNS Major Programs, TYMNET Global Network P.O. Box 49019, MS-C51, San Jose, CA 95161-9019 CA license plate: "POPJ P," Married to the LB, Quantum Leap's #1 net.fan PDP-10, 36-bits forever! Humorous disclaimer: "My Amiga 3000 speaks for me." Newsgroups: alt.suit.att-bsdi From: bzs@world.std.com (Barry Shein) Subject: Re: UC Berkeley Embroiled in Computer Software Lawsuit In-Reply-To: jms@tardis.Tymnet.COM's message of 7 Feb 93 04:23:53 GMT Message-ID: Sender: bzs@world.std.com (Barry Shein) Organization: The World References: <38437@uflorida.cis.ufl.edu> <1993Feb3.011536.11454@igor.tamri.com> <3363@tardis.Tymnet.COM> Date: Mon, 15 Feb 1993 21:47:45 GMT Lines: 26 From: jms@tardis.Tymnet.COM (Joe Smith) >>Especially when UNIX is only major software product available in source form, > >You need to modifiy that sentence to "the only major software product I am >personally aquainted with that is available in source form". > >DEC's TOPS-10 product came with 100% source code. The operating system, the >utilities, the compilers, the whole shebang. The entire world is not UNIX >vs. MS-DOS. ...Or at least wasn't in 1983 when DEC discontinued further development of all their Decsystem-10 and Decsystem-20 products (TOPS-10 being one of these.) Seems like you've made a rather hollow point, no? Actually, judging by the statistics the whole world *IS* Unix vs MS/DOS vs Mac (if you must see the world in this way), with only a few other outliers thrown in (outside of the corporate mainframe world which itself is rapidly moving in this direction also.) -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD