Installation failure: how the predominant purpose test has perpetuated software's uncertain legal status under the Uniform Commercial Code.

• Author: Gottlieb, Spencer

Courts have struggled to uniformly classify software as a good or a service and have consequently failed to apply a consistent body of law in that domain. Instead, courts have relied on the predominant purpose test to determine whether the Uniform Commercial Code ("UCC") or common law should apply to a given software contract. This test, designed for traditional goods and services that do not share software's complexity or rapid advancement, has perpetuated the uncertainty surrounding software's legal status. This Note proposes that courts adopt the substantial software test as an alternative to the predominant purpose test. Under this proposal, the American Law Institute ("ALI")'s Principles of the Law of Software Contracts would govern transactions that substantially involve software, and the UCC or common law would govern all other transactions. This new test would provide greater legal clarity with only a minimal shift in jurisprudence. No court has yet adopted a similar test or cited the ALI Principles as authority in a software dispute. The landscape is ripe for change.

TABLE OF CONTENTS INTRODUCTION I. RESOLVING SOFTWARE DISPUTES HAS BECOME AN EPICENTER OF UNCERTAINTY II. THE PREDOMINANT PURPOSE TEST IS THE PRINCIPAL CAUSE OF SOFTWARE'S UNCERTAIN LEGAL STATUS A. A Deficit of Appellate Guidance Has Produced Lower Court Uncertainty B. Courts Consider Improper Factors in Their Predominant Purpose Analyses C. Courts Reason by Analogy in Software Disputes Using Limited and Unsound Precedent III. THE SUBSTANTIAL SOFTWARE TEST CLARIFIES SOFTWARE'S LEGAL STATUS WHILE EXACTING ONLY A SMALL SHIFT IN JURISPRUDENCE A. The Substantial Software Test and the ALI Principles Provide a Straightforward Framework for Resolving Software Disputes B. The Substantial Software Test Is Superior to Alternative Reform Efforts and Overcomes Its Limitations. CONCLUSION INTRODUCTION

In 1983, the Soviet Union shot down Korean Air Lines Flight 007, obliterating the aircraft and killing all 269 passengers and crew on board. (1) Flight 007 had entered restricted airspace over Russia "likely because of an incorrect setting on the plane's autopilot" software. (2) In 2009, Air France Flight 447 crashed into the Atlantic Ocean after pilots failed to respond adequately when ice crystals outside caused the plane's autopilot software to disengage. (3) And in 2013, "bad software design" contributed to the runway crash that killed three passengers aboard an Asiana Airlines flight. (4) In an age where software dominates commercial life, it remains unclear what law a court would apply in contract actions arising out of events like these.

There are two primary options. A court would apply Article 2 of the Uniform Commercial Code ("UCC" or "Article 2") if it deemed the autopilot software to be a good, or it would apply common law if it deemed the software to be a service. (5) The difference is not merely semantic. The UCC and common law differ in significant ways on "contract formation and interpretation rules." (6) For instance, a software seller must tender a "perfect" product free of defects under the UCC7 but must only "substantially" perform under common law. (8) An aggrieved software buyer is consequently more likely to recover under the UCC than under common law when a glitch causes a catastrophic accident.

Courts routinely apply the predominant purpose test (9) to software contracts to determine if the UCC applies. (10) Under that test, Article 2 governs when the transaction at issue is predominantly for goods, while common law applies when the transaction is predominantly for services. (11) The U.S. Supreme Court has yet to rule whether software is a good or service, and "there is no national consensus" on the issue. (12) And yet despite its prevalence, the predominant purpose test has failed to assist courts in adjudicating software contract disputes. As a result, software's legal status remains a fundamental yet unanswered question.

This is the first piece of commentary to focus exclusively on the predominant purpose test's limitations in software disputes. It is also the first to present a practical replacement: courts should adopt the substantial software test, which would produce tremendous benefits to the legal community while exacting only a small shift in jurisprudence. The substantial software test directs courts away from classifying software contracts as goods or services transactions and asks only whether software is "substantial" in a contract. Courts would then apply the American Law Institute ("ALI")'s Principles of the Law of Software Contracts in cases where software is substantial and revert to the UCC or common law for all other contracts. "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." (13) For courts even to acknowledge the ALI Principles in this context would, in itself, be a giant step forward.

The substantial software test and ALI Principles would bring needed clarity and predictability to software disputes. Almost two million American jobs and $300 billion of the United States' GDP depend on the software industry. (14) Too much rests on software's legal status for this issue to remain unsettled.

This Note argues that courts should abandon the predominant purpose test in determining what law governs software contracts and instead utilize the substantial software test. Part I discusses software's uneasy relationship with the UCC and highlights what separates software contracts from other transactions. Part II elaborates on how the predominant purpose test has prompted courts to misapply multifactor balancing tests and haphazardly reason by analogy. Part III proposes the substantial software test and the ALI Principles as an alternative to the predominant purpose test and as an improvement on earlier efforts to clarify software's legal status.

1. RESOLVING SOFTWARE DISPUTES HAS BECOME AN EPICENTER OF UNCERTAINTY

   The predominant purpose test is favored for its versatility and simplicity, (15) but the software setting constrains its effectiveness. The test's precise phrasing varies among courts but invariably focuses on whether a contract is predominantly a transaction in goods or in services. (16) The UCC governs a contract that is primarily for goods, even if the contract also includes services, and the common law governs a contract that is primarily for services, even if the contract also includes goods. (17) The test has been so widely adopted in contract law that commentators have evaluated its potential use in other areas of law. (18)

   Understanding why the predominant purpose test is inappropriate for software contracts first requires looking at the UCC's scope. The UCC defines goods as "all things (including specially manufactured goods) which are movable at the time of identification to the contract for sale." (19) This includes obvious subsets like furniture, toaster ovens, and baseball gloves-- standardized products that are easy to conceptualize and evaluate. By contrast, "where the subject matter is intangible, dynamic, and protean," as in the case of software, "proper classification becomes much more problematic." (20) Determining whether the UCC or common law applies to a software lawsuit theoretically should be simple under the binary predominant purpose test, but courts have been unable to use this test uniformly to classify software transactions as involving either goods or services.

   Software's amorphous character has plagued courts for decades. One author contends that "[t]he legal definition of software first became an issue in 1969 when IBM ... announced that it was separating the pricing of its software and services from the pricing of its hardware." (21) The government and courts then had to determine whether "software was tangible personal property and therefore taxable, or intangible intellectual property not subject to taxation." (22)

   Software has given rise to a host of other debates in subsequent years. Commentators disagree over whether software is a good or a service; (23) whether, if software is neither a good nor a service, it is instead information; (24) whether software should be subject to federal copyright law rather than state contract law; (25) and whether software transactions involve licenses rather than sales. (26) This Note reframes these questions by focusing instead on the process of deciding what law should apply to software contracts. Only when courts have a clear framework for interpreting software contracts will parties know how to design their transactions.

   Four issues common to all software contracts shed light on the predominant purpose test's limitations. First, speaking of "software" is like speaking of "food." Two randomly selected examples are bound to be drastically different. Even the definition of software varies greatly from source to source. One possibility--that software is "a series of step-by-step instructions which tell the computer exactly what to do" (27)--is a definition "used in most of the cases and by the commentators." (28) By contrast, Merriam-Webster defines software in broader terms, as "the entire set of programs, procedures, and related documentation associated with a system and especially a computer system." (29) These definitional variations are legally significant. Software makers, for example, can patent a program that constitutes a "design or a physical invention" but not a step-by-step "process implemented on a computer." (30)

   Second, software varies in scope and power. Consumers who purchase Angry Birds for their tablet device have different expectations of how that product will function than do the purchasers of custom billing software. Developing legal uniformity among the vast swath of products lumped under the umbrella term of "software" has proved exceedingly difficult. (31)

   Third, unlike...