As technologies develop, and businesses expand, their software licences are prone to becoming outdated. This can give rise to unexpected legal and financial risks. Frequently negotiated hurriedly as a box-ticking exercise, without the benefit of detailed legal review – and often taking the form of standard T&Cs – software licensing agreements (“SLAs”) rarely encapsulate medium- to long-term supplier and customer needs. Yet SLAs remain the primary mechanism for obtaining the right to use business critical software applications.
Over the past year, I have seen numerous disputes arising out of SLAs. Each involved great disruption, expense and stress to software suppliers and their customers. Drawing on this experience, this article explores how suppliers and customers could better future-proof their SLAs against common disputes.
1. The software
Parties to an SLA need to ensure that their contract identifies what is being licensed with sufficient precision so as to avoid confusion and disputes down the track. Sometimes, the parties end up in difficulty merely because software is a developing product with multiple contributors.
What happens to the parties’ rights if the software is (a) upgraded to a new version, (b) renamed or (c) sold to a third party? An SLA should include terms to make clear what the parties have agreed on this front.
It is also important to consider whether the software makes use of any open source software (“OSS”). OSS may be subject to its own licence terms, in particular exclusions of liability, of which both suppliers and customers need to be aware. It is sensible for the SLA to provide for the allocation of liability if OSS causes the software to malfunction.
2. Restrictions on the licence
An SLA grants the customer permission to use the software. The SLA will usually impose some limit on use, for example, it will specify that use is only permitted:
- for a particular purpose, e.g. as part of the customer’s own software solution, or in the course of the customer’s business, or for onward distribution to a particular number of end users;
- in a particular geographic territory, e.g. the UK;
- for a particular period, e.g. three years or, less commonly, “perpetual” unless otherwise terminated; and/or
- by a particular number of users, e.g. 25 employees of the customer (or its affiliates or subsidiaries), a number of CPUs or named users.
Parties to an SLA need to consider how the limitations on the licence will affect what the customer’s business can do with the software. Does the licence meet present and future needs? Are future potential use cases likely to fall outside of the licence?
Disputes often arise where the customer decides to embark on a new IT project or otherwise seeks to transform its IT systems. For example, if a customer implements a program of virtualisation (moving physical servers to the cloud), it may find itself engaging in unlicensed use where the SLA contains a licence on the basis of access by a particular number of CPUs. Customers should review their SLAs to ensure that they cover additional use of the software that may result from a new project, or provides clearly for how additional use may be authorised and/or purchased.
Similarly, where the customer is part of a corporate group and the group is planning an internal restructure, offshoring or outsourcing certain functions or a merger/acquisition with a third party, customers should check that these changes are not going to cause unlicensed use of software. Definitions of the “Customer” or “Client”, and members of its corporate group such as “Affiliates”, “Subsidiaries” and “Group Members” that are “Owned” or “Controlled” by the customer, should be drafted with a view to minimising the risk of changes to corporate structure resulting in unlicensed use. It is risky to assume that because the benefit to the customer’s business, or the number of users accessing the software, remains constant that the SLA will cover use after a restructure or similar change in the customer.
In turn, suppliers should review their standard SLAs to ensure that they reflect the latest market practice to ensure that the supplier is protecting its intellectual property rights in the software. For example, suppliers should ensure that standard terms accommodate the global nature of customers (if applicable) and the advent of cloud computing and bring-your-own-device (BYOD) networks.
3. Pricing mechanism
There are diverse pricing mechanisms used in SLAs. By way of illustration, SLAs may involve payment of a fee to cover use for a particular period plus a fee (sometimes calculated as a percentage of the licence fee) for associated support and/or maintenance services if the customer chooses to purchase them. Most licences also involve a fee for additional coverage, such as the addition of more users, the right to use the software to process a higher volume of data, or the right to distribute to more end users.
When agreeing the pricing mechanism, the parties again need to consider present and future potential use of the software. An example of a pricing mechanism gone wrong is that considered by the Court in SAP UK Ltd v Diageo Great Britain Ltd [2017] EWHC 189 (TCC). The SLA in that case provided for incremental fees to be paid for, amongst other things, additional “Named Users”. “Named Users” were defined as certain persons “authorised to access the Software directly or indirectly (e.g. via the Internet or by means of a hand-held or third party device or system).” The supplier claimed additional fees of over £54.5 million on the basis that customers using Salesforce (Gen 2 or Connect) were interacting with the licensed Software in a way that constituted indirect access, which was unlicensed use.
The SLA in SAP v Diageo was drafted in 2004 when, as the Court noted, “usage through cloud-based portals was not generally available”. Unsurprisingly the SLA did not cover the kind of use caused by the Salesforce applications, nor did it provide a pricing mechanism for it.
The Court held that the supplier was entitled to additional fees and sent the parties away to negotiate over the amount of fees due. If not agreed by the parties, the Court would assess the amount of the fees “by reference to the nature and extent of the usage and [the supplier’s] price list”. The Court also found that the indirect access was a breach of contract so the supplier could, in addition to the fees, claim damages for breach of contract (subject to proof of loss and overcoming any contractual limitations on liability).
The key take-away from SAP v Diageo is that both customers and suppliers should review their SLAs regularly to ensure that the pricing mechanism remains fit for purpose. It is also important to include in the SLA terms about how the parties track the activity that generates fees, e.g. “use”, “access”, “distribution”. This is addressed in the next section.
4. Monitoring use and compliance
It is important to clarify expectations about how use of the software will be measured before executing an SLA. In particular, the SLA should include provisions about monitoring compliance with the restrictions on the licence discussed in part 2 above.
Disputes are bound to arise where the customer and supplier have different understandings of the unit being used to measure the volume of usage (e.g., “data record”, “field”, “user record”). Before the parties sign an SLA, they should therefore ensure that metrics are defined clearly.
Disputes may also arise where the relevant metric is solely within one party’s knowledge. Where possible, both parties should have in place clear and reliable systems to monitor use of the licensed software. Such systems obviously need to measure the relevant metric (whether use, access, distribution, end users, volume of data or something else). For example, where an SLA permits a particular number of named users, the customer should maintain a up-to-date register of those.
Where only one party is able to monitor and report on use, the SLA should provide for a mechanism to ensure that both parties have visibility over actual use. To this end, SLAs usually contain terms providing for regular reports on use and/or allowing the supplier to call for a periodic audit of the customer’s use. The SLA should specify whether such an audit needs to be conducted by an independent third party and, if so, how that third party is appointed. While this may be more expensive than a self-audit or audit by the supplier’s personnel, it is likely to result in greater comfort for both parties and reduce disagreements when periodically assessing the customer’s actual use against contractually permitted use (often referred to as ‘truing-up’).
A customer who fails to self-audit runs the risk of having to pay a lump sum for which they have not budgeted in the event that the supplier discovers the overuse. They may also risk having to pay interest on that amount or damages for breach, and/or risk an end-of-licence dispute if trust has broken down such that the supplier suspects the customer has had little regard for the terms of the SLA. While there may be short-term appeal for customers to conceal overuse from the supplier thereby deferring payment of fees for additional use, it is important to remember that this is likely to be a breach of the SLA and is generally detrimental to the supplier–customer relationship. If possible, the customer’s legal counsel should work together with the relevant IT team in reviewing SLA compliance.
5. When a dispute arises
Parties can limit disruption caused by a dispute by including a clear dispute resolution process (“DRP”) in the SLA. Typically, SLAs include a clause requiring the party triggering the DRP to serve a notice on the other party setting out the nature of the dispute. It is usual for the DRP to provide for the dispute to be escalated to management and, if not resolved, referred to mediation, expert determination or arbitration.
It is worth considering specialist forms of dispute resolution when negotiating an SLA. For example, the Society for Computers and Law Adjudication Scheme launched in 2019 is likely to offer parties a speedier, cost-effective pathway to resolving their dispute without the publicity associated with court hearings.
A party may wish to terminate the SLA, and threatening to terminate may be a way to prompt the other party to comply with the SLA. However, this strategy can be high risk, as a party who threatens to terminate in circumstances where they do not in fact have a right to do so is themselves in breach of contract, which may enable the other side to terminate. This is also often not a commercial solution to the problem. From the customer’s perspective, the licensed software may not easily be substituted by an alternative product. From the supplier’s perspective, termination may mean a loss of ongoing business and/or reputational harm.
In my experience, the parties generally try to negotiate a variation to the licence to accommodate additional or changed use. Parties should ensure that any variation is set out in writing and takes into account the issues outlined above in respect of SLAs. If the variation arises in the context of a dispute, the parties should ensure that any release from liability in respect of past periods of use is broad enough to prevent the parties becoming embroiled later in a dispute about the same facts.
6. Conclusion
Suppliers and customers can minimise the risk of disputes arising under their SLAs. It is rarely possible to foresee every eventuality that might lead to a dispute. But as is evident from the issues outlined above, where commercially viable, parties can reduce the risk of disputes arising by negotiating a broader licence to take into account changes to the licensed software, IT systems and/or corporate structure. While many SLAs appear to be standard in form, suppliers and customers should review their terms carefully before signing and periodically during the licence period. This is an area where a little bit of forward (and creative) thinking and robust negotiation can go a long way in preventing future strife.
Leah Gardner is an associate at CMS Cameron McKenna Nabarro Olswang LLP with experience in IT and procurement disputes. She is a member of the Society of Computers and Law. The views and opinions expressed in this article are those of the author and do not necessarily reflect those of CMS.
