Businesses entering into licences for specialist software should not underestimate the time and effort required to ensure that the licence documentation accurately reflects the commercial agreement: to do otherwise risks costly litigation and the threat of mission-critical software being withdrawn.
It is a rare business today that does not use commercially-provided computer software in at least some part of its operation.
Companies using mainstream software, deployed to a small number of users and purchased for a single up-front fee under a shrink-wrap or click-wrap licence, are unlikely to encounter too many difficulties.
However, many larger businesses now rely on specialist software, deployed in a solution specifically tailored to their needs, purchased on bespoke, periodic licences involving an ongoing relationship with the developer and (invariably) payment of ongoing maintenance and support fees. Those fees are often calculated by reference to matters in the control of the customer, such as the specification of the server hardware upon which the software will run, and/or the number of users required.
In such cases, the software in question is likely to be mission-critical. The deployment itself may well be complex, highly technical, and not easily described in writing. For these reasons, it is perhaps unsurprising that software licence agreements provide a fertile area for disputes to arise – in particular, over the boundaries of the use permitted by the licence agreement, and whether the business’s actual use falls four-square within those terms.
Software licence disputes are often time-consuming and costly to resolve. The sums involved can be substantial, with claims for compulsory annual maintenance fees (covering the whole period of the alleged infringing use, up to six years) put forward in addition to the up front licence fees claimed for any use that is said to have been outside of the licence agreement.
These disputes generally involve a two-stage analysis: firstly, what are the precise terms of the licence granted – what do the terms of the licence document, probably filed away and forgotten about moments after negotiations were concluded, actually mean? Secondly, has the business’s use of the software in practice in accordance with that meaning?
As ever, prevention is better than cure. By being aware of these problem areas at the outset, businesses can significantly reduce the likelihood of becoming involved in a dispute in the first place.
‘Just get the deal done’ – a risky approach
The genesis of a software licence is often a discussion between the parties as to how exactly the software will be used, how many user licences are required, and how the software will be deployed on the business’s server hardware.
In due course, a draft licence agreement is put forward for discussion, usually based on the software developer’s standard form document. There then follows a further period of negotiation, usually more focused on the commercial aspects of the deal than the detailed wording of the licence, or any schedule in which the specifics of the licence granted are set out. Those commercial discussions frequently outpace the drafting, until eventually a licence agreement is signed, often late in the evening on the last day of a quarter, by two senior representatives of the parties who themselves have probably had little to do with the negotiations and have not the slightest understanding of the technical requirements they hope the licence embodies.
Without doubt, the most frequent reasons for intractable licence disputes arising are that the language of the licence agreement and its schedule is ambiguous, inconsistent or plainly contradictory, was not properly understood by those actually involved in the negotiations, or was simply not checked by them to confirm it accorded with what they understood at the time the finally negotiated commercial agreement to be.
One of the most common errors behind these faults is to deal separately with the drafting of the licence agreement – which is usually led by the lawyers – and the schedule, which is often led by technical staff. Invariably, IT personnel will be involved right from the outset, assisting with the negotiations and ensure that the agreed structure is technically workable. However, when the work of the IT personnel and the lawyers is brought together at the eleventh hour, the risk of inconsistency is significant.
Particular precision (and care) is needed over the use of technical terms: the meaning of which is not always universally understood between countries, or industries, or even legal departments. For example, if the solution involves elements of ‘hot’, ‘warm’ or ‘cold’ disaster recovery, spell out the meanings of those terms in the agreement to ensure that both parties are clear about the rights being granted. In cases of doubt, terms should always be expressly confirmed in the text of the agreement.
Similarly, although it rarely seems to happen in practice, the value of all involved having a final check through the key terms on price and specification before signature can not be overstated. For example, the wording of the licence may contemplate fees payable on a ‘per CPU’ basis, whereas the pricing schedule (and the commercial negotiations) may have been based on a ‘per CPU core’ structure, leading to debate about which takes precedence, and whether that answer reflects the commercial agreement reached in the negotiations – upon which, surprise surprise, the parties views often differ months or years down the line. Those conducting the negotiations may well have their own view on such issues, but the scope for disagreement months or years down the line – at which point memories have faded, personnel have often moved on, and documents lost – is substantial. If a party considers that the document does not properly reflect the agreement reached, its only remedy may well be a difficult, costly and ultimately unattractive application to Court for rectification.
In short, time spent considering the drafting is rarely wasted, and will pay dividends if it means a potential costly dispute is avoided.
Finally, having been at pains to get the licence agreement right, it is imperative that the implementation of the software is given equally careful attention. Methodical deployment by a well-briefed technical team is as important as getting the drafting right in the first place. Where those involved in the installation of the software are not fully appraised of the rights granted (and the limits thereof), do not be surprised if the practical approach adopted by the IT department bears little relation to that contemplated around the negotiating table!
Tips for avoiding software licence disputes
Business contemplating a significant software purchase would be well advised to:
- assemble a negotiating team with the appropriate mix of expertise and ensure that the right people are involved in the negotiation and documentation of all parts of the final agreement;
- make sure that the drafting of the licence documentation keeps up with the commercial discussions, taking legal advice where necessary;
- be clear on the meaning of technical terms – if in doubt, spell it out;
- thoroughly review the documents before signature; and
- ensure that IT personnel fully understand the need for care in the deployment of software to avoid inadvertent infringements.