Authored by Barbara Murphy Melby, Christopher C. Archer, and Jay Preston
In Part 1 of this Contract Corner on Software as a Service (SaaS) agreements, we discussed ownership and use issues in SaaS transactions where the application is provided and hosted as a dedicated instance with common base software (sometimes with customization or variation) but running as a separate instance in a dedicated environment.
In this Part 2, we will look at ownership and use issues in transactions where the application is provided and hosted in a multitenant environment, with one common application layer and hosting environment that is logically partitioned by customer.
As noted in Part 1, when thinking about ownership and other intellectual rights in SaaS deals, we generally consider the following categories, discussed in more detail below. As with any solution there can be variations and customer-specific needs that drive different requirements.
- Base software and documentation
- Generally available modifications and enhancements
- Code customization
- Configurations and integrations
- Customer and user data (including aggregated data)
- System performance data
Base Software and Documentation
The SaaS vendor generally owns (or if there are third-party components, has the right to use and sublicense) and will continue to own the base application software code and related documentation, with a subscription license for the customer and its authorized users to use and access the object code. Depending upon the criticality of the software, customers may require that the SaaS licenses include escrow provisions for the underlying source code and a mirror copy of the object code. However, escrow may be a less critical issue in multitenant solutions, where the feasibility of hosting and using software that is used and configured for numerous customers is called into question. Many customers prefer to focus on rights to easily shift to an alternative solution.
Generally Available Modifications and Enhancements
The SaaS vendor will continue to deploy bug fixes, modifications, and enhancements to the SaaS offering as part of standard support. As with dedicated solutions, the SaaS vendor typically will retain ownership in the associated changes to code and documentation.
When there are dedicated instances of SaaS solutions, there may be an opportunity for the customer to customize the functionality to address the customer’s specific requirements. However, in multitenant solutions, often a perceived advantage of such solutions is that the solution itself is standard and can be leveraged across customers with little to no customization. In the limited instances where there are customizations, the ownership outcome is mixed and may depend on the competitive sensitivity of the customizations. Some SaaS vendors will require continued ownership of the code with restrictions on use with third parties. If the customization is an add-on or something that is reusable, ownership may pass to the customer.
Configurations and Integrations
Most SaaS solutions are configurable or allow for integration with other customer or third-party software, either directly or through an API. In multitenant solutions, there may be limited ways to configure or integrate the solutions, so vendors may take the position that the customer has no rights to the configurations or integrations themselves, other than as necessary to use the system. In some situations, how a particular customer configures a particular application may result in specific business processes or requirements that are confidential, competitive, and sensitive to the customer. In these instances, (a) the customer may want to own the configuration or interface, or at a minimum have the parties agree that the customer-driven configurations and interfaces are the confidential information of the customer, and (b) vendors often take the position that other users cannot be prevented from using similar configurations or interfaces, but that the vendor will not disclose the confidential information of a particular customer (including, for example, how it configures a particular field) and that any similar uses must be made independently by other users.
Customer and User Data
While the customer may have limited ownership rights in the software that underlies the SaaS solution, in all SaaS solutions, the customer typically will want to own data inputted into and generated by or through the SaaS solution and data outputs (including any changes or additions to the data made through the use of the SaaS solution). The data outputs may include information reflecting the use of the solution by the customer’s users, such as click-through data, visit or session data, profile data and other usage data. Ownership of these data categories is often a high priority for customers because it contains valuable insights into the customer’s operations and its users. As we all are learning, the use of data is a hot topic right now. Accordingly, some SaaS vendors will want to obtain the right to use aggregated, de-identified data that is based on the customer data. Customers will want to review these provisions closely and consider whether the customer itself has the authority or desire to grant such rights.
Some SaaS vendors will try to draw a distinction between customer “business” data and the performance data of the SaaS solution. This is a topic that all parties should consider carefully as the drafting is important. Performance data may include topics such as availability and response time of the system, but it also may include the number of transactions run through the system. Even in multitenant solutions, transaction volumes, for example, may be competitive information that the customer wishes to own or at least restrict the disclosure of to third parties. How “performance data” is defined often determines ownership and use rights. Some vendors will push back and seek the right to use certain performance data on an aggregated, de-identified basis for internal purposes to better measure and improve performance. Again, the data rights provisions should be reviewed carefully.