Return to Bad Software: What To Do When Software Fails.


Liability for Bad Software and Support

A paper presented to the Software Support Professionals Association
Executive Briefing, San Diego, October 3, 1996 and to the Software Support Conference East, March 12, 1997.

Concerned about the risk of lawsuits over their software, many executives have developed a perception of a litigation explosion. Actually, it hasn't been a very big bang. Here's an illustration of my point, from the 1994 Annual Report of the Judicial Council of California.1 1983-84 is the first of the 10 years in this study. 1992-93 is the last of the 10 years. Superior Court filings usually involve cases of $25,000 or greater.

Exhibit 1-Superior Court Civil Filings, 1983-1993
1983-84 1992-93 increase
561,916 684,070 122,154 cases (22%)

At first glance, this looks like a litigation explosion. But look again.

Exhibit 2-A Closer Look at the Filing Statistics
1983-84 1992-93 increase
561,916 684,070 122,154 (22%)
Other civil petitions (Child Support):
1983-84 1992-93 increase
121,968 267,980 146,012 (120%)
Personal injury, death, property damage:
1983-84 1992-93 decrease
96,731 88,346 -8,385 (-9%)
Other civil complaints (includes business litigation):
1983-84 1992-93 decrease
111,802 107,377 -4,425 (-4%)

The increase in filings comes from "Other Civil Petitions" in which the Judicial Council includes "petitions filed under the Reciprocal Enforcement of Support Act" and various other family-law related petitions. The statistics do reflect an explosion of actions, but it's an explosion of actions (often filed by the District Attorney's Office) to enforce child support orders. This is not a business problem.

On the other hand, I think that there are more cases involving bad software. Not long ago, I received an e-mail from Jim Cox of the SSPA that reported that customer service satisfaction is at a ten-year low. There are some cranky customers out there, and more of them are asserting the rights that they would have and would expect if they were dealing with any type of product besides software.

This paper will look at a few of these cases and try to draw some lessons from them. Here's where we're going:

Lessons from some software / support related lawsuits

  1. The Intel Pentium lawsuits

    Don't leave a product on the market after you learn that it has a serious bug.
    Handle your defects gracefully and responsibly.

  2. Brummel v. Leading Edge Products and G.E. Computer Service

    Answer the phone.

  3. Step-Saver Data Systems, Inc. v. Wyse Technology and The Software Link, Inc.

    Rather than relying on ineffective shrink-wrapped warranty disclaimers, make the software reasonably fit for its ordinary purposes.

  4. Daughtrey v. Ashe

    Test your documentation (and marketing and sales materials).

  5. Baldwin v. Alabama Insurance Brokers

    Sometimes, it's not wise to say RTFM.

  6. Family Drug Store v. Gulf States Computer

    The law doesn't guarantee customer satisfaction.

  7. Ritchie Enterprises v. Honeywell Bull

    Never mislead customers in post-sale transactions.

  8. Clayton X-Ray Company v. Professional Systems Corp.

    Don't settle disputes with customers by blocking their access to their own systems and data.

Lessons from some software / support related lawsuits

Customers rarely (if ever) sue when they first encounter a problem. They try to get help, such as a workaround, a refund, technical or financial assistance for recovering data that the program lost or corrupted, or reimbursement for other losses caused by the program. Some customer requests are reasonable, others aren't.

A lawsuit typically reflects the customer's (correct or incorrect) conclusion that the software publisher or seller is so outrageously unreasonable that it is appropriate to invest a substantial amount of time, money, and aggravation in the litigation process. The publisher's customer support organization probably played a role in shaping that customer's attitude.

The cases that I've picked for this paper illustrate some of the legally-relevant difficulties that customers and support groups have with each other.

The Intel Pentium lawsuits

In the summer of 1994, Intel discovered a bug in its Pentium chip.2 For several months, Intel continued to ship the chip, without notifying customers. Then, in late 1994, a professor published a report on the bug, Intel responded, and all hell broke loose on the Net.

From a technical viewpoint, I don't know how severe the underlying bug was. Intel estimated that a customer would encounter the bug once every 27,000 years. Others estimated that customers would encounter the bug within days, weeks, months, or years.3

In practice, this was a serious bug. On the basis of the failure, the Food and Drug Administration replaced its own chips and suggested that companies submitting data to the FDA should conduct their analyses on computers that didn't have the Pentium bug.4 A major stock broker swapped out all of its chips, fearing miscalculation-related liability. Scientific researchers and their graduate students had to redo work, losing months of research.

Initially, Intel refused to swap out defective chips unless the customer could prove, to Intel's satisfaction, that she was likely to be a victim of the bug. The response on the Net and in the press was a public relations nightmare. For example, an article in the Wall Street Journal, 12/15/94 was titled "Intel isn't serving millions who bought its Pentium campaign."5

On December 20, 1994, Intel announced a "no questions asked" returns policy.6

This took care of much of the criticism in the press, but it didn't solve Intel's problems with its customers. There was a wave of class action suits against Intel, and part of the reason that these suits wouldn't go away was that customers who called for replacement chips still ran into significant obstacles:

Taken together, despite Intel's public statements that it was taking care of its customers, these obstacles made it difficult to obtain even a simple replacement for the chip, let alone repayment of money lost because of the chip's bugs. The lawsuits continued.

Eventually, Intel settled the lawsuits, paid millions in attorneys' fees, and established a true no-questions-asked return policy for the chips. It paid for shipping and other incidental expenses associated with replacing the defective chips, and it repaid individual plaintiffs for consequential losses that they could satisfactorily prove.

To the degree that these obstacles reflected service implementation problems, rather than tactical decisions on Intel's part, they were expensive problems.

Lessons:

Brummel v. Leading Edge Products and G.E. Computer Service7

This is a class action suit, filed in New York. I'm still attempting to obtain the defendants' response to the suit, and any court rulings, but so far I haven't seen them. The initial version of a lawsuit complaint sometimes contains factual errors, so read this with some caution.

The plaintiffs claim that they purchased Leading Edge computers, which came with warranties, including warranty telephone support, and that the Leading Edge literature named General Electric as a partner in providing the support. The complaint continues:

  • 21. Notwithstanding defendants' representations, customers in need of warranty service and other technical support often cannot obtain service at all. Many times customers only get busy signals when calling the numbers provided by defendants. In many instances, it takes hours of persistent calling to get connected. Once connected, customers are placed on hold for inordinate and intolerable amounts of time. Those few customers who are persistent enough to remain on line until defendants' agent answers often find that the agent cannot address the problem or gives misinformation. Furthermore, on occasion when service has been offered, the offer of service was not fulfilled.

    22. Customers who leave messages on defendants' bulletin board on America Online fare no better. Messages are rarely answered by defendants. Those customers who do receive responses find they are often incomplete, with defendants promising, but never fulfilling that promise, to get back to the customer with more information.

  • The defendants in this case will spend thousands and ultimately, perhaps millions, in legal fees and expenses. They might have gotten better value for the money by spending it on answering the phone.

    Lesson:

    Step-Saver Data Systems v. Wyse Technology and The Software Link8

    In this case, the United States Court of Appeals for the Third Circuit held that a disclaimer of all express and implied warranties, printed on the outside of the box, was not binding on a mail order customer.

    Step-Saver repeatedly bought Multilink Advanced, an allegedly MS-DOS compatible operating system, from The Software Link (TSL). On each box was a disclaimer: the software was sold AS IS, without warranty; TSL disclaimed all express and implied warranties; and a purchaser who didn't agree to this disclaimer should return the product, unopened, to TSL for a refund.

    Step-Saver sued TSL, claiming that Multilink Advanced was not MS-DOS compatible. TSL argued that Step-Saver had accepted the terms of the warranty disclaimer when it opened each package, and therefore Step-Saver could not sue.

    Step-Saver made each purchase by telephone. The Court ruled that the essential terms of the sale (such as price and quantity) were set out during the calls. The warranty disclaimer on the box arrived later. Under Section 2-207 of the Uniform Commercial Code, the disclaimer was merely a proposal by TSL to add a term to the contract. Step-Saver was not required to accept this proposal. Having already bought the product, Step-Saver could open it and use it without agreeing to this new warranty disclaimer. Nor did it matter that Step-Saver placed additional orders after seeing the disclaimer. TSL never insisted that Step-Saver agree to the disclaimer during purchase negotiations (the telephone calls), therefore the disclaimer was not part of any contract.

    The Court said:

  • TSL has raised a number of public policy arguments focusing on the effect on the software industry of an adverse holding concerning the enforceability of the box-top license. We are not persuaded that requiring software companies to stand behind representations concerning their products will inevitably destroy the software industry.
  • As a matter of public policy, the Uniform Commercial Code (UCC) says that any product comes with a warranty of merchantability unless the seller specifically excludes it.9 This is a modest warranty. It doesn't require that a product be bug free or that customers like the product. It only says that the seller promises that the product is "fit for the ordinary purposes for which such goods are used"10 and that it conforms "to the promise or affirmations of fact made on the container or label."11 If you sell a word processor, it has to write memos, it shouldn't erase the customer's hard disk, and you shouldn't say on the box that it's compatible with the LaserJet IV if you don't mean it. Big deal.

    A seller can exclude an implied warranty by including a conspicuous12 notice of the exclusion in the sales agreement. However, the shrink-wrapped warranty disclaimer can't be conspicuous in the mail order case because the customer doesn't see it before paying for the product. And the disclaimer can't be conspicuous at retail either (unless you have X-ray eyes) because it's hidden inside the box when you buy the program. Therefore the purchase agreement does not include the warranty disclaimer and therefore it does not exclude the warranty of merchantability.

    This is not an isolated decision. It is standard Uniform Commercial Code analysis and has been applied in many non-software cases. Here's the policy restated in statutory form:

  • California Civil Code § 1790.1 "Any waiver by the buyer of consumer goods of the provisions of this chapter, except as expressly provided in this chapter, shall be deemed contrary to public policy and shall be unenforceable and void."

    California Civil Code § 1792.4(a) "No sale of goods . . . on an 'as is' basis, shall be effective to disclaim the implied warranty of merchantability . . . unless a conspicuous writing is attached to the goods which clearly informs the buyer, PRIOR TO THE SALE . . ." of the meaning and consequences of the disclaimer. (my capitalization)

  • Lesson:

    Daughtrey v. Ashe.13

    In 1985, W.H. Daughtrey bought a diamond bracelet as a Christmas gift for his wife from Sidney Ashe, a jeweler. He paid $15,000. After Daughtrey agreed to buy the bracelet, Ashe filled out an appraisal form and put it in the box with the bracelet. The appraisal said that the diamonds were of v.v.s. quality (a high grade). Daughtrey didn't see the appraisal until later, probably not until the box was opened at Christmas.

    In 1989, Daughtrey discovered that the diamonds were not of v.v.s. quality. Ashe offered a refund. Daughtrey refused, and demanded that the diamonds in the bracelet be replaced with diamonds that were of v.v.s. quality. Ashe refused. Daughtrey sued. He said that the statement that the diamonds were of v.v.s. quality was a description of the goods by the seller. According to the Uniform Commercial Code,

  • 2-313(b) any description of the goods which is made part of the basis of the bargain creates an express warranty that the goods shall conform to the description.
  • Therefore, Daughtrey said, Ashe created a warranty that the diamonds were of v.v.s. quality, and breached it by selling a bracelet whose diamonds were of a lower grade. Ashe argued that this claim couldn't have been a warranty because he never called it a warranty and Daughtrey didn't read the claim until long after the sale. How could this description be part of the "basis of the bargain"?

    Ashe won -- in the trial court. But the Supreme Court of Virginia overruled the trial court. Quoting the Official Comments to the Uniform Commercial Code, the Court said:

  • The whole purpose of the law of warranty is to determine what it is that the seller has in essence agreed to sell.14
  • and

  • The precise time when words of description or affirmation are made . . . is not material. The sole question is whether the language is fairly to be regarded as part of the contract.15
  • The Court concluded that Ashe had agreed to sell v.v.s. quality diamonds, and therefore that he had breached the sales contract by selling inferior diamonds.

    When a customer buys a computer program at a store, the box probably contains documentation-a manual and/or online help. Just as there was an appraisal in the bracelet box. And the documentation makes specific descriptive statements about the program. Just as the appraisal made a specific descriptive statement about the bracelet. The customer might not read the documentation until long after buying the program. Just as Daughtrey didn't know anything about the appraisal until after the purchase. A judge in Virginia would probably treat statements in the manual as warranties.16 The seller of the program would be liable for breach of warranty if the software didn't do what the documentation stated.

    If your manual or your help or your packaging say false things about the program, your company is risking lawsuits for breach of warranty, for deceptive trade practices, and for misrepresentation.17

    It takes about 15 minutes per page to thoroughly test a user manual against a typical mass-market program (word processors, spreadsheets, etc.). Getting the documentation right helps from a legal perspective. It also helps your company find bugs and it makes the product more supportable. For more discussion of this, see my paper, Liability for Defective Documentation.18

    Lesson:

    Baldwin v. Alabama Insurance Brokers19

    Baldwin sold a computer and software to Alabama Insurance Brokers (AIB). AIB sued, the jury verdict was in AIB's favor. Baldwin appealed and lost the appeal. From a customer support point of view, here is the most interesting quote in the case:

  • The evidence further discloses there were approximately 28 service calls to IPS by AIB in an attempt to resolve problems. There is testimony from AIB employees that the system never worked. IPS [Baldwin] contends that the system did work properly and that most of the service calls would have been unnecessary had AIB referred to the manuals supplied.
  • It's often tempting to say (or at least think) RTFM ("read the fine manual") when talking to a customer. But sometimes the manual and the help are worthless. The documentation might be badly written, badly indexed, or full of errors. Hassling the customer, instead of fixing the manual, is no way to solve the problem.

    Lesson:

    Family Drug Store v. Gulf States Computer20

    This is an important case for the point that it makes about customer satisfaction. It says that the law gives customers the right to what they were promised, but it does not give them a right to a well-designed product or to be satisfied or happy with the products they buy.

    Two pharmacists bought software from Gulf States. After they realized what they had bought, they asked for a refund. Here were some of the problems of the system:

  • (1) all data had to be printed out, and could not be viewed on the monitor;

    (2) the information on the monitor would appear in code;

    (3) numerical codes were needed in order to open a new patient file;

    (4) the system was unable to scroll.

  • This software was less expensive than competitive products. The buyers may have been dissatisfied, but there was no question of misrepresentation in this case-Gulf States' salesperson had demonstrated the software honestly before the sale. The buyers had gotten what they had paid for, and Gulf States was within its legal rights in saying that the buyers were stuck with it.

    Lesson:

    Ritchie Enterprises v. Honeywell Bull21

    Ritchie Enterprises bought a Honeywell mainframe and later sued for fraud, misrepresentation, breach of express warranties, breach of implied warranties, breach of the implied covenant of good faith and fair dealing, and breach of a fiduciary duty. In a motion by Honeywell for summary judgment, the court ruled against the plaintiff on almost every issue-this case is widely cited for its analysis and enforcement of a clause that excluded payment of consequential damages for breach of contract.

    Honeywell lost on one issue, post-sale fraud. The court ruled that if technical support staff intentionally deceive the customer after the sale, and so convince the customer to keep trying to make a bad product work (perhaps talking the customer out of a refund), then the customer can sue for fraud.

    Even though the customer can't collect these damages in the underlying breach of contract suit, the court ruled that in a suit for post-sale fraud, the customer can collect punitive and consequential damages.22

    Lesson:

    Clayton X-Ray Company v. Professional Systems Corp.23

    Clayton X-Ray bought a computer and software from Professional Systems Corp. (PSC). The software had bugs and Clayton withheld payments. Without Clayton's permission, PSC loaded some additional code that locked up the system and displayed "Call Professional systems Corporation About Your Bill." This prevented Clayton from accessing its data.

    Clayton sued for conversion (unlawful taking over of Clayton's property). The court ruled that this was a valid claim for conversion, that could justify an award of punitive damages by the jury.

    This does not mean that you can't build usage restrictions, such as time bombs or usage counters, into your software. The Clayton case involves three important features:

    Lesson:

    Closing note: The law is in transition

    There's work in progress to rewrite the Uniform Commercial Code to provide special rules for software-related transactions.

    Recent drafts of this Article 2B have heavily favored software publishers and would eliminate customers' abilities to bring several of the suits discussed in this paper.24 Until recently, this draft was on a fast track and was expected to reach State legislatures in September, 1997. Some lawyers have been giving advice on the basis of their expectation that this set of proposals would pass into law.

    In the most recent full meeting of the National Conference of Commissioners of Uniform State Laws (NCCUSL) (July, 1996), draft Article 2B was criticized for imbalance. If it reaches the States in 1997, I expect that it will be with significant revisions.

    Article 2 of the Uniform Commercial Code (sale of goods) currently covers most software transactions. It is also undergoing revision. My sense from reading the latest draft modifications and attending (as an observer) a recent Article 2 drafting committee meeting (Oklahoma City, September, 1996) is that its revisions won't bar the types of suits described in this paper. Before Article 2B is introduced to the State legislatures, it will probably be reconciled with the revised Article 2.

    I regularly attend the Article 2B drafting meetings (as an observer). At this point, I can't predict what the final version of Article 2B will look like, or when (if) it will become law. Therefore, I wrote this article to reflect current law, without taking into account the Article 2B proposals.

    You might want to have your lawyer look into Article 2B. In the drafting committee meetings that I've attended, software publishers have been extremely well represented but consumers, small businesses, software retailers, and third-party support organizations have been under-represented or not represented at all. Consumers' interests are gaining back some protection. Non-publisher businesses are either going to advocate for their own interests or risk being unpleasantly surprised.


    1The California Judicial Council is a non-partisan, government body concerned with the administration of justice. This is the Council's annual report to the Governor and the Legislature.

    2These notes are based on documents in the case file for Master Case Number CV745729, In re Pentium Processor Litigation, 11 volumes on file at the Santa Clara County Superior Court, San Jose, California.

    3See the discussion and test results in PC Week's "Testing reveals that Intel's and IBM's claims both exaggerate the magnitude of problems, risks" (Volume 11, #50, p. 1, 12/19/1994).

    4J. Mahler, Dow Jones News Service, "Pentium flaw raises eyebrows at FDA; Agency action uncertain."

    5W. Mossberg, page B1.

    6"Humble pie: Intel to replace its Pentium chips" Wall Street Journal, 12/21/1994 at B1.

    7Class Action Complaint, Index No. 102081/96, Superior Court of the State of New York, County of New York.

    8Federal Reporter, Second Series, Volume 939, page 91, United States Court of Appeals,Third Circuit, 1991.

    9UCC § 2-314(1).

    Under Federal law (the Magnuson-Moss Warranty -- Federal Trade Commission Improvement Act, United States Code, Title 15, § 2308(c), a seller who provides a written warranty with a product or who sells a service contract for (such as extended technical support) for the software may not exclude the implied warranties of merchantability and fitness.

    10UCC § 2-314(2). "Goods to be merchantable must be at least such as pass without objection in the trade under the contract description; and in the case of fungible goods, are of fair average quality within the description; and are fit for the ordinary purposes for which such goods are used; and run, within the variations permitted by the agreement, of even kind, quality and quantity within each unit and among all units involved; and are adequately contained, packaged, and labeled as the agreement may require; and conform to the promise or affirmations of fact made on the container or label if any."

    11UCC § 2-314(2)(f)

    12UCC § 1-201(10) "'Conspicuous': A term or clause is conspicuous when it is so written that a reasonable person against whom it is to operate ought to have noticed it. A printed heading in capitals . . . is conspicuous. Language in the body of a form is 'conspicuous' if it is in larger or other contrasting type or color . . ."

    UCC § 2-316 requires that written exclusions be conspicuous.

    13South Eastern Reporter, Second Series, Volume 413, page 336 Supreme Court of Virginia, 1992.

    14Daughtrey v. Ashe (1992) p. 339.

    15Daughtrey v. Ashe (1992) p. 339.

    16Rather than relying on subsection (b) of Section 2-313 of the Uniform Commercial Code, which says that a description of the goods is a warranty, the Court might use subsection (a) which says that "Any affirmation of fact or promise made by the seller to the buyer which relates to the goods and becomes part of the basis of the bargain creates an express warranty that the goods shall conform to the affirmation or promise." Manuals are large, detailed collections of statements (affirmations) of fact about the program that they document.

    17In the case of Burroughs Corporation v. Hall Affiliates, Southern Reporter, Second Series, Volume 423, page 1348, Supreme Court of Alabama,1992, Burroughs was held liable for "fraud" on the basis of false statements from its sales representative to a customer. There was no claim that the salesperson deliberately misled the customer. Alabama and a few other States allow customers to hold sellers liable for innocent and negligent misrepresentation, as well as for deliberate fraud.

    18Software QA, Volume 2, #3, page 8,1995.

    19Southern Reporter, Second Series, Volume 599, page 1196, Court of Civil Appeals of Alabama, 1992.

    20Southern Reporter, Second Series, Volume 563, page 1324, Louisiana Court of Appeal, 1990.

    21Federal Supplement, Volume 730, page 1041, United States District Court, District of Kansas, 1990.

    22Note that fraud goes beyond telling direct lies. Silence can be fraudulent if a reasonable person would have justifiably expected the defrauder to reveal certain information.

    23South Western Reporter, Second Series, Volume 812, page 565, Missouri Court of Appeals, 1991.

    24I look at the consumer issues in "Uniform Commercial Code Article 2b: A New Law of Software Quality", Software QA, Volume 3, #2, page 10,1996.

    Cem Kaner consults on technical and management issues, practices law, and teaches within the software development community. His book, Testing Computer Software, received the Award of Excellence in the Society for Technical Communication's 1993 Northern California Technical Publications Competition. He has managed every aspect of software development, including software development projects, software testing groups and user documentation groups. He has also worked as a programmer, a human factors analyst / UI designer, a salesperson, a technical writer, an associate in an organization development consulting firm, and as an attorney (typically representing customers and software development service providers). He has also served pro bono as a Deputy District Attorney, as an investigator/mediator for Santa Clara County's Consumer Affairs Department, as an Examiner for the California Quality Awards. He holds a B.A. (Math, Philosophy, 1974), a J.D. (1993), and a Ph.D. (Experimental Psychology, 1984) and is Certified in Quality Engineering by the American Society for Quality Control. He teaches at UC Berkeley Extension, and by private arrangement, on software testing and on the law of software quality.


    Return to Bad Software: What To Do When Software Fails.

    The articles at this web site are not legal advice. They do not establish a lawyer/client relationship between me and you. I took care to ensure that they were well researched at the time that I wrote them, but the law changes quickly. By the time you read this material, it may be out of date. Also, the laws of the different States are not the same. These discussions might not apply to your circumstances. Please do not take legal action on the basis of what you read here, without consulting your own attorney.
    Questions or problems regarding this web site should be directed to Cem Kaner, kaner@kaner.com.
    Last modified: Tuesday November 11, 1997. Copyright © 1997, Cem Kaner. All rights reserved.