What is a Serious Bug? Defining a "Material Breach"
of a Software License Agreement
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: Definition of a Material Breach of a Software License Agreement
Date: December 10, 1996
A software defect is a "material breach" of the contract
for sale or license of the software if it is so serious that the
customer can justifiably demand a fix or can cancel the contract,
return the software, and demand a refund. The ABA's, Section on
Patent, Trademark, & Copyright Law, Committee on Computer
Programs (Model Software Licensing Agreement, 1992) calls
these Material Bugs. I'll use the same phrase.
If a defect is not "material" then the customer is
probably stuck with the program and entitled to, at most, a partial
How should we decide whether a bug is serious enough to be
The July (and previous drafts) of Article 2B
Here's the proposed definition of a material breach of the
software contract in July, 1996 (and in several previous drafts).
Look closely at (c), which defines a material breach by listing
examples. All of these protect the publisher from breaches of
the contract by the customer. For example, the customer is in
trouble if s/he (1) discloses the publisher's confidential information,
(2) pirates the software, or (3) doesn't pay for the program.
None of these helps the customer argue that a given bug is material.
The September and November Drafts
The September, 1996 draft added a further clause to the list.
A breach is also material if it involves:
In September, I asked Ray Nimmer what this means. What is an
"express performance standard?" Is it any precise, verifiable
statement about the program that the seller makes to the customer?
For example, can the customer get a refund if the program fails
to match the written documentation?
He said, no, that's not what he meant. He was referring to
the specific promises that were contained in a negotiated contract,
that said that the program must do specified things or
have specified characteristics.
So I said that this is unfair. What about customers who don't
have negotiated contracts that specify all the right things? What
about mass-market customers? If the program doesn't work, don't
these customers have any recourse?
Ray said that this is a genuine problem. But he doesn't know
how to solve it. How should we define material defect when
the bug is not a direct nonconformity with an important part of
Then he said to me that I was the person who kept raising these
issues, so maybe I could take a crack at drafting the definition.
And I promised that I would. Not that I claim any particular
experience or skill in statutory drafting. I hope and trust that
you will read this proposal for the idea it contains and recognize
that its awkwardnesses will be cleaned up during the Article 2B
How Should We Define a Serious Defect?
Failure to conform to specifications is a common theme in legal
books, but many of the software development contracts provide
vague, incomplete specifications that will change over time without
being updated in the contract itself. Discussions within the software
development community consistently recognize that most failures
in commercial software products are due to errors in the specifications
or requirements. A widely used number is that 80% of the money
spent fixing or dealing with software problems can be traced back
to requirements errors.
As a result, texts that focus on software errors don't limit
themselves to failure to meet a specification (this type of failure
is called nonconformance). Here are some examples from
well respected texts in the field:
Whether or not the specification or user documentation addresses
the following issues, all of them should be considered material
bugs, shouldn't they?
- the product doesn't work at all
- the disks are blank
- the product caused substantial harm to the property or the
business of the licensee
- the licensor supplied a product that lack promised or advertised
features or capabilities
- the software deprives the customer of a key benefit that
she reasonably expected (for example, anyone would expect a word
processor to be able to print and it's unreasonable if a particular
one can't provide that benefit)
- the customer spent so much time, effort, and money dealing
with a bug that the customer's costs exceeded the cost of the
product. (If you think that this isn't a serious enough loss
to the customer, what if the customer's losses run at ten times
the cost of the software, or one hundred times the cost? At some
point, the amount of the losses caused by the software becomes
excessive, doesn't it?)
Reflecting the Relationships Between Licensor and Licensee
One of the crazy-making issues in product development is the
question of who should bear the risk for an error in the understanding
of the customer's requirements.I don't think that there is a simple
answer to this question that is fair and reasonable. Instead,
I propose that we think about four common classes of software
transaction. I propose specific rules for each case. Perhaps I
am proposing the wrong rules, but my fundamental point here is
the contention that these four classes deserve their own rules.
- 1. The customer writes the specifications and requirements
and asks the developer to write a program as specified.
In my view, the software developer meets its obligations if
it writes a program that meets the specifications. If the specs
say "2+2=5" then the program does not breach the software
contract if it generates the wrong answer (5) whenever it adds
2+2. Let the specifier beware.
2. The developer writes the specifications and requirements,
in preparation for custom development, but the customer is sophisticated.
If the customer is a computer expert, then it is able to review
the requirements and specifications just as well as the staff
of the developer. The customer is also probably in a better position
to understand its own requirements than the developer. Therefore
it is reasonable to hold this customer accountable for reviewing
Article 2 of the current Uniform Commercial Code defines a
"merchant" as follows:
2-104 (1) "Merchant" means a person who deals in
goods of the kind or otherwise by his occupation holds himself
out as having knowledge or skill peculiar to the practices or
goods involved in the transaction or to whom such knowledge or
skill may be attributed by his employment of an agent or broker
or other intermediary who by his occupation holds himself out
as having such knowledge or skill.
2-104(3) "Between merchants" means in any transaction
with respect to which both parties are chargeable with the knowledge
or skill of merchants.
Article 2B uses essentially the same definition:
2B-102 (26) "Merchant" means a person that deals
in information of the kind, a person that by occupation purports
to have knowledge or skill peculiar to the practices or information
involved in the transaction, or a person to which knowledge or
skill may be attributed by the person's employment of an agent
or broker or other intermediary that purports to have the knowledge
When Microsoft buys Apple computers, it is a merchant. When
a large, local hospital buys a bunch of Apples, it might be a
big business, but it is not a merchant. In these situations,
I would treat a hospital as a merchant if it retained an independent
consultant to review the specs, etc.
3. The developer writes the specifications and requirements,
in preparation for custom development, but the customer is not
When doctors, dentists, insurance brokers, small grocery store
owners, and other small business people buy software, they have
no clue how to specify the software, no clue how to evaluate
a requirements document, no clue how to test the software, and
no clue how to cost-effectively find a consultant who has these
skills. In common computer parlance, these customers are called
In UCC parlance, these customers are non-merchants.
These customers rely on the knowledge and experience of the
developer. If the developer makes errors in defining the requirements
or the specifications, which result in serious errors in the
operation of the program, this is the developer's bug, not the
4. The developer writes a mass-market product. The customer
has no input into the design or development of the product.
In the mass-market case, design errors belong to the developer,
and never to the customer. Internal specifications that were
used during development are largely irrelevant to the customer.
The end product works in a reasonable way, and as advertised
and as documented, or it does not.
The Proposed Statutory Language
This language expresses my sense of the fundamental differences
between these transactions.
|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.
The articles at this web site are not legal advice. They do
not establish a lawyer/client relationship between me and you.
I took care to ensure that they were well researched at the time
that I wrote them, but the law changes quickly. By the time you
read this material, it may be out of date. Also, the laws of the
different States are not the same. These discussions might not
apply to your circumstances. Please do not take legal action on
the basis of what you read here, without consulting your own attorney.
Questions or problems regarding this web site should be directed
to Cem Kaner, email@example.com.
Last modified: Sunday October 26, 1997. Copyright © 1997,
Cem Kaner. All rights reserved.