The DOs and DON’Ts of software contract negotiations

Does your company sell the perfect and most innovative software on the market? Has your procurement team set its eyes on the latest piece of software that will solve all your company’s problems? 

Congratulations on this first step! Now, beware of the next step which is not the simplest part for most legal counsels: setting up a contract in which both you and the other party can walk away happy. 

You have probably asked yourself: what steps can I take to ensure that the contract negotiation leaves my company with the best possible deal? 

Here are a few DO’s and DON’T’s to improve your chances of a successful outcome, whether you are on the provider or customer side.

1. Understanding the software, the core element:

During negotiations, one can sometimes notice a pattern in legal counsels’ comments and mark-ups that display a lack of comprehension of the core element of the contract being reviewed, i.e. the software. 

Before diving into any negotiation, the best and first thing to do is to understand the software and, more importantly, whether it is being used as a product (SaaP or on-premise solution) or as a service (or SaaS). 

SaaP solutions require the purchase of a license to use the software that will then have to be hosted by the customer. Conversely, SaaS - which is becoming an increasingly common and appealing tech solution - does not need to be hosted by the customer. The customer may simply access the software through a web browser and requires no installation. This means reduced costs of installation of the hardware linked to the SaaP solution as well as a decrease in manpower required to keep such solutions functional. This is also one of the reasons for the attractiveness of SaaS solutions. 

Another important point regarding the service or product distinction: in different countries, taxes are levied differently depending on the status of the software. Therefore, in some countries, there may be no taxes levied on a service, however, there will be a tax levied on a product. Although this is mainly a business decision, many actors in your company might not be aware of this and it is important in our role as counsel, that such points be brought to their attention - especially when there are other decisive factors on what type of solution to choose.  

By not being aware of these definitional differences between the two solutions, a legal counsel may request clauses or terms in contracts that are incorrect, causing delays and a loss of precious negotiation time. 

So DO understand the software as this is the core element of your contract negotiation. That way you DON’T waste time in pointless back-and-forths or worse, negotiate a contract that isn’t suited to the software in question. 

2. Intellectual property rights - language to include in software contracts:

The standard approach for drafting clauses on software ownership is for the provider to be the sole owner, whether it is a SaaS or SaaP solution. This means that the customer acknowledges that it is being granted a license to use the intellectual property rights of the provider but that the ownership of the software, documentation, and other intellectual property provided remains exclusively with the provider. 

Furthermore, such contracts should specifically enumerate the limitations of the license and state any restrictions of use by the customer of the intellectual property and that use in a manner inconsistent with those limitations is unauthorized and constitutes a breach of contract.

One other thing to look out for in software contracts is data ownership. The licensor of the data, whether it is the provider or the customer, should ensure that the contract accurately addresses its ownership or other rights in the data by obtaining acknowledgement of data rights and ownership from the licensee as well as  by including an appropriately tailored definition of the licensed data. 

Additionally, the licensor of the data should consider what rights it should grant to the licensee. Usually, the licensor will seek to limit use of the data by the licensee, such as limiting the provider’s use of customer data, except as necessary to provide the services or perform its other contractual obligations.

Therefore, DO make sure as a provider to protect all your intellectual property ownership interests as well as use complete and clear language to limit the use of your software. Also, whether as a customer or provider, DO make sure that any data owned is protected and limited accordingly. 

3. Data security and confidentiality - typical mistakes and how to avoid them:

A common mistake when it comes to confidentiality and protection of data is that these terms are confused or perceived as identical. In truth, they actually convey completely different ideas. 

The main difference between data protection and confidentiality is that data protection secures data from damage, loss, and unauthorized access while confidentiality limits data access to authorized users only.

One of the most common mistakes derived from an interchangeable use of these two terms is to rely on nondisclosure agreements, or nondisclosure clauses in contracts, not only for confidentiality but also for data protection. A nondisclosure clause or agreement will normally indicate that the party receiving the information will not use it for any other purpose than what is outlined in the contract and will not share it with anyone else. This is essential and important for protecting information shared throughout the contractual relationship such as business plans, personal information, or source code. However, such terms generally do not indicate anything about procedures to protect this data, mainly the personal data collected from users. A data security clause, on the other hand, is all about those procedures.

A data security clause should cover procedures for protecting data, such as passwords and/or dual control restrictions, physical protection of servers, and storage procedures. Many data clauses also require data breach response and notification procedures to be set up and possibly outside audits, such as SOC 2 and ISO 27001. Further, such data clauses should address compliance with laws and privacy policies.

However, the requirements and strictness of the data security provision may also vary depending on the type of software being sold or acquired. In the case of software that does not use of customer data (or SaaP solutions that are stored on hardware and will be on the premises of the customer with the provider having no access to the stored or uploaded data, then the lack of or a more lenient data security clause may make sense and one should not waste time and resources on it. 

Therefore, when negotiating a software contract, DO make sure to include confidentiality provisions and, when necessary, data security provisions. In any case, DON’T confuse the two or use them interchangeably!

4. Service level commitments - when this works and how:

As previously mentioned, with a SaaS solution the provider runs and delivers the service to the customer. Consequently, an important element of any SaaS contract is the negotiation of the “Service Level Agreement” or “SLA”.  

Typically, an SLA will provide service credits against the next month’s fees if the provider does not meet the requirements of one or more of the specific service level commitments mentioned in the contract. More importantly, the SLA will also state the situations in which downtime of the services or software would be the responsibility of the provider, thereby giving the customer the right to claim these service credits. A customer should not be expecting service credits on any downtime that it may have caused. 

While it is tempting to draft or negotiate a long SLA with many detailed metrics, it is actually more effective to direct a customer to concentrate on the metrics that are truly important to themand focus the negotiation on just those. This means that one should not get lost in demanding service-level commitments beyond what one’s company needs! Some downtime and occasionally deficient service are often reasonable risks depending on what the service does and the company cost associated with problems. 

Further, during international negotiations with customers and providers located on different sides of the globe, a customer demanding that the provider be available outside of business hours and days may be unreasonable and never acceptable to a provider, especially if dealing with a start-up. Additionally, a provider will never risk committing to service levels that would lead to a direct non-compliance with the contract!

Another point that is often seen in negotiations is the request of an SLA for SaaP solution contracts. Providers will not agree to any security commitments for SaaP solutions because the software is hosted and implemented by the customer on its premises. Therefore, the provider will not have the ability to implement and maintain security features with respect to how the software is used by the customer.

Therefore, DO include a reasonably required SLA in SaaS agreements. DON’T request things that are unnecessary to your company’s needs or that may risk non-compliance by the vendor.