ALI's Proposed Principles of the Law of Software Contracts Set for Final Release

Founded in 1923, the American Law Institute (ALI) consists of “judges, practicing lawyers, and legal scholars from all areas of the United States as well as some foreign countries, selected on the basis of professional achievement and demonstrated interest in the improvement of the law” who are tasked with publishing “various Restatements of the Law, model codes, and legal studies to promote the clarification and simplification of the law.”

Several years ago, the ALI, in partnership with the National Conference of Commissioners on Uniform (US) State Laws (NCCUSL), had promulgated Article 2B, the so-called "Uniform Computer Information Transactions Act", or UCITA, as a new component to the US states' Uniform Commercial Code (UCC). The UCC is a long-standing body of laws of commerce that has been adopted by nearly every state in the United States. UCITA did not fare as well as the larger set of laws embodied in the UCC, however; rather, only two states, Virginia and Maryland, adopted it. UCITA fell victim to controversies engendered by the attempt to codify rules that critics contended unfairly favored the interests of software companies over those of consumers. NCCUSL abandoned UCITA in 2003.

Since 2004, the ALI has been in the process of issuing a more modest set of guidelines applicable to software contracts, known as the Principles of the Law of Software Contracts. The intention is to secure broad consensus on a set of uniform principles, which could then, at some point in the future, evolve into a default set of licensing rules. The principles deal with issues such as enforceability of click-wrap or on-line agreements, forum selection, mandatory arbitration clauses, and embedded software.

On May 19, 2009, it is anticipated that the ALI will give final approval to these principles, barring any late proposals to postpone their adoption. A number of provisions will prove controversial among software companies. This article highlights a few of the more prominent features of the principles.

Implied Warranty of No Hidden Defects

Software developers often release software despite a long list of known defects, based on the assumption that the defects are not likely to materialize or prove fatal, with the intention to correct such errors in the next release. The principles' newly articulated implied warranty of no hidden defects may radically alter the way software is marketed and sold.

The principles require the software licensor to “warrant to any party in the normal chain of distribution that the software contains no material hidden defects” of which the licensor “was aware at the time” of the license or transfer of software. Unlike other implied warranties, such as the warranty of fitness for a particular purpose or merchantability, this new implied warranty cannot be excluded in the operative license agreement. Any such purported exclusions or disclaimers of this warranty will not be enforceable.

A hidden defect is defined as an error that "would not surface upon any testing that was or should have been performed by the transferee." The principles fail to provide any meaningful guidance on the severity of defect required to rise to the level of "material", other than state that such an error is one that renders the software "not fit for its ordinary purpose." Would a bug that renders the use of the software inconvenient but does not otherwise preclude the use of the software fall into this category? What of errors that render the software inordinately consumptive of memory or processing power? The principles are silent on this rather significant threshold issue.

The only way to avoid liability under this warranty is to either prove lack of knowledge, or fully disclose all known defects at the time of the license and beyond. In short, software vendors will be forced to produce a known defects list to its customers upon first license and constantly thereafter. The principles state that such disclosure should be done directly to the customer, and that a "mere posting of defects" on a website is "generally insufficient".

Software vendors will now need to seriously consider not only the most effective and diplomatic method of disclosing known defects to their customers, but also pursuing a list of known defects from each of their upstream suppliers, in order to be in a position to make the same disclosure downstream. This new implied warranty applies for the benefit of "any party in the normal chain of distribution", thus removing as defense lack of contractual privity.

Implied Indemnification Obligation

The principles advance a new implied indemnification obligation against intellectual property rights infringement for rights in existence at the initial time of the transfer or license of the software in question. The scope of the indemnity is limited to IP rights based on US state or federal law. The vendor "must pay those costs and damages incurred" by the licensee "that are specifically attributable to such claim" or those cost and damages agreed in settlement. If a court enjoins the licensee's use of the software, or rules that the software is infringing, the vendor is obligated to pay the customer's direct, indirect and consequential damages, and is further required to, at the vendor's election, replace or modify the software to render it non-infringing, or refund the fees paid for the use of the software (with a deduction for a reasonable allowance for the period of time the transferee used the software).

This implied obligation may be excluded in the operative license agreement only if the exclusion is in writing, is conspicuous, and "uses language that gives the transferee reasonable notice of the modification or notice that the transferor has no obligation to indemnify the transferee."

The comments to this section of the principles state that the commonly-used boilerplate, "THERE ARE NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS ….", would not suffice to satisfy this standard. The disclaimer must specifically reference the implied obligation of indemnification.

Effect on Open Source Licensing

Both the implied warrant of no hidden material defects, and the implied indemnification obligation, apply only in the situation in which the vendor receives monetary consideration in exchange for use of the software. Thus, open source software developers will not face liability under the principles. However, companies that aggregate, package and license open source components for a fee, for example, Red Hat, Montavista, Azingo, ACCESS, or the like, will not be exempt.

Conflicts with US Federal Law

The principles state that the term of a software license or transfer agreement is unenforceable if it (a) conflicts with a term of federal intellectual property law; (b) conflicts impermissibly with the purposes and policies of federal intellectual property law; or (c) would constitute federal intellectual property misuse in an infringement proceeding. Based on notions of federal intellectual property law preemption of contract terms, and caselaw regarding patent and copyright misuse, the principles provide illustrative examples of problematic provisions.

These examples include: contract terms that forbid reverse engineering; terms that prevent fair use under copyright law; restrictions on the dissemination of factual information; and enforcement of royalty or other obligations beyond the term of the intellectual property right in question.

The analysis, the principles suggest, may differ depending on whether the software is licensed under a mass-market click-accept agreement or under a arms-length negotiated agreement between two parties of relatively equal bargaining strength. Provisions restricting reverse engineering or fair use, for example, may be less likely to be enforced in the case of the former.

Interestingly, the commentary to this specific principle appears to call into question the enforceability of the GPL as interpreted to require that separate independently created works that merely link to or are integrated with GPL code be licensed reciprocally under GPL. This scrutiny comes in the form of a hypothetical:

Organization A licenses source code under standard terms that permit the licensee to modify and distribute the software provided that the licensee distributes its modifications under terms that replicate those in A’s standard form (including the term authorizing modifications provided they are distributed only with A’s terms). The term placing conditions on distribution of modifications is likely enforceable as long as those modifications are a derivative work of the original code. It is more troublesome if the modifications are independently developed and separable from the original code.