Licenses as Contracts

Read in a different light, open source licenses contain promises, just like ordinary contracts. In effect, each licensor promises, subject to certain terms and conditions, not to interfere with licensees who copy, modify, distribute, make, use, and sell open source software embodying the licensor 's intellectual property. Licensees rely on those promises when they adopt open source software to do useful things.

Many open source licenses are designed as contracts.

A contract is a promise or set of promises for breach of which the law gives a remedy, or the performance of which the law in some way recognizes as a duty. (Restatement, Second, Contracts § 3.)

A promise is a manifestation of intent to act or refrain from acting in a specified way, so made as to justify a promisee in understanding that a commitment has been made. (Restatement, Second, Contracts § 2.)

I'll discuss later in this book the specific promises made (express and implied ) in open source licenses. In particular, there are software licenses called unilateral contracts , in which only the licensor makes promises, and other licenses called bilateral contracts , in which both parties make promises. Most open source licenses are unilateral in intent. (Even lawyers who draft licenses are sometimes confused by these concepts; you will occasionally find terms of art, such as "licensee agrees" promissory language appropriate for bilateral contracts, in otherwise unilateral contracts.) For now, it is important only to identify the differences between a bare license and a contract.

Contract law, unlike copyright and patent law, provides procedures and rules for license interpretation and enforcement. Contract law, in the published court decisions and in the statutes adopted by legislatures around the world, addresses almost every possible term or condition a lawyer could dream up for a contract. Contract law specifies how contracts are to be formed , how they are to be interpreted, how they are to be enforced, and the remedies for breach. In many situations, where a license is silent about a particular term or condition, contract law even provides default "fill-in" provisions.

Some suggest that since contract law varies around the world, open source contributors and distributors should rely exclusively on consistent copyright and patent law for their licenses. But the varieties of contract law are exaggerated, as are the similarities of copyright and patent law around the world. The global requirement for consistency of commercial transactions ”a requirement of the capitalist market system ”helps ensure that contracts are interpreted in much the same way around the world. Meanwhile copyright law is not consistent; the courts around the world, for example, don't agree on what constitutes a derivative work of software. That is why it is sometimes better for an open source contract to define the term derivative work than to have a bare license simply use that term of art as if it had a consistent meaning worldwide.

Unlike a bare license, a contract can be enforced by a licensor even if he doesn't own the underlying copyrights and patents. This means that a distributor of software can enforce his contract against his licensees without needing the approval of the copyright and patent owner(s) to do so. For open source software containing original software contributed by programmers worldwide, it can be particularly important for a distributor to be able to enforce his licenses even without owning the underlying patents or copyrights.

Finally, the generally accepted rule that the contract is the law encourages us to create complete licenses that state the terms and conditions as clearly as we want. We don't have to rely on vague interpretations of copyright or patent law since we can write the law-of-the-contract exactly as we want it to be enforced. For example, later in this book I will describe two recent open source licenses, the Academic Free License (AFL) and the Open Software License (OSL), that specify in contract form and in clear and precise terms the rules for open source licensing. Those licenses ”one an academic license and the other a reciprocal license, but otherwise identical ”are intended to be enforceable under both contract and copyright law.

The main difference between a bare license and a contract is in the way the relationship between licensor and licensee is formed. To create a contract, there must be an offer and acceptance, and there must be consideration. I will describe these three elements in turn . (In first-year contract law courses, these elements are often referred to as the legs of a stool; a contract is the seat of the stool; it will fall if any of the legs ”offer, acceptance, or consideration “fails.)

None of these three elements is needed for a bare license.

Offer

An offer is fairly simple in the software licensing context.

An offer is a manifestation of willingness to enter into a bargain so made as to justify another person in understanding that his assent to that bargain is invited and will conclude it. (Restatement, Second, Contracts § 24.)

In an open source license, the licensor offers to allow licensees to copy, modify, and distribute the licensed software for any purpose whatsoever in accordance with the Open Source Principles in Chapter 1.

The appropriate manifestation of willingness required for an offer can be (and often is) expressed by posting the software on some Internet portal like SourceForge or on a public website in such a way that all prospective licensees will be able to retrieve the software under the terms of the license. Open source distributors offer licenses to everyone.

Acceptance

The offer empowers the licensee to create a contract by his acceptance. The second step in forming a contract, then, is for the licensee to accept it. He must intend to accept it.

Traditionally, a signed written agreement is evidence of both offer and acceptance, but that is no longer practical with the mass marketing of software. The most typical way to obtain acceptance of a software license is to require licensees to express their assent in a positive way, such as by making a purchaser of boxed software open an inner package that boldly announces the presence of the license (known as shrink-wrap ), or by making someone who downloads software click on an "I ACCEPT" button on a website (known as click-wrap ). Many courts around the world now agree that clicking on "I ACCEPT" or tearing the shrink-wrap is ample evidence that the licensee accepted the contract.

The law doesn't require shrink-wrap or click-wrap. Indeed, for many forms of software distribution and installation, neither of those specific techniques is appropriate. Any acceptance procedure that ensures an explicit manifestation of assent is usually sufficient. Even that is difficult to accomplish when open source software is merely posted and distributed on the Internet. So it is important to understand the implications of not obtaining an explicit manifestation of assent up front. There are three alternative situations:

• Both parties can later affirm that they intended to form a contract and agree to abide by its terms and conditions. That subsequent stipulation suffices to prove acceptance. (The courts won't care as long as the parties agree among themselves .)

• The licensor wants out of the contract: In the case of a unilateral contract (such as almost all the open source licenses in this book) in which the licensor is the only one making promises, the subsequent testimony of the licensee that he intended to accept the contract and that he acted in reliance on it is usually sufficient evidence of acceptance even if the licensor now wants out of the contract.

• The licensee wants out of the contract: As long as the licensor wants to enforce the contract, the licensor has the burden of proving that a contract was formed. This situation demonstrates why licensors should demand an explicit manifestation of assent that they can introduce as evidence if necessary.

Consideration

The third requirement for contract formation, consideration, is often the most complicated.

(1) To constitute consideration, a performance or a return promise must be bargained for.

(2) A performance or return promise is bargained for if it is sought by the promisor in exchange for his promise and is given by the promisee in exchange for that promise.

(3) The performance may consist of (a) an act other than a promise, or (b) a forbearance, or (c) the creation, modification, or destruction of a legal relation. (Restatement, Second, Contracts, § 71.)

If the requirement of consideration is met, there is no additional requirement of (a) a gain, advantage, or benefit to the promisor or a loss, disadvantage , or detriment to the promisee; or (b) equivalence in the values exchanged; or (c) mutuality of obligation. (Restatement, Second, Contracts, § 79.)

Taken together, these two legal principles from the Restatement prevent the enforcement of a gift , which may have both offer and acceptance but lacks the element of consideration. Section 79 in particular makes it clear that the value of the consideration, while it can't be zero, doesn't need to be very large at all. Early legal scholars made the point that a peppercorn could be sufficient consideration for a contract.

To cut to the chase, I'll refer to the following Simple License:

The copyright owner of this software hereby licenses it to you for any purpose whatsoever.

This is, of course, a bare license. Like any bare license, it is enforceable by the copyright owner under copyright law and can be revoked by the licensor at any time.

Assume, now, that we want this Simple License to be treated as a contract so that it can be enforced under contract law and so that it cannot be revoked. Assume also that we have satisfied the procedural requirements for offer and acceptance. Where can we find consideration in the language of the Simple License?

Laws in some jurisdictions provide that specified types of promises are enforceable without consideration. This is usually restricted to certain commercial transactions and written contracts. While it is not common now, the growth of the open source software industry may eventually demand that, by statute , the grant of a written license to computer software in commercial settings creates an enforceable contract between licensor and licensee even in the absence of consideration. Without such a legal exception, however, we must find consideration or we don't have a contract.

Perhaps we can look deeper into the Simple License to find consideration, even though consideration isn't among the express words of the license. Consideration might be implied.

The licensor's detriment is an implied result of copyright law. The licensor has licensed the otherwise exclusive rights under copyright, and as to that licensor, forbearance to enforce those exclusive rights is detriment (e.g., consideration) enough.

What about consideration or detriment by the licensee?

The easiest way for the licensee to ensure that the Simple License can be enforced as a contract is if he pays a royalty or license fee for the software to be used, copied , modified, and distributed. It needn't be much, and perhaps a penny is sufficient, but there must be consideration by the licensee or there is no contract. (That is not contrary to the Open Source Principles; some open source software is sold in stores.) That demand for payment needn't be expressed in the Simple License itself, because although consideration is an element of contract formation, it is not necessarily a part of the contract itself. Consideration may be obtained by demanding a license fee before allowing download of open source software. Of course, licensors should avoid sham consideration ”such as a penny ”that might convince a court that a gift rather than a contract was intended.

Many customers obtain their open source software from established commercial enterprises either combined with hardware and services or as part of a comprehensive support package. Those associated agreements often establish the element of consideration that is required for treating the license itself as a contract.

But ultimately, the issue of price is irrelevant for most open source software. Most is available truly free of charge for those who want it. Not even a penny is demanded for its download. Where can we find consideration by a licensee in an open source license that otherwise promises the free use of software ”at zero price ”and allows copies and derivative works to be distributed without payment of royalties? (See Open Source Principles # 1, 2 and 3.)

This question becomes even more confusing when we realize that open source licenses are almost always written as unilateral contracts in which only the licensor has made promises. At no time has the licensee been requested to bind him- or herself to do anything, and even if the licensee starts to use the software that licensee is not bound to continue to do so. A court may find the necessary detriment to the licensee, and thus the necessary consideration, in the very act of using, copying, modifying, and distributing the software. This is the basis of the contract law doctrine of promissory estoppel , in which detrimental reliance becomes a substitute for consideration. The law of contracts describes it as follows :

A promise which the promisor should reasonably expect to induce action or forbearance on the part of the promisee or a third person and which does induce such action or forbearance is binding if injustice can be avoided only by enforcement of the promise. The remedy granted for breach may be limited as justice requires. (Restatement, Second, Contracts, § 90.)

A court may find detrimental reliance by licensees who have accepted open source software for use in the infrastructure of the modern economy. It is inconceivable to me, for example, that licensors of Linux, or Apache, or any of the other major open source software packages, would be allowed to revoke their licenses for lack of consideration. But it remains to be seen whether promissory estoppel will generally serve as a substitute for consideration in open source licensing. It has never been tested in court.

Just because there is uncertainty about the element of consideration shouldn't lead us to ignore the other two elements of contract formation, offer and acceptance. A court is unlikely to find promissory estoppel when licensors haven't even made the effort to offer clear promises in the first place and to get them accepted.

If open source licenses are to be treated as contracts, all three elements of contract formation should be satisfied wherever possible.

Failure of Offer, Acceptance, or Consideration

Of all the licenses described in this book, only the GPL makes the explicit point that it wants nothing of acceptance or consideration :

You are not required to accept this License, since you have not signed it. ( GPL section 5.)

You must cause any work that you distribute or publish ... to be licensed as a whole at no charge to all third parties under the terms of this License. (Underline added; GPL section 2[b].)

The GPL authors intend that it not be treated as a contract. I will say much more about this license and these two provisions in Chapter 6. For now, I simply point out that GPL licensors are in essentially the same situation as other open source licensors who cannot prove offer, acceptance, or consideration. There is no contract.

What is left? Even if the contract fails, a bare license remains, and that license can be enforced under copyright law ”with all the limitations on such enforcement actions described earlier ”or it can be revoked.

Here is how the Open Software License and the Academic Free License make this legal point:

Any use of the Original Work outside the scope of this License or after its termination shall be subject to the requirements and penalties of the U.S. Copyright Act, 17 U.S.C. § 101 et seq., the equivalent laws of other countries , and international treaty. This section shall survive the termination of this License. ( OSL / AFL section 11.)

Even if this provision isn't explicit in all open source licenses, that's probably the way the law will treat the situation anyway.

Also note that licensees have little to gain by denying the existence of a contract unless they're willing to have their licenses revoked, and licensors almost always want their contracts enforced. Litigation about contract formation issues probably won't arise in commercially relevant situations.