In the United States as in many countries, the software industry is increasingly important. Proprietary and open source software powers items as diverse as PCs and refrigerators, and controls systems as vital as missile defense and the utility grid. Many software vendors’ principle source of revenue comes from licensing their code to businesses and/ or consumers. Others use software as a means to drive demand for another money-making product like services. In any event, no one seriously questions software’s place in the economy or its importance to modern life. It may be somewhat surprising then that the law of software transactions in the U.S. has not been uniform. In Europe, European Union directives,a such as Council Directive 2009/24/EC of 23 April 2009 on the legal protection of computer programs (EU Directive) (replacing the former directive from 1991), helpfully set forth basic principles. In the U.S., courts look to the common law of contract (that is, the decisions of courts) or the Uniform Commercial Code (UCC) (a statute enacted by each state) for the rule of decision, and must also consider other sources such as consumer protection law and federal intellectual property law. Contract law and consumer protection law can vary by state and interpretations of the UCC and federal law can also be inconsistent. Although this variation characterizes the U.S. approach to much of its law, software’s unique attributes and importance to the economy make legal uniformity and clarity particularly important.
Software’s unique attributes and importance to the economy make legal uniformity and clarity particularly important.
Against this background, the American Law Institute (ALI), a law-reform organization in the U.S.,b undertook a project to analyze the area of software contracting and to set forth principles that a court could adopt as the rule of decision in a case before it. This effort produced the Principles of the Law of Software Contracts, a volume that we drafted and that underwent extensive review over a five-year period. The Principles address a set of topics important to software transactions—some unique to the software context, others not. We discuss briefly here just a few of the more important or controversial provisions and recommend that interested readers refer to the complete work for more information.
Scope
The first question the Principles faced was how to define the transactions to which they applied. The Principles intentionally define their scope narrowly to software as traditionally understood. As drafters, we understood the danger of over-inclusiveness: In particular, we wished to avoid the trap of including all types of digital information within our project’s scope. As a result, digital media and digital databases are not part of the project.
Even with this narrow approach, questions remained. The Free Software Foundation, at least until the release of Version 3.0 of the General Public License (GPL), maintained that open source licenses akin to the GPL were not contracts under U.S. law, but rather were mere copyright permissions. We disagreed, arguing that under U.S. law as traditionally understood, most open source licenses are indeed contracts because they are in the nature of an exchange between the provider and user. The Principles therefore apply to open source agreements with exceptions and specific provisions where necessary.
Relationship to Intellectual Property Law, Public Policy, and Unconscionability
In the U.S., software agreements as consensual transactions implicate contract law, which is primarily the province of the states. Software, of course, can be protected by federal intellectual property rights, including copyright and patent. Questions can arise whether a state court may enforce provisions under its contract law that provide greater rights or restrict limitations that federal intellectual property law would grant in the absence of the parties’ agreement.
The Principles opt to direct courts to consider all facts and circumstances, rather than adopting a blanket rule.
Here, as in many areas, the Principles take the general position that parties are free to contract as they see fit. The Principles, however, note that courts must be particularly attentive to provisions affecting federal intellectual property rights in the case of boilerplate standard forms. Especially because of the take-it-or-leave-it nature of such forms and the tendency of consumers and others to fail to read them, the federal interest in state non-interference with the intellectual property system is at its height.
For example, many boilerplate agreements include a provision against reverse engineering. Under both the Uniform Computer Information Transactions Act (UCITA) and the EU Directive, such provisions are unenforceable in certain circumstances.c However, the Principles opt to direct courts to consider all facts and circumstances, including whether the ban on reverse engineering is in a standard form, rather than adopting a blanket rule.
Many legal doctrines in the U.S. take a similar contextual approach. Some police contractual provisions for fairness in their formation and substance or for their effect on third parties. In this regard, the Principles include sections on unconscionability and public policy. Here again, the Principles do not set forth a list of suspect or unenforceable terms. Instead, they take the traditional U.S. approach of considering the context. But the Principles provide extensive comments about the nature of reasonable contract-formation processes and the fairness of substantive terms to guide courts in their contextual approach.
Implied Warranty of No Material Hidden Defects
The Principles clarify warranty law that has become muddled particularly under the UCC. For example, in the Principles, the creation of an express warranty and whether it is disclaimed depend respectively on whether a reasonable person could rely on the representation and whether a reasonable person would be surprised by the disclaimer. One warranty provision, however, has been controversial. Section 3.05(b) provides that a party who transfers software and receives money or a monetary obligation in return warrants "that the software contains no material hidden defects of which the transferor was aware at the time of the transfer."
Software providers objected to this provision as inconsistent with current law and likely to increase litigation. They also believe the warranty should be disclaimable. However, the rule merely codifies U.S. contract law’s duty to disclose and obligation of good faith and tort law’s fraudulent concealment principle. Further, the material-hidden-defect rule should not be difficult to administer. It defines a material defect as one that constitutes a material breach of the agreement. As such, the rule draws on the well-rehearsed material breach doctrine of U.S. law. Additionally, a hidden defect is one the provider knows about but would not surface upon any testing that was or should have been performed by the user. Disclosure of the defect occurs when a reasonable user would understand the existence and nature of the defect. As the Principles point out, providers that do not engage in concealment should have little to fear from this rule. But contract law should not support a provider’s strategy to foist a product known to be materially defective on to a user without providing that user with a remedy for potentially significant losses. Providers can insulate themselves from liability by disclosing material defects in their software.
Automated Disablement
Another section that exposed conflicting views governs automated disablement. Automated disablement refers to a provider’s use of electronic means to disable or materially impair the functionality of software such as by building in a "time bomb" or accessing the user’s system remotely to disable certain software.d The Principles severely limit the use of automated disablement as a remedy for breach: It is unavailable at all in the case of a consumer transaction or a standard-form transfer of generally available software. Additionally, the term authorizing automated disablement must appear conspicuously in the agreement, the party seeking to employ automated disablement must provide notice and an opportunity to cure to the user, and the provider must obtain a court order before disabling the software. These obligations are not disclaimable and damages for their breach may not be limited.
It is better to provide protections to all firms rather than trying to distinguish between those that are knowledgeable and informed and those that are not.
Particularly those software providers marketing to large, knowledgeable, well-informed commercial parties objected to the restrictions placed on automated disablement as too onerous and an unwarranted intrusion on freedom of contract. They also objected to the non-disclaimable nature of the obligations and inability to limit damages.
The commentary to the automated disablement section recognizes both these concerns and the historical nature of the debate. Software providers argued that automated disablement is necessary to prevent ongoing misuse of the software or a continuing breach that is causing damages to accumulate without any real possibility the provider will ever be made whole. Users argue that breach is highly contextual and a wrongful denial of use may cripple a business and/or harm software not even implicated in the dispute. Moreover, allowing providers to leave a "back door" open to permit automated disablement poses real security risks. Automated disablement is so controversial that, as recently as 2002, UCITA prohibited its use.
We believe our approach to automated disablement presents a reasonable balance between the conflicting interests. Even when commercial entities negotiate contracts, one side may overreach. Firms using software are not monolithic—many are small firms that cannot afford to hire lawyers to negotiate complex provisions. These firms are more akin to consumers than to large businesses. It is better to provide protections to all firms rather than trying to distinguish between those that are knowledgeable and informed and those that are not.
What’s Next?
The Principles, of course, contain many other provisions, including standards for enforcement of online contracts, which we do not have space to discuss here. Rather, we would simply emphasize a few points:
- The Principles were the result of a five-year drafting process that included input from both users and providers of software. There were many contentious issues on which both constituencies would never agree. In such cases, we made difficult choices informed by the legitimate points raised by both sides. We are not surprised the result sometimes makes neither side happy.
- The Principles are not the law of the U.S. or any particular state in the U.S. One or more of their provisions would become law if a court in a concrete case chose to adopt them as its rule of decision.
- The Principles address both topics that are unique to software and those that are not. Their applicability is limited to their scope. To the extent, however, that courts or commentators find their approach useful outside of the software context, we would welcome their use by analogy in other areas.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment