C. PROPOSED CHANGES TO THE LANGUAGE OF THE EMBEDDED SOFTWARE EXCLUSION 999

III. HYBRID TRANSACTIONS AND THE MERELY INCIDENTAL EXCLUSION 1003

  A. THE MERELY INCIDENTAL TEST AS AN EXCLUSION OF LICENSED INFORMATION THAT IS INCIDENTAL TO SERVICES 1005

B. THE MERELY INCIDENTAL TEST AS AN EXCLUSION OF LICENSING AND SOFTWARE CONTRACTS THAT ARE A MINOR PART OF A TRANSACTION 1009

IV. CONCLUSION 1011

I. Introduction

Article 2B, a proposed addition to the Uniform Commercial Code,¹ addresses issues of formation, modification, warranty, disclaimer, transfer of rights, licensing, and remedy as they pertain to the sale and licensing of software, and the electronic formation of contracts.² The scope of Article 2B encompasses "licenses and software contracts" and "agreements to provide support for, maintain, or modify software related to a software contract that is included in this article."³ Article 2B governs the sale of copies of software, but not the sale of copies of books or other printed material, although both software and books are protected by copyright and seem to fit within the same category.⁴ Article 2B distinguishes the sale of copies of software from books because the use of software is expressly conditional, while conditions on copyrighted books or other printed materials are implied.⁵ Software is also distinguished from books because the nature of software (easily copied and transferred) makes it particularly susceptible to copyright infringement.⁶ Because software is so easily copied and transferred, licensing and distribution agreements are easily broken. Article 2B will go well beyond the common law in providing a legal framework to establish remedies and guidelines for the governance of commercial software transactions.⁷

Basically, a contract only fits within the scope of Article 2B if it is a licensing agreement that expressly conditions the use of information or if it is a contract which is related to a licensing agreement and which maintains, modifies, or supports software.⁸

The scope of Article 2B is intentionally ambiguous. The drafters intended to leave the general question of the types of licensed information within Article 2B's scope indefinite because the "long term viability" of Article 2B might suffer if the general scope were limited to a certain subject matter, such as digital information.⁹ Instead, the drafters focused on a type of transaction-licensing.¹⁰ The indefinite nature of the general scope of Article 2B is understandable because of the unpredictable evolution of technology in the information age.

Article 2B also has named exclusions which are imprecise: licenses and software contracts or agreements otherwise within the scope of Article 2B are excluded from the scope if one of several conditions exist. The scope of Article 2B excludes software embedded in goods,¹¹ licenses or software contracts merely incidental to a larger transaction that would not otherwise fall within the scope of Article 2B,¹² printed materials,¹³ some patents,¹⁴ entertainment contracts,¹⁵ employment contracts,¹⁶ and banking or monetary transactions.¹⁷

This Article explores the exclusions to the scope of Article 2B. Although Article 2B is still in the drafting process, this Article tries to identify possible sources of uncertainty and confusion in the language of the exclusions to the scope of Article 2B. By hypothesizing situations which are not clearly within the exclusions to Article 2B, this Article demonstrates the need for more carefully defined exclusions to the scope of Article 2B. Unless remedied in the drafting process, the imprecise exclusions to the scope of Article 2B might lead to less uniformity and guidance than the drafters had hoped to achieve.

Although the imprecision of Article 2B's general scope is necessary to allow Article 2B to change along with evolving technology, exclusions to the scope of Article 2B should not be so imprecise. Unlike the general scope of Article 2B and its concern with general technology, the exclusions concern a type of information which is not considered to be a part of the evolving technology. The exclusions to Article 2B-embedded software and merely incidental information-should be well-defined because they involve the end use of the technology, whether that end use includes chips, CD-ROMs, or the next form of technology. Because the form of the technology will not change the end use, there is no reason to be imprecise in the language describing the exclusion. If the drafters of Article 2B are imprecise in their definition of technology or information within the scope of Article 2B, and, therefore, hope to keep the scope of Article 2B as expansive as possible, then the exclusions to the scope of Article 2B should be as limited and narrow as possible.

Part II of this Article explores the exclusion of embedded software from Article 2B's scope. This section addresses two potential sources of ambiguity in the exclusion provision: the definition of embedded software and the condition that embedded software excluded under the provision cannot have been "developed specifically for the transaction." Part II.A explains the exclusion and defines embedded software using the language of Article 2B and the Reporter's Notes. Part II.A next suggests four factors which may help determine whether software embedded in goods falls within the exclusion, and applies these four factors to goods containing embedded software which do not clearly fall within the exclusion. The application of these factors indicates the insufficiency of the exclusion for embedded software. Part II.B discusses the meaning and consequences of the condition that the embedded software is only excluded if it was not developed specifically for the transaction. Part II.B also uses an example to illustrate the potential difficulties encountered when applying this condition. Finally, Part II.C proposes new language for a more specific exclusion of embedded goods from Article 2B.

Part III of this Article explores Article 2B's treatment of hybrid transactions which involve goods traditionally governed by Article 2 or services governed by other law, as well as information and software that will be governed by Article 2B. First, this Part explains the three tests used by Article 2B to determine whether the information or software is within its scope. Parts III.A and III.B focus on the newest exclusion to Article 2B created by the "merely incidental" test. Part III.A focuses on the first type of exclusion under the test: the exclusion of licensed information which is incidental to services. Part III.A explores the background of the exclusion, the conflicting past and present policies underlying the exclusion, the possible inequities in the application of the exclusion, and suggests a solution to the problems inherent in the exclusion as it now stands. Part III.B focuses on the second type of exclusion under the merely incidental test: the exclusion of licensing and software contracts that are only a minor part of the transaction. Part III.B discusses the competing policies of the "gravaman of the action" test used for hybrid transactions versus the new merely incidental test. Finally, Part III.B proposes changes to make the merely incidental test more consistent with the results and purposes of the other two tests the drafters use to structure the scope of Article 2B.

II. The Exclusion of Embedded Software

Article 2B limits the scope of its application by excluding embedded computer programs. Examples of embedded software include navigational system software used in airplanes,¹⁸ and computer programs which control automobile braking systems.¹⁹ Two examples of non-embedded software include software contained on a disk,²⁰ and software stored in a computer.²¹

Whether the software is within the general scope of Article 2B or within the section 103 exclusion affects the available remedies to the consumer or buyer of the software. If the only remedy lies within the U.C.C., Article 2 protects the consumer more than Article 2B. Therefore, if the embedded software falls within the exclusion to Article 2B, but is covered by Article 2, the consumer will benefit from the greater protection of Article 2's remedial provisions. The remedy available in an Article 2B suit for the failure of the software could be limited by contract. While Article 2 contains a presumption that a limitation on personal injury loss recovery is prima facie unconscionable in consumer contracts,²² Article 2B contains no such presumption. The two articles contain similar statutes of limitations,²³ with one potential difference: in Article 2B, sellers are not precluded from shortening this period by contract, while a recent draft of the revised Article 2 precludes limitation in consumer contracts.²⁴ A contractual limitation on the starting point for the running of the statute of limitations could reduce the consumer's ability to recover for losses.

Although the drafters have gradually limited the general scope of Article 2B since the original draft in 1996,²⁵ the specific exclusion of embedded software has been present since the early drafts of Article 2B.²⁶ In the February 1998 draft, the scope of Article 2B excluded computer programs which are embedded in goods and which are sold or leased as a unit with the goods in which they are embedded.²⁷ This embedded software is governed instead by the body of law which applies to the good containing the embedded software.²⁸

In the February 1998 draft, even embedded software did not fall within the exclusion if the buyer of the goods had specifically licensed it,²⁹ or if the embedded software was "developed specifically for the transaction."³⁰

There are at least two difficulties that emerge when determining whether software falls within this exclusion of embedded software. First, the exclusion does not clearly define embedded software. Second, the condition that embedded software cannot be within the exclusion if it has been "developed specifically for the transaction" ³¹ is ambiguous because of varying interpretations of the term "developed."

A. Definition of Embedded Software

There is no existing caselaw which defines "embedded software." The only explanation is supplied by two examples of embedded software listed by the reporter,³² and two examples non-embedded software.³³ While two of the examples of software do not fit within the exclusion, all four examples of software are "embedded" in goods in the literal sense. Therefore, "embedded software" is a term of art within the context of the section 2B-103 exclusion. Courts and practitioners should not use a literal interpretation or dictionary definition of embedded software to determine whether embedded software will be within the exclusion to Article 2B.

Instead, the practitioner or court should infer the meaning of embedded software from consideration of the embedded software examples in the Reporter's Notes and the language of Article 2B. The two examples of embedded software given in the Reporter's Notes are navigation software embedded in airplanes,³⁴ and computer programs embedded in automobile braking systems.³⁵ The two examples of non-embedded software are software stored on a disk,³⁶ and software on a computer.³⁷ Two underlying policies of Article 2B which should be considered in conjunction with the exclusion of the embedded software include the intention of the drafters to encompass all information which is particularly susceptible to unauthorized copying or transferring,³⁸ and the attempt of the drafters to mirror expectations and practices already present in the commercial world.³⁹

The scope of the embedded software exclusion should be informed by a comparison of the four examples of embedded or non-embedded software, along with consideration of the underlying policies of Article 2B. The author contends that four factors should influence the exclusion or inclusion of embedded software within Article 2B: 1) the purpose of owning the good; 2) the buyer's awareness of the software as a separately functioning part of the good; 3) the ability to copy or transfer the software; and 4) the risk associated with the malfunction of the software.

The first factor, the purpose of owning the good which contains the embedded software, is drawn from a distinction between software embedded in computers or disks and software embedded in automobile braking systems or navigation programs. In a good such as a computer or disk, the software embedded in the computer or disk is the central purpose of owning the good. In the airplane or automobile, the software is important to the functioning of the good, but is not the main purpose for owning the plane or the automobile.⁴⁰ This distinction suggests that if the main use of the good is solely to employ the software program, then the embedded software is within the scope of Article 2B. A common example would be the sale of a disk-a good-that contains an embedded software program, like a daily planner or a word processing system. Although the good (the disk) is important, the main purpose of the sale is to use the software program embedded in the disk. One test of whether the main purpose of the product is for the good or the software is whether the buyer would be satisfied with the software if it were embedded within another form of good, like a compact disk or a tape.⁴¹ Correspondingly, the distinction also suggests that if the purpose of the good is not for the use of the software within it, then the software is embedded and is not governed by Article 2B. This factor applies regardless of the importance of the software to the function of the good. For example, the software embedded in a car may be so important that a dealer would not be able to sell a car without it, but the main purpose of owning the good is still to obtain the services performed by the good, not just the software. Unlike the example of the daily planner software program above, the buyer would not be satisfied with the software if it were embedded in another good.

The second factor, the buyer's awareness of the embedded software as a separately functioning part of the good, is supported by the cited examples, and is drawn from the policy of the drafters to be accurate, not original.⁴² Software embedded on a computer is clearly separate from the computer hardware itself. Although hardware has occasionally been the source of computer miscalculation, if someone using a computer to compute their federal tax liability noticed that the amount of taxes figured was incorrect, then the user may determine that the computer is the cause of the malfunction. The user would identify the embedded software as the source of the malfunction, and would probably expect that the program would not be covered under the same warranty covering the computer, even if that program was embedded in the computer at the time the user purchased the computer. Since the reasonable user in the buyer's shoes would have been aware of the program and the manner in which it functioned separately from the hardware, it is appropriate to govern that software under a separate set of warranties and liabilities than the hardware (the computer) which is a good covered under Article 2.⁴³

Software embedded in a car, however, is not clearly a separate feature of the car. If a car will not stop, then the driver probably would not know whether to blame the brake failure on the embedded software or the mechanical brake hardware. The driver would probably view the software operating the brakes and the brake hardware as two parts of a single whole and would reasonably expect the same warranty to cover both. Therefore, if the buyer is aware of the separate status of the software, then the software is governed by Article 2B. But if the good operates with the software as a whole, and the buyer reasonably expects that the software and the hardware operate as a single unit covered by the same warranties, then the software is not governed by Article 2B.⁴⁴ In the case of the car with malfunctioning brakes, the buyer would not expect to have to sue under two different Articles or two different theories for an injury caused by both hardware and software failure. Instead, the buyer would probably expect the same warranties and remedies to be available for the failure as a whole.

In contrast, a buyer explicitly aware of the independent function of the embedded software may be unusually informed, and may enjoy greater bargaining power, thereby negating the need for the increased protections available under Article 2.⁴⁵ Thus, the buyer's awareness of the software is a factor used in determining the appropriate level of protection under Article 2. Therefore, the buyer's awareness should also be a factor used in determining whether the software falls within the embedded software exclusion.

The third factor, the ability to transfer or copy the embedded software, is based on the drafters' policy to include all information susceptible to copyright infringement within the scope of Article 2B.⁴⁶ This factor also matches a comparison of the Reporter's examples and the examples in the provision. Programs embedded in computers or disks are easily transferred or copied, while programs embedded in automobiles or airplanes are not. Therefore, it is appropriate that programs embedded in computers or disks should be governed by Article 2B. The programs embedded in cars or planes would receive unnecessary protection if they were governed by Article 2B because they are not as susceptible to copyright infringement. For example, car owners generally do not and cannot make copies of the information contained on the chip which controls their automobile braking systems.

This third factor also corresponds to the first factor (the purpose of the good) because consumers usually buy goods which include software that is easily copied and transferred for the purpose of using the software. Analogously, goods sold for the purpose of using the good do not usually contain embedded software in a format which is easily copied or transferred.

The fourth factor, the risk associated with the malfunction of software, is a result of the distinction drawn between software embedded in a computer or disk and software embedded in an airplane or automobile. Hypothetically, the physical and economic risks of malfunction of the software in a computer are much lower than the risk of malfunction of the software in an airplane or automobile. This difference in the examples suggests that one policy underlying the drafters' decision to exclude embedded software from the scope of Article 2B might be to protect consumers in situations in which the risk of harm due to malfunction is great. By placing embedded software outside the scope of Article 2B, the drafters insured that a plaintiff would not be limited to the remedies provided by Article 2B, but could rely on the remedies provided by Article 2. This exclusion tells courts that this type of software is not really software at all-it is part of a good which falls within the scope of state consumer protection laws, Article 2, and product liability laws.⁴⁷

Because Article 2, which would usually govern the product or good in which the software is embedded, provides more available remedies to the consumer than Article 2B,⁴⁸ the protection of consumers may be one reason for excluding embedded software from the scope of Article 2B. If the protection of consumers motivates this exclusion, then the risk of harm posed by the good containing the embedded software is an appropriate factor to consider in determining whether the software should be excluded.⁴⁹ Two underlying policies should be considered: the intent of the drafters to include all information particularly susceptible to unauthorized copying or transferring,⁵⁰ and their intent to formulate Article 2B according to the expectations and practices already present in the commercial world.⁵¹

We should consider these four factors when determining whether embedded software should be excluded from Article 2B. But problems arise when one or two of the factors indicate that the software should fall within the exclusion, while one or two indicate that the software should fall outside the exclusion. Such in-between cases highlight the weaknesses inherent in an imprecise definition of embedded software.

Some examples of goods for which the factors discussed supra indicate both exclusion and inclusion within the scope of Article 2B are: computerized surgical equipment; automated teller machines; robotics in factories; and advanced home appliances, such as coffee machines and bread machines.

Computerized surgical equipment is an innovation which combines computer software, a monitor, the actual surgical instrument, and a doctor's physical motions. This new technology operates endoscopes,⁵² and may soon become available to perform heart bypass surgery,⁵³ and other technically demanding surgeries.⁵⁴ For computerized surgical equipment, the consumer awareness factor and ease of copying factor indicate inclusion under Article 2B, while the risk factor and the purpose factor indicate exclusion from Article 2B.

The doctor or hospital purchasing the equipment will probably be aware that the software functions separately from the hardware (the surgical equipment itself). If the laser operated by the software consistently performs at a lower frequency than the one set by the doctor, then the doctor knows to repair the laser itself. But if the laser travels left when directed to travel right, then the doctor knows that the software programming is faulty. This characteristic makes the computerized surgical equipment appear to be more like the software embedded in a computer. Further, the software, if run through an actual computer hard drive, might be easily copied. Thus, the ease of copying factor also indicates that computerized surgical equipment falls within Article 2B.

However, the risk and purpose factors suggest that computerized surgical equipment should be excluded from the scope of Article 2B. A mistake in the programming of the software embedded in the equipment could lead to severe physical injuries. As the risk level of the product is high, it might be better governed by Article 2 or the common law. In addition, the purpose factor favors exclusion. The software is not the main purpose of owning the good. The main purpose of owning the good is to obtain the services performed by the surgical equipment, not the operation of the software alone. Since the possible factors which indicate exclusion or inclusion within Article 2B are evenly split, the language of the exclusion is not adequately precise. The language of the exclusion or the Reporter's Notes should clarify which of the four factors, if any, should sway the exclusion or inclusion of goods such as surgical equipment.

An automated teller machine (ATM) combines software and a computer-like appearance (keypad and screen) with the physical function of dispensing cash or accepting deposits. Like the surgical equipment, the factors are evenly split between exclusion and inclusion. But, unlike the surgical equipment, the risk and awareness factors favor inclusion, while the ease of copying and purpose factors favor exclusion. The ATM has a low level of physical risk, making the extra protection of Article 2's consumer-friendly laws unnecessary (as well as superfluous because ATMs are not truly consumer items-the banks would probably pay their customers for the economic consequences of ATM malfunctions). In addition, excluding these software programs from Article 2B would needlessly interfere with the transaction between the parties, forcing the buyer to pay for a good (insurance against the risk of software failure) which the buyer would rather not purchase. The bank which contracted for the development or installation of the ATM is probably aware of the software component of the machine. The machine developer probably asked the bank for its preferences in order to program the software accordingly (i.e., the cash limit on a single withdrawal; the number of transactions available to the consumer). Because the bank is aware that the software is a separately functioning part of the ATM, the bank does not have a reasonable expectation that the software is governed by the same laws and warranties as the mechanical parts of the ATM. Therefore, ATMs may easily fall within Article 2B.

But the remaining two factors place ATMs within the exclusion. The ability to copy or transfer the software is low because, although the ATM operates like a computer and may run from a central computer which processes information, the machine itself is not equipped with the loading or copying features of personal computers. If ATM-embedded software fell within the scope of Article 2B, then the goal of Article 2B to group together information which is susceptible to copyright infringement would not be served.

In addition, the purpose of owning the ATM is tied more to the function and service provided by the ATM as a whole than the operation and services provided by the software alone. The owner of the machine may be aware that the software functions separately from the good, but would neither want to own the software separately from the machine itself, nor be satisfied with the software if it were embedded in a different good. The software would be useless without the good in which it is embedded. Thus, applying the purpose factor to ATMs results in ATMs being excluded from Article 2B coverage.

Again, the application of these four factors to the ATM produces varying results, demonstrating the inherent difficulty in determining Article 2B's scope. The global goal of promoting uniformity in the law will be defeated if one court includes ATM software within the scope of Article 2B, while other courts exclude it.

Machinery used in factories, such as robotic arms, has both mechanical elements and embedded software. When the buyer awareness factor is considered, it seems that the machinery should fall within Article 2B. When the other three factors (the risk factor, the purpose factor, and the ease of copying factor) are considered, however, it seems that the machinery should be excluded from Article 2B. The factory manager who purchased the machinery or robot is probably aware of the software and may have even hired software programmers to modify the software to fit a specific application within the factory. This awareness of the software as a separate element of the machinery suggests that the manager would have a reasonable expectation that the software would be governed by law separate from the mechanical elements of the machinery. Despite being aware of the software as a separately functioning element, the manager or purchaser of the machinery may still think of the robot or machinery as a unit, because the purpose of the machinery is to obtain the services of the whole machine, and not to use the software, alone. The software would not be adequate if it were contained in a different medium. In addition, in some circumstances there is a high risk of physical harm to factory workers, creating a need to regulate this type of software under a law or Article more sensitive to remedies for physical harm than are provided by Article 2B. Because the software that is embedded in machinery is not easily copied or transferred, there is no need for Article 2B's protection, which is intended for easily infringed software.

Three of the factors suggest that the embedded software in factory machinery falls within Article 2B's exclusion. But the opposite result is reached when the buyer's awareness that the software is a separately functioning product and the buyer's reasonable expectation that the software should be governed by another Article are considered. The buyer's awareness is important because the buyer of the product, the factory owner, could have enough bargaining power and money to demand a higher quality product; alternately, the buyer could refuse to pay a high price for the software by requesting the elimination of costly debugging processes. An informed buyer with bargaining power may not need Article 2's extra protection, most of which applies only to consumers.⁵⁵ Perhaps the buyer is the cheapest cost-avoider; if the buyer is willing to pay a high price for a perfect product, the buyer can avoid software malfunction and resulting harm.

In the case of factory machinery, three of the factors seem to clearly favor the exclusion of the embedded software. Yet, the awareness and bargaining power of the machinery buyer in this particular fact situation undermine the confidence with which the machinery can be excluded. A clearer articulation of the most important principles underlying Article 2B's exclusion of embedded software may help answer whether Article 2B should be applied to factory machinery.

Home items such as coffee machines and bread machines also contain embedded software to help direct the mechanical elements of the product. As with the above examples, it is unclear whether such items fall within the scope of Article 2B. The awareness factor could place home items within Article 2B depending on the savvy of the consumer or the court's determination of what constitutes a reasonable consumer. The risk factor indicates inclusion, but the purpose and ease of copying factors both indicate exclusion.

The consumer may or may not be aware of the embedded software as a separately functioning element of the product. In coffee and bread machines, the computerized element of the product is highly visible: the exterior of the product usually contains a character display and a keyboard or buttons through which the user can enter information to direct the product. But computerized apparatuses have become so commonplace in household products that it is questionable whether the consumer has an appreciation of the software as a separately functioning element of the product. An uneducated consumer may use coffee or bread machines without questioning how the machine processes information entered through the keyboard or buttons. And whether or not the consumer is actually aware of the software as a separately functioning element of the product, the consumer may still have a reasonable expectation that the software is governed by the same laws as the mechanical elements of the product.

But the risk factor of home items such as coffee and bread machines is low, making consumer protections in addition to those provided by Article 2B unnecessary. If a serious injury did result from the malfunction of software in a bread machine, reasonable consumers might not expect differing awards for injuries caused by mechanical failure or failure of the embedded software.

The main purpose of owning such home items as coffee and bread machines is to obtain the services provided by these goods, not the services provided by the software by itself-this indicates that such home items are excluded from Article 2B's scope. Finally, including these kinds of software within the scope of Article 2B does not further the drafters' intention to regulate information susceptible to copyright infringement because there is little likelihood that the software would be copied or transferred.

Many of these ambiguities surrounding Article 2B's exclusion of embedded software may disappear if buyers of items such as factory machinery, ATMs, or surgical equipment form contracts which circumvent the default provisions of Article 2 or Article 2B, through such means as clauses specifying the law which will govern the contract, or clauses specifying warranties or licenses. But the need for detailed contracts only highlights the fact that Article 2B does not reflect the expectations of contractors. As we have seen, the application of these four policy considerations highlights the ambiguity and uncertainty surrounding Article 2B's scope.

B. Software Developed Specifically for the Transaction

The Section above explains why embedded software is excluded from Article 2B. However, the February 1998 draft explains that not all embedded software is excluded. The transaction is covered by Article 2B,⁵⁶ even though it is "embedded," if it was developed specifically for the transaction.⁵⁷ Including software developed specifically for the transaction within the scope of Article 2B reflects one of the factors explored in Part II.A. of this Article: buyer awareness. Because such software is developed specifically for the transaction, the buyer is presumably aware that the software is a separately functioning element of the whole. Therefore, the reasonable buyer would expect the software to be covered by a set of warranties and remedies separate from those that cover the hardware. In addition, the buyer who has software developed specifically for a transaction has more bargaining power, is less in need of the consumer protections under Article 2, and may more prefer to bargain for the risks involved in the software failure than the buyer who is buying software which was not designed specifically for the transaction.

Although it makes sense to include embedded software developed specifically for a transaction within the general scope of Article 2B, the use of the word "developed" may encompass more than software purchased by buyers who have bargaining power and an awareness of the software as a separately functioning element of the good in which it is embedded. The use of the word "developed" may be interpreted in a variety of ways, leading to uncertainty as to what falls within Article 2B. Applying this condition for exclusion may lead to inconsistent results for buyers of goods which contain embedded software and which qualify for the exclusion from Article 2B according to the four factors (awareness, risk, ease of copying, and purpose), but which are not excluded from Article 2B because they were developed specifically for the transaction.

Neither the Reporter's Notes nor the language of the provision itself indicate a special trade meaning or definition of the word "developed." Thus, there are several possible interpretations of "developed": a program designed to meet the needs of a particular client; a code that is written to fulfill the program design; an existing program that is customized for a particular client; or an existing program that is configured for a particular client by activating or deactivating toggle switches within the program. Whether the word "developed" refers to complex programming or programming involved in simple configurations may be an important factor in determining the scope of Article 2B.

Determining the proper interpretation of "developed" requires a consideration of the policies underlying the U.C.C., as a whole. The U.C.C. recommends liberal construction.⁵⁸ Therefore, the construction of the phrase "developed specifically for the transaction" should reflect the U.C.C.'s policy to "simplify, clarify, and modernize the law."⁵⁹ In addition, the construction should reflect the purpose of and policy behind the provision in question.⁶⁰ Although this particular provision does not state its policy or purpose either in the text or the Reporter's Notes, Article 2B's general purpose is to cover all software and information which is licensed and which all have similar characteristics-ease of copying, ease of modifying and unnamed "other uses" that result in express or implied limitations on the licensing of the information or software.⁶¹

The word "developed" in the context of software programming is inherently complex and ambiguous. As such, without interpretation, the phrase "developed specifically for the transaction" does not carry out policies underlying the U.C.C. It does not simplify and clarify the law, or fulfill the drafter's intention to include all information which is susceptible to copyright abuse within the scope of Article 2B. And, even if the software is developed specifically for the transaction, it is embedded, and therefore is not easily copied or modified. Embedded software within the meaning of the exclusion is, by its nature, embedded in a good that is not equipped with the technology or mechanics to enable the user to copy or transfer the software. Regardless of whether the good was developed specifically for the transaction, including this type of embedded software within the scope of Article 2B does not fulfill the drafters' intentions.

Therefore, placing specifically developed embedded software within the scope of Article 2B must fulfill some purpose other than the drafters' desire to include all information susceptible to copyright infringement and all information subject to express restrictions. As neither the U.C.C. nor section 103 of Article 2B mention any additional purposes or policies underlying Article 2B's embedded software exclusion, it may be helpful to consider the factors discussed, supra, in Part II.A.⁶² The applicable factors included: the purpose of owning the good, the risk associated with the malfunction of the good, and the buyer's awareness or expectation of the software as a product which functions separately from the good.⁶³

Neither the risk associated with the malfunction of the good nor the purpose of owning the good would change if the sole difference between embedded software in similar goods was the extent to which the software was or was not developed specifically for the transaction. One robotic arm containing embedded software which was developed specifically for the buyer has the same risk of harm due to malfunction as ten robotic arms sold to ten factories, all containing identical embedded software. Likewise, the purpose of owning those robotic arms does not change from arm to arm where one arm contains software developed specifically for the transaction, while the other arms do not. All the robotic arms were purchased for the services performed by the arm, and not for the services provided by the software, alone.

But when embedded software is developed specifically for the transaction, it may create a heightened level of awareness in the buyer-the cost and time involved in developing the software may have signaled to the buyer that the software is a separately functioning element of the product. Therefore, the buyer may expect that the embedded software is covered under a separate article of the U.C.C.

If embedded software which was developed specifically for the transaction falls within Article 2B because of the buyer's awareness, an interpretation of the word "developed" should incorporate the amount of money and time needed for the development, and the involvement required of the buyer. Of the four interpretations of development suggested, supra, designing a program requires the most time, money, and client involvement, and is most likely to make the buyer aware of the software as a separate element of the product.

Customizing an existing program or configuring a program by activating or deactivating toggle switches would probably result in a lower awareness than designing a new program for a buyer. Customizing an existing program requires rewriting portions of code or adding code to suit the needs of a particular client. In this case, someone has already designed the program and the majority of the code has been written. The costs of rewriting small portions of the code are much less than the costs of designing a new program. When customizing, the seller or producer of the software needs much less client information because the client may use the product to perform some common service-the seller only needs information on small details specific to the client to customize the program.

An example of customizing an existing program is the creation of an accounting system for advertisers or law firms. The program provider may have designed a basic accounting program already, but must rewrite certain parts of the program to meet the differing needs of the law firms or advertisers. For example, the billing categories into which the program saves items or the client information required from a user on an input screen may need modification.

The configuration of an existing program is also low cost and requires minimal buyer involvement. When configuring a program, the seller does not write or revise any code in the program. Rather, the seller needs only to activate or deactivate certain toggles or features of the program. One particularly common example is home alarm systems. Home alarm systems work through the operation of mechanical detection equipment and software. This mechanical detection equipment differs in quality and sophistication from system to system, but the software itself is consistent among models and manufacturers of alarm systems. The alarm systems must be configured to each house or business premises. The customization involves the customer's choices of certain "points of contact" in the house (usually doors or windows) which will trip detection devices if the contact is broken. The chip containing the software that activates the alarm must then be configured to reflect the choices. The program configuration is accomplished with a laptop computer⁶⁴ and may even be performed by hand on the self-installation models of home alarm systems sold in stores such as RadioShack.⁶⁵ The configuration does not substantially change the program, but it activates or deactivates certain features of the program that the consumer did or did not choose to install. The main function of the software is to report, via phone lines, any violation of a contact point (known as a "trip"), to a computer in a central control station. The computer in the central control station can identify the point of the trip based on the information delivered by the software and call an emergency number.⁶⁶

After configuration, the programming differs slightly for each home alarm system. However, the basic program which provides the framework does not significantly differ between programs used by customers with small homes who buy average alarm systems and large commercial businesses with elaborate customized systems.⁶⁷ If the alarm system in a single house does not work effectively, then industry experts would consider it a fault in the configuration, rather than a fault in the software program, itself.⁶⁸

When the development of custom software requires substantial amounts of time, money, and buyer involvement, it seems that a buyer's awareness of the separate nature of the software will usually be heightened. But the lower cost and customer involvement of customization or configuration does not necessarily mean that the buyer of customized or configured embedded software is not aware of the separate nature of the software, also. In the case of home alarm systems, the customer probably is aware of the software as a separately functioning part of the alarm system.

The awareness factor may help determine which types of "developed" software should fit within the exclusion. But even if a buyer is aware of the software's separate nature, the risk due to malfunction of the embedded software may still be high. In those cases, the buyer might be better protected under Article 2 or other law, but may not be in a position to bargain for terms which differ from those contained in Article 2B; therefore, the buyer may still need the additional protection of the Article 2B exclusion.⁶⁹

The drafters may have intended to include buyers with a high degree of bargaining power within the scope of Article 2B by formulating this "specifically developed" exception to the embedded software exclusion. If this was its purpose, then it has not been successful. Consumers of home alarm systems have little bargaining power, yet do not fall under the exclusion because the alarms were "developed" specifically for their transaction.

C. Proposed Changes to the Language of the Embedded Software Exclusion

The provision excluding embedded software from the scope of Article 2B is ambiguous, producing uncertain results. Whether or not a certain type of software is embedded within the meaning of the exclusion is unclear. Products such as computerized surgical equipment, ATMs, factory machinery, and home appliances may or may not fall within the exclusion. The ambiguous language of section 103 could also lead to the arbitrary exclusion of certain embedded software just because the embedded software was configured to fit the needs of the buyer (failing the condition to the exclusion that the software cannot have been "developed specifically for the transaction").

This Article proposes a more descriptive exclusion for embedded goods by listing two of the qualities of embedded software within the definition: ease of copying and purpose. The use of only these two factors is adequate to protect reasonable consumer expectations.

Although the risk factor is not specifically listed in this proposed definition, the purpose and ease of copying factors should encompass all embedded software which is not contained in a computer or disk, and, therefore, all items which may have some level of risk. The other factor not included in the descriptive listing is the awareness factor. The condition that embedded software is not within the exclusion if it has been "developed specifically for the transaction" should, once rewritten, sufficiently address this factor.

The February 1998 draft of the language excluding embedded software simply states that Article 2B does not apply to "a sale or lease of a computer program embedded in goods and sold or leased as part of the goods unless ... the goods are merely a copy of the program or are an information processing system in which the program is to operate."⁷⁰ The definition of embedded software should use more descriptive language, such as:

Article 2B does not apply to "a sale or lease of a computer program embedded in goods and sold or leased as part of the goods, if 1) the computer program is not in a form easily copied or transferred, and 2) obtaining the services of the goods is the purpose of the transaction."

Language in the March 1998 draft also supports a broad interpretation of the term "embedded software," using the purpose of the good as the principal determinant.⁷¹ According to the Reporter's Notes, embedded software is excluded from the scope of Article 2B unless its "primary purpose is to provide access to the functional or other attributes of the program."⁷² These notes clearly exclude computerized surgical equipment, ATMs, factory machinery, and home appliances because the purpose of each of these goods goes beyond providing access to the services of the software by itself.⁷³

The condition to the February 1998 draft's exclusion that the software cannot have been "developed specifically for the transaction" is also not clear enough to achieve the exclusion of embedded software with uniformity and without arbitrary results.⁷⁴ If the underlying policy of the condition to the exclusion for embedded software were to protect only those buyers of goods containing embedded software who lack bargaining power,⁷⁵ then using Article 2B's definition of a mass market transaction to determine the extent of the exclusion might limit the application of the condition appropriately.⁷⁶ If the condition were to apply only to transactions which were not mass market transactions, then the condition to the exclusion would not apply to consumers or to licensees who acquired "the information in a retail transaction under terms and in a quantity consistent with an ordinary transaction in that marketplace."⁷⁷ The definition of a "mass market" in Article 2B is used in provisions generally protecting buyers with less bargaining power. ⁷⁸ Therefore, its use in the condition to the embedded software exclusion furthers this purpose of protecting buyers with less bargaining power. The use of the definition affords these buyers the greater protection of laws other than Article 2B by excluding them from the scope of Article 2B, even if the embedded software was developed specifically for the mass market transaction.⁷⁹

Using the term "mass market transaction" would also prevent the uncertainty created by differing interpretations of "developed" in the phrase "developed specifically for the transaction." Because both consumers and non-consumers who buy goods with configured or customized embedded software can be included within the definition of "mass market transactions," the remaining uncertainties surrounding the interpretation of the terms configured and customized are minimized.

The February 1998 draft's condition to the embedded software exclusion reads that a program is not excluded if "the program was developed specifically for the transaction."⁸⁰ If the condition to the embedded software exclusion included Article 2B's "mass market transaction" definition by stating that "the program is not within the exclusion if the program was designed or written specifically for a transaction which was not a mass market transaction," then consumers and other mass market licensees would be protected from the harms caused by varied interpretations of the word "developed."

The March 1998 draft of Article 2B removed the condition to the embedded software exclusion, thus eliminating any problems that would have been created by arbitrarily including embedded software within the scope of Article 2B.⁸¹ Although the Reporter's Notes do not comment on it, the deletion may reflect intentions to further broaden the exclusion and to avoid ambiguities in its interpretation.

If the language of the exclusions to Article 2B were changed as suggested, supra, then the exclusions would be clearer and not overbroad. This would allow Article 2B to achieve the drafters' stated purpose of including all licensed software and information which have such similar characteristics as ease of copying or modification.⁸² In addition, the interpretation of the exclusion provisions of Article 2B would be more uniform because of the clearer language, resulting in more certainty to software and technology licensing and contracting.

III. Hybrid Transactions and the Merely Incidental Exclusion

Like the language in the provision excluding embedded software, the language of the provision governing hybrid transactions and merely incidental information creates uncertainty in software and technology licensing and contracting. This is because varying interpretations could lead to inconsistencies in the treatment of hybrid transactions and incidental information. Three tests govern the application of Article 2B to hybrid transactions involving both Article 2B subject matter and goods or services: the merely incidental test,⁸³ the gravaman of the action test,⁸⁴ and the predominant purpose test.⁸⁵

The merely incidental test arises from language added to the February 1998 draft of Article 2B and continued as part of the March 1998 draft with only minor changes.⁸⁶ It excludes information which would have been governed by Article 2B if the information is either merely incidental to services being performed under the contract,⁸⁷ or is only a minor part of any transaction.⁸⁸ For example, an attorney may provide information to a client as a service, governed by common law, but that information may be restricted by contract. Because the restriction on the information is merely incidental to the larger service-legal counseling-the information does not fall within the scope of Article 2B.⁸⁹ Article 2B also would not apply to a license or restriction on information where it is only a minor part of a larger transaction which predominantly involves services.

If the licensing or software contract does not satisfy the merely incidental test, then a gravaman of the action test determines which laws govern the information, services, or goods involved in the transaction.⁹⁰ Under the gravaman of the action test, information would be regulated by Article 2B, while goods would be regulated by Article 2 or 2A . For example, if a computer configured by software programs malfunctioned, Article 2B would govern the software programs, while Article 2 would govern the computer hardware itself (i.e., the mechanical parts of the computer's memory, such as chips and boards).

Unlike the merely incidental and gravaman of the action tests which apply to the actual transactions, the predominant purpose test is used only when determining which law will govern contract formation issues in a hybrid transaction.⁹¹ If Article 2B subject matter is the predominant purpose of the transaction, then Article 2B governs the contract formation of the entire transaction. Although Article 2B may govern contract formation for the goods and even the services involved in a hybrid transaction, it does not govern the services in matters which do not involve contract formation.⁹² For example, Article 2B would govern the contract formation issues for a contract involving the sale of accounting software and instruction to use the software. Even though the contract involves both software and services, Article 2B would govern the contract formation issues of both the software and the services as long as the predominant purpose of the contract was to provide the accounting software, not the instruction in using the software.

A. The Merely Incidental Test as an Exclusion of Licensed Information that is Incidental to Services

The first element of the merely incidental test determines whether licensed information is incidental to services performed under a contract, and therefore excluded from the scope of Article 2B. The changes in the language of the provision during the drafting history of Article 2B provide some guidance for interpretation, while the language of the provision itself and the Reporter's Notes accompanying it provide further guidance. After examining these considerations, this Article suggests an expansion of the exclusion to reach licensed information incidental to services which may have been inadvertently included within the scope of Article 2B by the current language of the provision.

Previous drafts of the provision delineating the scope of Article 2B applied both Article 2 and Article 2B to any hybrid transaction, not just transactions which involved software or licensing on a more than incidental level.⁹³ Although the previous drafts of Article 2B seemed intent on applying Article 2B as broadly as possible, notes from the newest draft of Article 2B indicate that the drafters are no longer interested in as broad an application.⁹⁴

The language excluding information which is incidental to services in the February 1998 draft limits the scope of Article 2B in two ways.⁹⁵ The first type of exclusion required by the language of Article 2B occurs when information and the contract or license governing the information is "an inherent incident of excluded services."⁹⁶ The Reporter's example of an inherent incident of excluded services is the information a lawyer might give to a client, like a memo, which has certain restrictions on it.⁹⁷ Because advice from a lawyer is a service which does not fall under Article 2B, the restricted information incidental to the service also does not fall under Article 2B. However, the scope of the exclusion is not clear because the Reporter's Notes suggest that a fact specific analysis is necessary to determine whether the information is incidental.⁹⁸

The scope of the exclusion must extend beyond the Reporter's only example because this example concerns services and transfers of information from a regulated professional.⁹⁹ Services of regulated professionals are already specifically excluded under section 2B-103(c)(4) of Article 2B¹⁰⁰ and had been excluded even in the earliest drafts.¹⁰¹ This new addition to the language of the scope provision must therefore indicate a further limitation on the scope of Article 2B.

The further limitation on the scope of Article 2B also signals a different policy underlying the exclusion. In earlier drafts, the policy of the exclusion was that professionals who were already regulated did not need to be regulated under Article 2B.¹⁰² This original policy cannot apply to the expansion of the exclusion to non-regulated professions. By expanding coverage of Article 2B to services beyond the services of regulated professionals, the drafters step outside the original policy of the exclusion.

According to the Reporter's Notes, the policy behind the exclusion now seems to lie in the characterization of the transaction as a whole. The information should be excluded because it is inherent in the service-the transfer of information and the service should be treated as a single unit under the law that governs the service.¹⁰³

The extent of this new exclusion is difficult to determine. The Reporter's Notes recognize that the merely incidental exclusion does not apply to services such as software development.¹⁰⁴ As in the context of the embedded software exclusion,¹⁰⁵ the Reporter's Notes give examples at two opposite extremes. An example of merely incidental information excluded from the scope of Article 2B is the expressly restricted memorandum or document prepared by a lawyer for a client in the course of performing professional services. At the opposite end of the spectrum lies an example of information which is not merely incidental, even though it is performed in the course of services-information transferred by an "independent contractor hired to develop software."¹⁰⁶

These two examples do not inform a fact-specific application of Article 2B to services. Like the embedded software exclusion, there are cases which fall between the two examples-some services which involve the transfer of information expressly limited by contract may or may not fall within the merely incidental exclusion. For example, the services of a professional photographer at a wedding would result in: 1) the transfer of information (photographs) which fit within Article 2B's definition of information,¹⁰⁷ and 2) an express contractual restriction on the use of the information (an explicit restriction on the reproduction of the photographs). However, it is unclear whether the merely incidental exclusion would apply to this transaction. The photographer is not a regulated professional, nor is he in entertainment services, so he does not fit within the exclusion in section 2B-103(c)(4).

He may still fall within the scope of Article 2B depending on other factors, such as the type of equipment he uses. If he uses film which may be loaded onto computer software, then he may still fit within the scope of Article 2B. The fact that providers of all types of services routinely use computer software makes the application of this exclusion more difficult than it first appears.

Since the drafters seem to favor the treatment of services and the transfer of information inherent to services as one unit, governed by one law, it would make sense to expand the exclusion in section 2B-103(c)(4) to all transfers of information inherent in services, with a condition that the services cannot involve computer software development or services supplying support, maintenance, or modification of software. This conditional exclusion would resemble the exclusion for embedded software, making the structure of the exclusions to Article 2B more consistent.

Expanding the exclusion of Section 2B-103(c)(4) in this way follows the trend of reducing the scope of Article 2B. It supports the apparent policy of Article 2B to exclude all documents which are unrelated to software or computers. The drafters have already narrowed the scope of Article 2B by excluding the entertainment industries,¹⁰⁸ books and other printed material,¹⁰⁹ banking services,¹¹⁰ and most patents.¹¹¹ Instead of continuing to draft language excluding specific industries, Article 2B should strive for a more general exclusion that can flexibly accommodate all industries that are served by the policy of the exclusion. In addition, expanding the exclusion under section 2B-103(c)(4) and eliminating the language about transfers of information incidental to services in the Reporter's Notes would result in a clearer merely incidental test which applies only to one literal definition of the word "incidental" instead of two.

Instead of excluding "a contract for performance of professional services by a member of a regulated profession,"¹¹² this Article proposes an expansion of the exclusion by changing the language to exclude "a contract for the performance of services which do not involve software development or services under section 2B-103(a)(2)."¹¹³

By expanding the language of the exclusion, the exclusion will achieve the policy evident in the Reporter's Notes to exclude all services that contain incidental transfers of licensed information. Since the current language may have been interpreted to exclude only licensed information incidental to services provided by those in a regulated profession or in entertainment services, it did not achieve the purpose of treating services and information incidental to those services as one unit governed by one law.

B. The Merely Incidental Test as an Exclusion of Licensing and Software Contracts that are a Minor Part of a Transaction

The second element of the merely incidental test determines whether Article 2B subject matter is a minor part of a transaction, and, therefore, excluded from the scope of Article 2B. Under this element, a licensing or software contract is excluded if it is "no more than a minor part of a transaction" not governed by Article 2B.¹¹⁴ The Reporter states that the test for whether the information is a minor part of a transaction is whether the "licensed information is so small a part of the transaction that it would be cumbersome, confusing and awkward to apply Article 2B to that small part of the transaction."¹¹⁵

Although the Reporter's Notes clearly state that the merely incidental test is not a predominant purpose test,¹¹⁶ this element of the merely incidental test is closely related to the predominant purpose test. The predominant purpose test is valuable because is saves time, and it is less costly than administering many different laws for one transaction. ¹¹⁷ Many jurisdictions use the predominant purpose test for these reasons when choosing between the application of Article 2 or the common law in a hybrid transaction.¹¹⁸ The merely incidental test lists the same policy reasons for its application: "it would be cumbersome, confusing and awkward to apply Article 2B to that small part of the transaction."¹¹⁹ Yet, in a situation in which the contracts were not merely incidental, Article 2B applies a gravaman of the action test in which the subject matter of Article 2B, such as software and licensed information, would be governed by Article 2B, while the subject matter of common law or other articles in the U.C.C., such as services or goods, would be governed by the applicable common law or article in the Code.¹²⁰ If the contracts were not incidental, the problems of applying more than one law would seem to be magnified.

By instituting both tests, the drafters get the worst of both worlds: litigation about the application of the merely incidental test (whether that part of the transaction is minor enough) and the cumbersome application of many laws under the gravaman of the action test. It is confusing to have both policies instituted within Article 2B. Since Article 2B was drafted to supply an appropriate body of law to the realm of software and licensing, then it seems that the gravaman of the action test should apply to all transactions, regardless of the amount of the transaction concerning software. In addition, applying the gravaman of the action test to transactions involving minor amounts of software will probably not create cumbersome problems because the software is also likely to be a minor part of the litigation. Article 2B bears much similarity to Article 2, so it should not be too cumbersome to apply both Articles. Instead of keeping the February 1998 draft language, that Article 2B does not apply to a "license of a trademark, trade name, trade dress, patent, and related know-how, unless it is part of a license that is otherwise within this article,"¹²¹ the drafters should eliminate this language and rely only on the gravaman of the action test contained in section 2B-103(d).

Eliminating this language and relying only on the gravaman of the action test avoids the problems associated with the predominant purpose test: hindsight decisions about the predominant purpose of the transaction, further litigation about the court's decision, and the application of inappropriate law to part of the transaction.¹²² Focusing on one test, instead of trying to apply both the gravaman of the action test and the predominant purpose test in different scenarios, also simplifies the law and helps promote certainty in the application of Article 2B because there will be less room for ad hoc decisions about the type of test to apply and the type of licensed information to exclude from Article 2B.

IV. Conclusion

The drafting of Article 2B fills a void in the U.C.C. by addressing the licensing and sale of software. If states adopt this uniform law, the software industry and consumers will benefit through decreased transaction costs. These benefits will only occur if Article 2B is drafted with default rules that reflect actual practices and expectations in the commercial world, and if the scope of Article 2B is clear.

The scope of the February 1998 draft of Article 2B is not clear enough to achieve a uniform application of Article 2B. The language of exclusions for embedded software and merely incidental information undermine the uniform application of Article 2B. The ambiguous language of the embedded software exclusion may lead to arbitrary exclusions of software depending on the interpretation of "embedded software" as a term of art. Instead of the ambiguous language in the February 1998 and March 1998 drafts of Article 2B, which do not illustrate the application of the term "embedded software," the drafters should use more descriptive language. This more descriptive language, based on the principles of the embedded software exclusion should guide the interpretation and application of this provision.

The February 1998 draft's ambiguous language of the condition to the exclusion regarding software that may not have been "developed specifically for the transaction" may lead to arbitrary results. A court interpreting "developed" to mean "designed, written, customized, or configured" may include software within the scope of Article 2B, whereas a court interpreting "developed" to mean only "designed" may not. Instead, the drafters should limit the application of this condition to non-mass market transactions, or eliminate the condition, as the drafters did in the March 1998 draft.

The February 1998 draft excluding merely incidental information and licenses creates two problems in the scope of Article 2B: 1) the exclusion of information incidental to services is a confusing repetition of the exclusion for services of regulated professions, and 2) the exclusion of information, if it is a minor part of a hybrid transaction, is contrary to the gravaman of the action test used for other hybrid transactions. Instead of excluding information which is incidental to services through the merely incidental test, the drafters should expand the exclusion for services from regulated professions to include all personal services, as the drafters have done in the March 1998 draft of Article 2B, and eliminate the reference to information which is incidental to services in the notes on the merely incidental exclusion. And, instead of excluding information which is a minor part of a hybrid transaction based on a merely incidental test, the drafters should eliminate the test in favor of the gravaman of the action test, thus promoting the application of the appropriate body of law regardless of the importance of the subject matter to the transaction. Use of the gravaman of the action test would ensure the consistency of the scope of Article 2B and avoid litigation about whether an information transfer or license constitutes an incidental part of the transaction.

By instituting these changes, the drafters will achieve more uniform application of Article 2B. This will increase certainty in commercial law, resulting in more efficient transactions due to reduced litigation and contracting costs.