|Cem Kaner, Ph.D., J.D.||Florida Tech, Dept. of Computer Sciences|
|Law Office of Cem Kaner||150 West University Blvd|
This talk sketches the field of software-quality-related liability. I will briefly outline many legal theories under which a maker of defective products or a provider of defective services can be sued. Then I'll focus on three specific issues. (1) Negligence in development or support of software products; (2) Professional negligence in software-related (including testing) services; (3) New legislation to govern all contracts for software development, sale, licensing, and support.
This 45-minute talk barely scratches the surface. Occasionally, I teach a once-over-lightly survey course on this topic--we squeeze the material into 8 hours and students complain that we needed more time. Even squeezing software contract law into one day is a big challenge. Between October 1, 1997 and January 1, 1998, you can download supplementary materials from my law firm's web site at www.badsoftware.com. The materials include about 200 slides, including all of the ones used in today's talk, plus several original source materials (court cases, links to draft statutes, etc.), plus any paper of mine that I reference in this talk.
Whenever I talk to software quality advocates about software liability, some people like what I have to say, and some people hate it. On the positive side, lawsuits for defective products drive up external failure costs. This changes the balance in quality cost analyses and encourages companies to ship products that are less defective. On the some-people-hate-me side, we have reactions of people like W. Edwards Deming, one of my heroes (except for his ideas about lawyers). He named seven "deadly diseases." Number 7 was "Excessive costs of liability, swelled by lawyers that work on contingency fees." (Deming, 1986, p. 98).
Deming's view is popular. This theme has been promoted in expensive publicity campaigns. For those who share Deming's view, and think (as I've been told loudly at some conferences) that legal issues have no place in a discussion of software quality, please suspend your judgment for an hour. Whether you like it or not, we work in a world that has several laws that govern our products and services. There's value in understanding the ground rules.
There is a myth that most business-related lawsuits are the frivolous creation of evil plaintiff's lawyers. Supporting this has been a wave of statistics that appear to show that customer lawsuits against businesses have skyrocketed. For example, the following data from the 1994 Annual Report of the Judicial Council of California to the Governor and Legislature have been used in political campaigns. (1983-84 is the first of the 10 years in this study. Superior Court filings usually involve cases of $25,000 or greater.)
|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.
Despite California's increase in population, there are fewer business, consumer protection, and personal injury suits, not more. And there are dramatically fewer customer-side lawyers and consumer protection advocates. The increase in civil court 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 its an explosion of actions (often filed by the District Attorneys Office) to enforce child support orders. This is not a business problem.
Many programs have serious bugs and unhappy customers, partially because it's impossible to fully test the software (Kaner, 1997g). If that was the main problem, we could substantially reduce it by adopting processes that reduce the probability of coding errors (Ferguson, Humphrey, Khajenoori, Macke, & Matuya, 1997; Humphrey, 1997). However, most (in my experience, all) software companies ship software with bugs that were found during testing but not fixed. Some of these problems have been extremely serious. In the mass market, which is what I know best, we've seen several recent class action suits by dissatisfied customers ( for example, Leading Edge Computers, America OnLine, Compaq, and Corel).
There is significant customer dissatisfaction. Please see Kaner & Pels (1997) for extensive footnoting to sources for the next five paragraphs.
Computers became a "real" consumer product in 1994, when they outsold television sets. By the end of 1995, computers and software ranked #8 in the Top 10 list for complaints to the Better Business Bureau, outdoing used car dealers. The consumer market continues to grow. By 1996, 34% of American households had computers.
In 1996, there were 200 million calls for technical support. At an average of about $23 per call, the industry spent about $4.6 billion on these calls. Over the past seven years, the ratio of support to total employees in hardware and software companies has grown from 1 in 12 to 1 in 6. The average amount of training for technical support staff before they are put on independent telephone answering duty is only 40 hours.
In 1996, the industry left these callers on hold for about 3 billion minutes. The software industry has been one of the worst for leaving callers on hold. One study found that software companies leave callers on hold longer than any other industry studied, worse than government agencies, computer hardware companies, airlines, banks, utility companies, and others. Once you get off hold, you often reach a first-level person who can't answer your question. Wait some more for a "specialist" The Software Support Professionals Association estimates that the average time to reach the right support technician is 30 minutes for PC/Shrink-wrap products. (This person may not know the answer, but she is the right person to ask the question of.)
Customer satisfaction with software companies technical support has dropped steadily for ten years.
Several software companies now charge customers $3 or more per minute for support. Some companies will waive the charge for a customer who calls about a legitimate (in the company's view) defect. Others will not. Customers get angry when they realize that they've been paying for support for a defect that the company chose not to fix when it shipped the product. For example, in a recent class action suit, a customer alleged that Compaq released a product with known software defects (Johnson v. Compaq, 1997. NOTE: I have not yet seen an answer from Compaq. Johnson's allegations sound very serious to me, but Compaq might have a strong and reasonable response. Always take initial complaints with a big grain of salt.). Apparently, Johnson spent $218 on support and his problems were never resolved. He posted complaints on the AOL/Compaq message board, Compaq allegedly removed the messages and complained to AOL that this customer was abusing his account by posting inappropriate messages. The customer responded with a lawsuit. Several other lawsuits have involved a combination of bad software and support (Kaner, 1997e).
There are many other types of lawsuits involving defective software. For example, in the case of General Motors Corp. v. Johnston (1992) a PROM controlled the fuel injector in a pickup truck. The truck stalled because of a defect in the PROM and in the ensuing accident, Johnstons seven-year old grandchild was killed. The Alabama Supreme Court justified an award of $7.5 million in punitive damages against GM by noting that GM "saved approximately $42,000,000 by not having a recall or otherwise notifying its purchasers of the problem related to the PROM."
RISKS has carried reports of many serious errors, such as an airplane that rebooted its software mid-flight. There have been many, many lawsuits over custom software whose defects seriously disturbed the customer's business, as well as widely publicized cancellations of large programming projects, such as a project for California's Department of Motor Vehicles and another for the US Internal Revenue Service. A recent news report claimed that over 13% of Americans are being underpaid from private pension funds, largely because of software errors.
A legal "theory" is not like a scientific theory. I don't know why we use the word "theory." A legal theory is a definition of the key grounds of a lawsuit. For example, if you sue someone under a negligence theory:
Every lawsuit is brought under a specifically stated theory, such as negligence, breach of contract, breach of warranty, etc. I defined most of these theories, with examples, in Kaner, Falk, & Nguyen (1993). Here's a quick look at theories under which a software developer can be sued:
Proof of negligence can be quite difficult. No single factor will prove that a company was non-negligent. A court will consider several factors in trying to understand the level of care taken by the company (Kaner, 1996b). Kaner, Falk, & Nguyen (1993) list several factors that will probably be considered in a software negligence case, such as:
It's worth asking whether current industry standards, such as IEEE standards, are appropriate references. Do they realistically describe what the industry does or should do?
Negligence is the type of lawsuit that many of us think about first when we think about litigation over defective products. It is an interesting lawsuit for us as quality advocates because the software development process is clearly relevant in the suit. However, most software lawsuits are for breach of contract or fraud, not negligence. That's because a defective product doesn't trigger a negligence theory unless the product does personal injury or property damage.
UCC transactions carry implied terms. For example, products normally come with an implied warranty of merchantability (the product will be fit for ordinary use, it will conform to the claims on the packaging and in the manual, and it will pass without objection in the trade.) This reflects a basic American public policy, that some modest standards of integrity should be applied to the sales of goods. To disclaim an implied warranty of merchantability (i.e. to legally effectively say that there is no such warranty), a merchant seller must put a conspicuous disclaimer in the contract. (A company that sells software in the ordinary course of its business would be a software merchant.) Court cases have almost always required this notice to be given to the customer in a way that makes it conspicuous (likely to be seen) before or at the time of sale (White & Summers, 1995, volume 1).
The specific validity of shrink-wrapped software warranty disclaimers that are not visible to the customer until after the sale was considered in two opinions, Step-Saver v. Wyse Technology and The Software Link (1991), and Arizona Retail v. The Software Link (1993). The courts ruled that an implied warranty comes with a product at the time of sale unless it is conspicuously disclaimed, and that a conspicuous disclaimer that is not available to the customer until after the sale is merely a proposal to modify the contract, and is not part of the contract unless the customer agrees. A recent case, ProCD, Inc. v. Zeidenberg (1996), appears to say that anything in a shrink-wrapped license is valid but that case didn't consider warranty disclaimers. Nor did a similar second opinion, Hill v. Gateway 2000, Inc. (1997) issued by the same court. It will be a major departure from UCC history if a court enforces a warranty disclaimer that was not available to be seen by the customer before the sale.
The UCC also says that express warranties cannot be disclaimed. An express warranty is any statement of fact (something you can prove true or false) by the seller to the buyer about the product that becomes part of the basis of the bargain. The phrase "basis of the bargain" is to be interpreted expansively. The exact rules vary from state to state, but if a reasonable customer would interpret the seller's pre- or post-sale statements as factual descriptions of the product that the customer has bought, and would be even slightly influenced by the statements in deciding whether to buy or keep the product, then you should think of them as "basis of the bargain" statements. (See Kaner, 1995a, Kaner & Pels, 1996, and the court case, Daughtrey v. Ashe, 1992.)
Software service providers can also be sued. A "software service provider" is a "person" that writes custom software, maintains or supports software, trains other people to use software, does software testing or certification, or enters into other contracts involving software in which a significant component of the benefit to be provided by the seller involves human labor. Service providers can be sued in many of the ways that I listed for products, above, but also for:
Some software quality advocates are calling for professionalization. The say that software quality "engineers" should be licensed by the government and held to professional standards. If you are thinking along these lines, please consider the problem that we need a solid basis for distinguishing unacceptable from acceptable practices. Otherwise, professional liability will be a lottery: you will be sued for practices that you consider good. Here are some examples of disagreements:
I'm not alone in these views, but many of you will disagree with me. That's the point of these examples. We do not have a consensus on professional practices.
One last word of caution. If a person who is not a licensed professional identifies herself to potential clients as a professional, they can sue her for malpractice as if she were a member of that profession. If you call yourself a "quality engineer" (in California) or an "engineer" (some other states), you might discover yourself at the wrong end of an engineering malpractice suit. The suit will challenge judge and jury to figure out what the professional knowledge and standards a software quality engineer would have if there was such a profession and if it had generally accepted practices. Your lawyer would make a lot of money on this case.
Any legal theory that involves "reasonable efforts" or "reasonable measures" should have you thinking about two things:
We are, or should be, familiar with cost/benefit thinking, under the name of "Quality Cost Analysis" (Gryna, 1988; Campanella, 1990).
Quality cost analysis looks at four ways that a company spends money on quality: prevention, appraisal (looking for problems), internal failure costs (the company's own losses from defects, such as wasted time, lost work, and the cost of fixing bugs), and external failure costs (the cost of coping with the customer's responses to defects, such as the costs of tech support calls, refunds, lost sales, and the cost of shipping replacement products). Note that the external failure costs that we consider as costs of quality reflect the company's costs, not the customer's. Exhibit 3 provides software examples of quality costs.
It's useful to realize that you don't have to set up a formal cost tracking system to get many of the benefits of quality cost analysis.
Cost of quality analysis was developed by Juran as a persuasive technique. "Because the main language of [corporate management] was money, there emerged the concept of studying quality-related costs as a means of communication between the quality staff departments and the company managers" (Gryna, 1988, p. 42). You can argue from monetary data without ever developing complex cost-tracking systems. When a product has a significant problem, it will cost the company money. Figure out which department is most likely to lose the most money as a result of this problem and ask the head of that department how serious the problem is. How much will it cost? If she thinks its important, bring her to the next product development meeting and have her explain how expensive this problem really is. The data are approximate, inexpensively obtained, but they provide strong persuasive benefit.
In quality cost analysis, external failure costs reflect the company's costs, not the customer's. (For example, see Campanella, 1990). Previously (Kaner, 1995b, 1996a), I pointed out that this approach sets us up to ignore the losses that our products cause our customers. Thus, in quality cost analysis of the Pinto, it was cheaper for the company to ship cars that were dangerously defective. Exhibit 4 shows a quality cost analysis for the Pinto. If you focus on the costs to the company, it is obvious that (from a cost of quality point of view) you should ship the Pinto as is, which is what Ford did.
However, the law cares more about the customer's losses than the manufacturer's. And from the customer's point of view, risks of death or serious burns are big potential costs. Ford valued the cost associated with a killed customer at $200,000. What do you think? Would you consider $200,000 an even trade for your son or daughter? (Even in 1960's dollars?)
A manufacturer's conduct is unreasonable if it would have cost less to prevent or detect and fix a defect than it costs customers to cope with it (Kaner, 1996b). And so, in the Pinto cases, the juries determined that the defects caused more cumulative harm to society than the total savings made by the company, therefore the company did not take reasonable care to ship a product that was not unnecessarily dangerous, and therefore it was liable for damages.
In my view, the sad part in cases like these is that well-meaning employees probably think that they're doing the right thing. The quality cost analysis encourages employees to think about their companies' costs, and doesn't encourage them to think about their customers' costs. If people see traditional quality cost analysis as the right way to make quality-related business tradeoffs, then cases like the Pinto are a natural result. If we don't pay careful attention to the severity of defects for customers, we won't recognize that some circumstances are going to cost customers huge amounts and are candidates for big verdict lawsuits. If our customers' losses are significantly worse than our external failure costs, then under a traditional quality cost analysis, we risk being blindsided by unexpectedly expensive litigation.
Exhibit 5 contrasts the external failure costs suffered by sellers and those suffered by customers.
Benefits (reduced external failure cost) of fixing the design
Savings 180 burn deaths, 180 serious burn injuries, 2100 burned vehicles
Unit Cost -- $200,000 per death, $67,000 per injury, $700 per vehicle
Total Benefit 180 x ($200,000) + 180 x ($67,000) + 2100 x ($700) = $49.5 million.
Costs (increased internal cost) to fix the design
Sales 11 million cars, 1.5 million light trucks.
Unit Cost -- $11 per car, $11 per truck
Total Cost 11,000,000 x ($11) + 1,500,000 x ($11) = $137 million.
|These are the types of costs absorbed by the seller that releases a defective product.||These are the types of costs absorbed by the customer who buys a defective product.|
The Uniform Commercial Code (UCC) governs most contracts for the sale of goods in the USA. Courts treat sales of packaged software as a sale of goods and apply Article 2 of the UCC (the Law of Sales) to disputes involving packaged software. The courts treat the development and sale of custom software as a sale of services, that is not covered by the UCC. This has caused some confusion and unpredictability, which is no good for anyone.
The UCC is maintained and updated by the National Conference of Commissioners on Uniform State Laws (NCCUSL) a legal drafting organization funded by the 50 US states that writes all "Uniform" laws. NCCUSL has significant influence with state legislatures. Unless there is serious public opposition, the odds are good that a NCCUSL-drafted bill will pass. The UCC is co-maintained by the American Law Institute, another non-profit body of senior lawyers.
The UCC is being revised to include a new Article, 2B (Law of Licensing of Information). This draft statute, which runs about 300 pages, is to cover all contracts for the development, sale, maintenance and support of software along with many other information-related contracts.
This work started in the American Bar Association, 11 years ago. It became a NCCUSL project around 1992. It crystallized as the Article 2B project in 1995. To this point there was almost no customer-side advocacy. I started attending these meetings at the second 2B meeting, in February, 1996. Article 2B is scheduled for completion in July, 1998 and submission to state legislatures in the fall of 1998.
There is great benefit in creating a uniform legal system for software products and services, that works the same way across all states. Unfortunately, this particular proposal for unifying the law is seriously flawed (Kaner, 1996c, 1996e, 1997a, 1997b, 1997c, 1997d, 1997f, 1997h; Kaner & Lawrence, 1997; see www.cptech.org for the Article 2B Protest Page developed by Todd Paglia, an attorney working with one of Ralph Nader's Organization's, the Consumer Project on Technology; see www.webcom.com/software/issues/guide/docs for several critical articles written by Gail Hillebrand, an attorney representing Consumers Union. This site also includes many articles from publishers and others favorable to Article 2B).
I am most interested in the rights of individuals and small businesses and I therefore focus my analyses of Article 2B on packaged software, especially software developed for the mass market.
Under Article 2B, when you buy packaged software, you won't be buying a copy of the product. Article 2B adopts wholesale the publishers view that it is merely granting a license to use intellectual property when it sells someone a software product. Software publishers have been claiming for years that mass-market software sales are licenses and that the pieces of paper inside software packages that call themselves "license agreements" are binding contracts. However, this view is highly controversial. The traditional Uniform Commercial Code analysis is that the sales contract is formed when the customer agrees to buy the product and then pays for it. The piece of paper in the box is a proposed modification to the sales contract, and if its terms are significantly different from the standard (default) terms laid out by the UCC, then they won't apply. See Step-Saver v. Wyse Technology and The Software Link (1991), Arizona Retail v. The Software Link (1993), and White & Summers (1995, volume 1). The contrary view, that publishers can enforce whatever terms they include in these shrink-wrapped "licenses" has been adopted only very recently (ProCD, Inc. v. Zeidenberg, 1996; Hill v. Gateway 2000, Inc., 1997). Both of these decisions are from the same court, and much of the analysis of the ProCD case involved discussion of the then-current draft of Article 2B. Even though it is not law, Article 2B is already able to pollute the American legal system because it is being drafted by such a prestigious legislative drafting organization (NCCUSL).
Off-the-shelf products are treated in most courts as "goods" today, but will be treated as "intangibles." There is no difference between selling the right to read a book from a computer disk and the right to read a book on paper. There is no reason in principle that we should declare one transaction a license and the other (for now) as a sale. Customers do not view their purchases of MS Word (or of books) as licensing transactions.
Once 2B characterizes the transaction as a licensing transaction, publishers gain several rights. For example, none of the consumer protection laws that apply specifically to sales of goods (such as the Magnuson-Moss Warranty Improvement Act) will apply to software, because software will no longer be "goods." Additionally, licensing laws give licensors (software publishers) very broad rights when drafting their contracts. Buyers of an information-bearing product enjoy several rights under copyright and patent laws. However, licensees of the same product don't necessarily have those rights. They have the rights that are granted in their license. Under this regime, in a mass-market software license, software publishers can (and some already say they do) forbid customers from publishing critical articles about the product (they use nondisclosure/confidentiality clauses for this), from lending the product to a friend, from using it where and when and on what machine they want, from using the product to create a competing product, from reverse engineering a product in order to make one product that is interoperable with another, and even from getting third party support for the product (MAI Systems Corp. v. Peak Computer, Inc., 1993).
The MAI case is a useful example of the power of licensing. MAI sold computers. Peak was a third party service organization. Customers would call in Peak to maintain their computers. If you had an MAI computer, the Peak staff member would come onto your site, turn on your machine, boot its operating system, run the diagnostics that came with the machine, and then do what was necessary. In this situation, MAI and Peak are competitors for your service business. MAI was able to stop Peak from servicing MAI computers because MAIs license restricted use of the software to not more than three of the customers "bone fide employees." Even though Peak was working at the customers site, at the request of the customer, running software licensed to the customer, and MAI supplied this software to the customer specifically to be run on this computer, Peak was a contractor, not an employee of the customer. Therefore, Peaks use of the software was a violation of the terms of MAIs license, and was therefore a copyright infringement.
This was, and continues to be, a controversial decision. But its rules have been adopted in Article 2B and it is talked about in the 2B meetings as good law. In other meetings, it is often called an abuse of copyright.
The effect that I want you to notice here is that the license can be used to eliminate competition. In this case, the competition that was eliminated was the independent maintenance service provider. Article 2B allows other restrictions on competition. For example, some mass-market licenses bar use that would result in creation of a competing product. Many mass-market licenses ban reverse engineering (reverse engineering is absolutely allowed under patent and copyright law) and this ban will make it nearly impossible for many companies to make products that are interoperable with another product. Here's an example that I've discussed with some publishers' lawyers. If I wanted to make a word processing program, I would probably want it to be able to read (import) documents from my competitors' files. For example, Microsoft Word and WordPerfect can read each other's files. Many programs can read competitors' files today, and they are able to do that because their publishers are able to reverse engineer their competitors' file formats. Under 2B, I would need my competitor's permission to reverse engineer its file format. I probably won't get that permission, so my program probably won't be able to import much data from competing products. Suppose that you have lots of documents that you've written using your current word processor. I offer to sell you a new word processor that you really like. Unfortunately, my program can't read your old files. Would you buy my program? Probably not. By making interoperability very hard to achieve, Article 2B makes it hard for a new competitor to enter the market.
What possible benefit is there to the public of a law that increases the power of a publisher to stop a dissatisfied customer from using an independent service company for technical support? And what benefit is there from a law that gives a publisher broad new rights to block the development of competitive services or products?
Another feature of Article 2B is that it lets publishers use confidentiality clauses in their license agreements, even in licenses for off-the-shelf products that you buy mail order or in a store. Today, if you buy a book (or any mass-market product that provides information), the Copyright Act gives you rights that you don't get under licensing law. For example, you can publish a book review, telling people what you think of specific parts of the book and quoting short passages to illustrate your points. You don't have this right under Article 2B. The license can say (as a few mass-market licenses do now, probably unenforceably), that the behavior of the product is confidential and that you may not publish information (such as in a magazine review) about the operation of the product without the written permission of the software publisher.
What benefit is there to the public of a law that lets publishers cut off their customers' right to read detailed, critical reviews of a product they are considering buying?
Some people have told me that the courts won't enforce these restrictions because people have rights of free speech. Maybe they're right, but the battle will not be a sure victory. Publishers have the rights to create trade secrets and to enter into nondisclosure contracts with people. The courts enforce those contracts. What is new here is that the publisher is creating a nondisclosure contract with the whole world, one customer at a time. Anyone who can afford the contract can learn the secret, as long as they pay. This is a big extension of the law of secrets, but a court might be reluctant to say that such an extension, adopted by most or all state governments, is unconstitutional and therefore invalid. And it will take a lot of money to fight the lawsuits to establish this invalidity. In the meantime, some large magazines might reject the law and print critical articles anyway, but other magazines and individuals with their own web sites might be much more cautious about speaking their mind. After a few well publicized enforcement letters from publishers' lawyers, and perhaps a favorable court decision or two, and many people will be afraid to speak their mind because the contract says they can't.
Article 2B also allows software publishers to disclaim warranties after the sale, in a contract that customers cannot see before the sale. In fact, all of the terms of the contract can be kept from the customer until after the sale has been complete. 2B requires publishers to draw the contract to the customer's attention early in the use of the product, and to allow the customer a refund if he rejects the terms of the contract. The effect of this is to make it impossible for customers to do comparison shopping on the terms of the contract. If no one publishes their warranty period, or the things that are covered by the warranty, then customers cannot make a buying decision that is based on comparisons of that information across products. I can speak from the experience of having tried to gather information about licensing practices across a broad group of mass-market products. I wanted to put together a statistical summary for an Article 2B drafting committee meeting and I finally gave up. There is no reasonably convenient way for shoppers to compare the warranty policies and support policies of competing products. Enforcement of the Magnuson-Moss Act will probably fix this problem under the law today. But if 2B passes, this inability to compare terms will be a result of law rather than a violation of it.
The same problem arises for any other terms that the publisher doesn't want the customer to see until after the sale is complete. Once the customer has taken the product home or to the office, and started loading it on her computer, he is no longer in a shopping frame of mind. He's much less likely to reject harsh legal terms in a license after he's committed himself to the product, and returning it would be an often-significant inconvenience.
What possible benefit is there to the public of a law that cuts off their right to know before the sale what guarantees the product comes with? And what do you think this will do for software quality?
Additionally, in several ways, it will be harder to collect damages (money) from publishers if the product is defective. (Kaner, 1996e, 1997b). Customers will almost always be limited to a refund, a partial refund, a bug fix, or nothing. A refund is available only for a "material breach" of contract (the contract written by the publisher), so even for a significant bug, the company can force a customer to prove in court that the bug is so serious that the customer is entitled to a full refund and not just a small partial one. This affects the negotiating power of customers when they call for technical support.
Damages are important external failure costs. If a company knows it risks paying damages for a bug, it will more likely fix the bug. I have repeatedly proposed a narrow damages rule (e.g. Kaner, 1997b, 1997f, ): If a publisher knows about a bug in a product before it sells it (or if the publisher would have known if it hadn't been "grossly negligent," such as doing no testing at all) then the publisher must either fix the bug, document the bug in a way that a normal customer will understand (how to avoid it, work around it, etc.), or pay for the losses that the bug provably cost the customer, up to a maximum amount. For low-priced products, I suggest a maximum of $500 or five times the price of the software. This increases external failure costs of the product only for those cases in which the publisher chose not to manage a known risk. This proposal has gone nowhere. Article 2B will allow publishers to knowingly leave serious bugs in the product, without disclosure, without risk of damages unless the product injures someone or does property damage.
To make matters worse for consumers, Article 2B reverses a right to a non-defective product. Under the Magnuson-Moss Act, purchasers of a defective consumer product who want a fixed product and not a refund are entitled to a repair unless this is commercially unreasonable. This goes away under 2B. Instead, publishers are required to try to provide bug fixes only for business customers of non-mass-market products.
Article 2B lets publishers pick what law will govern their sales and where customers can sue them. They can specify whatever location they like in the contract. Whatever state or country offers the most publisher-friendly laws will probably be the one specified in most contracts. (Remember that the customer doesn't even see this clause until she starts using the program. It doesn't have to be made conspicuous to the customer, and there will typically be no provision that allows the customer to negotiate it..) There are no geographical restrictions and no requirement of any relationship between the law, the forum and any party or aspect of the transaction. Small claims court actions will be unavailable (when exclusive jurisdiction is given to a higher-level court) or prohibitively expensive (in a state or country far, far away). There are slight restrictions on this if the customer is a "consumer" who uses the software for strictly non-business, non-professional purposes (the teacher who does research or writes assignments at home is not acting as a consumer, nor is the unemployed secretary who tries out some home-based network marketing scheme and uses a computer to manage her mailing lists and print fliers.)
It is a standing joke among some of us that the main positive benefit of Article 2B will be a massive expansion of the space program. Software publishers should be glad to support NASA in a push to colonize the moon, so long as one of the colonists' first acts will be to open a courthouse. Guess what forum will be specified in all software contracts after that? I've been told that this joke is unfair, that courts wouldn't possibly tolerate clauses that say that customers can sue only in a lunar courthouse. Well, maybe it is (though I wouldn't care to predict the decision that the Gateway 2000 v. Hill court would reach). But in practical terms, what is the difference between saying that you can sue only in Argentina and saying you can sue only on the moon? Or, for customers on the west coast, that they can only sue in Florida or New York? Few customers with meritorious cases will have the ability to bring a lawsuit against a publisher. Unless a customer paid a large amount of money for the program or suffered huge damages, the legal expenses will far outweigh whatever the customer can get back in a lawsuit.
We've talked about this at length in the Article 2B meetings. Everybody understands that small customers will be effectively barred from bringing many types of lawsuits by this rule. This is not an accident and not an oversight.
There are many more problems with 2B than this. I walk through them in detail in Kaner (1997h).
Let's tie all this together.
Quality cost analysis is important because it describes an important persuasive approach that is widely used in the field. Most of my colleagues do it less formally than the theorists would recommend, but we understand that a powerful way to stop a product from shipping or to get a problem fixed is to prove to management that there is a high risk of high external failure costs.
There are many types of external failure costs. For convenience, I'll lump them into three categories:
Most claims involving product defects will come under the law of contracts. Let's consider how Article 2B will impact each of those costs.
Customer support costs can be managed by charging the customer for support. Maintenance costs are already a common part of the contract in large systems. Mass-market publishers are increasingly charging $3 per minute, or $20-$150 per call or per incident for support calls. The customer must pay fee-based support from the first minute of the customers possession of the product, even for actual defects in the product that are already known to the publisher. Most publishers allow a grace period of 30, 60 or 90 days during which the customer can call about problems without paying a fee (Software Publishers Association, 1995) but some do not.
This practice is not new under 2B, but we should understand it in the context of 2B. These are incidental expenses which will not be refunded to the customer even when the customer gets a refund for material breach. For the first time, the law will clearly and explicitly say that the unscrupulous publisher gets to profit from its own defects, and the customer has no recourse. Article 2B will also make it easier for publishers to refuse to give refunds or bug fix updates. In sum, Article 2B will help publishers reduce their customer support costs in ways that don't improve the quality of their products.
Lost sales occur when a potential customer either buys nothing or buys a competitor's product. Article 2B will allow the publisher to limit the effects of competition in many ways. The publisher can limit the flow of bad information about its products and it can delay or block the development of competing products and it can limit the availability of competing support services for their products. Article 2B can help publishers reduce their lost sales through methods that don't improve the quality of their products.
And finally, there are legal costs. Most disputes between customers and publishers are breach of contract disputes. It is a breach of contract to sell a product that is supposed to work and deliver a product that does not. Most disputes will therefore be governed by Article 2B. Article 2B will allow publishers to make it extremely difficult and expensive to sue them, and it will let them severely limit the amount that they can be required to pay if they lose the suit. Article 2B will help publishers significantly reduce their legal expenses, without improving the quality of their products.
In sum, Article 2B provides publishers with a broad strategy for reducing external failure costs without improving products. Similarly, it allows them ways to reduce quality without experiencing, over the short term at least, increased external failure costs.
Throughout Article 2B there is tolerance for software defects. For example, in the Reporters comments we see "the perfect tender rule [should] be abolished with respect to software contracts because of the complexity of the software product and the fact that minor flaws ('bugs') are common in virtually all software."
Article 2B takes substantial force away from my most powerful tool for arguing that those bugs should be prevented or fixed--it helps publishers dramatically limit the costs associated with shipping products with those bugs. As a quality advocate, I find it appalling.
Arizona Retail Systems, Inc. v. The Software Link (1993) Federal Supplement, volume 831, p. 759.
Burroughs Corp. v. Hall Affiliates, Inc. (1982) Southern Reporter, Second Series, Volume 423, p. 1348 (Supreme Court of Alabama).
Campanella, J. (Ed.) (1990). Principles of Quality Costs, 2nd Ed. ASQC Quality Press.
Daughtrey v. Ashe (1992) South Eastern Reporter, Second Series, volume 413, p. 336 (Supreme Court of Virginia).
Deming, W.E. (1986). Out of the Crisis. MIT Press.
Ferguson, P., Humphrey, W.S., Khajenoori, S., Macke, S., & Matuya, A. (1997) Results of Applying the Personal Software Process, IEEE Computer, May, 1997, p. 24-31.
General Motors Corp. v. Johnston (1992), Southern Reporter, 2nd Series, volume 592, pages 1054 and 1061.
Gryna, F. M. (1988) "Quality Costs" in Juran, J.M. & Gryna, F. M. (1988, 4th Ed.), Jurans Quality Control Handbook, McGraw-Hill.
Hill v. Gateway 2000, Inc. (1997) Docket No. 96 C 4086 (1997 WL 2809), 7th Circuit Court of Appeals.
Humphrey, W.S. (1997) Comments on Software Quality. (unpublished) Annual Meeting of the National Conference of Commissioners on Uniform State Laws, July 25 August 1, 1997, Sacramento, CA. Available at www.webcom.com/software/issues/guide/docs/whsq.html.
In the Matter of Syncronys Software. (1996), Docket C-3688. Complaint at www.ftc.gov/os/9610/c3688cmp.htm. Decision and order at www.ftc.gov/os/9610/c3688d&o.htm.
In the Matter of Apple Computer, Inc. (1996), Docket C-3763. Complaint at www.ftc.gov/os/9708/c3763cmp.htm. Decision and order at www.ftc.gov/os/9708/c3763ord.htm.
Johnson v. Compaq (1997). Class action complaint filed against Compaq Computer in North Carolina. For the text, see users.aol.com/Cclass450/index.htm. This is a remarkable series of documents, and it is kept updated.
Kaner, C. (1995a) Liability for Defective Documentation. Software QA, 2, #3, 8 et seq. Available at www.badsoftware.com/baddocs.htm.
Kaner, C. (1995b) "Software Quality & the Law" in The Gate (newsletter of the San Francisco Section of the American Society for Quality Control), July, 1995, p. 1.
Kaner, C. (1996a). Quality Cost Analysis: Benefits and Risks. Software QA, 3, #1, 23 et seq. Available at www.badsoftware.com/qualcost.htm.
Kaner, C. (1996b). Software Negligence and Testing Coverage. Proceedings of STAR 96 (Fifth International Conference on Software Testing, Analysis, and Review), Orlando, FL, May 16, 1996, 313 et seq. Available at www.badsoftware.com/coverage.htm.
Kaner, C. (1996c). Uniform Commercial Code Article 2B: A new law of software quality. Software QA, 3, #2, 10 et seq. Available at www.badsoftware.com/uccsqa.htm.
Kaner, C. (1996d). Liability for Defective Content. Software QA, 3, #3, 56 et seq.
Kaner, C. (1996e) Warranty and Liability Hypotheticals for UCC Article 2B. (unpublished). Meeting of the NCCUSL Article 2B Drafting Committee, Philadelphia, PA, April 26-28, 1996.
Kaner, C. (1996f). Computer Malpractice. Software QA, 3, #4, 23 et seq. Available at www.badsoftware.com/malpract.htm.
Kaner, C. (1996g). Contracts for Testing Services. Software QA, 3, #5, 20 et seq.
Kaner, C. (1997a). What is a Serious Bug? Defining a "Material Breach" of a Software License Agreement. (unpublished). Meeting of the NCCUSL Article 2B Drafting Committee, Redwood City, CA, January 10-12, 1997. (abbreviated version, Software QA, 3, #6.) Available at www.badsoftware.com/uccdefect.htm.
Kaner, C. (1997b). Remedies Provisions of Article 2B. (unpublished). Meeting of the NCCUSL Article 2B Drafting Committee, Redwood City, CA, January 10-12, 1997. Available at www.badsoftware.com/uccrem.htm.
Kaner, C. (1997c). Proposed Article 2B: Problems from the Customer's View: Part 1: Underlying Issues. UCC Bulletin, January, 1-8. Available at www.badsoftware.com/uccpart1.htm.
Kaner, C. (1997d). Proposed Article 2B: Problems from the Customer's View: Part 2: List of Key Issues. UCC Bulletin, February, 1-9. Available at www.badsoftware.com/uccpart2.htm.
Kaner, C. (1997e). Liability for Bad Software and Support. Proceedings of the Support Services Conference East, Nashville, TN, March 12, 1997. Available at www.badsoftware.com/support1.htm.
Kaner, C. (1997f). Not Quite Terrible Enough Software. (unpublished). Annual Meeting of the Software Engineering Process Group, San Jose, CA, May 1997. Available at www.badsoftware.com/sepg.htm.
Kaner, C. (1997g). The Impossibility of Complete Testing. In press, Software QA.
Kaner, C. (1997h), Article 2B is Fundamentally Unfair to Mass-Market Software Customers, circulated to the American Law Institute for its Article 2B review meeting, October, 1997. Available at www.badsoftware.com/ali.htm.
Kaner, C., Falk, J., & Nguyen, H.Q. (1993). Testing Computer Software, 2nd Edition, International Thomson Computer Press.
Kaner, C. & Lawrence, B. (1997). UCC Changes Pose Problems for Developers. IEEE Software, March/April, 139-142.
Kaner, C. & Pels, D. (1996). User documentation testing: Ignore at your own risk. Customer Care, 7, #4, 7-8.
Kaner, C. & Pels, D. (1997). Article 2B and Software Customer Dissatisfaction. (unpublished). Meeting of the National Conference of Commissioners on Uniform State Laws' Article 2B Drafting Committee, Cincinnati, OH, May 30, 1997. A shorter version of this paper, for the software community, was published as Software Customer Dissatisfaction, Software QA, 4, #3, 24 et seq. Available at www.badsoftware.com/stats.htm.
MAI Systems Corp. v. Peak Computer, Inc. (1993) Federal Reporter, Second Series, Vol. 991, p. 511, United States Court of Appeals for the Ninth Circuit.
National Conference of Commissioners on Uniform State Laws (1997) Uniform Commercial Code Article 2B, Law of Licensing. Draft of September 22, 1997. Available at www.law.upenn.edu/bll/ulc/ulc.htm.
Princeton Graphics v. NEC Home Electronics (1990) Federal Supplement, volume 732, p. 1258 (United States District Court, Southern District of New York).
ProCD, Inc. v. Zeidenberg (1996) Federal Reporter, Third Series, volume 86, p. 1447 (7th Circuit Court of Appeals.)
Ritchie Enterprises v. Honeywell Bull, Inc. (1990) Federal Supplement, Volume 730, p. 1041 (United States District Court, Kansas).
Smedinghoff, T.J. (1993). The SPA Guide to Contracts and the Legal Protection of Software. Software Publishers Association.
Software Publishers Association (1995) 1995 Technical Support Survey Report. Software Publishers Association.
Step-Saver Data Systems, Inc. v. Wyse Technology and The Software Link, Inc., (1991) Federal Reporter, Second Series, volume 939, p. 91 (Third Circuit Court of Appeals).
White, J.J. & Summers, R.S. (1995), Uniform Commercial
Code (4th Edition), Practitioner Treatise Series, West Publishing