In the typical SaaS scenario, the SaaS vendor provides, maintains, and hosts (either itself or through a hosting SaaS vendor) the desired application layer, and grants the customer and its authorized users access to the application functionality via the internet. At a high level, there are two variations of this scenario:
- 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.
- The application is provided and hosted in a multitenant environment, with one common application layer and hosting environment that is logically partitioned by the customer.
In this Contract Corner series, we will look at ownership issues in SaaS solutions in two parts, with different perspectives based on whether the solution utilizes a dedicated instance (Part 1) or a multitenant environment (Part 2).
When thinking about ownership and other intellectual rights in SaaS deals, we generally consider the following categories, discussed in more detail below. Note that the analysis below is based on what we see for typical SaaS offerings for dedicated instances, but 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. Upon a release event (such as cessation of business and material breach), the customer’s subscription license may convert to a broader license. After the effective date of the subscription, the SaaS vendor (a) will modify and upgrade the base code on an ongoing basis through generally available bug fixes, modifications, and enhancements, and (b) in some instances, may modify the base code through customizations specifically requested (and paid for in whole or in part) by the customer.
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. 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. In these instances, 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. 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, 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. Some vendors will 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.
While the customer may have limited ownership rights in the software that underlies the SaaS solution, 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 a 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. The customer 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. 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.