Use restrictions in software as a service (SaaS) agreements work in tandem with the scope of access and use rights provisions to clarify the scope of a user’s right to use a SaaS solution. These restrictions will be extremely important to the SaaS provider, however, consideration of such restrictions is also paramount for the users of the SaaS solution.
Why Are Use Restrictions Included?
While the clause in a SaaS agreement granting access to, and use of, the SaaS solution will naturally limit the user’s rights, e.g., to access and use the SaaS solution solely for internal business purposes and in accordance with the functionality made available, it is also common for SaaS agreements to include clauses listing expressly prohibited activities.
These use restriction clauses have their genesis in on-premises software licenses where there is clearly a risk of users using the software in unauthorized ways, as the software (often including the source code) resides on the user’s infrastructure, to which they would likely have access.
The move to the provision of software on a SaaS basis has naturally limited those risks as generally the user only receives access to the user interface of the software (sometimes with an ability to undertake some form of standardized/minimal configuration) and therefore has limited to no access to the software code.
Notwithstanding this risk limitation, we still find use restriction clauses in the majority of SaaS agreements in a not too dissimilar form to those included in on-premises license terms. These clauses are included to provide protections for the SaaS provider in respect of its valuable proprietary asset and clarity for users in respect of what they can and cannot do with the SaaS solution. As such, these remain appropriate clauses to be included in a SaaS agreement, albeit with a slightly different risk profile from those included in on-premises licenses.
Use Restriction Examples and Considerations
There are many different use restrictions that may be included in a SaaS agreement: some may be generic and solution-agnostic, while some others may be specific to the solution that is being provided.
Set forth below are some standard restrictions and suggested considerations when determining whether general restrictions are necessary to include and/or are acceptable for the user of a SaaS solution.
|
Restriction |
Considerations |
|
Cannot provide the SaaS solution to any third party that is not an authorized user. |
The parties should carefully consider who may use/need to use the SaaS solution. Is this strictly personnel of the user or a wider group of users (e.g., personnel of affiliates or third-party service providers who need to access the solution to provide services)? |
|
Cannot access or use the SaaS solution to operate the business of a third party or otherwise use the solution on a third party’s behalf, or to act as a service bureau or provider of application services to any third party. |
Depending on the type of solution, the usage rights may only be for internal business purposes. If the user needs to use the SaaS solution to provide services to its own clients, consideration will need to be given to this use restriction. |
|
Cannot reverse-engineer, decompile, or disassemble the SaaS solution unless permitted by applicable law. |
As the user is unlikely to have access to the source code of the SaaS solution, the risk of reverse-engineering is low; however, because the look, feel, and unique functionalities could be copied, this is still a relevant restriction. It should be noted that reverse-engineering is permitted in certain circumstances in some jurisdictions, so legal advice should be sought in relation to this restriction, its enforceability, and best practices to mitigate risks. |
|
Cannot disclose or grant access to the SaaS solution to any person who is involved in any way in the design or development of a competitive alternative to the SaaS solution. |
The parties may want to make clear who is a competitor/what is a competitive product. |
|
Cannot alter, obscure, or remove any copyright, trademark (whether registered or unregistered), or other proprietary rights notice from the SaaS solution. |
If the agreement of the parties includes an ability to white label the SaaS solution (i.e., make it look like the user’s own solution), the parties will need to consider this restriction. |
|
Cannot use the SaaS solution in a way that is, or upload any content into the SaaS solution that is, unlawful, harmful, threatening, defamatory, discriminatory, obscene, infringing, harassing, or offensive. |
This is likely to be relevant for all SaaS solutions. The parties may want to consider broader provisions to cover intellectual property infringement and responsibility for protection against introduction of any viruses. |
Draft and Review with Care
As use restrictions are generally included in all SaaS agreements, those drafting or reviewing SaaS agreements may start to see them as somewhat boilerplate provisions; however, they should be drafted and reviewed with care. Many will be applicable in the majority of circumstances, but some may not necessarily align with the parties’ intentions and therefore should form part of any contractual negotiations.