Why Software Quality Professionals Should Actively Oppose the Uniform Computer Information Transactions Act

September 1999
Volume 1 • Number 4

Contents

Why Software Quality Professionals Should Actively Oppose the Uniform Computer Information Transactions Act
The National Conference of Commissioners on Uniform State Laws (NCCUSL) is an organization funded by the 50 states to promote uniformity among state laws by drafting model legislation for their consideration. The work of the NCCUSL is not binding on the states, but bills submitted to state legislatures based on NCCUSL drafts are often enacted into law.
NCCUSL voted, on July 29, 1999, to pass on to the states a model law affecting contracts for the sale, licensing, development, documentation, support, and maintenance of com-puter software known as the Uniform Computer Information Transactions Act (UCITA). There has been much controversy throughout the development and debate of this draft, with strong arguments on its advisability presented by both sides. These two position papers were prepared prior to the July meeting of NCCUSL, but they continue to provide insights that may help software quality professionals take an informed position on the UCITA proposal.
Key words: consumer rights, contract law, cost of quality, electronic commerce, public policy, quality management, Uniform Computer Information Transactions Act

by Cem Kaner

Editor’s Note: This “Talking Points” section is offered as a “Point/Counterpoint” with a pair of opinion pieces. Many software quality practitioners may not have heard of the Uniform Commercial Code or tried to untangle the legal intricacies of warranty and liability. SQP is printing this material, however, (and featuring more on its Web site) because such legal, regulatory, and public-policy issues are unavoidably part of our future professional environment. For instance, a new lobby group composed of major Internet firms announced its formation in July, saying it believed that “Over the next few years, the future of the Internet will be determined more by policy choices than technology choices.” We must be informed on the competing claims in these policy debates if we are to be knowledgeable citizens and responsible professionals.

INTRODUCTION

The Uniform Computer Information Transactions Act (UCITA) is a proposed new law that will govern all software transactions, including contracts for sale, licensing, documentation, maintenance, and support of computer software. It will also govern contracts involving electronic information (such as movies, music, text that one can download or buy on a CD) and, at the vendor’s option, can govern the sale of computers and other devices that are sold in conjunction with software.

Until recently, UCITA was proposed as an amendment to the Uniform Commercial Code (UCC), and was called Article 2B. However, the American Law Institute (ALI), one of the two organizations that must approve all changes to the UCC, recently withdrew from the Article 2B project. The other organization, the National Conference of Commissioners on Uniform State Laws (NCCUSL), decided to rename the bill the Uniform Computer Information Transactions Act and go forward with it.

WHY SOFTWARE QUALITY PROFESSIONALS SHOULD OPPOSE UCITA

Using this definition, when software is assessed as having higher testability, it means that incorrect output will likely occur if a defect exists. To understand why faults hide during testing, one must know the sequence of events that must occur in order to observe incorrect output:

The simple and short answer is that UCITA will dramatically reduce a software publisher’s external failure costs for defective software. It does this brilliantly, in many ways, reducing the costs of customer support, lost sales due to competition, and legal action. As a result, UCITA changes the economics of software publishing.

When we reduce the risks (to the publisher) of selling defective software, we reduce the incentive to spend the money and time to prevent, search for, and fix defects. In turn, this says that the American software industry:

  • Will ship worse software
  • Will invest less money in technology and process improvement needed to produce better software
  • Will be more vulnerable to foreign competition. Les Hatton, a well-known author on software quality, just finished his master’s degree in law (Hatton 1995). He advised me that the trend in Europe is to hold software companies more accountable for defects and to provide greater protection for European consumers and small businesses. I believe this will provide a greater incentive for companies that primarily trade in Europe to improve their products rather than ship them with obvious defects. Eventually, international competition will take care of this divergence of standards. But as with the car industry, that eventuality might be devastating for some parts of the American economy (such as software workers).
WHAT SOFTWARE QUALITY PROFESSIONALS CAN DO Kaner_2B_tn.gif

For the last three and a half years, I have spent a sizeable amount of time explaining software quality issues to legislative drafting and regulatory bodies. I have provided input to drafting committees for uniform laws (Article 2B/UCITA, Article 2-UCC law of sales, and the Uniform Electronic Transactions Act), to people drafting laws and treaties to govern international electronic commerce (a State Department study group and members of the American Bar Association), to the Federal Trade Commission (FTC), and to various consumer protection groups. Several other software quality advocates have shared in this work, and software-related professional societies, including the Association for Computing Machinery, the Institute for Electrical and Electronics Engineers, and the Independent Computer Consultants Association, have submitted letters criticizing UCITA/Article 2B.

Here are a few things that I have learned. First, UCITA is just one of several legislative proposals involving software quality that will go to the state and federal governments over the next few years. It is currently the most important. I expect to also see proposals to:

  • Reduce legal liability of vendors and users of Y2K-defective software
  • License software testers, developers, and consultants
  • Increase liability for defects in consumer or mass-market software (various proposed lemon laws)
  • Limit competition, via changes to the Copyright Act (for instance, to ban or restrict reverse engineering of software products)
  • Increase competition via changes to the antitrust laws (if Microsoft prevails in its antitrust case)
  • Increase/decrease/regulate/deregulate privacy protection on the Internet
  • Establish standards for reliability of Internet services
  • Establish standards for electronic signatures and other technical aspects of electronic commerce

There will probably be plenty of other proposals.

Second, we–software professionals–are credible sources of information on these types of issues. We are industry insiders. We are not embittered whistle-blowers–we want the industry to succeed. We also have special insight–we know how products fail, we understand the difficulties of making perfect products, and we know how defects affect customers.

Our input is valuable because most of the people who will have to evaluate these proposed laws are lawyers, and most of them are unsophisticated about software. Many of the lawyers working on committees writing legislation to govern electronic commerce did not even have e-mail accounts when they started work. Many of the lawyers who will vote on these proposed laws still do not have e-mail, let alone more sophisticated e-commerce experience.

Even those with some experience as software users get a huge portion of their education about software development and marketing from other lawyers who represent software publishers. This bias is pervasive. Legislative drafting committees dealing with software are visited or advised by many paid lobbyists for software publishers and by very few, usually unpaid, consumer advocates (almost none of whom have software-related backgrounds). Additionally, courses and industry seminars on software law are typically taught by lawyers who represent software publishers or consultants, and speakers at conferences on software law are typically lawyers who represent publishers. There are hundreds of lawyers working for software sellers, but I can count on one hand the number of lawyers who publicly advocate for software quality. If legal drafting bodies and legislatures are going to deal sensibly with the proposed laws to govern software quality, they need input from software quality professionals.

Third, we can provide input–we are welcome to provide input–as individuals and as professional societies. People are hungry for our input. Nonlawyers can have a significant impact on laws by addressing technological issues and explaining the consequences of technology-related decisions. Software developers and testers have not been that well received in the UCITA/Article 2B drafting committee meetings, but they have had big effects elsewhere. For example, Bob Johnson is responsible for many significant improvements to the Uniform Electronic Transactions Act. Even in the UCITA process, our comments have been effective in slowing the process down and convincing decision makers to consider UCITA more carefully. ALI would probably have approved UCITA/Article 2B if it were not for our many comments.

In my experience, regulatory agencies, such as the FTC, are even more interested in our input than legislative drafting groups. With particular reference to UCITA, we can do the following:

  • Write letters to your state legislators and state governor. (This is a state-law issue; members of Congress do not count.)
  • Write letters describing defects that were badly handled and examples of deceptive, dishonest, or unfair conduct by software publishers to Adam Cohn (ACOHN@FTC.GOV) of the FTC. Cohn will be interested in fully detailed (names, dates, and so on) letters. You can also send him a letter that deliberately disguises the people, companies, or products just to educate him about industry practices. These letters are valuable because the FTC is in an awkward position regarding UCITA. Federal agencies rarely comment on state law, but the authors of UCITA are making claims about the status and content of consumer protection law in the United States, and the FTC has significant expertise in this area. The FTC has now written two detailed comments on Article 2B (see www.ftc.gov/be/v980032.htm and www.ftc.gov/be/v990010.htm).
  • Write letters and op-ed articles for your local newspaper.
  • Encourage your professional societies to take a stand and to write letters of their own.
HOW UCITA DRIVES DOWN FAILURE COSTS

The total quality cost for a product is the sum of:

  • Prevention costs (cost of preventing defects)
  • Appraisal costs (such as cost of testing)
  • Internal failure costs (such as cost of fixing defects)
  • External failure costs (costs caused by the defect after the product is released to customers)

The external failure costs in this model are the costs of the seller or manufacturer, not the costs of the customer. This model ignores the customer’s costs (Kaner 1996).

Normally, the best way to reduce external failure costs is to improve the product, especially by preventing defects or finding them early in development. A company can reduce its external failure costs, however, by handling them (such as customer complaints or lawsuits) more efficiently.

UCITA provides another approach: Reduce external failure costs directly. I classify external failure costs into three categories:

  • Customer support costs
  • Legal costs
  • Lost sales (especially sales lost to competitors)

Note that publishers do not reduce their customer’s losses by reducing these costs. In many cases, publishers will save money by increasing their customer’s losses under UCITA.

Customer Support Costs

Here are some ways UCITA lets publishers reduce their technical support costs (without improving the product). Citations are to the July 1999 draft of UCITA:

  • The publisher gets to charge customers for support, even for known bugs. For example, if a customer buys a program for $50, the publisher might charge him $3 per minute for a support call. Suppose that the customer runs into a (known) defect, calls the publisher, talks for 30 minutes ($90), realizes that he is not getting anywhere, and demands a refund. The publisher says OK. The customer sends back the product (at his expense), the publisher sends the customer $50 and keeps his $90. It would have been much cheaper to throw the defective product away (Section 803(a)(1) or 803(c)).
  • When the buyer rejects a defective product because of obvious defects, the publisher can demand “a full and final statement in a record of all defects on which the refusing party proposes to rely” (Section 702(c)(2)). If there are bugs that buyers do not find and report in response to this, they cannot complain about it when it bites them later. (But not even the publisher’s testing staff can find all the defects, so why should a customer be expected to create a full and final statement of them?)
  • A publisher’s contract to support its software will not require it to fix all defects (Section 612(a)(1)(B)).
  • In a contract dispute, the publisher can sometimes use “self-help” to shut down the operation of the program without court approval (Section 816).
  • The publisher will have the same or (probably) greater power to restrict the customer’s right to maintain the publisher’s software or to contract for third-party support for the software. (This is achieved via contractual-use restrictions on modification or third-party use of the product. See Section 102(a)(20) and 701(a).)
Legal Costs

Here are some ways UCITA lets the publisher reduce its risk of legal liability for defective products without making the product less defective.

  • All contract terms except the price can be hidden from the customer until after the sale. “Hidden” means that the customer has no way to obtain the terms until after paying for the product (Section 112, 210-213).
  • The implied warranty of merchantability (which provides that products will be reasonably fit for ordinary use) will be trivially easy to disclaim (to refuse to provide), and the disclaimer can be hidden from the customer until after the sale (Sections 112, 210-212).
  • By defining software transactions as licenses (which are intangibles) instead of sales of copies of the software (Section 102(a)(42)), UCITA takes these transactions out of the scope of the Magnuson-Moss Warranty Improvement Act, and state consumer protection statutes that are based on sales of goods go away. Consumers thereby lose warranty rights.
  • It is much harder under UCITA than under current law (UCC Article 2) to prove that a warranty was created by a product demonstration (Section 402(a)(3) and 402(b)(2)). A publisher can more easily get away with making misleading product demonstrations at trade shows.
  • Business customers lose their right to reject a product for obvious defects. (Section 704(b) restricts the centuries-old “perfect tender rule” to mass-market contracts, repealing it for the rest.)
  • Except for mass-market software in the first day or so of use, one cannot cancel the contract (and return the software) unless there is a “material breach” (a very serious defect or group of defects) (Section 601, 704(a), 802(a)). The definition of material breach (Section 701) is more seller-friendly than the current definition, as laid out in the Restatement of Contracts. And finally, the publisher can specify that one cannot cancel the contract even if there is a material breach (Section 803(a)(1)).
  • Even if it is proven that the product is defective and the seller has materially breached the contract, the seller is liable for almost no remedies (payments to the customer). For example, the publisher does not have to reimburse callers for incidental expenses (such as the cost of phone calls to the publisher or of returning the product) or consequential losses (such as the cost of restoring lost data) caused by the product’s defect (Section 803(d)). UCITA eliminates the principle of the “minimum adequate remedy” developed in UCC Article 2 (the current law of sales, which governs contracts for packaged software today. See Reporter’s Note 6 to Section 803: “This Act does not give a court the right to invalidate a remedy limitation because the court believes that the imitation does not afford a “minimum adequate remedy” for the aggrieved party.”).
  • The publisher can easily set up a waiver of liability (customers “agree” to not sue the publisher for defects they have complained about) by including the waiver in the click-wrapped license that comes with a bug-fix upgrade that the publisher sends (Section 702(a)).
  • The contract can specify what state or country’s law will govern this transaction and what court (in what country, state, city) one has to go to bring a suit against the publisher. Forget about bringing a case in small-claims court against a publisher who sells someone a defective consumer product. Unless the software is very expensive or the suit is brought as a class action, customers prob- ably will not be able to afford to bring such a lawsuit because of the added travel and legal research expenses. Additionally, the publisher will probably have written into the contract the state whose laws and courts are most favorable to it (Sections 109, 110, and many debates and resolutions during the 2B drafting meetings).
Lost Sales
  • UCITA will let companies prohibit publication of criticisms of their product. For example, with VirusScanTM, comes with the restrictions: “The customer shall not disclose the results of any benchmark test to any third party without McAfee’s prior written approval” and “The customer will not publish reviews of the product without prior consent from McAfee.” These are restrictions on disclosure. Section 102(b)(20) defines a “contractual use restriction” as “an enforceable restriction created by contract, which restriction concerns the use or disclosure of, or access to licensed information or informational rights, including a limitation on scope or manner of use.” Therefore, on their face, these terms are enforceable. Section 105 provides some limitations on these clauses. A clause can be thrown out if federal law specifies that it can be thrown out if the customer can jump through a remarkable set of litigation hoops to prove that the clause violates a fundamental public policy, or if (Section 111) a judge rules that the clause is unconscionable. These decisions are made on a case-by-case basis, so it will probably take many years, trials, and appeals before one has a clear understanding of which restrictions are enforceable and which are not. In the meantime, publishers of defective products will be able to intimidate people who cannot afford to sue by quoting their nondisclosure terms in their contracts and threatening to sue if the person publishes a critical article. (Such threats have been made.)
  • UCITA will let publishers ban reverse engineering. This is just another contractual use restriction (102(a)(20)). See the discussion of these in the previous point. There are many legitimate reasons for doing reverse engineering, such as figuring out how to make one product compatible with another, figuring out how to work around product defects, and figuring out how to fix the product’s defects. (See Kaner 1998 for discussion and a list of other examples.)
  • Finally, by making it easy for publishers to hide the terms of their contracts until after the sale, UCITA makes it hard for customers to compare several types of terms. For example, when customers buy a program, do they know whether that publisher’s warranty is better than its competitors’? What does the publisher charge for support compared to its competitors? What are the customers’ rights to arrange for third-party maintenance of the product? Can they write critical reviews of it? These terms might affect customers buying decisions, but not if they cannot find them until after they have paid for the product.
CONCLUSION

This article focuses on UCITA’s impact on software quality, but UCITA has many other serious problems involving electronic commerce and intellectual property rights. For more details or to offer help, please write me at kaner@kaner.com.

Sidebar: Some Organizations That Oppose UTICA

Opp_UCITA_tn.gif

REFERENCES

Hatton, L. 1995. Safer C: Developing software for high-integrity and safety-critical systems.New York: McGraw-Hill.

Kaner, C. 1996. Quality cost analysis: Benefits and risks. Software QA 3,no. 1: 23. Available at www.kaner.com/qualcost.htm. Kaner, C. 1998. Article 2B and reverse engineering. UCC Bulletin (November): 1. Available at www.badsoftware.com/reversea.htm. See also “The problem of reverse engineering,” Software QA. Available at www.badsoftware.com/reveng.htm.

BIBLIOGRAPHY

Braucher, J. 1999. Why UCITA, like UCC Article 2B, is premature and unsound. UCC Bulletin(July). Available at www.2BGuide.com/docs/0499jb.html .
Copyright 1999 Cem Kaner.

BIOGRAPHY

Cem Kaner is senior author of Testing Computer Software.He has worked with computers since 1976, doing and managing programming, user-interface design, testing, and user documentation. Through his consulting firm, KANER.COM, he teaches courses on black-box software testing and consults to software publishers on software testing, documentation, and development management. Kaner is also the founder and cohost of the Los Altos Workshop on Software Testing. He is writing a book,Good Enough Testing,with James Bach and Brian Marick.

An attorney whose practice is focused on the law of software quality, Kaner usually represents customers and individual developers or small consulting firms. He is active (as an advocate for customers, authors, and small development shops) in several legislative drafting efforts involving software licensing, software quality regulation, and electronic commerce. He is the coauthor of the book Bad Software: What to Do When Software Fails(John Wiley and Sons, 1998).

Kaner holds a bachelor’s degree in arts and sciences, a doctorate in experimental psychology, and a law degree. He is an ASQ certified quality engineer. He can be reached at the Law Office of Cem Kaner, P. O. Box 1200, Santa Clara, CA 95052 or by e-mail at kaner@kaner.com.

Featured advertisers

Article
Rating

(0) Member Reviews

Featured advertisers





ASQ is a global community of people passionate about quality, who use the tools, their ideas and expertise to make our world work better. ASQ: The Global Voice of Quality.