[ Main | List of Articles | Bad Software | UCC 2B | Law of Software Quality | Digital Signatures | Bookstore | Court Cases | Links | Press Releases | About Us | What's New ]
Copyright © Cem Kaner, 1996. All rights reserved.
(This memo was written for the January 10-12, 1997 meeting of the Article 2B Drafting Committee.)
To: Article 2B Distribution
From: Cem Kaner
Re: Remedies provisions of Article 2B
Date: December 10, 1996
Article 2B provides virtually no remedies to the mass-market
customer, while providing significant remedies to the mass-market
licensor. This document suggests some ways to rectify this imbalance
without imposing impossible burdens on licensors.
In my view, the fundamental imbalance between licensors and
licensees lies in the remedies available to both. There are no
realistic remedies for mass-market customers and, therefore, this
law provides them with no rights.
NOTE: I have separately forwarded suggestions to Pat Fry on
examples of losses and expenses suffered by mass-market software
customers. I am not distinguishing between different types of
consequential losses here because I am awaiting Pat's next proposal.
I am hoping that this memo will complement, rather than conflict
with, Pat's analysis.
As drafted, Article 2B allows the mass-market licensor to exclude
all liability for consequential and incidental losses. (2B-706(d).)
The mass-market customer is not entitled to a cure (2B-618(b))
Additionally, the customer is not even entitled to a refund unless
the errors in the software are "material."
Article 2B allows the licensor to bury these terms in a statement
of the license (calling this a License "Agreement" is
a misuse of the language) that the customer will only see after
paying for the software, taking the software back to her home
or office, and beginning to load it on her computer. The customer
is deemed to have accepted the terms of the agreement if she (or
her secretary) presses the <Enter> key to continue installing
the software when the installation program displays a few lines
of the license and calls for an <Enter> or mouse-click on
"I agree" to complete the installation.
It is now common practice to charge customers for support calls.
A software publisher might charge $3 or $5 per minute or might
charge $25 to $100 (or more) per "incident". These rates
can add up. For example, calls about device compatibility or operating
system configuration problems can take an hour. (Data reported
at OpCon West '96 by a Microsoft representative indicated that
calls involving MS Office 95 and printer-related issues had been
averaging over an hour per call. This accords well with my experience
with other products.) Some publishers will refund the charge if,
in their opinion, the customer is calling about a known bug. However,
not all publishers do this. (I don't choose to single out companies
here, but managers at well-known software companies have personally
assured me that they do not refund customer call charges in the
event of a call over a known bug, or they don't do so unless the
customer makes a fuss about it.) Call centers are under significant
pressure to become profit centers in their businesses, and it
is difficult for them to grant credit to customers for bugs that
result in many phone calls or long phone calls. Finally, several
publishers outsource some or all of the support function to third
parties. The billing / reimbursement arrangements between publishers
and third party support organizations can be complex and may make
it uneconomical for the third party to provide support for specific
problems when the customer will not pay for the call.
The cumulative cost of the calls to report a bug, seek
help, and ultimately to demand a refund because of a material
bug can easily exceed the cost of the software itself. A refund
under these circumstances is a purely illusory remedy. It would
have cost the customer less to silently accept the breach and
throw the software away than to report the bug and demand a remedy.
Additionally, when the customer calls complaining about a serious
bug, the publisher may or may not admit that the bug is material.
Representatives of the publishers trade associations have attempted
to get the drafting committee to agree to insert a provision that
states that a disclaimer of all warranties, express and implied,
is not unconscionable -- even though the publisher cannot disclaim
its express warranties. Such purported disclaimers of express
warranties are common in software licenses. These serve to prevent
claims by customers by misleading them about their rights. Why
should we expect publishers to be any more forthright than this
in post-sale, verbal dealings with customers?
The cost of proving that a defect is material can easily
exceed the purchase price of the software.
Software publishers impose other transaction costs on customers who have defective products. For example:
These examples are by no means exhaustive. When we declare
in statute that a licensor's limitation of remedies to a refund
is valid, even if this would not be a "minimum adequate remedy",
we create an environment in which the licensor is encouraged to
follow its own cost/benefit analyses in determining whether or
not to provide even a refund.
Recommendation: Article 2B should follow Article 2 and
provide the licensee with a "minimum adequate remedy."
The amount and nature of such a remedy could vary appropriately
under the specific circumstances.
Under 2B102(a)(17) "Incidental damages"
Publishers' representatives have regaled us with the potential
harms of allowing compensation for consequential damages. They
state that they are concerned because:
These concerns don't apply for incidentals. The amounts involved
are generally small. If they skyrocket, it is usually because
the publisher is requiring the customer to jump through hoops.
The publisher can thus manage the size of the loss by managing
the responsiveness of its customer support organization.
Recommendation: Revise 2B-706(d) as follows (deleting
incidentals):
In the mass-market contract, the licensor sets the terms and
reveals these to the customer after the sale has taken place.
The customer has no opportunity to negotiate the terms. Very few
non-lawyers will understand the consequences of these terms.
Article 2B allows the licensor to exclude incidental and consequential
damages, restricting remedies, for example, to repair, replacement,
or refund. As 2-719(b) makes explicit (and see Reporters' Notes,
2-719, Note 3), if the limited remedy fails of its essential purpose,
the customer does not have recourse to the default remedies. As
far as I can tell, in this case, the customer is simply cheated
out of his money, with no remedy available.
In contrast, the UCC builds in several default remedy provisions
for licensors, that the licensor will not exclude. In the bargaining
structure created under Article 2B, the customer has no opportunity
to exclude these damages.
Here are some examples:
I don't understand what public policy is served by a law that
will predictably and inevitably provide consequential damages
only to licensors. It is true that licensees can often limit their
exposure to the risk of consequential damages by not revealing
confidential information and by not breaching the contract in
other ways (such as by breaching the restrictions on use, location
of use, identified users, etc.). But it is just as true that the
licensor can limit its risks by not knowingly shipping products
with serious bugs and by not otherwise knowingly breaching its
contracts. Why give licensors a break -- why create a law that
makes it trivially easy for licensors to give themselves a break
-- while making it virtually impossible for licensees to limit
their own liability?
Recommendation: Revise 2B-706(d) as follows:
Publishers' representatives have protested that they cannot
be required to pay consequential damages because whenever they
release a product, they would be betting their business on the
non-occurrence of serious bugs in the code. It is impossible to
find all bugs in any non-trivial program. (It really is impossible
to do this. For now, check my book, Testing Computer Software,
ITCP 1993. I will also be writing an explanation of this problem
for a non-computer audience within the next few months.)
Given that it is impossible to find every bug, a publisher
who can be held fully accountable for every bug will go out of
business. We risk killing the industry with an unrestricted consequential
damages risk. That result would not serve customers any more than
it would serve licensors.
On the other hand, most (probably all) software publishers
"defer" (decide not to fix) many bugs that are discovered
during the development process. Some of these are very serious.
If the publisher can reasonably foresee the consequences of a
bug that it is knowingly leaving in a product, I don't see why
we should force the customer to absorb those consequences. The
publisher can limit its risks very easily, by fixing the bug.
Recommendation: Revise 2B-706 as follows:
Beyond raising this issue, I don't yet have valuable comments
to make about Problem 5, so I'll stop here.
Thank you for considering this analysis.
| Cem Kaner attends Article 2B meetings as an observer. He consults on technical and management issues, practices law, and teaches within the software development community. His book, Testing Computer Software, received the Award of Excellence in the Society for Technical Communication's 1993 Northern California Technical Publications Competition. He has managed every aspect of software development, including software development projects, software testing groups and user documentation groups. He has also worked as a programmer, a human factors analyst / UI designer, a salesperson, a technical writer, an associate in an organization development consulting firm, and as an attorney (typically representing customers and software development service providers). He has also served pro bono as a Deputy District Attorney, as an investigator/mediator for Santa Clara County's Consumer Affairs Department, as an Examiner for the California Quality Awards. He holds a B.A. (Math, Philosophy, 1974), a J.D. (1993), and a Ph.D. (Experimental Psychology, 1984) and is Certified in Quality Engineering by the American Society for Quality Control. He teaches at UC Berkeley Extension, and by private arrangement, on software testing and on the law of software quality. |