The Uniform Commercial Code (UCC) is America's dominant source of commercial law. All 50 States have enacted all or most of the UCC. The UCC covers such matters as contracts for sale of goods, warranty law, funds transfers, security interests in goods, etc.
Article 2B will be a significant addition to the UCC. Drafts of this complex statute run over 200 pages. When it is adopted by the States, as are most revisions to the UCC, it will become the dominant source of American law that governs software contracts.
I like the idea of Article 2B because it captures several thorny legal problems, that are currently governed by different clusters of law, under one conceptual framework. At last, contracts for the development, sale, and support of software and of the content (data) on the disk will all be covered by one law. Simplifying and clarifying the law is good for everyone, and Ray Nimmer has done a remarkable job in this respect.
I also like the idea of 2B because it creates uniformity in the laws across states. Alabama, California, New York, Texas, and Virginia, all have different rules for fair trade practices and consumer protection. The differences reflect the different cultures of these states. But when a company does business nationally, as many software publishers do, the variations in law create problems and waste. It makes business much easier for everyone if there is one law that applies in all states.
When we reduce uncertainty in the law, either by clarifying the law itself or by resolving differences among different states' laws, we cut down on the opportunities for legal abuse, on the need for huge expenditures on legal research, and on unfair surprises to buyers and sellers. Contracts can be more certain, and software can sell for less money.
Unfortunately, I think that the implementation of Article 2B is seriously flawed. I believe that it will change the balance of rights that the original UCC struck between customers and sellers. As I read the drafts, they resolve ambiguities in current laws in favor of software publishers, and against customers and small developers. In my view, this will substantially reduce a seller's legal and competitive exposure for shipping bad software. Therefore, many companies will spend less than they spend today to prevent, find, and fix bugs because it will now cost them less when they ship defective products to customers.
I can't give you enough information, in a brief, lunch-time presentation, to lay out all (or most) of the problems. I may not be able to give you enough information to determine whether my concerns are well-founded or not. But I hope that I can motivate you to participate in this process.
You can download the latest draft of Article 2B (including its preface) from
You can download several public comments on Article 2B at
You can download several criticisms of Article 2B, with some articles written for a software development community audience, at my web site,
The meetings of the Article 2B Drafting Committee are open to the public. You can attend, and you can speak. Also, your State legislature will welcome your comments after Article 2B is introduced in your State. If you don't have the time to work on this yourself, you can at least send a message to your professional societies, begging them to get involved and to advocate for quality and integrity in this law.
If we stay silent, our careers and our professions will be governed by rules that we chose not to attempt to improve.
I won't spend further time summarizing 2B here because it's so well covered in Ray Nimmer's Preface to Article 2B, which should be in your materials. Ray is the Reporter of the Drafting Committee, which means that he is the primary author of the drafts. This Preface provides an excellent, detailed overview of Ray's vision of the scope, content, and purpose of Article 2B. By the way, even though I will strongly disagree with much of what Ray has to say today, you should understand his stature in the legal community and the respect that all of us have for him. His book, The Law of Computer Technology, is widely regarded as the leading treatise in the field.
Let me start with an example from a recent court case, MAI Systems Corp. v. Peak Computer, Inc. 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 MAI's license restricted use of the software to not more than three of the customer's "bone fide employees." Even though Peak was working at the customer's 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, Peak's use of the software was a violation of the terms of MAI's license, and was therefore a copyright infringement.
This was, and continues to be, a controversial decision. But this case is cited in the Article 2B notes as an example of permissible license restrictions. It is talked about in the 2B meetings as good law. In other meetings, it is often called a misuse of copyright.
The reason that MAI can do this is that it provides the software under a license. Under a license, you can set rules on how people use your product, including restrictions that would be unreasonable, as the MAI restriction would be, if we had a sale of a copy of the software rather than a license of it. The sale of the copy is governed by federal Copyright law, not state licensing law, and great effort has gone into the Copyright Act to balance the rights of publishers and users of information.
Here are some of the other restrictions in MAI's license:
Reverse engineering, even for the purpose of making this product interoperable with some other product, is prohibited. Again, these restrictions are controversial. Even the contract handbook of the Software Publishers' Association acknowledges that restrictions on reverse engineering might be invalid and unenforceable. 
Article 2B (2B-310 and 2B-601(e))
Even though some (for some restrictions, perhaps most) courts would not enforce these restrictions today, once they are written into the Uniform Commercial Code, most or all courts will enforce most or all of the restrictions.
The reason that Article 2B permits such a wide range of restrictions is that 2B is premised on the belief that parties should be free to draft whatever contract they want. That is, the Drafting Committee for 2B believes in Freedom of Contract.
Freedom of Contract was a fine tradition in licensing law, back when licenses were negotiated deals between two different sophisticated parties, each of whom used a licensing lawyer. The buyer and the seller can take care of themselves in these deals. The only obligation of the law should be to protect the deal that was actually made by the parties.
Unfortunately, Article 2B is set up to apply these rules more broadly, to transactions that most of us would think of as being more like sales than like traditional licenses. Article 2B extends licensing law to all transactions in software, even to non-negotiable mass-market transactions-you buy a computer game in a store. Under current law, these transactions would probably be called sales of consumer goods.
Freedom of Contract is a fine buzz-word, that you'll see often in the Article 2B notes. My problem is that I think of freedom as a relative concept - freedom for who? At who's expense? When you create a freedom of contract system to govern transactions between big players and small ones, what you create is freedom of contract for the big ones to foist unfair terms on the small ones.
The restrictions on use are harsh, but maybe they are acceptable in a big contract that was carefully negotiated. Unfortunately, we also see terms like these, and other difficult terms, on the shrink-wrapped pieces of paper that fall out of the box when you buy a word processor or some other mass-marketed software.
Until very recently, courts viewed these terms with suspicion. The terms of the contract for a normal sale are set when you pay the money and take the product away. Terms that are hidden inside the box don't necessarily become part of the contract. For example,
Step-Saver is an interesting case because early drafts of Article 2B frankly stated that "This section reverses Wyse Technology v. Step-Saver."
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.
After buying (Article 2B would say "licensing") several copies, 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:
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. 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" and that it conforms "to the promise or affirmations of fact made on the container or label." 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 conspicuous 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 can't see it before paying for the product. A shrink-wrapped inside-the-box disclaimer can't be conspicuous at retail either (unless you have X-ray eyes). Therefore under Article 2 of the UCC, the purchase agreement does not include the warranty disclaimer and therefore it does not exclude the warranty of merchantability.
Article 2B provides software publishers with a means for making every term in a shrink-wrapped license enforceable against the customer who never saw the license before the sale, including post-sale warranty disclaimers. This is new. It provides tremendous potential for mischief, and for the imposition of extremely unfair terms on the customer. I work through the details of the mass-market license and of manifest assent in two recently published papers that you can find on my web site. Here, I want to continue my focus on the software publisher's responsibility to the customer.
Article 2B creates a distinction among three categories of customers. There are consumers, mass-market customers, and ordinary customers. As an example of the application of the distinction,
Under Article 2B,
Other statutes define consumer goods instead of consumers. For example, under federal law (the Magnuson-Moss Warranty Improvement Act), a consumer product means any tangible personal property which is normally used for personal, family, or household purposes. "Normally" doesn't mean "usually." It just means that some customers (not necessarily the majority) buy this product for personal, family or household use. Anyone who buys such a product, unless they buy it only for business use, qualifies as a consumer. States have modeled their consumer protection laws on this statute, so they usually use the same definition.
Most or all of Article 2B's mass-market transactions would count as consumer transactions under the standard consumer protection laws. So would many other transactions that don't qualify, in 2B, as consumer or mass-market transactions.
Unfortunately, by defining software transactions as licenses, software products are defined as non-tangible personal property. This is an area of ambiguity in the law today-most software transactions are currently covered under Article 2 of the UCC, which is the law of the sales of goods. This is because courts classify software transactions as transactions in goods and then apply Article 2. Article 2B resolves the ambiguity by declaring the transactions as licenses, not sales, in which an intangible right to use the software is bought, rather than some tangible property.
As Thomas Smedinghoff put it in his book, The SPA Guide to Contracts and the Legal Protection of Software, If the Magnuson-Moss Act "applies to software at all, it only applies when software is sold and only in situations where the software is a 'consumer product.'"
By defining software transactions as licenses, we take them out of the scope of state and federal consumer protection law, eliminating the law's safety net for consumers.
The following terms deal with quality-related obligations of the publisher to the customer. They are easy to include in the license. In some cases ("consumer" or "mass-market"), the term has to be "conspicuous" which means that it has to be shown to the customer while she installs the software and she has to click OK (or take the software back for a refund). If she clicks OK, the term is fully enforceable:
There is an old legal maxim, "There is no right without a remedy." As a customer, you don't have any rights (such as the right to software that works) unless you have some way to make the publisher give you working software or reimburse you for your losses, caused by the software. Article 2B allows the publisher to make it almost impossible for a customer to sue. If the customer does sue, or go to arbitration, and wins, the publisher can make it almost impossible for the customer to collect any damages, beyond a refund for the software.
I have never heard trade association representatives acknowledge in the Drafting Committee meetings that legitimate customers sometimes have serious problems with software. The draft itself (comments after 2B-601) defines "bugs" as minor defects, and spends almost no time exploring ways that software errors can be serious.
The fact is that many customers have tremendous problems with software. It is almost deliciously ironic to review materials by Albert Stark, president of an information technology support services consulting firm, who lays out some of the problems that software support staff encounter when they try to buy and install problem management systems. In a series of slides titled "The Seven Stark Realities," Stark points out that
In a parallel session at the same conference, a software publisher's VP of Operations asked an audience largely composed of software publishers' technical support staff how many of them would trade in their problem management system if they could. Over half the attendees raised their hands.
This all sounds like pretty terrible software, even more so because these are the support staff, the people who help everyone else cope with bad software. If they are tremendously frustrated with their software, imagine how normal humans must feel.
But that doesn't mean that these people can get their money back for this software. They can't get their money back unless the softwawre is sufficiently terrible.
James Bach and Ed Yourdon talk about "good enough software" as software that is of sufficient quality to satisfy the customer's requirements. The idea of good enough software is that it is OK to ship software with some bugs, so long as the overall product is good enough for the customer. I don't like the phrase ("good enough software"), but I agree that it is normal practice for software developers, including highly ethical developers, to appraise the bugs they find and to choose which bugs to fix and which ones to defer (leave unfixed).
But there's a big difference between shipping "good enough" software and shipping the minimum that you can get away with.
Article 2B lays out a low minimum. Informed by many people (including me) that it is impossible to be sure that you've found the last bug in a program, the Drafting Committee says that software is acceptable if it substantially conforms to the contract. This sounds like "good enough" software, until we define substantial conformance (2B-102(a) (37)) to mean "performance of an obligation in a manner that does not constitute a material breach of contract." Material breach is defined in 2B-108 to mean a very serious failure that substantially deprives the other party of the benefit she expected under the contract.
If the program has lots of bugs, but is not terrible, the customer can only get a partial refund. She is still stuck with the software.
If the program is seriously flawed, the "material breach" requirement still gives the publisher a lot of wiggle room to argue that the software might not be very good, but it is not terrible enough to warrant a refund. (You might be entitled to other damages, but not if the license excluded incidental and consequential damages. For a "non-material" breach, no matter how unhappy you are with the product, the publisher will probably be able to legally keep you down to a partial refund, and not necessarily a very big one.
For those of you who fear that "good enough" isn't, welcome to a legal regime that lives on "not terrible enough" software.
Article 2B doesn't have to work this way. The phrase, "freedom of contract," is comfortable but it doesn't capture the effects of the law or the alternatives. The fact is that laws create incentives. What incentives does Article 2B create and what should it create?
In Article 2B, we have a choice about who to protect:
Training in quality engineering often harps on the theme that we should seek to optimize quality-related costs over the life of the product. The quality-related costs fit into four categories:
A little money for prevention can save a lot of external failure costs.
The incentive for preventing, finding, and fixing bugs is to avoid all those failure costs. However, if we drive down the failure costs in some other way, we reduce the incentive to invest in better process, better design, better programming, better testing, and better fixing. One way to drive down external failure costs is to reduce technical support costs through a call avoidance strategy. The goal of "call avoidance" is to reduce the costs of calls. You can do that in four ways:
The more capable we are of coping cheaply with complaining customers, the more bugs we can afford in the field (so the sooner we can ship the software).
Evasion is a dismayingly common strategy, but it makes some customers angry. The angrier you make customers, the more money you lose over the long term. There are some ways to estimate these costs, but many executives still dramatically underestimate them. Especially if they don't have much competition, or if the competition that they have is just as bad as they are. So, evasion has remained a common strategy.
Remember that the typical lawsuit-filing angry customer didn't just buy crummy software. He then called for support and got treated so badly that he said, "I'm going to sue the [expletive deleted]." A lot of people are getting angrier.
You drive the costs down further if you make it, for all practical intents and purposes, impossible or worthless to sue. For all practical intents and purposes, Article 2B will make it impossible or worthless for customers to sue for bad software, even for serious bugs that the publisher knew about when it shipped the software.
Some time ago, I consulted to a company that sold software applications for $500,000 and up. Their customer satisfaction data were appalling-only 62% of the customers were satisfied with the reliability of the software; even fewer were satisfied with the usability, and less than 30% liked the user documentation. I asked why the numbers were so low. I also asked why the company was trying to make testing go faster and cost less, instead of trying to improve customer satisfaction. They answered honestly. They said that they benchmarked their competitors and their customers were even less happy.
For a while, under the right legal framework, companies like these can prosper.
I was born in Detroit and raised near there. The laws protected the car companies from their customers. And the companies prospered. Until two disasters hit the industry:
No one pays me to go to these Article 2B meetings or to speak at conferences like this. I've lost business because of this work. To the best of my knowledge, I haven't gained any business because of it, and I don't have a business model that says that I will gain. I've spent a significant portion of my income on this Article because I think it is fundamental to my profession, my career, my industry, and my community.
You are welcome to disagree with my analysis. My appeal to you is to get yourself educated, to make up your own mind, and to advocate for whatever it is that you believe will foster integrity, quality, and long-term prosperity in our industry.
|Cem Kaner consults on technical and management issues, teaches, and practices law within the software development community. 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 (at different times representing consumers, drafting development contracts, and prosecuting criminals). He has also served as an Examiner for the California Quality Awards and an investigator/mediator for a California county's Consumer Affairs Department. He holds a B.A. (Math, Philosophy, 1974), a J.D. (Law, 1993), and a Ph.D. (Experimental Psychology, 1984) and is Certified in Quality Engineering by the American Society for Quality Control. His book, Testing Computer Software (2nd Edition, ITP, 1993, with Jack Falk and Hung Q. Nguyen), received the Award of Excellence in the Society for Technical Communication's 1993 Northern California Technical Publications Competition. He teaches at UC Berkeley Extension, and by private arrangement, on software testing and on the law of software quality.|
 Presented at the SEPG 97 Conference, San Jose, CA, March 18, 1997. This paper is slightly modified from the paper that I handed out, in order to include some remarks that I added while speaking at the conference.
Federal Reporter, Second Series, Vol. 991, p. 511, United States Court of Appeals for the Ninth Circuit, 1993.
 MAI, footnote 3.
 MAI, footnote 3.
 Smedinghoff, T. (1993) The SPA Guide to Contracts and the Legal Protection of Software, Software Publishers Association.
 This issue is complex because Federal law overrides State law. The Uniform Commercial Code is passed by the States whereas the key intellectual property laws (copyright, patent, trademark) belong to Congress. A judge who sees a conflict between Federal and State policies will enforce Federal law, but will make an effort to do as little violence to the State policies as possible. To illustrate the conflicts, the main policies (as expressed in statutes, court decisions, and regulations) that protect competition, free speech, and the ability to do reverse engineering, are Federal.
 The United States Court of Appeals for the Second Circuit recently published a decision that generally endorses the terms of shrink-wrapped licenses. Previous drafts of Article 2B were influential in this case-the effects of Article 2B's proposed rules are already being seen. See ProCD v. Zeidenberg, Federal Reporter (1996), Third Series, Vol. 86, p. 1447, United States Court of Appeals for the Seventh Circuit.
 Unless there is a proper disclaimer, the buyer is entitled to express and implied warranties.
 Federal Reporter, Second Series, Vol. 939, p. 91, United States Court of Appeals for the Third Circuit, 1991.
 Vault Corp. v. Quaid Software Ltd. (1988) Federal Reporter, Second Series, Vol. 847, p. 255, United States Court of Appeals for the Fifth Circuit.
 UCC § 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.
 UCC § 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."
 UCC § 2-314(2)(f)
 UCC § 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.
 You can fix this by telling the customer about the disclaimer at time of sale. It's just inconvenient.
 Kaner, C. (1997a) "Proposed Article 2B: Problems from the Customer's View: Part 1: Underlying Issues," Uniform Commercial Code Bulletin, January 1997; Revisions To The UCC: Part 2--List Of Key Issues," Uniform Commercial Code Bulletin, February 1997. Also available on my web site.
 Page 87; Published by and for the Software Publishers Association.
 The draft statute's language governing contracts for support and updates has been significantly revised. I am still thinking through its implications. The prior drafts definitely kept these duties separate from the duty to provide not-terrible-enough software. I believe this is still true if, for example, the publisher defaults on the support contract the day after the warranty period expires for the program being supported. The typical case would have a 30-day warranty and a 1-5 year support contract.
 "Uncovering the Surprises of Problem Management System Implementation." Paper presented at the Support Services Conference East, March 11, 1997
 Bartlett, Mary, "Support Issues Unique to Small Companies." Paper presented at the Support Services Conference East, March 11, 1997.
 Bach, James, "The challenge of 'good enough' software." American Programmer, October, 1995. Yourdon, Ed, Rise & Resurrection of the American Programmer, Yourdon Press, 1996.
 This is a longstanding position for me. See the first edition of Kaner, Cem, Testing Computer Software (TAB Professional & Reference Books, 1988).
 Lawyers will/should recognize this as a standard of actual knowledge or gross negligence, and not as a recommendation to impose consequential liability for simple negligence.
 I published a paper on this, with examples and references: Kaner, Cem. "Quality Cost Analysis: Benefits and Risks", Software QA, Volume 3, #1, 1996, p. 23.You can also find it at http://www.kaner.com/qualcost.htm.
 Goodman, J. "Utilizing Customer Feedback to Measurably Improve the Value of Support" Paper presented to the Software Services Conference East, March 10, 1997.
 Kaner, C., "Liability for Bad Software and Support." Paper presented to the Software Support Professionals Association Executive Briefing, San Diego, October 3, 1996, and to the Software Services Conference East, March 12, 1997. See http://www.kaner.com/support1.htm.
 Brown, D. Optimizing Support Center Staffing, Service Management International, 1996.
 Better Business Bureau, Annual Inquiry and Complaint Summary, 1995, p. 16.
 Read Hunziker, Janet, R. & Jones,
Trevor O. (Eds.), Product Liability and Innovation: Managing
Risk in an Uncertain Environment, National Academy Press,
1994 for a flavor of the aggravation involved in doing engineering
in highly regulated, lawsuit-prone industries.