"A Man's Gotta Know His Limitations"

As I recall, when Clint Eastwood's Dirty Harry said "A man's gotta know his limitations" in Magnum Force, he wasn't talking about software licenses. But as a recent Northern District a California case shows, he could have been. Poorly drafted license limitations can be deadly for a licensor.

(Yes, that may be the cheesiest lede ever. But work with me on this.)

Recall the basics. When a software licensee exceeds the scope of his or her license, the licensor generally has a claim of infringement. In many cases, this is quite straightforward. For instance, if the license grant doesn't give the licensee a right to create derivatives of the code, then doing so likely infringes. So far, so simple.

But consider those other provisions of the license agreement that aren't in the license grant. Does violating those provisions give rise to infringement? Common sense (at least my common sense) suggests not. Fortunately, the cases tend to agree, and Netbula, LLC v. Storage Technology Corp., No. 06-07391, 2008 U.S. Dist. LEXIS 4119 (N.D. Cal. Jan. 18, 2008), has a nice discussion of the issues.

Netbula licensed a software development kit (SDK) under what looks like a pretty typical SDK license. However, the drafter forgot to hook the license limitations onto the license grant. Big mistake. Netbula wanted to claim copyright infringement based on the licensee's violating a term of the license. The court didn't buy it.

Why? Basically, the putative "license limitation" was in the wrong place---drafted as a separate promise not a license limitation. (A man--in the gender-neutral sense--has to know his limitations, remember?) The court looked to Sun Microsystems, Inc. v. Microsoft Corp., 188 F.3d 1115, 1121-22 (9th Cir. 1999), Sun Microsystems v. Microsoft Corporation, No. C 97-20884, 2000 WL 33223397 (N. D. Cal. May 8, 2000), and S.O.S., Inc. v. Payday, Inc., 886 F.2d 1081, 1088 (9th Cir. 1989) for guidance.

"Before [Plaintiff] can gain the benefits of copyright enforcement," said the court, "it must definitively establish that the rights it claims were violated are copyright, not contractual, rights." So, the court

must therefore determine if Plaintiff has established that the disputed terms of the license are limitations on the scope of the license, and thus an issue of copyright, or independent contractual covenants and thus contractual rights. If they are the former, then Plaintiff must also show that Defendants have acted outside of the scope of their license....

In Sun Microsystems v. Microsoft Corporation, No. C 97-20884, 2000 WL 33223397 (N. D. Cal. May 8, 2000) ("Sun II"), the district court confronted a similar question of scope with regards to a software license agreement. In Sun II, the contract between the parties required that the commercially distributed software Defendant developed with Plaintiff's copyrighted software had to be compatible with certain other software....

The court found that this "compatibility" provision was a separate contractual covenant and not a limitation on the scope of the license itself because, inter alia, the contract says "nothing about the license grants being subject to, conditional on, or limited by compliance with the compatibility obligations."

This is why these days most carefully drafted licenses have a heading that says something like LICENSE GRANTS; LIMITATIONS after which come both the grant and (wait for it) the limitations. Or you might see a subsection under the main heading LICENSES that lists the limitations on the grant. Another approach is to add a new section below the grant that says, in big, bold, glowing neon letters LICENSE LIMITATIONS.

Different strokes for different folks. But cases like Netbula (and the Sun cases mentioned above) make one thing clear: you should not only know your limitations, but make sure the court knows them as well.

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.)

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.)

Gauging Interest in SaaS

Phil Wainewright has a nice piece here on why SaaS will surge in 2008. It's pretty convincing. If nothing else, interest in SaaS seems quite strong relative to those other software darlings everyone is talking about, social networking and virtualization: