Many, perhaps trending to most, commercial licensors and licensees are utilizing delivery models other than the historic on-premised method (i.e., using computer hardware located at the end user’s location) for providing and accessing software applications. Most commonly illustrated through the use of “cloud computing,” these delivery models raise many of the same issues involved in traditional software licensing, while at the same time creating issues unique to the respective delivery model. Cloud computing provides on-demand delivery of IT resources and applications via the Internet with substantially pay-as-you-go pricing, allowing customers to reduce initial IT expenses while having the ability to quickly increase or decrease IT resources to meet their perhaps varying needs.
Under a “SaaS” model, access to a software application is provided to the customer as a service. The vendor/cloud provider or another party hosts the software application on its web servers or via a third-party application service provider, allowing customers access to the software using web browser software via a portal and/or the Internet. The customer does not license a copy of the software but accesses the software as a service on an as-needed basis.
From a software cloud provider’s perspective, SaaS allows the cloud provider to reduce its support costs by maintaining a single version of its software on a single platform. A SaaS model allows cloud providers to monitor how their customers use the application, bring improvements to the market, and address uniformly for all customers any problem that arises. The cloud provider’s support staff is able to evaluate a customer’s problem as each customer is using the same application on the same platform. Updates are automatically made available to customers instead of customers having to wait to receive, install, integrate and pay for, the newest update. In addition, SaaS allows the cloud provider to sell to customers who may not be able to afford the upfront fees required to procure the software and/or the infrastructure to support it.
From the customer’s perspective, the customer is able to reduce its information technology costs by not having to purchase an application license, the hardware required to run it, as well as fees for updates and technical support. All of these costs are built into the fee for accessing the application, allowing the customer to direct its technology budget to those technologies that will provide a competitive advantage in its industry.
For cloud provider–owned applications, the customer’s cost to access the application should be reduced as the price is amortized among several users and the subscription fee is often based on usage. By paying only for its proportionate share of computing power and other resources that it uses, the customer avoids paying for excess capacity. The usage fee is amortized over the period of the customer’s use as differentiated from the purchase of a software license where payment in full is usually due immediately upon acquisition of the license. This payment mechanism evens out the user’s payments over the course of a year, potentially helping cash flow.
The customer will also avoid the significant time and cost of installing an application. In essence, application management has been outsourced, allowing the customer’s IT staff to focus on other projects. Because the software is already operating on the cloud provider’s system, the time to begin using the new application is dramatically reduced. The customer’s software usage is fully monitored by the cloud provider, allowing the cloud provider to instantaneously receive “feedback,” speeding the pace of improvements to the application, and allowing customers to benchmark against their peers. Further, the customer is able to automatically access the most recent updates and enhancements to the application without the risks inherent in transitioning to a new version.
SaaS does have several limitations/reasons for concern. The greatest is that the customer has relinquished control over its IT to a third party and is totally dependent on the third party to consistently deliver access without interruption while using a secure environment. Although the customer is purchasing a service not a software license, a customer still needs contingencies that address sudden cessation of the cloud provider’s business or an event of force majeure, as application continuity is necessary to enable end user business continuity (contingency) plans. The customer also lacks the ability to customize the applications for its needs as most cloud providers will only modify the application for very large customers.
Another challenge for customers is that many cloud providers require customers to use the cloud provider’s non-negotiable template agreement to purchase the cloud provider’s services. These cloud providers argue that pro forma contracts are industry standard and reflect the nature of lower margins and shared services, thus negating the need to negotiate the contract. Although a cloud provider’s contract may be non-negotiable, customers should carefully review the agreement to make sure it meets their needs. For example, does the agreement provide the use rights the customer requires, such as allowing the customer, its contractors, and the customer’s customers to access and the software?
(iii) Delivery Models
SaaS is usually delivered through one of two models: a hosted application model or a software-on-demand model. In the hosted application management model, a hosting provider hosts the desired application, delivering the application to its customers over the Internet. Under the software-on-demand model, the cloud provider (i.e., the software cloud provider/licensor or cloud provider) provides its customers network-based access to a single copy of an application modified for SaaS over a network. Software on demand is also known as the “application service provider” model. In both cases, the customer is paying for access to the application. The cloud provider may choose to have someone else host it, but delivery is the same and essentially “on-demand.” In most situations, the cloud provider will provide, maintain and host an application while providing the customer access to the application. The application may be held in a dedicated environment with its own instance of the application, or alternatively, the application may be hosted in a multi-tenant environment with a common version of the application running on a logically partitioned environment.
A shared multi-tenant environment uses a single instance of the application to provide access to multiple customers. All customers access and use the same instance of the application, creating an efficient means of implementing patches, upgrades, fixes and maintenance. A single tenant environment provides access by a single customer creating a more expensive service that cannot be easily scaled. A shared environment creates greater security risks as many clients’ data may be hosted on a single server. Thus, clients with sensitive data will often insist on dedicated servers. The language below reflects the potential convers of customers.
Dedicated/Partitioned Environment. Any time Services are performed at the Customer Facilities, Vendor shall provide the Services using hardware, software and related resources dedicated solely to supporting Customer. Unless otherwise expressly provided in this Agreement, all Services provided from the Vendor’s Facilities shall be provided using partitioned or dedicated Equipment. Vendor shall not provide any Services from a shared processing environment unless specifically approved in writing by Customer.
The cloud provider may choose to deliver SaaS either by hosting the application itself or by outsourcing the hosting of the application to a hosting provider. Usually, the cloud provider will use its own proprietary software which it provides to its customers. In some cases, a hosting provider will license a copy of the software from the cloud provider and set up a SaaS model with its own customers. In the latter case, the hosting provider acquires rights from the software cloud provider and provides access and use of the application to customers. This approach is often co-defined through a “reseller” situation.
(B) Contractual Provisions
The underlying SaaS agreement between the parties should clearly set forth the cloud provider’s obligations and the services it will provide. In a SaaS relationship, most cloud providers will provide:
- Access to an identified application,
- Technology updates,
- Data storage,
- Data back-up,
- Data security, and
- User support.
To the extent a service is not listed, the customer should assume it is not included. For example, if data back-up is not listed, the customer should assume the cloud provider will not be providing such services and the customer should back-up its own data on a regular basis. To the extent the cloud provider desires to implement a material change in the provided services, the cloud provider should be required to provide the customer advance notice of any material change, and the customer should have the right to terminate the agreement for convenience without penalty.
If applicable, proof of concept or beta testing should be conducted prior to making any long-term commitments to the cloud provider. The customer should ensure that the data created by the application is compatible with the customer’s legacy systems (e.g., that the data schema are susceptible to “extract transform and load” (“ETL”) modification and injection to other current systems) and thus avoid any potentially costly and time-consuming data migration project. The cloud provider should also be willing to provide the customer a written commitment as to the application’s future features and functionality that will be made available to customers. A prudent cloud provider may be hesitant to do so, however, to retain the maximum flexibility to operate its business.
(ii) Ownership of Data
From the customer’s perspective, the agreement should clearly state:
- the customer owns its data (and all intellectual property rights related thereto);
- the customer will have immediate access to its data without charge upon demand;
- upon termination of the agreement the customer may take its data to a new cloud provider; and
- the format in which the data will be returned to the customer.
The agreement should also describe how and in what format the data will be returned and prohibit the cloud provider from withholding data for non-payment. Return of the data should be prompt and not conditioned on the customer meeting a payment demand by the cloud provider.
Sometimes it is the customer’s responsibility to remove the data, i.e., to copy it onto its own system. If this is the case, the customer should make sure that once the data has been copied and the customer has confirmed it has a reliable copy of its data, the cloud provider destroys the data that remains on the cloud provider’s systems. Usually, the cloud provider will want to do so in accordance with its own practices, e.g., by overwriting, etc. To the extent any data is contained on backup tapes, the backup tapes should be immediately destroyed, and an authorized officer of the cloud provider should certify that the tapes have been destroyed. Finally, the agreement should set strict time frames for the destruction or return of the data.
Some customers may require the cloud provider to issue a “destruction certificate” as proof of action by the cloud provider. However, there may be issues with respect to multi-tenancy environments where redundant data sets or similar copies of data continue to exist. Unless the relationship is managed in a single tenant database, it may not be possible to assure total destruction of the data. Contrary to the point above, it is also critical from the customer’s perspective that the cloud provider be prohibited from destroying the customer’s data in the event of non-payment until the customer has provided written instructions to do so.
Prudent cloud providers should develop an internal guidance/checklist setting forth the actions to be completed prior to executing a destruction certificate to avoid unintentionally creating liability on the cloud provider’s behalf. To avoid potential problems, the certificate should be signed by the team lead for the team that completed the work, usually a member of the IT department.
(iii) Cloud Provider Access and Use of Customer Data
Cloud providers often seek access to the customer’s data for many reasons including the cloud provider’s desire to aggregate and resell the customer’s data to third parties. Under no circumstances should the cloud provider be able to sell the customer’s data to a third party even if it has been “cleansed” of any identifying information. The cloud provider should be contractually prohibited from accessing or disclosing the customer and customer data. While prudent customers should seek to limit the cloud provider’s use of their data, the cloud provider should have the ability to collect and analyze usage data to improve the quality of the cloud provider’s services including as input for its product/services “roadmap.” The agreement should clearly state that all customer data, including customer data, is confidential regardless of whether it is displayed or accessible by the cloud provider. Allowing the cloud provider to access customer data may raise antitrust issues as well as limit the customer’s ability to claim trade secret protection for such data. For a discussion of trade secrets in the cloud see Sandeen, Lost in the Cloud: Information Flows and the Implications of Cloud Computing for Trade Secret Protection, 19 Va. J.L. & Tech. 1 (2014).
The customer should not agree to amorphous language such as the cloud provider will “comply with industry standards” or the cloud provider will “use commercially reasonable efforts to protect the customer’s confidential information.” A prudent customer will also seek to prohibit the storage of users’ credentials and passwords by the cloud provider.
Model language favoring the cloud provider:
We routinely collect and analyze metadata regarding your usage of the Cloud Services, excluding any personal data. We may use this information to gauge Cloud Services usage levels and application performance, as well as to create anonymized statistics for our own marketing purposes.
The following language provides the cloud provider even greater leeway to utilize the customer’s data.
Vendor may use and reproduce Company Data at the direction of Company (such direction taking the form of the terms of this Agreement and the relevant Schedules) for the limited purposes of providing, operating, and maintaining the Services provided to Company. Company will secure for Vendor the right to use and reproduce Company Data, including any Personal Information therein, solely to the extent necessary to provide the Services to Company, without creating any obligations for Vendor beyond those set forth in this Agreement. Vendor may use usage patterns, trends, and other statistical data derived from use of the Services (but not Company Data itself) for the purposes of providing, operating, maintaining, or improving the Services and any Vendor products and services used to deliver the Services.
Compare the preceding language to the following language which favors the customer:
Customer grants Vendor a limited, royalty-free, non-exclusive, non-transferable and non-sublicensable license to process the Customer Data only in the United States as instructed by Customer and only to provide the services for Customer’s benefit so long as Customer uploads or stores Customer Data in the System, subject to all terms and conditions of this Agreement.
(iv) Data Retention
Given significant numbers of customers, relatively short contract lengths, and the commoditized nature of cloud computing, many cloud providers retain customer data for very short periods of time. To the extent the customer has specific concerns, it should ensure the underlying agreement allocates not only responsibility for data retention and backup but also the time period in which data will be retained. The period of retention will depend on RTO/RPO’s, requirement for the retention of metadata and the cost of doing so. RTO and RPO are common terms used to measure “Recovery Time Objectives” or how long it will take to recover data and resume using an application that has gone down. “Recovery Point Objectives” speaks to data freshness at the time of recovery. Sometimes, companies can recover data that is a week old meaning all the data from the current week would be lost. For mission critical applications, RPOs of less than one hour are standard.
Another issue for consideration is litigation holds for litigation, including the ability of the cloud provider to retain metadata. A prudent customer will contractually provide how it will notify the cloud provider of any litigation hold and how the cloud provider will preserve the relevant data. The failure to do so may lead to discovery sanctions on the customer in the event of any litigation.
Further, to the extent a cloud provider is required to destroy or retain the customer’s data, the parties should realize that it is virtually impossible to destroy all data as customers’ data will be inevitably retained in backup tapes and the memory of the servers. As a result, some negotiated transactions include provisions for ongoing but secure storage by the former cloud provider of former customer data for specified, tax, quality control, or other purposes.
(v) Pricing and Payment
Customers may be charged through various means, including on a per-user per-month basis, on a monthly subscription for the customer’s entire company, and results for a customer’s use of the application. For example of the last, infrequent pricing metric, a marketing software company is paid according to the number of solid leads generated through the customer’s use of the software.
Customers should carefully evaluate a contract’s pricing model to ensure the pricing structure is clearly delineated and that the customer has the ability to independently verify any amounts that it is billed by the cloud provider. If access is based on the number of seats or users, the definition of “users” will serve as the basis for establishing the aggregate fee paid by the customer. As such, the customer should clearly understand how the application will be used and who will be accessing and using the application.
For example, if a cloud provider defines a “user” as a named individual accessing the system, the “named user” terminates their employment, and a replacement employee is hired, is the customer is required to purchase a new license of the new employee or may it transfer the license from the old employee to the new employee? Like a traditional license, the price should be fixed for a set period of time, and the amount of any future price increases should be capped.
Further, if the customer’s customers will be indirectly accessing the application, do they need a license? The customer’s failure to obtain the rights it requires or understand its use rights may prevent it from achieving the synergies it expected from using the application as well as cause the customer to incur significant unforeseen costs. See SAP UK Limited v. Diageo Great Britain Ltd  EWHC 189 (TCC) February 16, 2017 (SAP successfully sought additional compensation for Diageo’s customers access and use of SAP’s software).
Most cloud providers require the customer to pay quarterly or annually in advance, eliminating any payment risk.
(vi) Performance Standard/Service Level Agreements (SLAs)
Service levels are very important as they establish the cloud provider’s minimum performance obligations and the degree of access that the customer will have to the application or services, including the customer’s own data. Many cloud providers, however, do not offer meaningful SLAs, arguing the application must meet the demands of multiple customers. Most cloud providers will at least offer availability service levels, and some may be willing to provide additional remedies beyond service credits for an additional fee. If appropriate, customers should seek to negotiate additional SLAs including response times, bandwidth and security breaches, although most cloud providers will only agree to meet minimum legal requirements. SLAs almost never cover failover guarantees or contingencies that address issues beyond the cloud provider’s control, such as the sudden cessation of the cloud provider’s business or an event of force majeure. Cloud providers should avoid being measured on any customer-dependent elements such as location processing capability.
Service levels should reflect the usage of the application. For example:
- How is the application being used?
- Where are the employees using the application located?
- What time of day will the employees be accessing and using the application?
A successful service level should be objective, critical to the successful performance of the services, tailored to the services, and achievable by the measured party. Common service levels include:
- Availability (both network and application)
- Remedies (including financial penalties/credits)
- Problem response time
- Issue resolution/Escalation Procedures, including status reporting
- User support
- Data return (Recovery Time/Recovery Point Objectives)
- Simultaneous visitors/users
- Page response times
(vii) Data Security
Security is important when utilizing a SaaS model, but it is especially important for those customers utilizing a public cloud. By centralizing a party’s data in a secure data center, a party may actually increase its security (e.g., via the greater skills, resources, oversight, and testing that may be enabled by greater scale, i.e., a cloud provider testing and optimizing cybersecurity on behalf of multiple customers and its overall business model, versus a single entity attempting to achieve cybersecurity excellence only on its own behalf and outside its core focus or competencies). On the other hand, the customer has ceded control over its data and now is dependent on the cloud provider for protection.
There are three aspects of security: physical security, technical security and administrative security. Prudent customers should undertake a comprehensive risk assessment that evaluates the scope of the purchased services and seek to identity any threats and vulnerabilities to receiving those services. It should assess the cloud provider’s security policies and ascertain the potential risk of a threat triggering a vulnerability as well as the potential impact if such a threat occurs. Customers will typically address their concerns with the cloud provider and incorporate its security requirements in the underlying agreement—often as a detailed, separate exhibit to the contract. Depending on the value of the contract and the importance of the application, the customer should visit the facility from which the cloud services are provided, if applicable and allowed, and request a written copy of the cloud provider’s security protocol for the building’s physical security and the security of the network from intrusion, and viruses, as well as annual updates. The customer should closely examine and vet the cloud provider’s policies as well as ascertain the specific type of infrastructure used by the cloud provider to provide the hosting services.
The cloud provider should undertake an external and internal security analysis several times a year. The results of these efforts should be provided to the customer without the customer having to request it.
Most important, however, is the definition of “data,” as the definition will establish the cloud provider’s security, confidentiality, and privacy obligations. Is “data” limited to information stored by the cloud provider, or does it include data created and collected by the cloud provider in the course of delivering services to the cloud provider? Customers should seek to draft the definition of “data” as broadly as possible to ensure that its data is completely secured.
Multi-tenancy creates significant risks that other customers may be able to access or extract a customer’s data, increasing the risk of viruses and malware entering the customer’s environment as well as other security lapses. As such, customers should carefully negotiate the agreement’s security standards after identifying potential risks and potential approaches to mitigate the identified risks. Such risks, both internal and external, as well as the agreed upon risk mitigation controls, must be continually monitored during the term of agreement.
To avoid ambiguity, the parties should specify the specific security standard the cloud provider must adhere to. The customer should ensure that the data center is ISO compliant as well as SSAE 18/ ISAE 3402 compliant. SSAE 18 SOC 2 and SOC 3 set forth significantly more stringent audit standards and are specifically focused on data centers. ISAE 3402 is the international equivalent of SSAE 18 and should apply and be reported against whenever data is kept in a global environment. See Chapter 7.E of The Practical Guide to Software Licensing and Cloud Computing, 7th Edition, for a more detailed discussion of SSAE 18 and its requirements.
The cloud provider should maintain a written comprehensive information security program that includes reasonable security procedures and practices to ensure the security, confidentiality, privacy, availability and integrity of user content and other information if transmitted through or stored in connection with the services. Sophisticated customers seek to negotiate these cybersecurity specifications, attaching the agreed upon standards as a detailed exhibit to the agreement.