American Law Institute approves the Principles of the Law of Software Contracts
posted by Bob Hillman
Thanks to Dave Hoffman, who just completed a very successful visit at Cornell Law School, for inviting me to be a guest blogger for the month. 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
June 2, 2009 at 8:12 am
Tags: American Law Institute, software contracts
Posted in: Consumer Protection Law, Contract Law & Beyond, Cyberlaw, Intellectual Property, Law Talk, Technology, Uncategorized
Print This Post
Responses (5)
Ken Arromdee - June 2, 2009 at 1:50 pm
As we have already said, the section simply memorializes existing law.
If it simply memorializes existing law you wouldn’t have any reason to put it in. Usually “this memorializes existing law” really means “we have one interpretation of existing law. This is there to ensure that our interpretation of existing law is accepted by the courts and others aren’t.
I noticed you haven’t bothered to mention the objections by the Linux Foundation. Undisclaimable warranties could destroy free software. Also, the joint Linux Foundation/Microsoft letter suggests that the principles are not as in accordance with existing law as you might want us to believe.
Sean Hogle - June 6, 2009 at 5:48 pm
The decision to apply the common law principle in question (namely, the principle that requires the contracting party to disclose material facts if they are under the party’s control and the other party cannot reasonably be expected to learn of those facts) to the licensing of software is a decision the reporters made with very little if any actual caselaw support. To that extent the reporters are in fact attempting to create new law. This type of decision is one that only a legislative body should make after careful factual investigation as to the nature of software and how it is developed.
Sean Hogle - June 8, 2009 at 8:19 pm
Further to this, I’m recommending to all of my clients that they insert into their operative software license agreements the following or something close to it in the choice of law clause: “This Agreement and all related disputes shall be governed by the laws of _______, without regard to the United Nations Convention on Contracts for the International Sale of Goods or the American Law Institute’s Principles of the Law of Software Contracts (“Principles”). The parties agree that (i) the Principles shall have no application whatsoever to the interpretation or enforcement of this Agreement, and (ii) neither party shall invoke the Principles in whole or in part in any judicial or arbitral proceeding relating to this Agreement.”
But, aren’t many of the rules stated in the Principles, especially the controversial ones like the implied warranty of no hidden material defects and the implied indemnification obligation, not excludable or disclaimable, or disclaimable only with specific prescribed language?
Well, that’s what the Principles say. The Principles dictate, for example, that the newly-discovered warranty of no hidden defects cannot be excluded or disclaimed.
Here’s the thing: the Prinicples have no force of law whatsoever. They have persuasive authority only. They are not the equivalent of a statute or judicial decision. If the parties agree in their contract that the Principles will have no effect, why would a court feel free to disregard that?
For example, if a famous law review article written by a highly regarded law professor advocated for a specific interpretation of common contract language, and this interpretation would benefit one side over the other, there’s no reason why the parties could not simply agree that this professor’s article will be disregarded in any legal proceeding.
The same should hold true for the Principles.
ALI Approves the Principles of the Law of Software Contracts | licensinghandbook.com - June 19, 2009 at 7:34 pm
[...] I mentioned a few weeks ago and now recently reported by Concurring Opinions, the American Law Institute recently approved the final version of the Principles of the Law of [...]
ALI Approves the Principles of the Law of Software Contracts « NET(net), Inc. - May 12, 2010 at 9:51 am
[...] contract terms,governing law,law As I mentioned a few weeks ago and now recently reported by Concurring Opinions, the American Law Institute recently approved the final version of the Principles of the Law of [...]
Leave a Reply