HDTenEightyP/NetNews huggingface dataset:
From: smb@ulysses.att.com (Steven Bellovin)
Newsgroups: alt.suit.att-bsdi
Subject: Re: 32/V licensing
Date: 2 Sep 92 01:13:10 GMT

This notion of the contract being thrown out because circumstances have
changed is nonsense.  That's one of the risks of business -- you have
to guess the odds of things changing, and hedge your bets if
necessary.  Look at it this way -- suppose you're employed somewhere,
and, relying on your salary, you get a mortgage to buy a house.  If,
two years later, you lose your job, you can't go to the bank and say,
``My circumstances have changed; I'm not going to pay off the rest of
this loan.''  Well, you can say it, but you're not going to get very
far, at least if you want to keep your house.

It's quite possible that AT&T would not have made UNIX system licenses
so readily available if they'd known what was going to happen.  On the
other hand, maybe they would have -- there's a lot of research software
that's still made available to universities.  And in any event, the
current suit is by USL, not AT&T -- and though AT&T is the majority owner,
it's by no means the only owner of USL.  I have no idea what USL's
policies towards universities are.

		--Steve Bellovin,
	working for, but not speaking for, AT&T Bell Laboratories
Newsgroups: alt.suit.att-bsdi
From: asoper@wyvern.twuug.com (Aubrey Soper)
Subject: Re: 32/V licensing
Organization: Tidewater UNIX Users Group
Date: Fri, 4 Sep 1992 02:43:23 GMT

bzs@ussr.std.com (Barry Shein) writes:


>I would call such a situation a change in circumstances that affects
>the original assumptions of the contract.

Sorry, but assumptions have nothing do to with contract law.

Also, I think your example of bankruptcy is a little off the mark
since, arguendo, BSDI might avail itself of bankruptcy protection 
but this would not provide any collateral protection against the
charges asserted by AT&T/USL.

My suggestion is that we defer comments about the law until AT&T/USL 
is more explicit about what's bothering them.  

aubrey soper
-- 

aubrey
---                              ;
><>  ><>  ><>  ><>  ><>  ><>  ><>'  ><>  ><>  ><>  ><>  ><>  ><>  ><>  ><>  ><>
Newsgroups: alt.suit.att-bsdi
From: peter@taronga.com (Peter da Silva)
Subject: Re: We could blow up USL.
Organization: Taronga Park BBS
Date: Mon, 31 Aug 1992 11:29:01 GMT

In article <KANDALL.92Aug31173719@globalize.nsg.sgi.com> kandall@nsg.sgi.com (Michael Kandall) writes:
>Other than providing source code, it does not do anything which I can
>see would greatly distinguish it from other binary UNIXes on the
>market.  What are its competitive points?

It's smallar and supposedly faster than SCO UNIX, and all the people who
were reluctant to move from SCO Xenix to SCO UNIX because of the size will
be a ready market.

For that matter, my own tired iron doesn't have much disk space for screwing
around with source code... but a reliable binary version with support would
be a welcome change.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
From: vander@flab.fujitsu.co.jp (Mike van der Velden)
Newsgroups: alt.suit.att-bsdi
Subject: 1-800-NOT-UNIX
Date: 4 Sep 92 08:19:12 GMT
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan


Just to inject a bit of humour into this otherwise rather serious
discussion, I am posting something I read on rec.humor.


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

This was found in a catalog for Public Brand Software.  They sell
software for IBM PCs.  From their tone, I suspect they won't mind
being quoted without permission.

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note that we used to refer to our phone number as 1-800-IBM-DISK.  We have
been told by IBM Corporation that we can't do this anymore.  While it is
tempting to represent IBM as a bully picking on the little guy, we do see
their point.  The use of their trademark in such a generic sense can lead
to a dilution of their identity.  (Besides, they have more lawyers than we
have disks.)  So, in the future, please think of our phone number as:

	For the amateur radio crowd: 1-800-HAM-DISK
	For all you couch potatoes: 1-800-HBO-DISK
	For purists: 1-800-426-3475
	Even: 1-800-I-AM-DISK (hear me roar)
	But not, we repeat, NOT as: 1-800-IBM-DISK

We thank you for your support in this matter.

~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Mike van der Velden
Distributed Systems Laboratory, Fujitsu Laboratories Ltd., Kawasaki, Japan
e-mail: vander@tokyo.hi.flab.fujitsu.co.jp

ps. If you send me a picture postcard      Mike van der Velden
    from your area to the address at       Fujitsu Unoki Dormitory, room 227
    right, I'll send you one from Tokyo.   2-17-18 Unoki, Ota-ku, Tokyo 146
    Postcards must be received by          Japan
    November 15, 1992
From: jpk@Ingres.COM (Jon Krueger)
Newsgroups: alt.suit.att-bsdi
Subject: we infer how you feel from how you act
Date: 28 Aug 92 06:34:54 GMT
	<KANDALL.92Aug24143319@globalize.nsg.sgi.com>
	<1992Aug24.202349.20503@gateway.novell.com>
	<BZS.92Aug24192342@ussr.std.com>
	<KANDALL.92Aug25180650@globalize.nsg.sgi.com>
	<92Aug25.190728edt.187@smoke.cs.toronto.edu>
Reply-To: jpk@Ingres.COM (Jon Krueger)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501

Michael Kandall writes:

> BSD/386 is not a direct revenue threat.  Same for NET/2.

Clearly USL feels differently.  They behaved one way with respect to
net.2 and another with respect to BSD/386.

-- Jon
--
Jon Krueger  jpk@ingres.com
From: bzs@ussr.std.com (Barry Shein)
Subject: Re: 32/V licensing
Organization: The World
	<1992Aug20.235637.21040@njitgw.njit.edu>
	<KANDALL.92Aug21141122@globalize.nsg.sgi.com>
	<BZS.92Aug21192010@ussr.std.com>
	<KANDALL.92Aug24143319@globalize.nsg.sgi.com>
	<Aug.25.21.17.13.1992.1004@athos.rutgers.edu>
	<BZS.92Aug26173417@ussr.std.com>
	<KANDALL.92Aug27115836@globalize.nsg.sgi.com>
Date: Sun, 30 Aug 1992 01:17:20 GMT


From: kandall@nsg.sgi.com (Michael Kandall)
>AT&T entered the computer business in 1984.

Is that the relevant date? Or is the date they were legally permitted
to enter the computer business (some time before that, 1981 I believe)
relevant?

>The restrictions in the educational (vs.
>commercial) varieties of the license do NOT stem from AT&T's former
>business restrictions (otherwise there would be no pre-'84 commercial
>market).

Why do you believe this? Did the varieties and restrictions change
radically after the business restrictions were lifted? Indeed they
did. How do you account for that?

I don't see how your "otherwise" follows.

>The fact that either license cost merely a song is.

To a great extent, yes, of course nothing prevented them from
maintaining those prices etc.

>Only
>AT&T was restricted from making money, not other commercial
>businesses.

Yes...and...? (I fail to see where this catechism is leading, it's
mostly just a rehash of tangential points no one is particularly
disputing.)

>Anyways, your analogy employing the law of propagating release from
>responsibilities (B was released from its responsibilities to A, so
>C must be released from its responsibilities to B!) does not hold.

...well, it didn't lead to this conclusion, that's for sure.

Who says it does not hold?

It's not very useful to have a person with a particular point of view
make this sort of "assertion by authority".

--
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
From: brian@ucsd.edu (Brian Kantor)
Newsgroups: alt.suit.att-bsdi
Subject: TV coverage?
Date: 31 Aug 1992 20:58:32 GMT
Organization: University of California, San Diego
NNTP-Posting-Host: ucsd.edu

Many of us have Court-TV on our cable systems.  I think it would be a
good idea for each of us to write to the Court-TV people asking them
to cover the trial.

I suspect that much of it might well be worth watching, especially
when friends of ours are called to testify!
	- Brian
From: richard@pegasus.com (Richard Foulk)
Newsgroups: alt.suit.att-bsdi
Subject: Re: basics of NET/2 and suit?
Date: 29 Aug 92 02:02:01 GMT
Organization: Pegasus,  Honolulu

In article <1992Aug26.004246.23899@usenet.ins.cwru.edu> trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
> [...]
>
>USL has not been specific.  They claim that some part of the Net/2 release
>is derived from their copyrighted and trade-secret-protected works.  They
>also claim that BSDI somehow added some USL-proprietary code to BSDI *after*
>the Net/2 release.

Could you please quote the portion of the document that states this?
I don't remember seeing any such claims.


-- 
Richard Foulk		richard@pegasus.com
Newsgroups: alt.suit.att-bsdi
From: peter@taronga.com (Peter da Silva)
Subject: Re: We could blow up USL.
Organization: Taronga Park BBS
Date: Thu, 27 Aug 1992 01:09:15 GMT

In article <KANDALL.92Aug26181242@globalize.nsg.sgi.com> kandall@nsg.sgi.com (Michael Kandall) writes:
>I really meant BSDI's product, BSD/386, is not a direct revenue
>threat.

Why not? It's a stable commercial quality UNIX implementation that supports
X, TCP/IP, and will in the final release run SCO UNIX binaries. It will
probably run System V release 3.2 and Xenix binaries as well, since they
run on SCO UNIX. This is a direct threat to SCO, and will result in a loss of
royalty revenues via SCO.

>That is sort of my point about OSF, in particular, about DEC and IBM
>who are still making public statements to the effect of being bent on
>bringing OSF/1 to market.

I see no indication that they are planning this.
-- 
                                                                `-_-'
                         Have you hugged your wolf today?        'U`

Peter da Silva, Taronga Park BBS, Houston, TX  +1 713 568 0480/1032
From: kandall@nsg.sgi.com (Michael Kandall)
Newsgroups: alt.suit.att-bsdi
Subject: Re: 32/V licensing
Date: 2 Sep 92 19:00:08 GMT
	<1992Aug20.235637.21040@njitgw.njit.edu>
	<KANDALL.92Aug21141122@globalize.nsg.sgi.com>
	<BZS.92Aug21192010@ussr.std.com>
	<KANDALL.92Aug24143319@globalize.nsg.sgi.com> <Aug.25.21
Organization: Nihon Silicon Graphics, Japan

>>>>> On Tue, 1 Sep 1992 21:32:00 GMT, bzs@ussr.std.com (Barry Shein) said:
>
>Barry> The point is, if you need it in a soundbite, the change in conditions
>Barry> under which the contract was originally agreed to are sufficient that
>Barry> there should be plenty of room for negotiation to salvage its intent.

Barry> Being as both sides, but particularly USL (being a for-profit corp
Barry> with shareholders), have a fiduciary obligation not to yield an inch
Barry> voluntarily one obvious source of leverage would be a judge making it
Barry> clear that the contract as it stands has a strong liklihood of being
Barry> thrown out entirely due to fundamental changes in the assumptions
Barry> under which the contract was drawn. Since that would also negate that
Barry> contract with every other signee one would assume USL would suddenly
Barry> find the motivation to renegotiate a modification of the contract.

You have made two points (I think).

First you said some fundamental change in conditions/assumptions
invalidates the contract, then you provided the soundbite above that
"there should be plenty of room for negotiation", now you are back to
the contract being invalidated.  Could you please clarify whether
these are two different points, or different aspects of the same
point.

I do not think the contract is invalidated in any way by AT&T's
deregulation.  UCB signed a contract saying they would keep the
UNIX code "in confidence", and in USL's opinion, they aren't.

Thanks,


Mike
----
Newsgroups: alt.suit.att-bsdi
From: kandall@nsg.sgi.com (Michael Kandall)
Subject: Re: We could blow up USL.
Organization: Nihon Silicon Graphics, Japan
	<92Aug25.190728edt.187@smoke.cs.toronto.edu>
	<KANDALL.92Aug26181242@globalize.nsg.sgi.com> <M9PI4CB@taronga.com>
Date: Mon, 31 Aug 1992 22:37:19 GMT

>>>>> On Thu, 27 Aug 1992 01:09:15 GMT, peter@taronga.com (Peter da Silva) said:

Peter> In article <KANDALL.92Aug26181242@globalize.nsg.sgi.com> kandall@nsg.sgi.com (Michael Kandall) writes:
>I really meant BSDI's product, BSD/386, is not a direct revenue
>threat.

Peter> Why not? It's a stable commercial quality UNIX implementation that supports
Peter> X, TCP/IP, and will in the final release run SCO UNIX binaries. It will
Peter> probably run System V release 3.2 and Xenix binaries as well, since they
Peter> run on SCO UNIX. This is a direct threat to SCO, and will result in a loss of
Peter> royalty revenues via SCO.

If they can win the confidence of business users, it may turn out to
be a real competitor.  I see the main sales-point of BSD/386 as the
provision of source code, which would appeal more to hobbyists and
students.

Other than providing source code, it does not do anything which I can
see would greatly distinguish it from other binary UNIXes on the
market.  What are its competitive points?


Mike
----
From: tg@cs.toronto.edu (Tom Glinos)
Newsgroups: alt.suit.att-bsdi
Subject: Re: We could blow up USL.
Date: 25 Aug 92 23:22:17 GMT
Organization: Department of Computer Science, University of Toronto

In article <1992Aug24.202349.20503@gateway.novell.com> terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert) writes:
>and the publications referenced in their bibliographies on pages xi and 454,
>respectively, and the POSIX 1003.1 standard and SVID 85 publication of AT&T
>customer information center.  These leave exceptionally little to the
>imagination as far as how an implementation is to behave.  What is secert?
>Anything left is bound to have appeared in one of Knuth's books.

I'll comment on the SVID since I was initimately involved with it's production.
All references of the word "UNIX" were scrubbed. The reasoning was to
protect the trademark and to "define" a particular UNIX implementation.

Bach's book wasn't scrubbed in the way the SVID does.
This weakens USL's position.

Personally, I think USL, is acting badly.
USL suit may have a few good points going for it, but it's hard to think what
those might be because you have to strip away the abusive and irratating
parts of their petition.

This could have been done in private discussions between the involved parties
and "arrangements" could have been made. It seems USL has lost the ability
to make subtle business or politcal moves.
-- 
=================
No regrets, ever!			| Tom Glinos @ U of Toronto Statistics
For down that path, lies madness	| tg@utstat.toronto.edu
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: alt.suit.att-bsdi
Subject: 32/V licensing
Date: 26 Aug 92 01:17:13 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I have a copy of an educational license for 32/V which seems to be
from the same time period as Berkeley's.  It talks about methods and
concepts.  (If Berkeley did in fact refuse to sign such a license, it
could be that theirs is earlier.)  However there's another clause that
suggests that a broad interpretation of what is covered is going to be
hard to justify.  It explicitly *requires* us to release any
modifications we make to the software without restriction on use,
copying, or further distribution, to the extent that these
modifications do not include any portion of the LICENSED SOFTWARE.
This suggests strongly that arguments are going to have to be based on
specific presence of ATT code, and can't take the wide view that
anything which is integrated with ATT's code become a derivative work.
I'm not a lawyer, but a straightforward reading of this contract
suggests that if Berkeley is convinced that NET2 no longer contains
any actual portion of 32/V, they are not only permitted, but required
by the provisions of their educational license to distribute it.
Newsgroups: alt.suit.att-bsdi
From: rob@violet.berkeley.edu (Rob Robertson)
Newsgroups: alt.suit.att-bsdi
Subject: Re: We could blow up USL.
Date: 26 Aug 92 11:49:48
Organization: /home/math_a/cc/rob/.organization
	<1992Aug17.222442.6705@leland.Stanford.EDU>
	<1992Aug20.235637.21040@njitgw.njit.edu>
	<KANDALL.92Aug21141122@globalize.nsg.sgi.com>
	<BZS.92Aug21192010@ussr.std.com>
	<KANDALL.92Aug24143319@globalize.nsg.sgi.com>
	<Aug.25.21.58.03.1992.1295@athos.rutgers.edu>
NNTP-Posting-Host: hanalei.berkeley.edu
In-reply-to: hedrick@athos.rutgers.edu's message of 26 Aug 92 01:58:04 GMT

In article <Aug.25.21.58.03.1992.1295@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:

   The problem with this argument is that one of the explicit goals of an
   educational license was to encourage the educational licensees to
   develop software, including modifications of the system itself, for
   public distribution.  Thus "educational purposes" was interpreted as
   including public software development.  What would definitely be
   inappropriate would be developing code limited to BSDI.  But the
   license provides a very clear test for whether efforts are for profit:
   is the code available to everyone without any restriction on
   redistribution.

from what i've heard, and this is a friend of a friend type of rumor,
is this isn't the first time AT&T has sued the university over what
they could do with software developed on AT&T educationally licensed 
unixs.  the case reportedly involved Ingres, the university was going
to take it (spin off a company probably) and market it directly.  then
AT&T sued, saying they were not allowed to do commercial development
on an educationally licensed machine.  AT&T won, and College Ingres
was released to the general public.

anyone who has more knowledge of this, please correct me.

rob
--
			  william robertson
		       rob@violet.berkeley.edu

     "when i was your age, i walked 10 miles to school, unarmed."
Newsgroups: alt.suit.att-bsdi
From: bzs@ussr.std.com (Barry Shein)
Subject: Re: We could blow up USL.
Organization: The World
	<92Aug25.190728edt.187@smoke.cs.toronto.edu>
	<KANDALL.92Aug26181242@globalize.nsg.sgi.com> <M9PI4CB@taronga.com>
	<KANDALL.92Aug31173719@globalize.nsg.sgi.com>
Date: Mon, 31 Aug 1992 23:49:10 GMT


>I see the main sales-point of BSD/386 as the
>provision of source code, which would appeal more to hobbyists and
>students.

(BSDI also provides source code of course)

It's a fallacy that source supplied OS's are only of interest to
"hobbyists and students". It's of interest to them also, but there are
other very important markets out there.

Larger corporations have centralized staff to deal with source on
behalf of their internal users. Some areas where source becomes
important and worth their having:

1. Fixing or working around security holes/bugs that the vendor will
not get to until the next release.

2. Installing security that is not anticipated by the standard version
(or any other version) of the OS. For example, callbacks, secondary
password or challenges in login, tracking or trailing of certain types
of system access (e.g. file opens on certain sensitive files.)

3. Device support, perhaps in cooperation with a vendor (where there
is no general market, consider the entire Military market and the
gazillion custom devices they need to support and do data gathering
with.)

4. Other network protocols or telecom needs, typically where there is
no vendor for the need (e.g. something old and in-house that you have
to support.) Many transaction systems use proprietary, in-house
protocols you wouldn't believe, and many of these are sunk into
silicon out there and can't be changed (e.g. consider swipe boxes for
credit cards and you need to replace your in-house data gathering
systems, I've written software for these systems, it's often custom
built.)

5. Implementation of turnkey systems of various flavors (typically
replacing the entire login/getty stuff, and other aspects of the OS so
it will run on the lightest weight possible hardware.) An example
might be those touch screen things you see at airports, restaraunt and
hotel cash register systems, etc. Many are done with Unix now, I know
of several problems with one vendor that would best be handled via
source code (for example, better detection of various paper out and
other offline conditions on robot printers and choosing alternate
printers to send to, often these things cannot stop, and the logic for
recovery is subtle, it would often be nice to be able to diddle with
the low-level drivers to provide better/more-detailed error reporting,
add new query ioctl()'s [*where* does it hurt?!] and so on, tie it
into other facilities to alert operators, etc.)

--
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: alt.suit.att-bsdi
Subject: Re: Monopolistic Practices
Date: 27 Aug 92 20:53:59 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

In article <1992Aug26.104810.13029@wimsey.bc.ca> jhenders@wimsey.bc.ca (John Henders) writes:
>How many CS students could go through their entire 
>time in school and never see U*ix source code? 

Almost all of them.  Only people who are supporting Unix system
software have access to the source code at Rutgers, and I doubt that
we're unique.  Even our faculty don't normally have access to Unix
source.  When they need source to something, we are generally able to
find a free equivalent that we can point them to.

Aside from license requirements (which I am pretty careful about
abiding by), in the long run I think we want to move to technology
that our students and researchers can get free access to.  Given the
widespread availability of free replacements for almost all Unix
software, we're planning to move to a policy of replacing utilities
that we don't like with free equivalents, rather than modifying vendor
source code.  This is probably not practical for the kernel and libc,
and maybe not for a few things like login.  But we're planning to
start moving to the Gnu utlities as our standard ones over time.  We
already use X11R5 rather than Openwindows.  This accomplishes a number
of things aside from allowing students access to source.  It also
reduces the problems in dealing with multiple dialects of Unix.

Once this move is finished, almost all of our development work will be
with public source.  We hope to reduce the number of changes we make
to vendor code to a very small number.