Contract drafters regularly confuse cloud services with traditional products and services. They approach software-as-a-service (aka SaaS) and other cloud services as if they were either software products or old-style services, like professional services. That leads to perplexing negotiations and contracts full of errors.
Much of the trouble stems from the IT industry’s vocabulary. In the 20th Century, words like ‘product,’ ‘service,’ and ‘software’ had simple, singular meanings — but no longer. Fortunately, once you recognize the confusion created by language, the underlying concepts start to look pretty simple.
The key point is this: software-as-a-service and other cloud services are neither products nor services, as those terms have been used for centuries. They’re in between: something new in the world.
To many, the differences among the three offerings seem subtle. But for anyone writing a contract, structuring a business relationship, or maximizing revenue recognition, they are crucial.
Traditional Definitions: Products and Services
For most of history, most business deals involved either a product or a service (or an animal, but the beast-trade doesn’t concern us here). A ‘product’ is “a thing produced by labor,” according to Dictionary.com. You can either buy one or rent it. A product might be a plow, spoon, shirt, car, or computer. Software is a product too.
A ‘service,’ on the other hand, is “an act of helpful activity,” again according to Dictionary.com. Services include help building a barn, treating an illness, writing a will, or cooking a meal. Services also include tech support and software programming, among many others common to the IT industry.
What Dictionary.com does not point out, because it’s obvious, is that human beings provide services. Nor does Dictionary.com point out that products are things you get. You get your hands on them, whether you rent or buy. Again, that’s obvious.
Except it’s not so obvious anymore.
The New Thing: Cloud Services
Shortly before the turn of the 21st Century, the IT industry created a new type of offering. Tech companies began putting computers and software online, and they allowed customers to access and use them remotely. These customers did not have to install, run, or manage the software or computers they got from the vendor. They could just access and operate them, generally using their own desktops to connect via the Internet. The customers didn’t possess or copy the vendor’s software or computers, so they weren’t receiving a product. But at the same time, no human being got directly involved in the vendor’s offering. So it wasn’t a service either.
Today, we call this new thing ‘cloud services.’
Salesforce.com provides a well-known cloud service: its customer relationship management (CRM) system. The customer gets to use Salesforce’s CRM software, but it doesn’t get to copy it or even to possess a copy. The customer just accesses and uses the software remotely. (That’s software-as-a-service or ‘SaaS,’ a type of cloud services.)
Amazon Web Services (AWS) provides another well-known cloud service: use of its server computers and other hardware, as well as security software. The customer accesses AWS’s computers, loads them with its own software, and uses them and the rest of the AWS infrastructure — again, remotely, without getting possession. (That’s another type of cloud services: infrastructure-as-a-service, or IaaS.)
Cloud services share features with both products and traditional services, but they differ from each, a lot. They stand in between.
Cloud Services vs. Products
To many users, cloud services look like traditional products. They involve software and computers — both products. But though IT products and cloud services have a lot in common, they call for very different deals and contracts.
Prime Clauses
In a product contract, the vendor’s key promise — which I call its ‘prime clause’ — involves delivering the product. The vendor also grants a copyright license if the product is software, giving the customer the right to make copies. But in SaaS and other cloud services deals, the vendor does neither. Its computers and software remain with the vendor. So it doesn’t deliver a product or grant a copyright license — at least, it doesn’t grant a license if it knows what it’s doing. (See my article, “Don’t Use License Agreements for Software-as-a-Service”.) The vendor’s prime clause simply promises to let the customer access and use the cloud services via the Internet (often called a ‘subscription’).
Also in product contracts, the vendor’s prime obligation ends once it’s delivered the product and/or granted the license. (FYI, maintenance obligations don’t play a role in the product sale; rather, they’re separate professional services offerings, though often in the same contract.) Yes, the contract might give the vendor side-jobs, like addressing malfunctions or IP claims about the product. But those are secondary provisions, only relevant if a problem arises.
In a cloud services deal on the other hand, the vendor’s primary job is continuous. It hosts and runs the technology for the customer. Instead of the software product vendor’s one-and-done prime clause, the cloud vendor has to perform throughout the term — like a traditional services vendor.
Revenue Recognition
Product and cloud services deal-types also involve different revenue recognition rules. Those are accounting standards that determine when a company’s financial statements can take credit for money expected or received. In general, a company has to earn fees to recognize them. After the one-and-done sale in a software product contract, the vendor has earned its fees. So it usually can recognize revenue almost immediately.
Not so in cloud services. There, the vendor hasn’t finished its job until it’s finished delivering the cloud service. So it doesn’t really earn its fees until then. That means the vendor often can’t recognize all the revenues from cloud services until months or years after signing the contract — again, like a traditional services vendor.
Cloud/Product Confusion
Despite all these differences, industry terms like ‘software-as-a-service’ suggest that cloud services call for terms about products, like software. In other words, the vocabulary misleads contract-drafters. What happens then?
Often, the cloud services negotiation reaches an impasse when one party requests product-related terms, like software copies and copyright licenses — and the other refuses, because those terms don’t belong in a cloud services contract. But that’s actually better than the alternative, which is that the parties agree on the misplaced terms, since both misunderstand. Then they’ll write a baffling contract. And that leads to greater chances of dispute and litigation down the road, as well as revenue recognition problems.
So you don’t want product terms in your cloud services contract. What about traditional services terms?
Cloud Services vs. Traditional Services
Like cloud services, traditional services involve ongoing help from the vendor. The two offerings also have similar revenue recognition rules. But there the similarities end.
Service Level Agreements
In a services deal, the vendor provides people, while in a cloud services deal, it provides technology, with no people directly involved. So cloud services contracts include service performance requirements that would make no sense for traditional services. They require automatic backups of data, for instance, often hourly or even every few minutes. Or they require compliance with software specifications, or system uptime of 99.9% or more, or electronic communications free of issues like ‘jitter’ and ‘latency.’
These are tech-related requirements — clauses better suited to tech products — usually found in the contract’s service level agreement (SLA). And they make no sense for human services. (I guess a human could avoid jitter by limiting caffeine, but how would you or I perform according to software specifications or remain “up” 99.9% of the time?)
Training, Professionalism, and Other Human Requirements
The problem cuts the other way too. In traditional services deals, vendors often promise that their staff will receive certain training and credentials. They also promise that they won’t subcontract the services. And they warrant that their people will perform in a professional and workmanlike manner. None of that makes sense for services provided through software and computers. (How does a remote-hosted software program behave like a professional or avoid subcontracting?) Nor do the many other human restrictions common to traditional services contracts.
Cloud/Human Services Confusion
Once again, the IT industry’s choice of vocabulary creates confusion. Names like ‘software-as-a-service‘ and ‘cloud services‘ suggest that cloud deals should use services terms, despite the issues discussed above. As with misuse of product-related terms, this error leads to impasses and confusion during negotiations. The customer asks for traditional services terms, like restrictions on subcontracting and warranties of professionalism, and the vendor refuses. Or worse, the vendor agrees. And if the vendor agrees to terms only appropriate for human services, it may not add cloud-appropriate terms, like service level agreements. Once again, the parties end up with a baffling contract and a high chance of dispute.
The new thing, then, looks like services in some ways and products in others, but it needs terms distinct from each. Again, it stands in between.
Combination Contracts: Just a Side-Note
You may be thinking: “Wait! SaaS contracts and other cloud agreements do sometimes involve services by people, like tech support. And they do sometimes involve at least some vendor software products installed on the customer’s computers.”
You’re right, but think of those as combination contracts. A contract can involve two or three types of offerings: products and services, as traditionally defined, and cloud services. But the fact that one deal could address several offerings doesn’t solve the confusion among them. It doesn’t solve the problems generated by mistaking the new thing, cloud services, for the old ones: products and services.
Simplicity Restored: The Middle Offering and a Little More Vocabulary
Contract work gets simpler when you recognize that cloud services are neither products nor services. They stand in between.
Fortunately, the IT industry has at least some helpful vocabulary to offer. The industry has two new(ish) terms for its traditional products and services, and they help draw lines between those offerings and cloud services.
First, instead of just ‘software’ for traditional software products, the IT industry has started using ‘on-premise software.’ That distinguishes this traditional product, which the customer gets on its premises, from the new thing, cloud services, which the customer only accesses remotely.
Second, the industry frequently uses ‘professional services’ for traditional (human) services. That tells us those services come from people — ‘professionals’ in IT-speak — not from computers, like cloud services.
Better Negotiations and Contracts
If you banish the old product/service dichotomy from your thinking, your job will get easier. Once you adopt the new three-offering vocabulary, the industry will look simpler, and so will your negotiations and contracts.
In his role as a trainer, and U.C. Berkeley Law School lecturer, David Tollen has taught the subject-matter of this article to attorneys, contract managers, procurement officers, IT staff, and law students. And he has testified about it in court, as an expert witness.
Want to do tech contracts better, faster, and with more confidence? Check out our training offerings here: https://www.techcontracts.com/training/. Tech Contracts Academy® has options to fit every need and schedule: Comprehensive Tech Contracts Master Classes™ (four on-line classes, two hours each), topical webinars (typically about an hour), customized in-house training (for just your team). David Tollen is the founder of Tech Contracts Academy and our primary trainer. An attorney and also the founder of Sycamore Legal®, P.C., a boutique IT, IP, and privacy law firm in the San Francisco Bay Area, he also serves as an expert witness in litigation about software licenses, cloud computing agreements, and other IT contracts.
And, consider also the 3rd edition of David Tollen’s best-seller, The Tech Contracts Handbook, available to order (and review) from Amazon here, or purchase directly from its publisher, the American Bar Association, here.
© 2020, 2022 by Tech Contracts Academy, LLC. All rights reserved.
Thank you to Pixabay.com for great, free stock images!
#cloudcomputing #softwarelicense #softwarelicensing #SaaS
I’ve been giving this a thought, just in a different context. As an IT lawyer, who does work with SAAS quite a bit, I still have trouble grasping that it is not a service. If I pay someone to clean my home, I think about it as I’m getting a clean home at the end of it, i.e. the outcome. That’s sometimes how I think about a SAAS if there is a specific outcome that can happen.
The one thing that really got me thinking is that because it is not on-prem software, is the IP indemnity clause really necessary? There’s no IP that is really being left with the client, and since it’s all accessed on-line (like this article and comment box) what is the real risk of an IP infringement claim?
Even I’m wondering if IP indemnity is required for cloud services. It would be great if the academy can answer this.
Hello, Latha. An indemnity is never required, but it’s usually a good idea for the customer to get one — covering IP suits and maybe other topics, like data incidents. And that applies roughly the same to cloud services as to on-premise software.
It’s an interesting question as to whether a User of SaaS can be held liable for infringement by the Vendor. Maybe under some set of circumstances. If the Vendor indemnity covers “allegations” of infringement, then the User’s defense expenses get covered, even if there is ultimately no liability. So I’d say try and include the indemnity.
Years back I encountered similar issues with B-2-B telecom contracts for use of subsurface fiber. Some companies called it a lease (the owner of the fiber network was the lessor). Others called it a license – where the owner of the fiber was the licensor. I think hosting services and cloud services are more akin to property leases. The lessor has a right to access the property and the lessee has a duty to maintain the property. With SaaS, it’s a combination of a lease and a license and a service. First, the lease. Access to the cloud platform is required for performance of the SaaS as the vehicle to enable performance of the owner’s software – so you’ll need contract wording which sounds like a lease (e.g., the lessee has a limited time to use the lessor’s cloud asset). Second, the license. The provider of the software performing as a SaaS will have an interest in protecting its intellectual property interests in the underlying software. So a SaaS agreement should address (as a prophylactic) the limited rights a user has to the underlying software. E.g., licensee may not copy the software or use it for purpose outside of the agreed scope. Third, the service. The service element of a SaaS is directed more towards the SaaS provider. E.g., maintenance of the underlying software to keep the SaaS in good shape – such as ongoing scanning for malicious code; will they prevent others from interfering with a user’s use of the SaaS or accessing the user’s content, etc. SaaS is inherently a combination of offerings – which is why many call their SaaS offering a “SaaS solution.”
That is a great question. On the other hand, I am seeing a lot of SaaS engagements where the SaaS provider also provides onpremise software. For instance, security software in many instances has a cloud solution and also has software loaded on the end points to monitor their behavior and respond. In those cases, an indemnity is required if for no other reason than the actual onpremise component.