roger@nsc.nsc.com (Roger Thompson) (01/04/89)
I'm in the process of doing a market study on "Computer Security". Granted this is rather broad, but one has to start somewhere. My bottom line interest is to determine what if anything a semiconductor manufacturer such as National Semiconductor should do in the design of their various products which will make the systems designers job easier IF he has requirements in the the area of Computer Security. In short, if your system has security requirements what could we do to make your life vastly easier. I would like feed-back from those of you working on ACTUAL product development. My questions are 1.) Is security important --- if it isn't let me know 2.) If it is --- I have a few questions a.) is your product commercial or government driven. what is the consumer base? I don't need the actual customer name. b.) what type of product is it? Is it a workstation, a peripheral controller, a network server or a stand-alone controller. c.) Is security provided via software solutions, hardware only, or a mix of hardware and software. 3.) If you had your choice, what would you like to see in the way of enhancements to microprocessor, peripheral controllers and memory devices. I would like to see responses via email and I'll summarize the results. Thanx for your help in advance.
andy@Gang-of-Four.Stanford.EDU (Andy Freeman) (01/10/89)
In article <8846@nsc.nsc.com> roger@nsc.nsc.com (Roger Thompson) writes: >In short, if your system has security requirements what could >we do to make your life vastly easier. The world does change. Some time before the IBM-PC was introduced, "someone" suggested anti- software piracy features to Intel. The basic idea was to have dealers trap-door encrypt code, using a processor-specific number, before delivering it to their customers. The cpu chip would then decrypt the code in real-time and execute it, but only if the dealer had encrypted it for that particular chip. Intel's response was that they sold chips and that software piracy helped them sell more. -andy UUCP: {arpa gateways, decwrl, uunet, rutgers}!polya.stanford.edu!andy ARPA: andy@polya.stanford.edu (415) 329-1718/723-3088 home/cubicle
nusip@maccs.McMaster.CA (Mike Borza) (01/17/89)
In article <5995@polya.Stanford.EDU> andy@Gang-of-Four.Stanford.EDU (Andy Freeman) writes: >In article <8846@nsc.nsc.com> roger@nsc.nsc.com (Roger Thompson) writes: > >The world does change. Some time before the IBM-PC was introduced, >"someone" suggested anti- software piracy features to Intel. The >basic idea was to have dealers trap-door encrypt code, using a While the details are somewhat hazy now, I believe that HP did sell some systems with a similar scheme, whereby a system call or dedicated read-only memory location was available to software to verify that the software was running on a CPU for which it was licensed. As I recall, the scheme was quickly abandoned for a variety of reasons, not least of which was the potential liability if a legally-licensed user had to replace the CPU. I think the scheme was described in an HP Journal article (c. 1982) describing the design of the system software and hardware (series 200?). mike borza <nusip@maccs.uucp> ....it's all so hazy now....
rpw3@amdcad.AMD.COM (Rob Warnock) (01/18/89)
+--------------- | >The world does change. Some time before the IBM-PC was introduced, | >"someone" suggested anti- software piracy features to Intel. The | >basic idea was to have dealers trap-door encrypt code, using a | While the details are somewhat hazy now, I believe that HP did sell | some systems with a similar scheme... +--------------- Fortune Systems (yes, they still exist, as part of SCI) had a protection scheme on their Unix systems which allowed user backups. Uninstalled software was encrypted with a "global" key known only to Fortune. The act of installing it -- using a protected (gencrypted) "install" program -- caused it to be decrypted and re-encrypted with a key based on the CPU serial number (the key was stored in a PAL on the motherboard). Thus once the software had been "installed" on a given CPU, you could make as many copies as you like (back it up, put it on a net server, etc.), but it would only run on the specific CPU it had been "installed" on. And the "install" procedure was about as user-friendly as one might want. You stuck a shrink-wrapped disk in (unwrapping it first ;-} ) and selected "Install New Product" on the "System Management" menu. Each product disk had a product-specific install script that could ask questions for local configuration, if needed. Motherboard changes required moving the (socketed) security PAL. And a damaged security PAL could be replaced [with a *lot* of questions asked, as the PALs never broke!] from the factory, based on the serial number of the CPU. (Oh, and the PAL stored not the actual serial number, but some encrypted/checksummed function of the serial number.) Actually, it worked pretty well. There was a way for a large site to buy CPUs in a "group", and then buy "group-coded" versions of software that would run on any machine in the group (but priced so high nobody used it). More importantly, there was a program for 3rd-party software vendors so they could have their disks "branded" by Fortune to make them one-time installable. (You didn't *have* to use copy-protection, by the way. Things compiled on a Fortune would run on any CPU unless specifically "branded".) Physical security of uninstalled disks was an issue, as clearly any uninstalled program disk was a single-use "blank check". (There were some tricks played to prevent copying of uninstalled disks.) Many people in this group (and others) have expressed disgust with the whole notion of copy-protection, but Fortune's original business plan was based (rightly or wrongly) on having a number of proprietary applications run on their system, and at the time (1980) "software piracy" was estimated in the trade press to account for as much as 80% of the software actually being run. So they wanted to protect their development investment. Of course, they went a bit far, for my taste. They were so scared of somebody copying their programs that they encrypted/decrypted a protected program if it ever had to swap out/in. This seriously affected multi-user performance, to say the least! They forgot that "security" is always a balancing act, between what it costs the perpetrator to penetrate and what it costs you (in lost function/convenience) to protect. (*Sheesh!* Look, anybody capable of picking bits off swap space is capable of using a logic analyzer and cracking the scheme more straightforwardly!) Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
shane@chablis.cc.umich.edu (Shane Looker) (01/19/89)
In article <1804@maccs.McMaster.CA> nusip@maccs.UUCP (Mike Borza) writes: :In article <5995@polya.Stanford.EDU> andy@Gang-of-Four.Stanford.EDU (Andy Freeman) writes: :>In article <8846@nsc.nsc.com> roger@nsc.nsc.com (Roger Thompson) writes: :> :>The world does change. Some time before the IBM-PC was introduced, :>"someone" suggested anti- software piracy features to Intel. The :>basic idea was to have dealers trap-door encrypt code, using a : :While the details are somewhat hazy now, I believe that HP did sell :some systems with a similar scheme, whereby a system call or dedicated :read-only memory location was available to software to verify that the :software was running on a CPU for which it was licensed. As I recall, :the scheme was quickly abandoned for a variety of reasons, not least :of which was the potential liability if a legally-licensed user had to :replace the CPU. : :mike borza <nusip@maccs.uucp> If I remember correctly, the Apple Lisa used a scheme where, when software was originally run on a machine, it registered the CPU number. You then could not use the software on any other Lisa. Needless to say, software was forever getting corrupted or breaking in some way, and a new version couldn't be installed for a while. (This was in a semi-public lab.) No wonder those machines never flew... Shane Looker | Looker@um.cc.umich.edu America works less, when you say "Union Yes!"
pag@tcsc3b2.UUCP (Philip A. Gross) (01/20/89)
In article <24102@amdcad.AMD.COM>, rpw3@amdcad.AMD.COM (Rob Warnock) writes: [...stuff deleted...] > Fortune Systems (yes, they still exist, as part of SCI) had a protection > scheme on their Unix systems which allowed user backups. Uninstalled software > was encrypted with a "global" key known only to Fortune. The act of installing > it -- using a protected (gencrypted) "install" program -- caused it to be > decrypted and re-encrypted with a key based on the CPU serial number (the > key was stored in a PAL on the motherboard). Thus once the software had been > "installed" on a given CPU, you could make as many copies as you like (back > it up, put it on a net server, etc.), but it would only run on the specific > CPU it had been "installed" on. > [...stuff deleted...] > Motherboard changes required moving the (socketed) security PAL. And a > damaged security PAL could be replaced [with a *lot* of questions asked, > as the PALs never broke!] from the factory, based on the serial number of > the CPU. (Oh, and the PAL stored not the actual serial number, but some > encrypted/checksummed function of the serial number.) > [...even more stuff deleted...] > More importantly, there was a program for 3rd-party software vendors so > they could have their disks "branded" by Fortune to make them one-time > installable. (You didn't *have* to use copy-protection, by the way. Things > compiled on a Fortune would run on any CPU unless specifically "branded".) > Physical security of uninstalled disks was an issue, as clearly any > uninstalled program disk was a single-use "blank check". (There were some > tricks played to prevent copying of uninstalled disks.) [...yet more stuff deleted...] The AT&T 3B2 line of computers as well as the NCR Towers make use of a what is generally called a firmware serial number that is kept on the motherboard. On the AT&T box, the serial number is recorded in one of four EPROMS on the motherboard. On the NCR box, it is recorded perhaps in some other manner. NCR makes use of it during the installation of the UNIX operating system, effectively locking the OS to the particular Tower it was installed on. While AT&T (from what I understand) doesn't make use of the firmware serial number in the installation of the UNIX operating system, they do provide a function call in 'C' which can be used to get, among other things, the firmware serial number. This can then be used during the installation of software to lock the software onto that particular box. In fact, the accounting software and 4GL database that we resale does this. ========================================+====================================== Philip A. Gross | The Computer Solution Co., Inc. | I haven't heard what I have 1009 Sycamore Square, P.O. Box 716 | to say about that yet. Midlothian, VA 23113-0716 | Voice: (804)794-3491 | ----------------------------------------+-------------------------------------- INTERNET: pag%tcsc3b2@wb3ffv.ampr.org USENET: ...!ames!haven!aplcen!wb3ffv!tcsc3b2!pag UUCP: tcsc3b2!pag (804)794-1514 ATTMAIL: attmail!tcsc3b2!pag ******************************************************************************* The opinions expressed here are strictly mine and nobody elses. ===============================================================================
kean@tank.uchicago.edu (Keane Arase) (01/24/89)
In article <356@tcsc3b2.UUCP> pag@tcsc3b2.UUCP (Philip A. Gross) writes: >The AT&T 3B2 line of computers as well as the NCR Towers make use of a >what is generally called a firmware serial number that is kept on the >motherboard. On the AT&T box, the serial number is recorded in one of >four EPROMS on the motherboard. On the NCR box, it is recorded perhaps >in some other manner. NCR makes use of it during the installation of the >UNIX operating system, effectively locking the OS to the particular Tower >it was installed on. While it is true NCR looks at the serial number on it's Towers when installing unix, it is extremely simple to bypass this check when installing unix. (A couple of comments in one of the shell scripts and unix can be installed on *any* Tower.) No I never did this, nor do I condone such actions. I merely wish to point out that this type of protection can be bypassed. (As a disclaimer, I used to work *extensively* with NCR Towers. Please don't ask my opinion on NCR equipment, as I have a bias against them.) > >========================================+====================================== >Philip A. Gross | >The Computer Solution Co., Inc. | I haven't heard what I have >1009 Sycamore Square, P.O. Box 716 | to say about that yet. >Midlothian, VA 23113-0716 | >Voice: (804)794-3491 | >----------------------------------------+-------------------------------------- >INTERNET: pag%tcsc3b2@wb3ffv.ampr.org >USENET: ...!ames!haven!aplcen!wb3ffv!tcsc3b2!pag >UUCP: tcsc3b2!pag (804)794-1514 >ATTMAIL: attmail!tcsc3b2!pag >******************************************************************************* > The opinions expressed here are strictly mine and nobody elses. >=============================================================================== --- Keane Arase, Systems Programmer University of Chicago Computing Organizations Acedemic and Public Computing, Technical Project Support kean@tank.uchicago.edu syskean@uchimvs1.uchicago.edu ** Please file the standard disclaimers here **
peter@stca77.stc.oz (Peter Jeremy) (01/24/89)
In article <5995@polya.Stanford.EDU> andy@Gang-of-Four.Stanford.EDU (Andy Freeman) writes: >The world does change. Some time before the IBM-PC was introduced, >"someone" suggested anti- software piracy features to Intel. The >basic idea was to have dealers trap-door encrypt code, using a >processor-specific number, before delivering it to their customers. >The cpu chip would then decrypt the code in real-time and execute it, >but only if the dealer had encrypted it for that particular chip. The IBM/370 has a unique CPU ID available via a supervisor instruction. If the OS made it available, this could presumably be used by a software package to verify that it was running on the licensed hardware. (Although I seem to recall the this instruction was one that did something slightly different under VM). Probably most other mainframes (and early mini's) have something similar. This is not as secure as encrypting the code, but I don't think mainframe software piracy is as big as problem as PC stuff. >Intel's response was that they sold chips and that software piracy >helped them sell more. Also, building unique ID's into chips adds extra complexity into the manufacturing process. And what happens when the CPU fails? This would not be a big a problem for mainframes, since the ID could be a bunch of straps (or a ROM) which can be changed by the field engineer. -- Peter Jeremy (VK2PJ) peter@stca77.stc.oz Alcatel-STC Australia ...!uunet!stca77.stc.oz!peter 41 Mandible St peter%stca77.stc.oz@uunet.UU.NET ALEXANDRIA NSW 2015
gillies@m.cs.uiuc.edu (01/24/89)
Xerox Information Systems Division sells a lot to the government, and
sells to some fortune-500 companies (Boeing, etc). Here is how they
protect their system software from copying:
Each Daybreak=6085/Star=8010 workstation has a unique identifier.
This identifier is the 6-byte absoluately unique ID used for a 48-bit
ethernet host ID. I'll call this the "UID". The ethernet cards are
made & sold only by Xerox, and I believe the UID is in an EPROM chip
which (probably) also contains startup microcode.
This is very-much a closed-architecture / proprietary product (source
code is never distributed, & the assembly language is proprietary like
on the old Pyramid computers), so the following scheme works fairly
well:
Each sites gets a full set of floppies with every piece of software
Xerox makes.
Each major software package has an "product number" K. Xerox has a
(perhaps public-key?) private encryption function F(K, UID). The O/S
is programmed with the (public) decryption function Finverse().
During initialization, each package reads a "product factoring file"
looking for its number F(K, UID). It then applies Finverse and checks
to see if Finverse(F(K, UID)) = K,UID. If so, then the program will
run. If not, then it says "call technical support to get
authorization to run this package"
You install all the software you want, then run the "factoring"
program, and call Xerox, giving them your UID. Xerox checks to make
sure you paid for certain packages, then gives you the numbers
F(K2,UID), F(K2,UID), ..., computed from your UID & the package
numbers K1, K2, ....
There may be some added subtlety, but this is the main idea.
Anyway, this scheme provides enough protection for their needs. Of
course, there are obvious attacks, but you asked for a REAL-WORLD
system. Some obvious flaws are:
1. Reprogram the ROM chip to be the same as a competitor, who
has paid for all the software. But you better not *EVER* connect to his
network!
2. Dissect each software package and remove the checks
(nearly impossible without any development tools or debuggers)
3. Spoof Xerox into giving you the numbers by saying you're
from another company (with the software), then giving out your machine
number & package numbers (Xerox can check machine ownership).
Also, after every release the encryption/decryption functions change,
so they can charge for new software versions.
Nobody says you must solve this problem totally, in order to make a
healthy profit on your product. I doubt if *ANYONE* outside Xerox has
ever broken the product factoring system. If anyone ever did, then
you could just revise the hardware/software to thwart the attack their
attack.
I think this system serves the needs of Xerox adequately.
Don Gillies {uiucdcs!gillies} U of Illinoisrogerson@PEDEV.Columbia.NCR.COM (rogerson) (01/24/89)
In article <1546@tank.uchicago.edu> kean@tank.uchicago.edu (Keane Arase) writes: >In article <356@tcsc3b2.UUCP> pag@tcsc3b2.UUCP (Philip A. Gross) writes: > >>The AT&T 3B2 line of computers as well as the NCR Towers make use of a >>what is generally called a firmware serial number that is kept on the This is no longer true. The current NCR Tower series have no such protection scheme. I can't even find one of the old Towers around here which did use this protection scheme. According to one of my co-workers it is extremely easy to defeat. Still, such protection schemes are stupid and do not help sales of your computers any. -----Dale Rogerson-----
scc@cl.cam.ac.uk (Stephen Crawley) (01/27/89)
Don Gillies (gillies@m.cs.uiuc.edu) message about Xerox workstations contains some factual errors. The working microcode for a Xerox D machine (Dandelion, DandyTiger, Dolphin, Dove = Daybreak, etc) is loaded from Hard disc, Floppy disc or from the Ethernet when the machine is booted. Different microcode is used for Mesa, InterLISP, Smalltalk and (I think) for standalone diagnostics. When a new release of a product comes out, you often get a new microcode image. Eg the XDE 5.0 release had microcode with extra instructions to implement C character pointer operations. The source code of many products IS available. In the Mesa world, the source code for the base operating system (Pilot), for XDE and for all of the XDE tools are available. True, Xerox won't release the source code for their network servers or for Viewpoint. The assembly languages are no longer proprietry. I don't think that the InterLISP and Smalltalk instruction sets ever were. > I doubt if *ANYONE* outside Xerox has ever broken the product > factoring system. I think you'd be surprised how easy it is :-) -- Steve
pag@tcsc3b2.UUCP (Philip A. Gross) (01/28/89)
In article <3377@cbnews.ATT.COM>, djz@cbnews.ATT.COM (Danny Zerkel) writes: > >The AT&T 3B2 line of computers as well as the NCR Towers make use of a > >what is generally called a firmware serial number that is kept on the > >motherboard. On the AT&T box, the serial number is recorded in one of > >four EPROMS on the motherboard. ... > Which works until the system board dies and is replaced by maintanence, > rendering all your expensive copy protected software useless... :-( Generally, we insist that the AT&T service tech migrate the EPROMS from the original system board to the new one, if at all possible. Otherwise, the customer merely needs to obtain a new INSTALL diskette to update his software to the serial number contained in the new set of EPROMS, otherwise his software don't work. ===================================+=========================================== Philip A. Gross |INTERNET: pag%tcsc3b2@wb3ffv.ampr.org The Computer Solution Co., Inc. |USENET: ...!wb3ffv!tcsc3b2!pag 1009 Sycamore Square, P.O. Box 716 |UUCP: tcsc3b2!pag (804)794-1514 Midlothian, VA 23113-0716 |ATTMAIL: attmail!tcsc3b2!pag Voice: (804)794-3491 | The opinions expressed here are strictly mine and nobody elses. << I haven't heard what I have to say about that yet. >> :-)
pag@tcsc3b2.UUCP (Philip A. Gross) (01/28/89)
In article <2373@PEDEV.Columbia.NCR.COM>, rogerson@PEDEV.Columbia.NCR.COM (rogerson) writes: > In article <1546@tank.uchicago.edu> kean@tank.uchicago.edu (Keane Arase) writes: > >In article <356@tcsc3b2.UUCP> pag@tcsc3b2.UUCP (Philip A. Gross) writes: > > > >>The AT&T 3B2 line of computers as well as the NCR Towers make use of a > >>what is generally called a firmware serial number that is kept on the > > Still, such protection schemes are stupid and do not help sales > of your computers any. > The big issue is, does it really matter if the software makes use of a hardware imbedded serial number. The software will operate smoothly and consistently so long as it is retained on the CPU it was installed on. The customer generally does not even need to know that their is any copy protection mechanisms in force. The customer can make all the backups of the software they need to, all without violation of the copyright protection because the software will not operate on any _other_ CPU once it has been installed. We generally do not inform the customer that there is any copy protection being used. However, we do STRONGLY advise them that they should contact us, along with their AT&T service personnel whenever they experience a hardware problem which may involve the exchange of the motherboard. Under such circumstances, their are simple procedures in place which will allow the software to be 're-installed' on a machine which has had the motherboard replaced. Generally if the customer has had to have the motherboard replaced in the computer, re-installation of licensed software is not a major concern. ===================================+=========================================== Philip A. Gross |INTERNET: pag%tcsc3b2@wb3ffv.ampr.org The Computer Solution Co., Inc. |USENET: ...!wb3ffv!tcsc3b2!pag 1009 Sycamore Square, P.O. Box 716 |UUCP: tcsc3b2!pag (804)794-1514 Midlothian, VA 23113-0716 |ATTMAIL: attmail!tcsc3b2!pag Voice: (804)794-3491 | The opinions expressed here are strictly mine and nobody elses. << I haven't heard what I have to say about that yet. >> :-)
les@chinet.chi.il.us (Leslie Mikesell) (02/02/89)
In article <424@tcsc3b2.UUCP> pag@tcsc3b2.UUCP (Philip A. Gross) writes: >The big issue is, does it really matter if the software makes use of >a hardware imbedded serial number. The software will operate smoothly >and consistently so long as it is retained on the CPU it was installed >on. The customer generally does not even need to know that their is >any copy protection mechanisms in force. The customer can make all the >backups of the software they need to, all without violation of the >copyright protection because the software will not operate on any _other_ >CPU once it has been installed. >We generally do not inform the customer that there is any copy protection >being used. However, we do STRONGLY advise them that they should contact >us, along with their AT&T service personnel whenever they experience a >hardware problem which may involve the exchange of the motherboard. >Under such circumstances, their are simple procedures in place which will >allow the software to be 're-installed' on a machine which has had the >motherboard replaced. >Generally if the customer has had to have the motherboard replaced in the >computer, re-installation of licensed software is not a major concern. We keep spare machines and can swap one into operation in an hour or two (about the amount of time you spend on hold when you call service..). I suspect that other sites that consider their computer operations important do likewise. I would be *real* unhappy to find out after a swap that some piece of software didn't work *on purpose*, especially if I hadn't been told to expect it. Les Mikesell
mcdonald@uxe.cso.uiuc.edu (02/03/89)
>We generally do not inform the customer that there is any copy protection >being used. However, we do STRONGLY advise them that they should contact >us, along with their AT&T service personnel whenever they experience a >hardware problem which may involve the exchange of the motherboard. >Under such circumstances, their are simple procedures in place which will >allow the software to be 're-installed' on a machine which has had the >motherboard replaced. >Philip A. Gross |INTERNET: pag%tcsc3b2@wb3ffv.ampr.org >The Computer Solution Co., Inc. |USENET: ...!wb3ffv!tcsc3b2!pag >1009 Sycamore Square, P.O. Box 716 |UUCP: tcsc3b2!pag (804)794-1514 >Midlothian, VA 23113-0716 |ATTMAIL: attmail!tcsc3b2!pag Not informing potential buyers that your program is copy protected is a VERY nasty thing. Nasty to the users, nasty to potential users nasty to your company's reputation, and potentially bad for your bottom line. When we have bought software that wasn't a "known quantity", we always insert clauses in our purchase order that specifies that the software is 1: Not copy protected in any way. That is, it will run on a simple, straightforward copy of the distribution media, can be installed from that copy any number of times, does not depend on any specific hardware device (i.e. we can install it on two machines, only one of which can possible be in service at the same time, and have it run on either without changing any hardware between computers), and will contine to run on the computer it is installed on even if any unit specific hardware is changed (i.e. serial number roms changed to a new serial number.) 2: If the vendor wants to try to sell us software that violates article 1, that vendor must have an officer of the company discuss this with us in great detail, and must individually negotiate a contract. 3: If software that is copy protected is indeed delivered without a contract specifically negotiated as under #2, and it causes us problems, the selling company will pay for the cost of any problems, plus 10 time the cost of the problems, plus 10 times the price of the software. To date, no company has had any problems with this - either they have said truthfully "we're not copy protected" or they have said "uh - well - maybe we don't want to do business with you - we care more about copy protection than a sale" - and that was the end of that. (By "we" I mean my group and most of our department- the larger entity we are in has perhaps negotiated as in number 2; I'm not sure about this, though.) What would your company do if a purchase order had such a clause? Doug McDonald
aglew@mcdurb.Urbana.Gould.COM (02/03/89)
>We generally do not inform the customer that there is any copy protection >being used. However, we do STRONGLY advise them that they should contact >us, along with their AT&T service personnel whenever they experience a >hardware problem which may involve the exchange of the motherboard. >Under such circumstances, their are simple procedures in place which will >allow the software to be 're-installed' on a machine which has had the >motherboard replaced. > >Philip A. Gross |INTERNET: pag%tcsc3b2@wb3ffv.ampr.org >The Computer Solution Co., Inc. |USENET: ...!wb3ffv!tcsc3b2!pag Well, let's see... back when I was an undergrad I worked on IBM PCs that had more than a dozen purchased software packages installed - starting off with DOS, going through FORTRAN, LATTICE C, various mathematical subroutine libraries, HALO graph, and ending up with the little things like Sidekick. These were *not* all purchased at the same store. No store in town sold all of these - mant *had* to be purchased separately. Now, then, if, every time one of the lab PCs died, I had had to call each of these vendors separately - conservatively estimating 2 hours on the phone to each vendors customer service, plus maybe an hour of reinstallation - gee, that's 36 hours, almost a full week, just reinstalling software after a board swap. That's almost as long as the mean time to failure of one of the lab systems (not a single system, mind you, just time to failure of any one of multiple systems). Well, I guess that gives you an argument for buying all of your software at one place (preferably *your* place). But that's not always possible.
kenny@m.cs.uiuc.edu (02/07/89)
/* Written 10:44 am Feb 2, 1989 by mcdonald@uxe.cso.uiuc.edu in m.cs.uiuc.edu:comp.arch */ What would your company do if a purchase order had such a clause? /* End of text from m.cs.uiuc.edu:comp.arch */ At least one company that I worked for would run screaming and never speak to you as a customer again -- and they didn't use nor believe in copy protection. But consider -- you get a new model disc or something -- something that maybe wasn't even invented at the time the software was released -- and suddenly the program no longer works (Maybe it's got timing dependencies, or something). Now you whine, `But this violates the clause that says the software has to continue to run when the hardware platform is changed!' and sue the pants off the vendor for ten times the loss of your business during the time the machine was down. You can even go as far as to claim that the failure made you go bankrupt, and sue for ten times the value of your business. Such is the stuff of which hundred-million-dollar lawsuits are made. Rephrasing the contract to exclude bugs and include only intentional copy protection won't help, either, as it's anyone's guess what a jury will decide is `intentional,' and what to me is a `bug' may be `intentional restriction on operation' to a jury.