Keep it Simple: How to Ensure Your EULA is Enforceable

Fascinating summary of four cases discussing the enforceability of click-through licenses and other contracts over at the E-Commerce and Tech Law Blog.  The gist of the cases is that if you're EULA is well drafted and someone clicks-through the agreement, it's likely to be enforceable (even if you're a company that most people would want to "get").  On the other hand, if the terms of the contract aren't available, the contract is contradicted by the sales person, or the customer is rushed through the process, courts may not enforce what would otherwise be an enforceable contract.  The fact situations of the cases are amusing in their errors (the contract wasn't included in the box, a kiosk that was supposed to link to the terms of the contracct wasn't connected to the Internet, the button for "assent" to the contract was labeled "print", etc.), but they reflect a consistency in the jurisprudence on the effectiveness of electronic contracting, namely that EULAs, click-throughs and other electronic contracts aren't enforced only when someone tries to get cute a la Douglas.  If a company will just enact a simple on line contracting policy and be consistent in its enforcement, it is unlikely that a contract will be unenforceable.

Head in the Cloud

If you're curious about "cloud computing," Nick Carr's latest piece in The Guardian gives a nice overview of the subject. Carr became infamous for his widely misunderstood book Does IT Matter? His latest book is The Big Switch, a short, punchy history of technology that supports Carr's current idee fixe: just as electricity became a utility in the late 19th century, computing power is increasingly being provided the same way (in other words, it's now "in the cloud.")

Examples abound, but consider SmugMug (where I store my photos.) Rather than build a huge data center itself, SmugMug relies on Amazon's S3 service, which is essentially a computational utility for storage. (Amazon also has another service that that is even more utility-like, EC2.)

In any event, Carr makes a compelling case. More details can be found in this piece from Technology Review, which discusses Carr's prognostications. For an overview of some of the legal/biz issues, check this out--a couple years old, but still useful, in my view.

(Cloud illustration by tinney used under Creative Commons license.)

Weekend Reading: Goldstein's Intellectual Property

Looking for a nice overview of IP written for the non-lawyer? Here it is.

Paul Goldstein, Lillick Professor of Law at Stanford and counsel with MoFo, has written a wonderful---and wonderfully readable---review of IP law that weighs in at just over 200 pages. Goldstein keeps it lively, covering the necessary topics (patent, copyright, trademark and trade secret law) without bogging down in minutiae.

Don't be scared by the Publishers Weekly review you'll see on Amazon, either. This book is a delight. And speaking of Amazon, you can even download Intellectual Property to your Kindle.

Tags:

Know Your Nines

If you're negotiating a service agreement, sooner or later you have to confront the question of how many "nines" you want to buy.

Often, businesses want at least "five nines" of uptime, meaning the service will be up 99.999% of the year. (Though it often isn't clear what exactly that means.) Certain businesses, like financial firms, may require more availability than this.

Five nines, though, can be expensive. Often money saved from cutting the service level down a nine could better be used on something else. Joel Spolsky has a nice, non-theoretical discussion the issue here. Here is another helpful analysis.

Unless you live and breathe these issues, those articles are probably worth rereading before negotiating your next SLA. At the least, it's not a bad idea to know the approximate meaning of the various service levels for annual uptime. For instance:

  • 99.9999% uptime means about 30 seconds of downtime.
  • 99.999% uptime means about 5 minutes of downtime.
  • 99.99% uptime means about 1 hour of downtime.
  • 99.9% uptime means about 9 hours of downtime.
  • 99.0% uptime means about 90 hours of downtime.

I find it much easier to think of these issues it terms of how much approximate downtime I am "buying." Then the question becomes, "Can I live with that?" Often it's not easy to say, for the reasons Spolsky points out on his blog. But at least it clarifies the problem.

(By the way, if you haven't had enough of the number nine yet, you can always get John August's highly entertaining and enigmatic movie on DVD.)

Risk Shifting in Licenses

This article by William Denny is a few years old, but it gives a nice summary the ways parties to a license agreement shift risk:

A. Express and Implied Warranties The extent of warranty protection in a software license is usually a matter of business leverage. Basic warranties usually included in a license agreement are that the software materially conforms to the specifications and documentation, that the vendor has good title to the software and has the right to license it free of any encumbrances, and that the software is virus-free and does not contain worms, trojan horses or other harmful code. Often there is a time duration associated with express warranties.

B. Indemnification Against Third Party Claims Indemnification clauses deal with third-party claims or suits against one of the contracting parties. A common indemnity clause in a software license agreement is for the vendor to defend and indemnify the customer and hold the customer harmless from and against third party claims for infringement of intellectual property rights, for claims of injury, death or property damage brought by the vendor's employees, agents or contractors resulting from services at the customer site. Because third party claims are not within the contracting parties' control, the damages resulting from such claims should be addressed separately from other provisions allocating risks between the parties.

C. Limitations of Liability The limitation of liability section typically relates to the liability of the parties to each other, as opposed to third party actions covered by the indemnification section. These provisions normally include a mutual waiver of incidental, consequential, indirect and punitive or special damages, and an overall cap on the vendor's liability to the customer for direct damages. A larger or more influential customer may negotiate certain exceptions to the mutual waiver of incidental or consequential damages or to the cap on direct damages. For example, a vendor may agree to carve out an exception to the waiver of incidental or consequential damages in the event of breach of the confidentiality provision, or it may agree to exclude from the cap on direct damages any liability resulting from its gross negligence.

D. Insurance An insurance provision is important where the software is part of a business critical application in the customer's business, and there is no commercially reasonable alternative in the market. It is also important in cases where the vendor will have its personnel performing services at the customer's site. The customer should ask the vendor to provide complete commercial general liability coverage, workers' compensation coverage, automobile liability coverage and employee fidelity coverage. If the vendor is going to customize software to meet the customer's unique requirements, the customer should request data processing errors and omissions insurance.

The rest is here.