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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
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