Source: http://badsoftware.com/sepg.htm
Timestamp: 2019-04-22 02:17:31+00:00

Document:
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.
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.
At this point, the vast majority of people who attend these meetings, to advise the Article 2B Drafting Committee, are lawyers. Almost none of them have engineering experience. They are primarily lawyers representing trade groups, such as the Software Publishers Association, the Business Software Alliance, and the American Film Marketing Association, or representing large companies, like Microsoft, Oracle, IBM, Apple, and DuPont Chemical.
At this point, the Article 2B Drafting Committee refers to these lawyers as representing "The Industry." There is no sense in these meetings that, within the industry, there are different viewpoints about what is the best course for us. The notion that the opinions of sales/marketing might not reflect the views of R&D is not even discussed at these meetings.
Imagine your industry being represented by a swarm of lawyers who report to the President of Dilbert's company. How hard do you think these lawyers would advocate for customer satisfaction, or for quality of product, or for rules that make it harder for software companies to lie to their customers, or even about optimizing the law to promote long-term survival (rather than optimizing for this quarter's numbers)?
At this point, IEEE, SPIN, ASQC, HFES, ACM and the other leading professional societies are completely silent on this work.
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.
The MAI case, use restrictions, and the problem of "freedom of contract"
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.
Customer Prohibited Acts . . . Any possession or use of the Software . . . not expressly authorized under this License . . . is prohibited, including without limitation, examination, disclosure, copying, modification, reconfiguration, augmentation, adaptation, emulation, visual display or reduction to visually perceptible form or tampering . . .
allows restrictions on the location and purposes of use of the program. The company can tell the customer what she can or can't do with the program.
allows restrictions on who can use the program, as in the MAI case.
allows restrictions on what the customer can reveal about the program. It can impose a duty of confidentiality on the customer. As far as I can tell, any aspect of the operation of the program (including its user interface, and certainly including bugs that the customer discovers during use of the program) that is not available to the general public, can be declared confidential.
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.
Disclaimer of warranties. The seller says the product is sold "As Is" with no warranty, express or implied. The seller says there is no guarantee that this product can do anything, despite the claims made in the advertisements, on the box, and in the documentation.
The disclaimer may be found in an operator's manual, or in sales literature not sent to the buyer until sometime later, or it may be hidden away in the package that also contains the goods, with no warning on the outside of the package. In all of these cases, it is as though the seller were determined that the buyer should not see the disclaimer until after the fact. Given this seller perversity, it is not surprising that the courts generally nullify such post-contract disclaimers.
California Civil Code § 1790.1 "Any waiver by the buyer of consumer goods of the provisions of this chapter, except as expressly provided in this chapter, shall be deemed contrary to public policy and shall be unenforceable and void."
Judges in software cases have also rejected shrink-wrapped disclaimers in software, as in the case of Step-Saver Data Systems, Inc. v. Wyse Technology and The Software Link, Inc.
Reverse engineering. A shrink-wrapped prohibition of reverse engineering was sharply rejected by a Federal appellate court in 1988.
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.
TSL has raised a number of public policy arguments focusing on the effect on the software industry of an adverse holding concerning the enforceability of the box-top license. We are not persuaded that requiring software companies to stand behind representations concerning their products will inevitably destroy the software industry.
As a matter of public policy, the Uniform Commercial Code (UCC) says that any product comes with a warranty of merchantability unless the seller specifically excludes it. 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.
warranty disclaimers have to be "conspicuous" (even though they can be hidden until after the sale) if the customer is mass-market, but not in non-mass-market situations.
Article 2B lets publishers choose their forum (what state or country a customer will be allowed to sue them in.) According to Section 2B-107, however, if the choice of forum would force a consumer to sue in a place that is far from home, and if the circumstances that would unfairly disadvantage the consumer, and if the purchase wasn't made over the Internet, then the customer gets to sue in his own state. Otherwise (if you are an ordinary customer or a mass-market customer), the publisher can say "you can only sue us in Nairobi" and that term will stand in the contract, even if the publisher and the customer are both based in Seattle.
Very few purchasers of software will qualify as consumers under this definition. Home-based businesses and one-person businesses do not qualify. This is the narrowest definition of consumer that I can recall having seen.
A mass-market transaction involves a non-negotiable software license that is sold in general retail-like distribution, for less than $500, so long as it is not delivered over the Internet, and not to be used by more than one person (so much for multi-player computer games). (2B-102(a)(25)).
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.
no liability for viruses, even for a virus that the software publisher knew or should have known was on the disk. In a recent draft of 2B, this was modified so that the publisher can't escape all liability merely by putting a disclaimer in the license-if the software is mass-market and is not sold over the Internet or otherwise delivered online. By "no liability" I mean that you can't even ask for a refund if a virus from a publisher's product trashes your hard disk. The virus is not a defect.
If the program is sold with a support contract (see 2B-615), but the publisher fails to provide the support, then the customer can be stuck with the software, only getting a refund for the unprovided support. The fact that the customer wouldn't have bought the software without support can be (under Article 2B, but not to the customer) irrelevant.
the publisher can require the customer to arbitrate disputes instead of suing. This generally has the effect that the customer gets less access to the publisher's records (making it easier for the publisher to hide fraudulent or other unlawful acts), and the proceedings are private (no stories in the newspaper to alert other customers that the problems they're having are intrinsic to the product, not just user or configuration problems). Similar clauses in contracts for cars would probably have let Ford hide the problems in the Pinto from the general public. The regulatory backlash against the car industry that arose out of cases like these would never have happened.
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.
"Good enough" software? The 2B criterion is "Not terrible enough."
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 system will not do everything promised."
"System functionality is typically overstated."
"You'll need to purchase additional modules to get the functionality you need."
"Features you need are scheduled for a future release."
"The out-of-box reality is less than expected."
"You'll need to purchase additional hardware."
"The software will be more complex than it appeared during the sales cycle."
"System customization will not go smoothly" even though "Vendors can make customization look easy."
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?
We can protect sellers from unreasonable customers. There are unreasonable customers. Article 2B protects sellers by virtually eliminating seller liability for defects.
Or we can protect customers from unreasonable sellers. This is not such a radical idea. In fact, it's traditional contract law. If I breach a contract with you, I am responsible to you to put you back into the position that you would have been in if I had lived up to my side of the bargain. This is the standard rule.
Unfortunately, this is too risky for sellers. If software publishers can't fully test the code, they can never be sure that they're shipping bug-free software. In the 2B meetings, publishers' representatives are justifiably afraid that this rule could put the software industry out of business.
When the customer suffers losses because of a bug that the software publisher/seller knew about when it shipped the software, the publisher should have to reimburse the customer for her losses. The reimbursement might be for the full consequential loss, or we might cap it at, say, the higher of $500 or five times the purchase price of the software. This might sound harsh, but it's a fully manageable risk if we write the law in a way that makes sellers pay these damages only for known bugs or for bugs that they would have discovered if they'd done even a modest job of testing.
For all bugs, sellers should reimburse their customers for incidental expenses. These are limited damages that don't begin to cover many losses that are caused by software defects. They include the costs of reporting and returning the software (including the $95 per call fee that some publishers charge for technical support). The more the publisher/seller gives the customer the run-around, the bigger these expenses get. Reimbursing the customer for these creates a limited, manageable disincentive to bad software and bad support.
These two provisions would make software publishers less likely to ship software with known serious bugs and less likely to run their customers around, but they don't threaten the industry. Publishers can manage their risk of liability just by doing a modest amount of testing and by not shipping with serious bugs that they know about.
A little money for prevention can save a lot of external failure costs.
evasion (don't answer the phone; busy out trunks; leave people on hold for 2 hours).
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.
A cross-industry study of call hold times showed that complaining software customers were on hold for longer than any other industry, even longer than people calling airlines and government offices.
A press release from the Better Business Bureau put computer-related calls in the top 10 for 1995 complaints to the BBB, even higher than used car dealers.
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.
Customers got so mad about bad cars, and about dangerous cars, that they finally started screaming and suing. The state legislators responded with regulations, more regulations, and more tolerance of a wider range of lawsuits for defective products. When there's a popular uprising, by the way, you can't expect the legislative responses to be thoughtful, patiently studied, and well-optimized to deal with the problem at hand. You get a nightmare of excess regulation, a problem we hear time and again from many other industries.
The farther we let the pendulum swing to favor sellers today, the faster and harder it will swing back, in an inevitable counter-reaction. You might not like working in the industrial culture that that counter-reaction will create.
Toyota came to town and listened to its customers. American customers had so little loyalty to American car makers that 35% of the American market switched to foreign cars. The American car industry suffered hugely from the foreign competition. So did the American mid-West. I keep hearing that the car industry is better again, that it's having golden years as far as profits, but when I go back to Detroit, I still see rubble in the streets.
I live in Santa Clara, at the border of San Jose. For a few months when I first moved to Santa Clara, I prosecuted criminals in San Jose, and toured the troubled parts of San Jose. San Jose looks wealthy today, but it has its underlying problems. And San Jose is no less dependent on information technology than Detroit was on cars. If we're not careful, if we make the same mistakes made by the car industry, 20 years from now San Jose might well look like Detroit.
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.
 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.
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 § 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.
 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.
Last modified: Monday November 10, 1997. Copyright &COPY; 1997, Cem Kaner. All rights reserved.

References: v. 
 § 1790
 v. 
 v. 
 v. 
 v. 
 § 2308
 § 2
 § 1
 § 2