Bad Software: What To Do When Software Fails.

[ 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 ]

Contracts for Testing Services:

Indemnification and Warranties

This month's column looks at legal issues that confront you when you provide testing services as an independent contractor or as a consultant.²

Contracts for software-related services (programming, testing, writing, etc.) vary widely. Some companies' contracts contain only the basic terms -- the services that you'll provide and the pay you'll receive. Many use standard form contracts that cover a wider range of issues. Some standard forms are designed to provide fair terms without haggling. Others have serious problems that expose you to unreasonable financial risks or unreasonably limit your ability to find other work or use your skills on other jobs.

Unfortunately, testers are suckers for warranty and indemnification clauses that expose them to unreasonable risks. These clauses guarantee the quality of your work and promise that you will pay the company's expenses and losses if certain events take place. Most testers believe that business people, including us, should be accountable for the quality of our services or goods. So, we tend to be a bit more open to the argument that we should guarantee our work.

I think that guarantees are good things -- up to a point. But some companies go well beyond that point in their standard contracts. You must cut those guarantees back to something reasonable or some day you may be badly burned. I'll start this discussion with the Warranty clause because it's probably the most familiar concept to most readers. The Indemnity clause (next section) is the one that contains the nastiest traps. The Limited Remedy clause (final section) is a consulting company's most common general defense.

The Warranty

If you develop a product, you may be asked to provide a warranty that the product is reasonably reliable. Standard-form contracts for custom-programmed software often contain warranty clauses. ³. Here's some language that blends a few contracts that I've seen:

This may be appropriate for a programming agreement, but if the company uses a battery of standard clauses in its software-related contracts, this clause might also creep into a contract for testing services.This doesn't make sense. You can't control the quality of the software. You find the bugs, but you don't fix them. And when was the last time that anyone allowed you to do as much testing as you considered desirable for a product? Any guarantees you make should focus on what you do, not on the quality of the released product.⁴

Here's is an example of a clause that focuses on the quality of your work:

This is just peachy if your client will give you the time and money that you need to provide services that are consistent with the highest industry standards.⁵ Of course, you'll want to avoid ambiguity here. You can best achieve clarity about what the contract means by "highest industry standards" by putting specific references into the contract to specific standards documents. For example, the IEEE publishes a fine collection of software engineering and testing standards for you to use. But if your client won't agree, in writing, to give you the time, staff, and money that you'll need to meet these standards, then you can't agree in writing to meet them, can you?

Ocampo, Curtis, & Moss ⁶ suggest the following language and provide some methods for resolving disputes about what is meant by "generally accepted industry standards."

This might work for you, but not if the client wants you to cut all possible corners in a race against a deadline.

If your client is paying you by the hour ⁷, maybe the best clause looks like this:

Indemnification

Indemnity clauses are often outrageous. When I see one in a contract, I usually cross it out completely. If the company won't accept that, I reword it to something that gives the company narrow protection against carefully specified risks.

An indemnity agreement involves a promise that, if a specified event happens, you give the company money. The most common form of indemnity agreement is called "insurance." If your name is not "Lloyds of London" then you should think carefully about whether it makes any sense whatsoever for you to agree to pay the company a nickel for anything that is not your direct, personal fault or that happens under circumstances that are beyond your control.

Here's an example of a troublesome indemnity clause:

If you test a program, any failures of that program relate to the services that you performed. So, if the program has a bad bug and the company gets sued, you pay. Suppose that you actually found and reported this bug to the company, but it shipped the software anyway. Does this save you? Well, I hope that under the circumstances, a judge would throw out this clause as "unconscionable." If not, then the language of the clause says "relating to" and not "caused by." You're at risk for anything related to your work, not just for the problems you cause. If you reported something as a bug, isn't that proof positive that this bug is in some way related to the services that you performed?

What about hard-to-find bugs or bugs that came into the program late in development. What about bugs that you missed because the schedule was too tight for you to run all the tests the program needed? Should you be liable for these?

Next, suppose that you were at fault. Suppose that you missed a bad bug, and that a different tester might have found it. This clause says you pay everything -- all losses, liabilities, judgments, attorney's fees, court costs, etc. Maybe -- maybe -- you should owe the company something in this situation. But everything? That's ridiculous. You didn't make the bug. You didn't set the development schedule and you probably didn't set the testing schedule. You didn't set the expectations of the now-angry customers by deciding how to advertise the program, what to say on the box, what to say during the sale, or who to sell it to. You didn't fail to take care of the customers when they called the company's technical support center. Even if you were at fault, so is the company, and probably much more at fault, in more ways, than you. Why should you pay everything and the company pay nothing?

Here's another common variation on the all-encompassing indemnity clause:

This is classic insurance. You pay even if there is no bug and no fault. If someone sues, whether they win or lose, you hire the lawyer, you defend the company in the lawsuit, you pay for the company's lawyer so the company can help you defend the lawsuit, and you pay for everything else. Your responsibility is triggered by anything "in connection with this Agreement."

This isn't quite classic insurance, because the standard General Commercial Liability policy doesn't insure a company against warranty claims for defects in its own products. Under this clause, you do. Furthermore, insurance policies have limits -- the insurance company pays up to the limit and not beyond. Under this clause, you pay everything.

Note also that this second example specifies a "breach of any representation or warranty" as a specific basis for holding you accountable. In court, the company can more easily defend its demand for indemnification under this contract if it can prove that the lawsuit is about a bug, and that you probably would have found the bug if the quality of your service had lived up to your warranty. This is why you word your warranty carefully. If you promise more than you can deliver, you can be held accountable for failing to provide services that you couldn't provide.

Here's another one:

Your "obligations" are partially determined by your warranties. If you warrant (guarantee) that you will provide testing services that are consistent with the highest industry standards, you have an obligation to do that level of testing.

I recommend that you flatly and clearly refuse to indemnify the company for claims involving defects in its products, unless the company is willing to give you control of the programming, scheduling, testing, documenting, maintenance, marketing, sales, and post-sale support of the software. If the company insists that you sign such a clause, try one last tactic before giving in (or breaking off negotiations). Ask for a copy of the standard contract that the company provides to its customers. Does the company (your customer) indemnify its customers? Probably not. Does the contract specifically exclude payment for consequential damages? ⁸ Probably so. And if there is an agreement that the company will provide indemnification or consequential damages, you will see that the clause is very narrowly limited to a very small range of circumstances. With this contract in hand, you can gently explain to the company that it is asking you to take risks that no reasonable company, not even it, would take.⁹

If you choose to provide defect-related indemnification, then I recommend that you build in some basic protections:

1. Proportionate liability: You should only pay in proportion to the degree to which you are at fault.
2. Prompt notification: The company must notify you promptly -- within days -- after it is told of a claim that it might want to hold against you.
3. Participation: You should have the right to participate in the defense (i.e. you should be allowed to send your lawyer to all settlement meetings, mediation, arbitration, trial, etc.). ¹⁰
4. Approval: You have to pay all or some of the amount of any settlement, so you should have the right to approve or disapprove any settlement agreement. You will probably have to agree that you won't unreasonably withhold your approval.
5. No Loss, No Liability. You shouldn't have to pay anything if the company wins the case. Your indemnification involves your defective work. If the company wins, where's the defect? You should pay only if you agree to a settlement or if a court judgment or arbitration decision says the company is at fault (and determines your proportional liability).

It is much easier to get agreement on notification, participation, approval, and loss-only liability than it is to get agreement on proportionate liability. But you have a strong argument that anything else is fundamentally unfair. The notion that defendants should only have to pay damages in lawsuits up to the degree that they are at fault is one of the most popular and most sensible "tort reforms" pushed by the American business community. The company's lawyer may despise this provision because it will complicate the handling of any lawsuits, but you are probably negotiating with an engineering manager not with the lawyer. Engineers are less likely to understand or sympathize with a lawyer's litigation-tactics arguments than they are to be impressed by your willingness to accept responsibility for your own errors and by the unfairness of making you pay 100% of damages for a problem that is only partially your fault.

Don't be fooled by the common fall-back variation on these clauses that exempts you from liability in those cases that are "due solely and directly to Company negligence." If you're 1% at fault, and the Company is 99% at fault, these clauses still require you to pay everything.

Indemnification for Employee Personal Injury

Suppose that you are a large testing agency. You send staff to a customer's site to test their software. One of your staff is injured on the job. Who pays? If this person was employed by the company (your client), their Workers Compensation insurance policy would take care of this. But you are an independent contractor and so your staff aren't covered under their insurance. Workers Compensation provides fast, no-hassle, limited compensation for workplace injuries. Under many circumstances, people feel unreasonably limited by the Workers Comp limits and they would rather be able to sue. If your staff can sue the company for injuries on the job, they have broader rights than the company's own staff. It is reasonable for your customer to try to make sure that your employees look to you, and to your Workers Compensation insurance, rather than being able to sue.

You can see this issue as one of the roots of the following indemnification clause:

Note how broadly worded this clause is. If a bug in the company's software causes a death, you pay for it, even if the bug is entirely your customer's fault. Not acceptable.

If you're a big testing lab, you might want to have your lawyer work on cutting a clause like this down to size.

If you're an individual, this clause is unreasonable. You should quote Hancock's advice to corporate counsel "We are now talking about personal injury, and it would be void and against public policy to bar the consultant's right to sue you for a personal injury based upon your negligence" ¹¹ and cross the clause out.

Indemnification for Tax Liability

If you're an independent contractor or a consultant, the company doesn't pay your Social Security taxes, your unemployment insurance, disability, etc. It doesn't send part of your check to the Internal Revenue Service or to your state's taxing authority. The company also doesn't owe you the same rights to fair treatment that it might provide to its employees. To make up for this, the company does pay you more per hour, probably at least 35% more per hour, than it would pay to comparably skilled full-time employees.

Suppose that a tax authority audits this company and determines that you were really an employee, not an independent contractor. It might fines the company. The company will have to pay back taxes, insurance premiums, etc. What should happen to you?

Here's what you're likely to see in the contract (if you see anything):

This clause is not outrageous, but it covers a bit too much. Some clauses go further, covering fines, attorney's fees, accounting expenses, etc.

You might agree that it wouldn't be unfair for the company to recover from you the amounts that it has to pay as employee benefits. After all, the company paid you extra so that you could cover these things yourself. However, if you didn't misrepresent your situation to the company, you shouldn't be liable for fines or late payment penalties or other expenses that go beyond what the company would have paid as employee benefits.

In the United States, when a company retains you as an independent contractor, it should make a reasonable effort to ensure that you can be appropriately classified as an independent contractor. The Internal Revenue Service has published a well-known list of factors for deciding whether a person is an employee or an independent. If you don't lie (if you lie, maybe you deserve whatever happens to you), then checking your status against these factors is not rocket science. If you don't meet the criteria, the company shouldn't make you a contractor; it should make you a temporary employee. This is basic Human Resources policy and most companies have somebody on staff who understands these issues a lot better than most contractors. If the company decides to take its risks, either by not bothering to check or by deciding to, or agreeing to, misclassify you, it should accept the consequences.

In practical terms, relatively few companies seem to include this clause, but some are fanatical about it. If you know that you qualify as an independent contractor, you have an opportunity to haggle. Whine about this clause for a while, then reluctantly agree to it if the company will agree to drop some other clause in return.

Indemnification for Intellectual Property Infringement

This last variant is the most reasonable one for a company to demand and the one that you might find hardest to escape. Ocampo ¹² et. al provide a long, thorough version of this clause and an extended discussion. A common short version reads:

According to Ocampo et. al., indemnification for patent infringement is often a negotiation issue because you might not realize that a technique that you're using has been patented. Also, in American contracts, trademark and trade secret infringement indemnification clauses are usually restricted to the trademarks and trade secrets that are held in the United States.

I will sign these clauses, and I advise clients to agree to these clauses, so long as they provide for the basic safeguards (prompt notification, participation, approval, no-loss-no-liability). I've deliberately dropped "proportionate liability" from this list because it is rarely relevant here. Your client company is rarely at fault if you use trade secrets or copyrighted material that you got somewhere else. However, you should not indemnify the company for its use (or your use, as part of your work for the company) of material that was supplied to the company by someone else.

Here's the language that I use:

Limitation of Remedies

With slight wording variations, the following clause is standard in the industry.

The clause is often modified to specify that you are fully responsible for infringement indemnification, but not for any other types of consequential damages.

A refund of all fees is a harsh result for an individual consultant. Losing a year's consulting fees because you missed a bug is pretty serious. If the company thinks you're doing a lousy job, it should fire you, not wait until you've done a huge amount of work and then demand a full refund. You might consider separating out the consequential damages clause and doing this instead:

Now you can haggle separately over the details of the two clauses. You might, for example, agree to pay consequential damages so long as they (and all other damages) are limited to a maximum total of 50% of your fees.

Yes, These Contracts Are Negotiable

Many people are afraid or reluctant to negotiate their contracts, especially if they think that everyone else finds the terms acceptable. Aggressively-worded contracts are drafted with the expectation that a careful person will reject some of the terms. Don't worry about statements that "everybody else just signs this contract." The more outrageous the contract, the more the opposing negotiator will probably insist that "everyone else" thinks the terms are just fine.

At the start of a job, you are in a good position to negotiate. Your basic deal with the company is that you will provide certain testing services in return for payment. The Manager or Director or Vice-President wants those testing services. This stuff about indemnification is bureaucratic blah-blah -- engineering managers don't much care about it and they don't want it to get in their way. Explain your refusal to provide indemnification by reminding the manager that your agreement was to provide testing services, not to sell the company insurance. You'd like to provide testing services, but you can't unless this engineering manager gets these crazy boilerplate demands out of your way. In many companies, including some very large ones, the engineering manager has more than enough clout to get these terms out of the contract.

Some companies are impossible to negotiate with, and you have to decide what level of risk you're willing to accept. Faced with a nonnegotiable demand for broad liability coverage, you can accept the risk (I think this is unwise), reject the contract (this is what I do), or incorporate. The entire point of incorporation is to limit personal liability that could arise from business dealings. You can and should make sure that all risk of liability in your contract is assigned to the corporation and that you have no risk beyond your investment in the corporation. If you go that route, be sure to retain counsel and have her teach you the rules / formalities of running a corporation and signing documents as a corporate representative. Follow these rules scrupulously. Buy liability insurance. And raise your rates (significantly) to cover all this added overhead and hassle of incorporation.

¹R. Ocampo, Jr., S.S. Curtis, & J.J. Moss, Negotiating and Drafting Software Consulting Agreements, Glasser LegalWorks, 1996. (Note: Ocampo is Oracle Corporation's General Counsel and Senior Vice President. Curtis and Moss are also Corporate Counsel at Oracle.)

²This article looks at specific contract clauses and provides several legal suggestions. My intent is to raise issues and to help you avoid some serious traps. But please don't take this as legal advice. Some suggestions may be inappropriate for you, depending on your particular circumstances, and the law in your state or country. If you have questions about your best legal course of action, you should talk to your lawyer.

³For example, look at the warranties in R. Raysman and P. Brown, Computer Law: Drafting and Negotiating Forms and Agreements. Law Journal Seminars-Press, 1984 (supplemented 1996), "8.22 Form: Software and Equipment Development Agreement." See also W. Hancock (Ed.) Corporate Counsel's Guide to Software Transactions, Business Laws, Inc., 1995, Form 223, "Programmer Agreement for Individual Consultants."

⁴A customer might reasonably demand stronger guarantees from a big independent test lab, especially one that promises some form of certification. If your name is National Software Test Labs or XXCAL or Software Testing Labs, I trust that you will rely on your own lawyer's advice and on your own extensive experience in determining how to negotiate, structure, and charge for performance and service guarantees.

⁵W. Hancock (Ed.) Corporate Counsel's Guide to Software Transactions, Second Edition, Business Laws, Inc., 1995, makes this point eloquently. "The standard of performance really should be the complete satisfaction of the company. After all, you [the company] are paying on a time and material basis, and if you want the programmer to redo his work for some reason, you will be paying for that anyway.... If you are arbitrary, unreasonable, and generally engage in 'nit-picking,' you are the only one who will suffer. The programming house will collect its fees regardless." (p. 22.008).

⁶Negotiating and Drafting Software Consulting Agreements, Glasser LegalWorks, 1996, Section 4.01.

⁷Some clients will want you to contract on a fixed-fee basis. You agree to test the program completely, for a fixed rate of $10,000. If you get done early, you make a lot of money. If you get done late, very late, or very, very, very late, all you get is $10,000. This is rarely a wise choice in a testing contract.

⁸ Consequential damages repay the company for losses that are caused by a breach of contract. For example, consquential damages cover lost profits or the cost to re-enter lost data. The damages provided under the indemnification clauses are all consequential damages.

⁹ Ocampo et. al, Negotiating and Drafting Software Consulting Agreements, Glasser LegalWorks, 1996, recommend this trick in their section 6.03.

¹⁰If you are a big company, you might want to provide and control the defense. If you are a one-personal consulting firm, let the company defend itself, but make the company help you defend yourself at the same time.

¹¹W.A. Hancock (Ed.) Data Processing Agreements, Second Edition, Business Laws, Inc., 1996, Section 8.008.

¹² Negotiating and Drafting Software Consulting Agreements, Glasser LegalWorks, 1996, Chapter 5, "Infringement Liability."
 

Cem Kaner 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.

[ 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 ]

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, kaner@kaner.com, P.O. Box 1200, Santa Clara, CA 95052.

Last modified: Tuesday November 11, 1997. Copyright © 1997, Cem Kaner. All rights reserved.