Maureen O’Rourke, the Associate Reporter on the Principles of the Law of Software Contracts, and I are posting the following to acquaint readers with the Principles and also to respond to some criticism of one section of the Principles that creates, under certain circumstances, an implied warranty of no known material hidden defects in the software.
On May 19, the membership of the American Law Institute unanimously approved the final draft of the Principles of the Law of Software Contracts. As the Introduction to the project states, the Principles “seek to clarify and unify the law of software transactions.” The Principles address issues including contract formation, the relationship between federal intellectual property law and private contracts governed by state law, the enforcement of contract terms governing quality and remedies, the meaning of breach, indemnification against infringement, automated disablement, and contract interpretation.
The Introduction to the Principles explains further that “[b]ecause of its burgeoning importance, perhaps no other commercial subject matter is in greater need of harmonization and clarification. . . . [T]he law governing the transfer of hard goods is inadequate to govern software transactions because, unlike hard goods, software is characterized by novel speed, copying, and storage capabilities, and new inspection, monitoring, and quality challenges.” Many of the rules of Article 2 of the UCC therefore apply poorly to software transactions or not at all, and the Principles are intended to fill the void.
The Principles are not “law,” of course, unless a court adopts a provision. Courts can also apply the Principles as a “gloss” on the common law, UCC Article 2, or other statutes. Nor do the Principles attempt to set forth the law for all aspects of a transaction, but instead rely on sources external to the Principles in many areas.
The Principles apply to agreements for the transfer of software or access to software for a consideration, i.e., software contracts. These include licenses, sales, leases, and access agreements. The project does not apply to the exchange of digital media or digital databases. It applies a predominant purpose test to determine applicability to transactions involving embedded software or software combined in one transfer with digital media, digital databases, and/or services.
We are the Reporter and Associate Reporter of the software principles. We have been greatly aided by our advisors, consultative group members, ALI Council members, liaisons from the National Commissioners on Uniform State Law, Business Software Alliance, and the American Bar Association, and many additional lawyers from industry and other groups who, over the last five and one-half years, have met with us, talked with us on the phone, and exchanged e-mails with us. We believe the project moved along smoothly largely because of the efforts of all of these groups and individuals.
Nevertheless, in the two weeks leading up to approval in May, we received communications from a few software providers evidencing concern largely with one section of the Principles. Section 3.05(b) creates a non-excludable implied warranty that the software “contains no material hidden defects of which the transferor was aware at the time of the transfer.” The section only applies if the transferor receives “money or a right to payment of a monetary obligation in exchange for the software.” Because the section may be the most controversial provision, we devote the rest of this post to the issue.
Despite concerns that section 3.05(b) creates “new law,” it simply memorializes contract law’s disclosure duties and tort’s fraudulent concealment law. The section makes clear that these rules apply to software transfers in order to allocate the risk to the party best able to accommodate or avoid the costs of materially defective software. Obviously this is the transferor in situations where only it knows of the material defect and the transferee cannot protect itself. The section requires that the transferor knows of the defect at the time of the transfer (negligence in not knowing is not enough to trigger liability), the defect is material, and it is hidden.
A few software providers have concerns that the concepts of “hidden,” and “material defect” are obtuse and will “increase litigation” or require a flood of “detailed notices” to prospective users. These concepts, however, are hardly unknown to the law. A comment to section 3.05(b) says that a “hidden” defect occurs if the “defect would not surface upon any testing that was or should have been performed by the transferee.” This is nothing new. See, e.g., UCC 2-316(3)(b) (“there is no implied warranty with regard to defects which an examination ought in the circumstances to have revealed to [the buyer]”).
A few software providers also worry about the meaning of “material defect.” The comments to section 3.05(b) point out that the section simply captures the principle of material breach: Does the defect mean that the transferee will not get substantially what it bargained for and reasonably expected under the contract? The criticism that “materiality” is too vague, if accurate, would mean that contract law would have to abolish its material breach doctrine too.
Putting together the requirements of actual knowledge of the defect at the time of the transfer, that the transferee reasonably does not know of the defect, and that the defect constitutes a material breach means that a transferor would be insulated from liability in situations identified by the concerned software providers as problematic. These include where the transferor has received reports of problems but reasonably has not had time to investigate them, where the transferee’s problems are caused by uses of which the transferor is unaware, where the transferor learns of problems only after the transfer, and where the problems are benign or require reasonable workarounds to achieve functionality. The best example of when section 3.05(b) would apply is, as comment b to the section says, where the transferor already knows at the time of the transfer that the software will require “major workarounds . . . and cause[] long periods of downtime or never [will] achieve[] promised functionality,” the transferee cannot discover this for itself, and the transferor chooses not to disclose the defect.
As we have already said, the section simply memorializes existing law. Under the common law, a contracting party must disclose material facts if they are under the party’s control and the other party cannot reasonably be expected to learn of the facts. Failure to disclose in such circumstances may amount to a representation that the facts do not exist and may be fraudulent. See, e.g., Shapiro v. Sutherland, 76 Cal. Rptr. 2d 101, 107 (Cal. Ct. App. 1998) (“Generally, where one party to a transaction has sole knowledge or access to material facts and knows that such facts are not known or reasonably discoverable by the other party, then a duty to disclose exists.”); Hill v. Jones, 725 P.2d 1115, 1118-19 (Ariz. Ct. App. 1986) (“[U]nder certain circumstances there may be a ‘duty to speak.’ . . . [N]ondisclosure of a fact known to one party may be equivalent to the assertion that the fact does not exist. . . . Thus, nondisclosure may be equated with and given the same legal effect as fraud and misrepresentation.”). The Restatement (Second) of Contracts section 161(b) states that “[a] person’s non-disclosure of a fact known to him is equivalent to an assertion that the fact does not exist . . . where he knows that disclosure of the fact would correct a mistake of the other party as to a basic assumption on which that party is making the contract and if non-disclosure of the fact amounts to a failure to act in good faith and in accordance with reasonable standards of fair dealing.” Section 161, comment d of the Restatement (Second) adds “In many situations, if one party knows that the other is mistaken as to a basic assumption, he is expected to disclose the fact that would correct the mistake. A seller of real or personal property is, for example, ordinarily expected to disclose a known latent defect of quality or title that is of such character as would probably prevent the buyer from buying at the contract price.”
One concern of a commentator is that fraudulent concealment is a tort, implying that it has no place in the Principles. But the principle appears prominently in the Restatement (Second) of Contracts section 161. And why not memorialize a principle that discourages a party in a contract setting from hiding material facts that the other party reasonably does not know? The commentator notes that fraudulent concealment requires intent to deceive, but wouldn’t that be the usual inference if a transferor licenses software it knows is materially defective and knows the transferee cannot discover it?
A few organizations also are concerned that section 3.05(b) cannot be disclaimed. But there are plenty of cases that do not allow a party to contract away liability for concealment. One critic wonders why a statement such as “I am not giving any assurances about there being no defects in this software,” should not insulate a transferor from liability. A reasonable licensee, assuming the good faith of the licensor, would believe that this licensor does not intend to make any express warranties or implied warranties of merchantability or fitness, not that the licensor knows that the software is materially defective so that the software will be largely worthless to the licensee. A transferor playing this game is surely in bad faith and, frankly, engaging in reprehensible conduct. But there is a way to ensure no liability under this section, namely to disclose material hidden defects. In effect, disclosure is the disclaimer.
Bob Hillman and Maureen O’Rourke
June 2, 2009
