A lot of software licenses grant the recipient the right to “use” software. But the use license springs from a misunderstanding of copyright law. As a result, it’s not clear. A use license may give broader rights than the provider intends or narrower rights than the recipient needs. I’m going to suggest a better, simpler way to draft licenses. (This post expands on a point made in The Tech Contracts Handbook—something that comes up in many of my trainings.)
Why does anyone need a license to software? A software recipient needs a license because software is text—a set of instructions for a computer—and the law gives the copyright holder certain monopoly rights over text. To exercise any of those monopoly rights, the recipient needs a license. But the right to use software is NOT one of those monopoly rights. So if you grant a use license, you’re really granting a license to one or more of the actual monopoly rights, and whoever’s reading the license will have to guess which ones.
Are you surprised to hear that “use” isn’t a monopoly right of copyright holders? Think of a self-help book. That’s a set of instructions in written text, just like software. Do you need a license to “use” a self-help book: to read it and follow the author’s instructions on finding your soul-mate, investing like Warren Buffet, or reorganizing your closet? Of course not. You’d need a license to copy the book, distribute copies, etc., but not to use it. The same goes for software.
The law gives the copyright holder a monopoly on the rights (1) to reproduce software (or any work of authorship), (2) to modify it (to “create derivative works”), and (3) to distribute it. It also grants a monopoly on the rights (4) to publicly perform a work of authorship and (5) to publicly display it, though those relate mostly to visual arts and don’t often come up in software deals. So a software license—a copyright license—grants one or more of those rights. A clear license lists the rights granted: “Provider hereby grants Recipient the right to reproduce and distribute the Software.” But what if the license just says, “Provider hereby grants Recipient the right to use the Software”? You can’t tell which monopoly rights the recipient gets.
As a result, a license to use software is an unclear license. To figure out what it means, you’ve got to look at the context. If it’s clear the recipient needs to reproduce the software to use it, and doesn’t need any of the other copyright monopoly rights, then a use license just grants the right to reproduce. But what if “use” of the software in question in requires that the recipient reproduce and modify it in some cases, while in others the recipient only needs to reproduce? Which does the license grant? What if some uses of the software require distribution to third parties—in a client-server setting, for instance, where third parties hold the client app? A license that merely grants the right to use won’t tell the parties what they need to know. And clarity is the whole point of a written contract or license.
If you’re the software recipient (licensee), don’t rely on the right to use. List the copyright monopoly rights you need. Make sure the license grants you the right to reproduce and distribute and modify the software if you need all three—or some subset of those if you don’t. Then, if you’ve already listed the necessary rights, you can throw in the right to use too. It won’t mean much, but it does no harm if you don’t rely on it.
If you’re the software provider (licensor), don’t grant the right to use—at least not without some explanation—because you can’t be sure what you’ve given. Instead, grant the copyright monopoly rights your recipient needs and withhold the rights it doesn’t. If the recipient needs only the right to reproduce the software, grant the right to reproduce and specify that the recipient may not distribute, modify, publicly perform, or publicly display the software. Or give the right to reproduce and modify, if that’s necessary, while specifying that the others aren’t included. Then, if your recipient insists, you can also throw in the right to use the software. It won’t mean much, but it’ll do you no harm if you’ve been clear about the copyright monopoly rights not granted.
That said, don’t hesitate to add terms about how the recipient can “use” software. A clear contract might grant the right to reproduce software, deny the other monopoly rights of copyright holders, and provide that the recipient may not “use the software to process more than 7,000 transactions per day.” There, you’re not relying on “use” as a grant of monopoly rights. You’ve got a clear grant of rights, using clear language from the copyright statute. You’re just narrowing those rights, using the verb “to use.”
- The Tech Contracts Handbook addresses software license rights in Chapter I.C.1.
- For the monopoly rights of Copyright holders, see the Copyright statute, 17 USC § 106.
© 2012 by David W. Tollen. All rights reserved.
What about with SaaS? You aren’t wanting to grant a right to reproduce, modify, or distribute… you just want to grant a right for people to access the software and receive the services. So how to you properly root that in copyright language?
JB, thanks: that’s an important question. A SaaS contract should not give any license to the underlying software. In fact, in a SaaS contract, the provider should be sure to state that the recipient doesn’t get a copyright license or any other IP rights—to the software or to any other element of the service. That’s because a SaaS contract is a subscription, not an IP license. (That’s unless the recipient needs some software to access the service, in which case that software should have its own license, while the main SaaS offering remains under a subscription basis with no license.)
I’ve actually got a post on this: Don’t Use License Agreements for Software as a Service (9/12/2011).
There’s no harm in using the word “use” in a SaaS subscription. But it shouldn’t read as a “license to use” because that suggests IP rights. Rather, you could say something like, “Recipient may use the System during the Subscription Period.”
How do you account for Vernor v. Autodesk? The 9th Circuit appears to hold that the customer getting only a “license to use” the software is an essential prerequisite to the first sale doctrine and essential step defense not applying as affirmative defenses.
Thanks, HR. The Vernor case actually didn’t turn on the rights language in the license at issue—on whether it was a license to “use” or to “reproduce,” etc. The court addressed a separate question: the difference between a contract giving the recipient ownership of a copy of software and a contract merely giving a license to that copy. The first sale doctrine applies to the former situation—where the recipient owns its copy—and not to the latter—where the recipient merely gets a license to its copy. Autodesk won (thanks in large part to my former boss at Morrison & Foerster, Mike Jacobs). The court held that Autodesk’s contract language gave a license to the copy, not ownership of the copy.
In other words, the Vernor court didn’t address the issue in my post above: license to “use” vs. license to “reproduce” or exercise other rights of copyright holders. It did talk about a license giving the right to “use” (I think), but the result didn’t turn on that issue. The license could just as easily have given a right to “reproduce” one copy, or to “install” one copy (which means roughly the same thing).
BTW, Vernor’s lesson for software vendors is to draft language that denies recipients ownership of their copy of the software—language that says recipients merely get a license to that copy. In other words, draft copy-ownership vs. copy-license language like the terms Autodesk used in the Vernor case. The Tech Contracts Handbook provides that kind of language, and addresses the first sale issue, in Chapters I.A.2 (simple end-user licenses), I.B.2 (simple distributor licenses), and I.C.1 (all other licenses).
A software recipient needs a license because software is text—a set of instructions for a computer—and the law gives the copyright holder certain monopoly rights over text.
Most software license agreements define the software as the licensor’s confidential information, and then also state that confidential information can only be used as specified in the agreement. In that framework, if the license was only to “reproduce”, doesn’t that literally mean that the licensee can only install it on a computer but not actually run the program? Doing the latter would not violate copyright law, but would it not violate the restriction of the confidentiality clause? In such a case, then, wouldn’t a license to “use” (as well as to reproduce) be appropriate, with the former serving as a license under the confidentiality obligation and the latter serving as a license under copyright law?
I agree with the crux of your statement – a licence to reproduce addresses the copyright implications of operating the software, but not necessarily the confidentiality restrictions imposed by the licence agreement. If I were acting for a licensee, I would expect to see the right to “reproduce” supported or supplemented by a right to “run” or “use” the software.
(Great blog btw!)