Some Legal Issues to Consider When Migrating to Become a Service Provider
Although everyone’s into blockchain and the “Internet of Things,” believe it or not, there are still plenty of traditional software developers out there, and some of them still distribute physical software under traditional licenses to end users. Many of these vendors are in the midst of migrating their business models to distribution of their software as a service (SaaS), or via related models (platform or infrastructure as a service [PaaS and IaaS], among others). For vendors moving in that direction, there is a tendency to try to shortcut changes to standard license agreements by merely amending existing license terms to refer to SaaS environments. However, that attempt to “make do” with a software license when vendors move to the cloud can lead to potentially significant legal problems down the road.
License or Not?
Commentators on the legal consequences of SaaS distribution of software are quick to point out that a license grant to software provided over the web is probably ill-advised (although that analysis may be over-simplified). Technically, because the software is not installed locally, and users are merely accessing it in the cloud or at a remote location, then a license to the software (in theory) is no longer necessary. Furthermore, granting such a license, depending on its language and the scope of the grant, can lead to unwanted results. For instance, the typical end-user license might have provisions allowing the user to reproduce the software for certain purposes, and/or to install it on various machines, allow affiliates to use it, allow for the maintenance of copies for archival purposes, etc. If you merely shift that kind of software license grant to refer to access in a SaaS environment (without making other changes), you are also granting users the right to attempt to download or access the software beyond what is actually intended.
By granting a “license” to the software—even if styled merely as an intellectual property license to use the software in a SaaS environment—the vendor could find itself in an unintended position in the event of bankruptcy. Specifically, because the vendor has styled the access as a license, under Section 365(n) of the Bankruptcy Code, it is conceivable that they could be required to continue to provide access to the software. This is especially likely if the vendor has merely converted its software license into a service contract, since many software licenses contain express provisions that allow a licensee to retain its rights in the event of a bankruptcy. The reason this error could be quite consequential is that the bankrupt entity may be required not just to maintain the access to the software, but also to continue providing third-party cloud services to maintain that access.
Given these results, there are decided potential benefits to casting aside a traditional license grant in favor of merely agreeing to provide the “services” of allowing users to access the software, and offering that software to users over the web.
But there can be reasons, notwithstanding the above, that a software vendor migrating to a SaaS model might want to consider styling its agreement to include a traditional license grant, rather than merely create a service obligation. In particular, an IP license could give rise to claims for intellectual property infringement in the event of a breach by the user. If the software, or the way it is accessed or used, is vulnerable to copying or reverse-engineering, then the licensor may really prefer a license approach as a way to ensure that its IP rights in the software are protected and enforceable. Of course, any illicit copying of the software could be an IP infringement, regardless of the contract language, but an express license, together with traditional restrictions on copying and reverse-engineering, could be beneficial and, potentially, lead to higher damages awards in the event of a licensee’s bad acts. Also, a traditional license approach could be preferable if the vendor customizes or creates a custom interface (or provides other development) on behalf of the customer. To wit, the re-drafting of agreements to embrace a SaaS model needs to be carefully considered in light of the vendor’s product and individual circumstances.
Other Contractual Issues to Consider
In addition to working through “license” versus “access” issues, migration to a SaaS model requires thought on a panoply of additional topics that are less likely to be found in traditional license agreements. These include:
Data Maintenance and Ownership: One question that has to be answered when a traditional software vendor moves its software to the cloud is, who is responsible for the data that may be entered into or accreted from usage of the software in the cloud? Is it the vendor, the customer, or a third party? Who will back it up and be liable for any corruption or data loss? Does the vendor have any ownership of/control over the data? What if the data is “sensitive” or contains illegal or infringing content? The SaaS agreement must define the contours and the obligations of the parties with respect to the data and its ownership, control, and disposition, post expiration or termination of the agreement.
Service Levels: Typically, in a SaaS model, customers insist on heightened levels of service, to ensure round-the-clock access and trouble-shooting. Service-level agreements in SaaS contracts are often heavily negotiated and can impact pricing of the transaction.
Locations of Cloud Services and Data Transfers: When migrating to a SaaS environment, fundamental questions will surround where the data that may be entered or generated from the software is physically located, and whether the data is transferred over any international borders. This is especially important for customers who collect data from citizens in multiple countries, since its retention and transfer can trigger protections of various and conflicting privacy and data-security laws. Since SaaS services are often provided by third parties (e.g., Amazon, Microsoft, IBM), vendors need to understand their cloud services contracts, so that they can adjust their own agreements, representations, warranties, and liability disclaimers appropriately.
Indemnification, Liability Caps, Disclaimers: Among the provisions that require careful review when migrating from a license model to a cloud-based or SaaS model are those that divide up indemnification obligations, and those that seek to disclaim or limit liability of either party. Commonly, in a SaaS agreement, customers will insist that they do not owe any indemnification obligation to the provider, since (they argue) their only obligation is pay for the service. But that argument is also an over-simplification, since customers will have their own obligations and representations to make about (for example) confidentiality, the data, and imposed limits on the use of the services, breaches of which should invoke indemnity obligations for the provider, at least under certain circumstances.
In sum, when migrating to a SaaS model, software vendors need to consider myriad issues and undertake a comprehensive review of their agreements, rather than rely on the terms that exist in standard software licenses.