By Blaney Harper and Vaishali Udupa

As in-house counsel for XYZ software company, you have been tasked with protecting your client’s most precious asset — its software code. The R&D manager in charge of XYZ’s newest product has also just informed you that XYZ has developed a new "killer app" that is expected to provide XYZ with the cost and performance advantage it has been promising its customers and investors. The development of this new software has cost XYZ more than $10 million. XYZ’s marketing department has already contacted potential customers and arranged for 100 of them to receive the beta version by the end of the month. The beta product and all documentation will be distributed electronically, as will the version for general release. What do you do?

You are, of course, well aware that a chief concern with any software release is preventing a competitor from using your product to create a cheap knockoff. Certainly, this is a danger for XYZ's product. As a result, you have made sure that XYZ only ships its product in executable (i.e., object) code form. You also know, however, that some who legitimately acquire the executable code may attempt to reverse engineer it to create that cheap knockoff. In such a case, XYZ’s development investment would be lost. To guard against this risk, you have advised your client that the new product should be distributed with a license that protects the copyrighted and trade secret material in the code by, inter alia, contractually preventing a user from reverse engineering the code. Your client has agreed that it needs strong license protection and has instructed you to prepare just such a license. You have done so. The XYZ company now wants its product distributed. Can you advise XYZ that its investment will be protected when the code and associated license are electronically distributed?

The Problem

The answer to XYZ’s problem is not at all clear. Ambiguities in how to create an enforceable license arise because the intersection of state contract and federal copyright law, as applied to e-commerce, has left an enforcement void into which many licenses fall. This void exists in part because copyright law permits legitimate software users to have fair use of copyrighted material. That is, even though your code is protected from copying, federal copyright law permits users to copy enough of your code to ascertain the structure of the code that may be used to create otherwise legitimate products that interact with it. In spite of this application of federal copyright law, however, parties to a contract (enforced under state law) may agree to waive any such rights. License terms for a specific product may prevent a licensee from exercising any ability (even that otherwise available under federal copyright law) to reverse engineer the licensed code. The problem for XYZ is determining whether its mass-market electronic license prohibiting reverse engineering is enforceable, and if so, to what extent.

Software License Jurisprudence

The first cases dealing with mass market software licenses concerned so-called shrinkwrap licenses. Early decisions concerning these licenses were not favorable to their enforcement. See e.g., Step-Saver Data Sys., Inc. v. Wyse Tech., 939 F.2d 91, 105-06 (3rd Cir 1991) (failing to enforce limitations of liability on shrinkwrap license); see also Arizona Retail Sys., Inc. v. The Software Link, 831 F. Supp. 759, 762 (D. Ariz. 1993) (holding shrinkwrap agreement invalid without express assent of both parties under section 2-209). Many of these decisions focused on the battle of forms under the Uniform Commercial Code ("UCC"). See Step-Saver , 939 F.2d at 98-104; see also Arizona Retail Sys., 831 F. Supp. at 763-66.

A turning point for the enforcement of shrinkwrap licenses, however, came in the case of ProCD, Inc., v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996), in which the Seventh Circuit upheld the enforcement of such licenses. In ProCD, the license at issue restricted the software to noncommercial uses. In agreeing that shrinkwrap licenses are enforceable, so long as they do not otherwise violate generally accepted principles of contract law, the court cited the evolving nature of the software market and the role of shrinkwrap licenses in preserving the viability of the mass market software industry. See id. at 1455. The Court rejected the licensee's argument that the contractual restriction on how the software may be used was preempted by the federal Copyright Act. According to the Court, the contract claim was distinctly different from a copyright claim because the contract claim required proof of an extra element beyond that necessary for the copyright claim. That extra element was the mutual assent of the parties, necessary in any contract to make it enforceable. See id. at 1454-55.

Since ProCD, numerous courts have upheld the enforceability of shrinkwrap licenses, generally rejecting the argument that they are unenforceable contracts of adhesion. See Hill v. Gateway2000, Inc., 105 F.3d 1147, 1149 (7th Cir. 1997) (holding that contract terms inside a box of software were binding on consumer who subsequently used it); see also Mudd-Lyman Sales and Serv. Corp v. UPS, Inc., 236 F.Supp. 907 (N.D. Ill. 2002) (ruling that plaintiff has accepted terms of license by breaking shrinkwrap seal and by its on-screen acceptance of terms of software license agreement); see also M.A. Mortenson Co. v. Timberline Software Corp., 140 Wn.2d 568 (Supreme Court of Washington, 2000) (the licensing agreement set forth in the software packaging and instruction manuals was part of a valid contract).

The rationale underlying ProCD has also been extended to the electronic variation of the shrinkwrap -- the clickwrap. See DeJohn v. TV Corp. Int’l., 245 F.Supp.2d 913 (C.D. Ill. 2003) (holding that clickwrap agreement was enforceable and not an adhesion contract because user expressly indicated that he read, understood, and agreed to terms when he clicked box on Web site); see also Barnett v. Network Solutions, Inc., 38 S.W.3d 200, 203-04 (Ct of App. Tx 2001) ("by the very nature of the electronic format of the contract, [the plaintiff] had to scroll through that portion of the contract containing the forum selection clause before he accepted its terms…and that parties to a contract are not excused from the consequences resulting from failure to read the contract").

In fact, the rationale for enforcing clickwraps is even stronger than for enforcing shrinkwraps. The concern over unfair adhesion contract terms has been substantially reduced because clickwraps require an affirmative assent, not required in shrinkwraps, to the specific terms of the license. See Hughes v. McMenamon, 204 F.Supp.2d 178, 181 (D. Mass. 2002) (finding a clickwrap agreement with a forum selection clause to be valid and enforceable); see also I. Lan Sys., Inc. v. Netscout Serv. Level Corp., 183 F. Supp. 2d 328 (D. Mass. 2002) (clickwrap agreement was enforceable under the laws of the Uniform Commercial Code, because plaintiff explicitly accepted the clickwrap license agreement when it clicked the box stating "I agree"); see also Register.Com, Inc. v. Verio, Inc., 126 F.Supp.2d 238 (S.D.N.Y 2000) (holding that even though user was not required to click on an icon indicating that it accepted terms, the submission of a query itself manifested assent to be bound by contract); see also Hotmail Corp. v. Van Money Pie, Inc., 1998 U.S. Dist. LEXIS 10729, No. C98-20064, 1998 WL 388389 (N.D. Cal. April 16, 1998) (in an action for preliminary injunction, the court found that an Internet provider was likely to succeed on breach of contract claim where defendants breached terms of "clickwrap" service agreement).

Prohibitions on Reverse Engineering Clauses

While shrinkwrap and clickwrap licenses are generally enforceable, the question of enforcing a specific prohibition on reverse engineering in such a license is still open. The oft-cited basis for arguing that an anti-reverse engineering provision should not be enforced is that federal copyright law preempts state enforcement of laws equivalent to any of the exclusive rights protected by copyright. The preemption argument is generally made in two versions. In the first version, licensees assert that there is a federal right under the Copyright Act to reverse engineer software code and that this federal right constitutionally supercedes any state law. In the second version, licensees assert that the Copyright Act itself expressly preempts enforcement because the act of reverse engineering is equivalent to rights protected under copyright law. Hence, state enforcement of any license provision prohibiting reverse engineering is equivalent to a state law that prohibits copying and is statutorily preempted.

No Federal Right to Reverse Engineer Software. The first version of the preemption argument — a federal right to reverse engineer — is based on a perceived extension of certain caselaw. In two widely cited decisions, Sega Enterprises, Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1993) and Sony Computer Equipment v. Connectix Corp., 203 F.2d 596 (9th Cir. 2000), the Ninth Circuit held that disassembly of computer code may be a fair use of a copyrighted work if disassembly is the only way to gain access to the ideas and functional elements embodied in the work and there is a legitimate reason for seeking such access. While these cases are cited as support for a general policy of a federal right to reverse engineer software regardless of license restrictions, the cases themselves make no such holding.

Sony and Sega are explicit in their analysis that the acts constituting reverse engineering in any particular case must be evaluated under the statutory framework for a fair use defense to copyright infringement. See Sega Enterprises, Ltd., 977 F.2d at 1521; Sony Computer Entertainment, 203 F.3d at 602. This fair use defense is equitable in nature and is applied to any one case based on a number of factors. As a result, the same reverse engineering acts (e.g., disassembly) may be characterized as "fair use" in one context (e.g., product code legitimately acquired) but may not be so characterized in another (e.g., product code stolen). Since such reverse engineering acts are analyzed as an equitable fair use defense, and not a right to affirmatively perform reverse engineering under any circumstances, there is no conflict between federal statutory rights and state enforcement of license provisions concerning reverse engineering.

The case law is also clear that merely because a contract relates to copyright or other intellectual properly does not mean that federal intellectual property law supercedes state enforcement of the contract. The "states are free to regulate the use of such intellectual property in any manner not inconsistent with federal law." Aronson v. Quick Point Pencil Co., 440 U.S. 257, 262, 99 S.Ct. 1096, 1099 (1979) (emphasis added). State enforcement of an agreement between private parties does not withdraw any idea from the public domain. Id. at 262-263. In contrast to laws regulating general public conduct, "[p]arties to a contract may limit their right to take action they previously had been free to take." Universal Gym Equipment, Inc. v. ERWA Exercise Equip. Ltd., 827 F.2d 1542, 1550 (Fed. Cir. 1987). Significantly, the Sony and Sega cases did not involve a license restriction between private parties. Nothing in those cases limits a party's ability to contract away any statutory rights they might otherwise have. Accordingly, state enforcement of a specific contractual prohibition on reverse engineering between private parties is not superceded by any federal 'fair use' rights because there is no conflict between the federal law and the contractual rights of private parties.

Moreover, even if copyright fair use were considered a federal right superceding contract rights, the scope of such a right would be particularly narrow in the specific context of reverse engineering program code. As noted above, any fair use right is only permissible to gain access to the ideas and functional elements of the code. As explained in Atari Games Corp. v. Nintendo of America, Inc., 975 F.2d 832 (Fed. Cir. 1992), fair use is a limited exception to the scope of copyright protection and "is not an invitation to misappropriate protectable expression. Any reproduction of protectable expression must be strictly necessary to ascertain the bounds of protected information within the work." Id. at 843 (emphasis added). It is the rare case in which code is reverse engineered solely to determine its functions and ideas. Such information is typically available by simply running the actual program. In the usual case, the entire body of product code is reverse engineered and substantial portions reused in the knockoff product because it is simply cheaper and easier to use what an original author has already created. Fair use does not protect such copying.

Statutory Preemption of State Contract Enforcement. The second version of the preemption argument — statutory preemption — is based on §301 of the Copyright Act, which expressly preempts state laws equivalent to any of the exclusive rights protected by §106 of the Copyright Act. Briefly, the general argument is that, because reverse engineering software necessarily involves copying, state enforcement of any such agreement restricts copying and is preempted by §301. The authority usually cited in support of this analysis is Vault v. Quaid, 847 F.2d 255 (5th Cir. 1988). In Vault, a licensor had sought to prevent a licensee from disassembling its software as prohibited by the terms of a license agreement. The license-at-issue was a shrinkwrap-type agreement that incorporated terms conforming with a Louisiana state statute. The district court had found that the license-at-issue was a contract of adhesion that could not be enforced (whatever its terms) unless such enforcement was permitted by the Louisiana state statute. The 5th Circuit affirmed the district court's analysis that the Louisiana state statute was unenforceable as being preempted under §301 of the Copyright Act. Neither the 5th Circuit nor the district court, however, found that an otherwise enforceable contract was statutorily preempted because of the prohibition on copying. Accordingly, the holding in Vault is substantially narrower than it is frequently portrayed.

Beyond the general statutory preemption argument of Vault, there are a number of cases in which it has been argued that specific license agreements having certain anti-reverse engineering provisions are preempted. The most recent appellate case is Bowers v. Baystate Technologies, 320 F.3d 1317 (Fed. Cir. 2003). The Bowers case involved software for improving a computer-aided design (CAD) process. The plaintiff copyright owner distributed its software using a shrinkwrap license that prohibited reverse engineering. The defendant Baystate legitimately acquired the software and then used the software in violation of the license prohibition on reverse engineering to create a competing product. The ensuing lawsuit involved claims for copyright infringement and breach of contract. Baystate contended that the Copyright Act preempted the prohibition of reverse engineering embodied in Mr. Bowers' shrinkwrap license agreement. The Federal Circuit, applying First Circuit law, found that the license prohibition against reverse engineering was not preempted by the Copyright Act.

In this case, the Federal Circuit noted that the question of whether the Copyright Act preempts a state law contract claim concerning alleged copying had not been expressly addressed by the First Circuit. The Court, however, indicated that it would be guided by the preemption principles set out in Data General Corp. v. Grumman System Support Corp., 36 F.3d 1147 (1st Cir. 1994) in which the First Circuit held that the Copyright Act did not preempt a state law trade secret claim. In Data General, whether a claim was preempted under 17 U.S.C. § 301 was determined by evaluating the so-called "extra element" test. That is, does the state claim at issue require proof of more than the specific acts protected by copyright? The particular claim-at-issue in Data General was for trade secret misappropriation that required proof of trade secret status and confidentiality. Clearly, trade secret status and/or confidentiality are not required to prove a copyright claim. As a result of those extra elements, the state trade secret claim in Data General was not equivalent to copyright and, hence, not preempted.

While the Bowers case did not involve the trade secret or confidentiality elements of Data General, it did involve a contract between private parties. The Federal Circuit noted that, in ProCD as discussed supra, the mutual assent and consideration required by a contract renders a contract claim qualitatively different from a copyright claim. Bowers, 320 F.3d at 1325. The Court also stated that "[t]he shrink-wrap license agreement prohibited… all reverse engineering of [plaintiff's] software, protection encompassing but more extensive than copyright protection, which prohibits only certain copying." Id. at 1327 (emphasis added). As a result, the contract claim in Bowers met the extra element test of Data General and was not preempted. In making this holding, the Federal Circuit expressly noted that it had left untouched the Atari decision regarding reverse engineering as fair use. Id. at 1325. Moreover, it distinguished the Vault v. Quaid case because that decision did not involve a private contract. Id.

The Black Dot Law. The Bowers majority opinion drew a dissent from Judge Dyk in which he asserted that the majority had provided an invitation for states to undermine extensively the protections of the Copyright Act. Bowers, 320 F.3d at 1335. While Judge Dyk agreed with the majority that license prohibitions against reverse engineering are enforceable in freely negotiated contracts, he nonetheless asserted that such prohibitions in shrinkwrap licenses were simply state protection for material otherwise unprotectable under the federal copyright law. Id. at 1336-1337. In particular, Judge Dyk complained that shrinkwrap licenses were not enforceable because they are contracts of adhesion in which the only choice offered is avoidance of the purchase altogether. According to Judge Dyk, the shrinkwrap license restrictions were no different than a state law in which a copyright holder bars fair use of the work by simply placing a "black dot" on the copies of works offered for sale. Since this hypothetical black dot law would clearly be preempted under copyright law, so should reverse engineering clauses in shrinkwrap licenses. Id.

Although Judge Dyk's analysis did not prevail in Bowers, it does find some support in other jurisdictions. Notably, in California, state courts have rejected the notion that the mutual assent necessary to form a contract is an "extra element" sufficient to avoid preemption. In Kabahie v. Zoland, 102 Cal.App. 4th 513 (2002), a state appellate court extensively reviewed copyright preemption law including its legislative history. The Kabahie court adopted what it contended was the majority view that "[t]he mere breach of the promise inherent in every contract does not constitute the requisite extra element [to avoid preemption] unless the promise creates a right qualitatively different from copyright." Id. at 528 (emphasis added). While the Bowers decision avoided preemption by resting on both the extra elements of mutual assent and specific reverse engineering acts other than copying, Kabahie suggests that, in a majority of districts, a licensor should not rely solely on mutual assent as an extra element to avoid statutory preemption.

Avoiding the Black Dot

In spite of the unsettled law concerning the enforcement of anti-reverse engineering provisions in mass market software licenses, it is clear that a software developer can increase the likelihood of having such license provisions enforced. The software developer should take care to i) properly structure the physical form of the license and ii) specifically recite acts prohibited by the license. First, the physical form of the license should be in the nature of an electronic clickwrap-type agreement having a strategically placed "I Agree" (or equivalent) button gating access to the product. As noted above, requiring users to acknowledge reading license terms (even if they do not actually read them) enhances the likelihood of proving that your license is not a contract of adhesion. Care should also be taken, however, to ensure that the acknowledgement button is placed in such a way so as to avoid hiding important license terms. For example, an arbitration clause in a clickwrap agreement was found to be unenforceable because the format of the user's acceptance did not give reasonable and conspicuous notice of the existence of the arbitration clause. Specht v. Netscape Communications Corp., 306 F.3d 17, 35 (2nd Cir. 2002) (holding that downloading of a software did not constitute acceptance of defendant's license terms because terms were hidden below the "download" button on the next screen).

Beyond the physical form of the license, an anti-reverse engineering provision in the license should also recite that the information contained in the software is confidential and subject to protection as a trade secret. The key here is that the tools for protecting software are not limited to only one of copyright or trade secret or contract law protection. Rather, software is frequently subject to all three protection schemes (and others) at once. Also, software code generally includes substantial amounts of confidential and/or trade secret material. Accordingly, to the extent that clearly non-copyright-related terms (e.g., confidentiality) can be incorporated into an anti-reverse engineering provision of an agreement, the greater the likelihood of showing an "extra element" and of avoiding preemption. See e.g. Firoozye v. Earthlink Network, 153 F. Supp.2d 1115, 1130 (N.D. Cal. 2001) (holding that trade secret misappropriation claim includes an extra element of secrecy that makes the claim qualitatively different from a copyright infringement claim).

Additionally, anti-reverse engineering provisions should specifically identify those acts that the licensor understands to constitute reverse engineering and that are to be prohibited. The phrase "reverse-engineering" has been argued to cover everything from straight decompilation to the simple monitoring of data as it moves across electronically accessible buses. See, e.g., Sony, 203 F.3d at 300. Some of these acts (e.g., loading software into memory) are similar to copying and some (e.g., monitoring certain data sequences) are not. Also, while decompilation and/or disassembly of code may be techniques generally applicable to most software, other techniques such as detection and use of interface protocols may not be applicable to some products. To the extent that acts particularly suited to uncovering the operation of specifically sensitive licensed product code can be identified before product distribution, those acts should be explicitly recited in an anti-reverse engineering license provision. Reciting such acts enhances the likelihood of showing that the provision applies to conduct other than copying, hence avoiding preemption.

Finally, notwithstanding the techniques discussed above, a licensor should anticipate that its anti-reverse engineering provision will be circumvented by some as-yet undetermined technique. To prevent commercial harm arising from such circumvention, the licensor should provide contractual remedies that protect licensor's investment in its code. That is, assuming that the software product is legitimately used (in whatever unanticipated fashion) to derive a competing product, the license should contractually limit or otherwise condition use of any derivative product by the licensee. Such field-of-use restrictions may, but need not, mirror the restrictions made in the provision granting rights to the licensee in the underlying software. For example, a licensee who legitimately creates a competing derivative product may be contractually obligated to use that derivative product only for noncommercial uses. Alternatively, use or other distribution of the derivative product may be contractually limited to particular institutions or in certain territories. There is a wide variety of contractual restrictions that limit the potential use or further distribution of a derivative product. The applicability of any one of them will depend on the particular software and business involved. Nonetheless, by applying such restrictions on the derivative product, the licensor discourages reverse engineering of its product in the first instance and increases its likelihood of retaining the investment value in its software product in its particular business area even in the event that the operational details of its product have been revealed.

Conclusion

Mass market electronic licenses are an integral component of the business of software products and services. Through these licenses, businesses protect their development investment and resulting revenue stream. A key to any such protection is a license structure that prevents the creation of competitive products through reverse engineering of the original. Enforcement of such licenses, however, may depend on avoiding the Black Dot copyright preemption problem. By paying attention to the nature of the specific software product, and its use in the market, the license can be drafted to avoid the preemption problem and protect the commercial value in the software. Such license protection will improve your company's ability to realize the market potential for its software products.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.