What to Pick in SaaS: EULA, SLA or ToS

Software-as-a-Service (SaaS) is becoming more widely used and service-based offerings are becoming the new normal for vendors. But the legal agreements involved for new businesses operating SaaS apps are still confusing for many people.

Should you use a Terms of Service (ToS) when you sign up new users? What about an End-User Licence Agreement (EULA)? Or a Service Level Agreement (SLA)?

What's the difference between all of these agreements and which one is best for a SaaS product?

Let's take a look.

EULA, ToS, SLA

An End-User Licence Agreement (EULA) is a type of licensing contract between you and the purchaser of your software.

An EULA agreement gives the purchaser (the buyer) the right to use a copy of your software after they have paid for it, as per whatever terms of the licence you have set out (such as payment being made, a time limit placed on the licence, and prohibitions on sharing the software with other people).

This kind of licensing agreement is an intellectual property licensing agreement that relates mainly to that ability of your user to make that copy of your work and use that copy in certain ways. This kind of legal agreement also usually prohibits things such as reverse engineering and making additional copies of the software.

In contrast, a Terms of Service (ToS) is a legal document that more widely covers expected user behavior and the rules for users when they use your software.

The Terms of Service agreement (ToS) (also called Terms and Conditions or Terms of Use) doesn't usually give your users the right to make a copy of your work for their own use, instead, it sets out how they can use the service that you have provided them.

This kind of agreement may include sections on acceptable use, dispute resolution, and payment details.

Finally, a Service Level Agreement (SLA) is another type of agreement that you may be considering for your SaaS app.

The SLA is a legal agreement between the customer and the service provider that sets out details of the service itself, rather than the relationship between the parties. This means that this kind of agreement will usually cover things like the service's scope, quality levels, performance and up-time targets, and what will happen if there is a fault or problem with the service you provide.

Now let's take a look at what the pros and cons of each of these agreements are for a SaaS product.

How to decide

First, consider the fact that with a SaaS product, you don't actually want to license your software to your customers. Instead, you're providing them with a service.

This means that an EULA agreement is less suitable, as the end result of using EULA agreements is that the customer is licensed a copy of your software to use.

An SLA or Terms of Service is more useful in SaaS. These kind agreements don't license your software to your customers. Instead, they set out how the service will operate, expectations for customer behavior, and are more focused on the general agreement on the vendor and customer in relation to the service, rather than a proprietary contract in relation to the software (like an EULA is).

One of the major benefits of using an SLA is that it sets out clear performance expectations for your app and it reminds your customers that your SaaS application is a service, not just a piece of software.

Here's an example of a performance clause from the SLA agreement of Google Cloud:

You can see that Google sets out their "Monthly Uptime Percentage" of at least 99.95%, with financial credits received by the customer if this target isn't met. It's clear that Google Cloud is a service and that Google will be responsible if the service does not perform.

A Terms of Service (ToS) agreement can also set out clauses like above, but will not go into as much detail as an SLA. For this reason, it's possible to use both a ToS and an SLA as long as their clauses don't contradict each other.

The ToS agreement usually sets out a more general performance expectation, such as in this example from a ThoughtWorks SaaS application, called Mingle:

Note that ThoughtWorks simply states that they will "attempt to provide continuous availability and access to Services", without making explicit percentage-based service targets like what you would see in an SLA.

Under most SLAs, if your SaaS application has performance issues, your customers will receive fees credited back to their accounts or they may receive time extensions to the period in which they can use the service.

Other agreements might allow for reductions in the price of their subscription plan or licence.

Here's an example from HP, that sets out the availability of their HP Cloud CDN service. HP's SLA also set out clearly what the customer receives if the service does not meet their availability targets:

HP's credits increase as the availability failures increase, with a 30% credit being the largest service credit available. The credit amounts vary widely among providers, and it's up to you as a vendor to set your credits at a level that you can pay out to all customers if your service has a major incident and you owe service credits across the board.

If your SaaS application has a low likelihood of having service-level interruptions, performance clauses in your SLA will not be triggered, and potential liabilities under the SLA are an extremely low risk for the vendor.

Another major benefit of an SLA is that it usually covers clear escalation procedures in the case of an issue. Having a clearly defined escalation procedure (and one that promptly reaches high-level management if issues are severe) builds customer confidence and shows that you're ready and willing to fix the issues.

An escalation clause would usually look like this example from Monash University:

You can see that Monash University notes a "nominated time frame" for a response, after which the problem is escalated. Monash's nominated time frames are in the previous clause:

In Monash University's example above, for critical impact bugs or problems, the "nominated time frame" is a response within 30 minutes and best effort resolution within 2 hours. After that 2 hours had elapsed, the issue would be reported to the manager of network services to be resolved.

On a practical level, some customers may feel like an SLA is not useful for their purposes.

If your SaaS app goes down, even for small periods of time, the last thing your customers may want is extensions to their subscription, or money credited back. Instead, they just may want to cancel the subscription plan. Furthermore, customers may not be interested in signing up to an SLA in the first place. Instead of guaranteeing future performance with an SLA, they may be more interested in the past performance of your application, by way of public up-time data and performance metrics.

If this is the case, use a Terms of Service (ToS) agreement to set up general performance expectations and a termination clause, rather than "money back" clauses or time extensions.

An SLA may also be less suitable in the case where your SaaS app relies heavily on third parties. If your app is reliant on the performance of others to a great degree (like Amazon AWS), you may not be able to confidently set out what your service levels and performance targets are. Or, you may find yourself falling short of performance targets due to the failure of a third party that you work with.

If your app is fully contained and does not rely on third parties, this will be less of an issue for you.

Some clauses in SLAs explicitly set out that the service is not liable or responsible for the failures of third parties, such as this example of a clause from MODX Cloud:

If your app is a relatively new product and is likely to suffer from problems with up-time and performance, or you're relying heavily on third parties, a Terms of Service is more useful. It's a more high-level, general agreement than an SLA, and is less likely to tie you into specific performance metrics that you may not be able to meet.

Overall, the best choice for a SaaS product is an SLA or a ToS, or both. An SLA usually covers service levels in fine detail, including performance targets, response times, and escalation procedures.

A Terms of Service (ToS), on the other hand, would set out broader performance expectations, acceptable user behaviour, and other more general clauses such as intellectual property and limitations of liability.

But what you should not use for a SaaS app is an EULA, as the customer is not actually receiving software that they need a license to use. Instead, they are receiving a service.