Marc is a patent attorney and shareholder in the intellectual-property law firm of Poms, Smith, Lande, & Rose in Los Angeles, CA. Marc specializes in computer law and can be contacted at 73414.1226@compuserve.com.
Software sometimes doesn't work the way it is intended or expected to. Users may lose profits, have their reputation injured, and demand corrective action.
Particularly with custom software, the original software developer is often targeted as the source of compensation for these injuries. Even if the customer's complaint is without merit, the cost of defending yourself against a lawsuit can exceed the profit you hope to make from your software.
However, there are clauses that you can incorporate into development contracts that can substantially reduce your exposure, and can prevent the misunderstandings that often lead to these expensive lawsuits.
When software crashes and/or damages data, it is obvious that the software is malfunctioning. But liability can also be imposed from a broad variety of less-apparent defects.
For example, liability could be imposed if the software fails to manage an important data field, run on a desired platform, or is incompatible with other software. Objections over speed, memory usage, and ease of use can also form the basis of liability.
These objections usually stem from customer expectations about the software. Clear contract language can control these expectations and limit your legal liability.
Consequently, you should be sure to incorporate detailed performance specifications in the contract. This is one of the best ways to reduce the scope of objections that could form the basis for legal liability. To be most effective, the contract should state that the performance specifications are the sole criteria the software must meet.
With the exception of Louisiana and the District of Columbia, every state in this country has enacted a variant of the Uniform Commercial Code (U.C.C.). These laws impose a broad variety of liabilities and significantly restrict the ability to avoid these liabilities through contract restrictions.
But the U.C.C. does not apply to every commercial transaction--it only applies to the sale of goods by companies regularly engaged in such activity. Software support is usually not governed by the U.C.C. because it is a service, not a product. Mass-produced software, on the other hand, would probably be categorized as goods. Although the purchaser is usually only granted a license, the transaction is usually viewed as sufficiently analogous to the "sale," which the U.C.C. requires. Custom software development has the complexion of both a product and a service, and it is therefore not entirely clear whether the U.C.C. applies to it.
It may be possible to ensure that the U.C.C. is not applied to a software development transaction by stating in the agreement that it is primarily an agreement for service, not the sale of a product. Of course, the agreement will indicate that the customer will be receiving software. But the agreement should indicate that the customer is paying primarily for the service of designing, writing, testing, and improving the software. Language should also be included stating that the parties do not consider the agreement to constitute a "sale of goods" and that it will not be governed by the U.C.C.
A court might ignore such language and still find the transaction to be governed by the U.C.C. The remainder of this column will therefore include a focus on the Uniform Commercial Code.
The most-common legal theory asserted against a software developer is breach of contract. The customer alleges that the developer breached a contract by providing defective software.
Any recitation of performance criteria usually will be interpreted as constituting a warranty that these criteria will be met. This is true even if the contract does not expressly warrant the recited criteria. The developer also may be held to performance criteria that were merely discussed during the course of contract negotiations or that appeared in promotional material. The moral here is simple: Specify performance criteria, but be careful what you say.
When applicable, the U.C.C. implies three additional and significant warranties, even when no assurances are expressly provided.
The first is the implied warranty of "merchantability" --a warranty that the software will be fit for the ordinary purposes for which it is intended and will pass without objection in the trade. Although the concept is imprecise, it can result in the imposition of very broad performance requirements.
The second is the implied warranty of "fitness for a particular purpose." When you know the particular purpose for which the customer needs the software (as is usually the case with custom software), the U.C.C. implies a warranty that the software will be fit for this purpose. The warranty of merchantability will not be breached if the software is working perfectly. But if the software does not fulfill the needs of the customer as they were described to the developer at the incipiency of the relationship, the implied warranty of fitness for a particular purpose will be breached.
The third warranty is an implied warranty that the software will not infringe another's patent or copyright. It's easy to avoid copyright infringement--just don't copy other software! But software can infringe a patent even if the software developer created all of his software independently and was never aware of the patent. This type of liability can be enormous.
One way to avoid express and implied warranties is to disclaim them. The development agreement should state that no express or implied warranty is provided. Such a disclaimer will not be effective against the implied warranties of merchantability and fitness unless these implied warranties are expressly mentioned by name or the contract states that the customer accepts the software "as is" or "with all faults."
When the contract does contain strong disclaimers, their legal effect can sometimes be overcome by an allegation of fraud. The customer alleges that the developer misled the customer by erroneously telling the customer that the software would meet his or her needs.
Fraud will survive the very broadest disclaimer. However, four elements usually must be proven by clear and convincing evidence:
Another way for users to overcome contractual disclaimers is to allege that you are "strictly" liable for the defective software. The phrase "strict liability" means liability without fault. Even though you may have acted with the utmost care, you can nevertheless be "strictly" liable for any defect in the software. Like fraud, it cannot be disclaimed.
Most jurisdictions refuse to recognize this doctrine unless the software was intended for an application that is "inherently dangerous." Software that controls the explosion of a bomb would be one example. Most business software, on the other hand, would not satisfy this requirement.
Another typical limit of this doctrine is that it only covers injuries to persons or property. The more-typical claims for lost profits or injury to reputation are usually not covered.
Another theory sometimes used to overcome contractual disclaimers is "negligence." To establish a claim of "negligence," it is not sufficient to merely prove that the software is defective. There must be proof that the defect is the result of the software developer failing to exercise due care in its development. That the software is defective can serve as evidence of negligence. But it is not decisive. Mistakes can and are often made in the development of software, even though the utmost care is exercised.
Negligence also is sometimes alleged in connection with performance representations. Although the software may be working perfectly, it may not be fulfilling the customer's expectations. When these expectations are the result of performance representations made by the developer, the allegation of "negligent misrepresentation" is sometimes made. As with malfunctioning software, it is not sufficient to simply prove that the representation turned out to be false. The customer must prove that the developer failed to exercise due care when he made it.
Most courts will not recognize a claim of "negligence" when it is being used to recover purely economic losses, such as lost profits or injury to a customer's reputation. As with a claim of "strict liability," most courts will only recognize an allegation of negligence when personal injury or property damage has resulted.
Many customers are not willing to accept sweeping disclaimers. On the other hand, they can understand that the profit that the developer is making is not sufficient to cover exposure to unbounded liability. As a consequence, many customers are willing to accept contractual limits on the amount of liability, even though they are not willing to accept disclaimers eliminating all liability.
One common technique is to limit liability to "direct" damages. These are damages "directly" caused by the defective software, such as the cost of replacing or repairing the software. The contract typically provides that the developer is not liable for "indirect" or "consequential" damages, such as lost profits or injury to reputation.
Another approach is to limit the customer to a certain amount of dollars for each day during which the developer fails to repair the damaged software. This is known as a "liquidated damage" provision and is enforceable in many states, particularly when it is difficult to accurately predict the amount of damage the customer would suffer because of a defect at the time of contracting.
Yet another approach is to limit the developer's liability to an arbitrary amount, such as the amount of money the customer paid for the software development.
As discussed earlier, representations made outside of the contract can form the basis for a breach of warranty or fraud claim. Exposure to these claims can be reduced or eliminated by including an "integration" (or "merger") clause. This is a clause that states that the developer has not made any representation concerning the software that is not expressly recited in the contract and that, if he has, the customer is not proceeding forward in reliance upon it.
Some customers do not report problems promptly. During the interim, the developer may devote months of additional effort, only to later find out that the customer is unwilling to make any payment because of the defect, or that he must redo much of the code that was written after the defect surfaced. Key programmers also may become unavailable and memories of how the code works may fade.
The contract can minimize these problems by stating that the customer waives all rights he has in connection with any defect, unless that defect is brought to the attention of the developer within a stated number of days after it is discovered. Preferably, the contract should require written notice of the defect to eliminate any later dispute over whether timely notice was provided.
To reduce the expense of a legal dispute, include a clause which requires the customer to arbitrate any claim. Many people believe that arbitrators compromise claims, rather than decide them. Unlike courts, arbitrators usually are not bound to legal principles. But few dispute that arbitration is far less expensive than court proceedings.
Getting the customer to agree on liability limits does not always mean that these limits will be enforced. When the U.C.C. applies, a limit on liability will not be respected when it is "unconscionable" or causes the contract to "fail of its essential purpose." Typically, the court looks to see whether the customer had a real opportunity to negotiate the terms of the contract, whether the customer was unsophisticated in software, and the unfairness which enforcement of the restriction would cause.
For example, a contract that imposed no liability upon the developer if he failed to deliver the software after receiving payment from the customer would run afoul of these requirements. This would cause the essential purpose of the contract--the delivery of software--to fail. It also leads to an obviously unconscionable result.
Limiting the customer to a return of his money, on the other hand, might well satisfy these requirements. Some courts have already so held.
It also is important that the limitations on liability be imposed at the time the agreement is signed. Attempts to limit liability afterwards through the delivery of self-serving notices would probably be ineffective.
Contractual limitations on liability will rarely bar claims for fraud, gross negligence (in some jurisdictions), and claims for personal injury or property damage.
The typical "Commercial General Liability" policy will protect against claims for personal injury and property damage when caused by defective software, or claims alleging that promotional representations were false. The more-common breach of contract claim, however, is usually not covered. But when a breach of contract claim is combined in a lawsuit with a claim that is covered, the insurance company usually will be obligated to defend the entire lawsuit. Companies also can purchase an "Errors and Omissions" policy, which provides broad protection against most defective software claims.
When a problem does arise, strict adherence to restrictions in the contract is not always the best course. Responding positively and flexibly to the concerns expressed by the customer--even if not required by the contract--often will preserve an important business relationship, enhance the developer's reputation, and avoid a lawsuit that is likely to be far more costly.