Understanding Open Source and Free Software Licensing

Chapter 6. Legal Impacts of Open Source and Free Software Licensing

All of the discussions in earlier chapters have assumed that each of these licenses can be and will be enforced by their licensors, and, ultimately, by the courts. However, two unique problems (in addition to those involved in the enforcement of any contract) affect licensors of software under open source and free software licenses.

First, for each license described in previous chapters, the licensor may not even know who the licensees are. All of these licenses, to varying degrees, put forth the licensed code with an invitation to adopt it and use it, subject to the terms of the respective licenses. These open source and free software licenses do not require notification or other affirmative action to be taken by licensees that would notify the licensor of the fact that the licensee has entered into the contract.^[1] In addition, most of these licenses permit and even encourage the free sublicensing of the licensor's work to other licensees, whose connection to the original licensee can become tenuous as the licensed work moves through multiple generations of licensing before ending up with a particular user.

Second, while some of these licenses require that the licensee engage in some affirmative action to access the licensed work (such as clicking on a button indicating that the licensee agrees to be bound by the terms of the license) prior to permitting access of the licensed work, many of them—like the BSD, MIT, and Apache Licenses—do not. Others, like the GPL and LGPL, do not require such affirmative assent in all cases.

Both of these problems are substantially addressed by the fact that use of the licensed work is contingent on accepting the terms of the license. Unlike other types of contracts, open source and free software contracts impose very few, if any, affirmative obligations (such as the payment of royalties) on licensees, but rather impose restrictions only on the rights granted by the license. This property will operate, most likely, to save the enforceability of these licenses from challenges regarding the absence of mutual consent or consideration that may otherwise arise.

Entering Contracts

Any contract between two or more persons rests on two fundamental assumptions: one, that there is some mutual obligation created by the agreement, which is known as the consideration ; and two, that there is mutual consent, or a meeting of the minds, as to the terms of the contract, usually described as the offer and the acceptance . Once an offer that involves the exchange of consideration has been made and accepted, an enforceable contract is created. This principle is, of course, subject to numerous exceptions.

These concepts are capable of any number of variations and any number of hard cases involing these variations provide the subject matter for first-year law students. Basic principles suffice for our purposes. The idea of consideration turns on the fact that each party is undertaking an obligation, even a very minor one, to the other as part of the transaction. If Robert promises to give Sidney $10,000 in one year, and Sidney does nothing and agrees to do nothing, there is no contract, but only a promised gift. The significance of this is that such a promise is not legally enforceable. If Robert does not pay, Sidney cannot legally compel him to pay. However, if Robert agrees to pay Sidney $10,000 in one year if Sidney forbears from drinking alcohol for that entire time, that creates an enforceable promise: if Sidney fulfills her half of the bargain, she can legally compel Robert to live up to his, even though the consideration (abstinence from alcohol) that she promised (and performed) has at most only a very tangential benefit to Robert.

Even the most unrestrictive open source license imposes at least a minimal obligation ensuring that consideration in the legal sense is exchanged and an enforceable contract is created through the license. The MIT License, described in Chapter 2, imposes the following restriction on licensees:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

While this obligation is not onerous, it is real, and failure to abide by it constitutes a breach of the contract. By extension, the more onerous restrictions imposed by the GPL, the BSD, the Apache, and all of the other open source and free software licenses already described impose sufficient obligations so as not to fail as contracts for lack of consideration. The licensor grants a real benefit, the right to use the licensed software, and the licensee agrees to genuine restrictions, i.e., those that are expressed in the license.

Potentially more problematic is the question of mutual consent. In an ordinary commercial contract, this question rarely, if ever, arises. In general, mutual consent can be attacked only in relatively unusual circumstances. In the classic formulation of a contract, the two parties to the contract have met, negotiated, and reached final agreement, embodied in a formal, signed document. Under those circumstances, the consent of either of the parties can be attacked, essentially in only two ways. First, one of the parties can argue that his consent was induced by fraud , i.e., that the other party deceived him as to a fact material to the contract. For example, two parties may agree to a contract that provides for the sale of a document signed by Elvis Presley. The genuineness of the signature is critical to the contract. If the buyer can prove that the signature was a forgery and that the seller knew it, he can void the contract—render it of no legal effect—on the grounds of fraud. Second, mutual consent can be attacked on the basis of incompetence . In most jurisdictions, a person under the age of 18 cannot enter into a binding contract. Accordingly, if such a person enters into a contract, she can sue to have the contract voided on the basis that she was incompetent to enter into the contract in the first place.

While these circumstances appear in numerous variations and can present difficulties in interpreting contracts and adjudicating disputes that arise from them, they are relatively clear cut assaults on the mutual consent to a contract. However, because of the absence of a writing signed by both parties formally indicating their agreement to a contract, the open source and free software licenses described earlier present a different, and more complex problem.

It has long been accepted that contracts may be formed in the absence of a signed document. Oral contracts, with significant exceptions, are regularly enforced. The familiar " shrinkwrap" license that frequently governs the use of commercial software is more applicable to software contracts. The user purchases the software; the box in which the media containing the software is sold indicates that use of the software is governed by a license; and the purchaser is further informed that breaking the shrinkwrap and opening the box indicates the user's consent to the license agreement. Some courts have upheld the creation of a contract under these terms; other courts have not. A potentially critical distinction, described in more detail later, is the extent to which the purchaser was aware (or could have made himself aware) that the software was provided subject to a license and could have learned the terms of the license that would govern the use of the software.

These questions become more difficult when the product and the license both exist in a virtual space and the offer and acceptance both take place there. There are a number of different contexts in which this kind of offer and acceptance can take place, and small differences can be critical in determining whether a contract is formed. For the following examples, a web site is posited as the locus of the contract, although the same issues could arise as easily with software recorded on a physical medium, such as a CD-ROM.^[2]

In the first example, an icon appears on the introductory screen for a piece of software, indicating that that software is being provided subject to the terms of a license. A user who wants to view the terms of the license can click on a hyperlink that takes him to a page displaying the terms of the license. Another hyperlink links to the site from which the software can be downloaded. This " browsewrap" license may create an enforceable contract: the user (or purchaser) is at least made aware that the software is produced subject to a license, but he is not required to assent to the terms of the license, or even to look at it, before accessing the licensed work. The enforceability of this kind of contract is, however, subject to dispute and this arrangement may not result in a contract that would be enforced.

The second example, the so-called " clickwrap" license, is more likely to create an enforceable contract. In this variation, the user is required to view, however fleetingly, the terms of the license and to take some affirmative action to agree to its terms, such as by clicking a button that says "Yes, I have read this license and I agree to its terms," before accessing the licensed software. This is the form of license contemplated in some of the licenses described earlier and will generally provide sufficient notice to the user of the terms of the license and require sufficient affirmative action to create an enforceable contract, so long as the other requirements of contract are met, such as the competence of the parties and the absence of fraud.

A variant of the "clickwrap" and "browsewrap" licenses, in which the user only views the license and is not required to take any affirmative action indicating consent to the licensed terms, but where consent is implied from some other action (usually the downloading of the licensed software), may or may not be sufficient to create an enforceable contract. The licensee knows of the license, knows it governs use of the software, and has the opportunity to review it before accessing the software. Nonetheless, the absence of affirmative consent (such as clicking on a text box as required by the "clickwrap" license) is troubling to courts, and correctly so. It seems unfair to enforce terms of a contract to which one of the parties has done nothing to positively affirm.

This issue has obvious application to the open source and free software licenses already discussed. Staying with the MIT License, say, for example, that an ordinary user comes across a piece of code that is subject to this license. The user takes the code and uses it on his personal computer. The user incorporates the code into a program that he is writing. The user distributes the program, either for profit or not. At no point has the user taken any affirmative, symbolic action that would indicate his consent to the terms of the license that is comparable to the act of signing a contract.

---

^[1] The SCSL, which is not an open source or free software license, although it incorporates some of their principles, does require some form of notification. The Microsoft Shared Source Initiative operates under totally different custom-negotiation principles, so they know who they are dealing with from the outset.

^[2] Readers interested in a more detailed legal analysis should read the opinion of Judge Alvin K. Hellerstein in Specht v. Netscape Comm. Corp., 00 Civ. 4871 (AKS), 2001 WL 755396 (S.D.N.Y. July 5, 2001).Such contracts arise outside the world of software licensing as well. Ticket stubs—such as those received at coatchecks or parking garages—which typically disclaim any liability for checked items, present similar issues.