Manifestation of Assent
There's been an interesting academic argument going around in certain legal and open source circles about how to make sure that our software licenses are enforceable.
Most open source licenses you'll find at www.opensource.org and all proprietary software licenses you'll find anywhere are to be interpreted under contract law. They can be enforced, like other contracts are enforced, against both a licensor and a licensee.
Contracts can almost always be enforced against a licensor. If a licensor promises you the source code or promises not to interfere with your lawful uses of the software, he is bound by those promises as long as you reasonably relied on those promises when you accepted the contract. The general rule is that the author of a contract is bound by his own words.
In most jurisdictions, contracts can be enforced against a licensee only if the licensee agreed to be bound to the contract.
There are two things that a licensor must worry about, then, when creating a software license:
What are the terms of the license I want to enforce against a licensee? Rather than confuse everyone, I'll say nothing more about the content of contract licenses in this article, except to note that in most jurisdictions the parties can agree to almost any damn fool thing they want, except those things which are against public policy. I'll probably write another article about this someday.
How can I make sure that a licensee agrees to be bound to the license? This is the important issue of contract formation.
Here's where I always get flamed on SlashDot or license-discuss. The law usually requires that the party seeking to enforce the terms of a contract be prepared to prove that the other party agreed to those terms. There must be some clear manifestation of assent by the "obligee" (i.e., the obligated party) that can be presented as evidence to show that a contract was actually formed between the parties.
Many cases have been lost because the licensor's procedures for contract formation were faulty and he cannot present evidence manifesting assent by the licensee.
In the early days of proprietary software, all software licenses were documented by a writing signed by the parties. Signed documents are the most obvious form of manifestation of assent. When you contract for real property, for example, written documents are often the only acceptable manifestation of assent. But this procedure is no longer typical for software. With mass market distribution of software we now use shrink-wrap, click-wrap or browse-wrap techniques to manifest assent.
Even as the technology changed to accommodate mass market software, the courts continued to struggle with contract formation issues in the software context. Simply uttering the magic words "click-wrap" didn't automatically win the case. Licensors continued to lose where they hadn't done what was reasonable to make sure that the licensee became aware of the license and had an opportunity to read and manifestly accept the license terms, before he began to use the software.
Notice that the law never requires that a licensee actually read the license terms. If you're foolish enough to agree to something without reading it, the courts say, you can't claim foolishness as a defense. (Insanity, however, remains a defense to contract formation, as does "infancy"--meaning, in many states by some perverse historical twist, anyone under the age of 18.)
I finally realized yesterday, after engaging in a particularly acrimonious debate on this topic with some friends of mine, that one reason I'm being flamed is because I keep referring to this issue as the "click-wrap notice." I'm confusing the technology with the legal principle, and the terminology is earning me battles I don't need.
What I really mean to say is that the law requires some manifestation of assent to prove that a contract was actually formed.
We lawyers like to play what-if games with each other in which we imagine strange scenarios, such as, does the mere fact that the licensee knew that there was a license when he used the software manifest his assent to form a contract? What if the cable repair guy installed the software and the user didn't even know the software was there? What if someone told his insane 17-year-old son to accept the license and install the software for him?
The answers are the same in each case: Look for a specific statute in your jurisdiction that covers the situation or go ask the judge what she thinks.
Obviously I can't punt that way when my own client asks me what to do to ensure that contract formation is done correctly. That is why I suggest to clients distributing end-user software over the Internet that they present the end-user with a dialogue box requiring the licensee to AGREE with the license before they get the software. (Usually this is called "click-wrap".) Clicking, previous courts have held, can be an acceptable manifestation of assent. When done correctly, a click-wrap procedure is an easy and effective way to accept licenses.
It isn't the only manifestation of assent possible, and indeed click-wrap doesn't work in many situations. For example, FTP downloading procedures aren't amenable to click-wrap procedures. For another, click-wrap can become onerous when licensors require clicking for each package in a multi-package distribution. In some situations it may be more appropriate to implement a splash-screen to indicate license terms. It may be that prominent notices in the product documentation will suffice to ensure that knowledgeable users knew about and assented to the licenses.
Contract formation cases present fact-specific and jurisdiction-specific legal questions that don't always have easy answers. I hate to let a judge decide if I don't have to, because most judges are technically incompetent on software matters and it takes too long to educate them.
Instead what I recommend is that licensors, in consultation with their attorneys, do the best job they can to obtain a manifestation of assent when they license their software. Open source licensors have to do that also. Click-wrap may be the technical solution in some situations, but other creative solutions are available. Just do your best to do it right.
Lawrence Rosen is an attorney in private practice in Redwood City, California (www.rosenlaw.com). He also is general counsel for Open Source Initiative, which manages and promotes the Open Source Definition (www.opensource.org).
Legal advice must be provided in the course of an attorney-client relationship specifically with reference to all the facts of a particular situation and the law of your jurisdiction. Even though an attorney wrote this article, the information in this article must not be relied upon as a substitute for obtaining specific legal advice from a licensed attorney.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Client-Side Performance
- Tibbo Technology's Tibbo Project System
- Sony Settles in Linux Battle
- July 2016 Issue of Linux Journal
- Peppermint 7 Released
- Libarchive Security Flaw Discovered
- The Giant Zero, Part 0.x
- Profiles and RC Files
- Git 2.9 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide