Contract drafters regularly confuse cloud services with traditional products and services. They approach software-as-a-service 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.
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.
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.
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 offering 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.
David Tollen is the author of The Tech Contracts Handbook, the American Bar Association’s bestselling manual on IT agreements. He is an attorney and expert witness and the founder of Sycamore Legal, P.C., a boutique IT, IP, and privacy law firm in San Francisco. His practice focuses on software licenses, cloud computing agreements, and other IT transactions. David also serves as a lecturer at U.C. Berkeley Law School. And he is the founder of Tech Contracts Academy and our primary trainer.
In his role as a law school lecturer and trainer, David has taught the subject-matter of this article to attorneys, law students, contract managers, procurement officers, and IT staff. And he has testified about it in court, as an expert witness.
© 2020 by Tech Contracts Academy, LLC. All rights reserved.
Thank you to Pixabay.com for great, free stock images!