Most IT contract drafters know the difference between a software license agreement and a technology services contract. In a license, the customer gets rights to copy and use software, while in a services contract, the customer gets a service, like tech support or IT consulting. But software as a service (SaaS) seems to throw a wrench into the gears. Which is it? Fortunately, the newish landscape isn’t actually all that confusing (or all that newish). A SaaS agreement is a services contracts, pure and simple. It doesn’t call for a software license.
The confusion stems from the central role of “software” in software as a service. You can cut through that confusion by asking what the customer will do with the software. If the customer puts a copy of a software on a computer — downloads it, installs it from a disk, etc. — the deal calls for a license. Copyright law gives the software’s owner a monopoly over the right to copy it (to “reproduce”), so the customer needs a copyright license to make a copy and put it on a computer. But in a SaaS deal, the customer doesn’t put software on a computer, or copy it at all. The software sits on computers run by the vendor (possibly in a third party data center), and the customer merely accesses it, usually via the Internet. With no copies, copyright plays no role in the transaction, so the customer doesn’t need a copyright license. Rather, the customer needs a simple promise: “During the term of this Agreement, Vendor will provide Customer with access to the System.”
In other words, the customer gets a service in a SaaS deal, not software. The vendor just uses software to provide the service.
The distinction has implications for several clauses in a SaaS agreement:
- The Prime Clause/Promise: The customer should get a subscription, not a software license. The customer gets a right “to receive the Service” or “to use the System” so long as the subscription lasts. You actually could describe the vendor’s offering as “a license to the Service,” and lots of companies do. But that suggests some kind of intellectual property license. If you’re the vendor, you don’t want even to imply that your customers get IP rights to your precious software. And if you’re the customer, you’re not likely to benefit from unclear terms. Either way, you’ll write better contracts — and keep things clearer in your own head — if you avoid licensing language. (For sample language, see The Tech Contracts Handbook (2nd ed.) Chap. I.E.1, Cloud Services Subscriptions — as well as the connected sample terms posted in our clauses archive.)
- Maintenance: You don’t need it! In a maintenance clause, the vendor agrees to fix problems with installed software and to send updates and upgrades, so the customer’s copy doesn’t fall behind those of other customers. In a SaaS deal, the customer doesn’t have a copy. The vendor keeps the software and provides it as a service, and that obligation already involves maintaining the software, by definition. (But see below re SLA’s.) Plus, the customer has no copy to fall behind other customers’ copies and so no need for updates and upgrades. When the vendor updates the software on its computers, all customers benefit (in most cases).
- SLA: You should consider a service level agreement (SLA) for a SaaS contract. Most SLA’s address time-frames for fixing errors or minimum performance standards — speed, latency, etc. — or both. (For more guidance, see The Tech Contracts Handbook (2nd ed.) Chap. II.B, Service Level Agreements — as well as the connected sample terms posted in II-B of our clauses archive.)
- Data Management & Security: Data management and security play a more important role in SaaS deals than in most software licenses. The customer’s sensitive data generally sits on the vendor’s computers, along with the software, rather than on the customer’s computers. That’s why many SaaS contracts include a data clause, addressing the vendor’s obligations for managing data and for keeping it secure. (Be sure not to use an NDA for data security! See my post on NDA’s vs. data security clauses. And for more guidance, see The Tech Contracts Handbook (2nd ed.) Chap. II.H, Data Management and Security — as well as the connected sample terms posted in II-H of our clauses archive.)
Of course, your deal may involve both SaaS and installed software. A SaaS vendor may provide its main offering online but also give its customer a software application to install on the customer’s computer — something that helps that computer interact with the online service, for instance. Don’t let that confuse you. What you need there is a software license covering that one installed application, wrapped into the larger services (subscription) contract. The license and its supporting terms should address the installed application only, not the software the vendor keeps on its own computers and uses to run the service.
© 2011, 2016 by David W. Tollen. All rights reserved.
[…] to undercut an owner’s argument that no license was given in the first place. As David Tollen writes in his “Tech Contracts Blog”, “SaaS customers generally don’t risk suits about copyright […]
[…] /**/Don’t Use License Agreements for Software as a Service […]
[…] was going to explain this in some detail, but alas, David Tollen over at The Tech Contracts Blog beat me to it by, oh, about a year and a half. Tollen explains it well, though, so I thank him for saving me the […]
What about 365(n) and SaaS? If you call it a right and not a license, you may lose certain rights if the provider goes bankrupt.
Scott, good question. Section 365(n) is for IP licenses. It won’t work in a SaaS agreement. To put it another way, I very much doubt that mistakenly calling a SaaS subscription a “license” would trigger 365(n). (The slight risk, however, is another reason SaaS vendors should not use the word “license.”)
So if a SaaS vendor goes bankrupt, the customer is out of luck — unless it’s gotten some kind of SaaS escrow or backup provider. I don’t think there’s any rescue available from 365(n).
[…] However the best article I found, “Don’t Use License Agreements for Software as a Service” written by David W. Tollen, J.D., most clearly explains the differences in risks and liabilities between the perpetual license agreement and the software subscription and, as the title shows, he provides very directed advice that is not easy to misunderstand. Tollen Explains, using directed headings, the different clauses commonly found in SaaS agreements and software licensing agreements and how each part affects the service provided. For example, he explains that a maintenance agreement is not needed in a software subscription because it is part of SaaS. Then it reminds us of the importance of maintenance, among other huge issues. http://techcontracts.com/2011/09/12/dont-use-license-agreements-for-software-as-a-service/ […]
What would be the big downside of granting both a license and having some sort of service component? Just the fact that there does not need to be upkeep of the software? At first, treating the contract as a subscription made sense, but upon further reflection, I am trying to pin down the true practical benefits of paradigmatically favoring the transaction as services-based versus license-based.
[…] Don’t Use License Agreements for Software as a Service. […]
Interesting article, but how do you square this with the ruling in MAI Systems Corp. v. Peak Computer, Inc., 991 F.2d 511 (9th Cir. 1993) or the more recent Comedy Central and Warner BRos. v. WTV Systems cases? Don’t some, if not potentially all SaaS services call for loading of part or all of the software into the end-user’s RAM, thereby constituting a copy for purposes of copyright law requiring a license to avoid infringement? And if it’s possible, what’s the harm in including licensing language to be sure the SaaS provider’s IP is protected?
Good question, but I don’t think it’s right that many or all SaaS services call for loading software onto the end-user’s computer. In most cases, the customer just views screens produced by the software and sends instructions, without getting a copy. If the customer does get a copy of some software, like something needed to interface with the SaaS system, that should be licensed, as the last paragraph of the post points out. But that doesn’t mean the whole SaaS system calls for a license. I think that for the part not downloaded, the vendor’s better off being quite clear that it’s NOT giving an IP license, or any copies.
In Warners Bros v. WTV, the defendant wasn’t an end-user but rather a distributor (without a license to distribute, publicly perform, etc.). So I don’t think it tells us a lot about end-user rights. (I don’t know the MAI case, though.)
Does using the word “license” rather than “service”, and generally how the contract language is written, have any effect on the applicability of sales taxes? Given that services generally are not taxed but canned software (licenses) are, would the contractual characterization of the transaction matter?
Bob, state sales tax laws vary, so it’s hard to give a universal answer. In general, I suspect there’s a risk you could turn a non-taxable service transaction into a taxable license by mischaracterizing a SaaS subscription as a software license.
I’m not a tax expert, though, and I’ve never run into this issue. Any tax lawyers out there?
[…] what you should not use for a SaaS app is a EULA, as the customer is not actually receiving software that they need a licence to use. Instead, they […]