6.1 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梤ender it of no legal
effect梠n 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.
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.
|
No comments:
Post a Comment