Obviously you don’t negotiate with Goliath; you put a pebble in a sling and launch it from a safe distance. But if your client is a modest software house, and its potential customer is a corporate – say, a major bank or industrial behemoth – that isn’t an option. You’re going to have to negotiate, and often it is with a party that really thinks you need them more than they need you.
Part of the IT law world is wrapped up in big outsourcing projects – the part where we’re told that 70% of projects fail. In the world where my firm operates, we act for companies who provide really useful components which make their customers’ businesses work better. On the face of it there is a real inequality of bargaining power; the skill is in taking the inequality out of the discussions and understanding what options there are in reaching a position which upholds your client’s interests.
The first step is to understand your client’s technology on a functional level, and what benefits it will give to the intended licensee. You are likely to be negotiating with the customer’s procurement people or in-house counsel rather than an external lawyer; they’ll know a lot about their employer’s house-rules, but not a lot about the product they are acquiring or the benefits it is being bought to achieve.
Whose contract?
The first battle may be about the form of contract you’ll use. If you’ve acted for your client for a while then, we’d hope, you’ve been able to create a form of licence which is specific to the product – the way it is licensed, the way it is delivered and used, the pricing and support model – and that licence will be well balanced whilst protecting the licensor’s rights. Often the corporate customer will want to use the company’s standard form of contract – a one-size-fits-all monster which doesn’t work for a specific project and which, by the way, assigns the rights in the product to the licensee. Usually we’ve found that, so long as we’ve got a good licence for our own clients, we can get that accepted as the basis for the final agreement. With one client, we’ve probably negotiated the best part of 100 licences and in only one case, with an American financial institution, did we have to concede using their form of licence. We then eviscerated it so the look was theirs, but the content was ours. (They later went belly-up in the credit crunch, and it served them right.) However – and here’s something lawyers need to bear in mind – the cost of battle over the document made a significant dent in the client’s licence fee.
Ownership of rights
The principal point of protection for the software house is generally around the ownership of rights. The product represents the software company’s crown jewels – this is what creates its revenue, employs its people and, if they are lucky, will give the owners a good, sustainable and perhaps saleable company.
The first and basic step of course is to licence, not sell, the product – and to watch out for agreements which assign all rights to the licensee. However, it goes further than this – it will often be the case that, in the course of work for a particular customer, new rights will be being created – indeed this might be happening all the time. The customer may want ownership or exclusivity in this, at least, and there is a beguiling attraction to this, but it is an attraction that should be resisted. Whatever is being developed to meet one customer’s needs may well lead to the development of improvements to the core product, and you don’t want to have given ownership away in a bid to be nice and accommodating. Distinguish this from that which is genuinely specific to the customer – this is more likely to be, for instance, some visible wording rather than some underlying code. Ask the client, and ask again, before conceding ownership.
Be very clear, too, on the rights you are licensing. Is it a right to use the product, any time, anywhere, by any number of users? If you want to limit the number of users, can you actually monitor or do this? This may depend on the way in which the product is delivered. Is it installed or hosted? Do users have to log on and be registered? An unlimited global perpetual licence is worth a lot more to the licensee than a limited one – as lawyers we need to help the client to get the best value from the negotiation. A medium-sized customer could be acquired and turn into a very large one; will your client then be entitled to any more fees, or will the pass have been sold? If you are limiting the use, you’ll also need to have not just the right but the ability to audit use. Expect some resistance – and understand what it is that your client will really need to monitor whilst being sensitive to the customer’s security and data protection imperatives.
If you are not vigilant, your client can give away more than it should; but you’ll also need to be wary of your client – the supplier – licensing more than it has a right to do. This is a whole big subject of its own, but does the supplier have the right to license its product? At an extreme, has the product been developed using unmonitored open source components which are acquired on a restrictive licence (such as under the most popular licence, the GNU General Public Licence) so that the open source nature of the component virally transmits its nature to the proprietary product, and compromises its proprietary nature as well as the safeguarding of the source code.
You need to know from your supplier client that it has the correct rights to licence the product and maintain the confidentiality of the source code; and then you are going to have to take a stand, in negotiation, on the protection of those rights and on the IPR indemnity. The first point has been discussed above. The second will arise where, as the supplier, your client will need to maintain control over the conduct of any claims that the product breaches anyone else’s IP. A corporate customer may well want to be able to take over dealing with such a claim, because it doesn’t want to be dragged into an argument – its interest might be in making an admission, reaching a settlement and going after the supplier under an indemnity, regardless of the actual facts. If it did that, there may be no supplier left to go after. Generally this is an area where a stand has to be taken – the supplier can’t have each and every customer going off and doing its own thing, making admissions and landing the supplier in the mire. So long as the supplier undertakes to, and does, defend its product, does so diligently and if anything is not compliant, makes it compliant – that should be its right.
Acceptance
The key trigger for the operational and financial relationship between the software house and its customer is usually the completion of acceptance testing. There is an important balance of interests to be observed here:
– Can the customer delay in carrying out acceptance tests?
– Who has the ‘say’ over whether the product is acceptable?
– If the first acceptance tests fail, can the failure be challenged – does the supplier have a right to put any problems right and, if its first attempts fail, how many more chances will it have?
The supplier will be keen to get the product out and in use, since this will be key to getting paid a large tranche of its fee. There may well be other fees which will then follow on from this key stage – such as support fees and fees for the installation of further modules. The customer may, in some cases, want to delay pulling the trigger – some of the impetus for the project might have dissipated, other projects may be taking time and attention or budget constraints may be kicking in. From the supplier’s end, you want to minimise the ability of the customer to delay for reasons other than genuine problems with the product. The customer has made its commitment by the time the acceptance procedure should have commenced, and on the strength of this the supplier has committed financial and human resources. There should, for instance, be deemed acceptance if acceptance or rejection has not taken place within a limited time of delivery (delivery rather than installation, because the customer might take delivery but delay installation).
Limits of liability
What is it reasonable to expect the supplier to take on as liability? The first point to understand is the level of insurance your supplier client has, and then to understand how business-critical the application will be to its customers. If the customer is a bank, will it impact on the movement of money or customer data (highly business-critical) or on whether the bank staff get the right sandwiches (less so)? If the latter, the customer may be more flexible; it will be for you as negotiator to know what role the application plays. On the customer’s side, they might be working to a negotiating template – ‘we never agree to this’ which you need to have the knowledge to challenge. We have had the fortunate situation where we have had more than one client supplying software and services to the same bank and when they told us ‘we never agree to this’, we were able to tell them that, yes, they did, because they just had on another matter.
In terms of limiting liability, once you’ve understood the criticality of the application, you need to be realistic as to the level of loss which the customer could suffer. If failure of the client’s product is not going to cause a high level of financial loss, you will be in a better position to limit liability to the price paid, a multiple of that or a fixed sum within your insurance limits. If the product is really critical,– your client will need to have invested heavily in its insurance.
Warranties – what do they do?
Warranties are a bit of a vexed area in software licences. Telling people that they happily settle for a three month warranty on Microsoft Office software does not seem to help (apocryphally – a search to check it revealed nothing) – but generally you should be trying to limit the lifetime of the warranty. What, though, are you warranting? Generally speaking the licence will not contain a functional specification; try getting that off your clients and they’ll give you a sales document. Often the best way to go is to refer to the documentation which is provided alongside the software – the user manuals, which do actually state how the thing works. Remember though that this is software so it won’t all work. But if you’re lucky, it will work ‘materially’ in accordance with the user manuals and, as part of the support, the supplier will get things working. You would not accept that in a car, but people know that software is buggy, and will accept it as being so if the support obligations are there.
Support
Corporate customers may want all their suppliers to provide a uniform level of support, with a uniform level of remedies, but they cannot have that and this has to be explained. For every supplier to do this, each supplier would have to provide a different level of support to each of its customers – and that’s just not feasible. It ought to be clear from the outset of discussions between the parties what resources the supplier has, and therefore what level of support it gives, to all its customers. If it can’t give 24/7 support (and how often is that necessary?), it shouldn’t pretend it can. There’s no point in a customer trying to get its supplier to claim to supply more than it can or really will.
As part of the support, there needs to be real clarity on what is included within support costs and what isn’t – otherwise there’s a looming area of dispute. What’s a fix, what’s a release, an upgrade and a version; what does the customer get and what does it pay for? Support and upgrade fees are a vital part of the revenue for a software supplier, and the customer needs to appreciate that – it is not to the customer’s advantage to have an impecunious supplier.
And service credits? The answer’s no, isn’t it?
Brief points
Termination
Termination may be pretty much a boilerplate issue – but boilerplate is a minefield, and each instance and opportunity needs its rationale. Beware, particularly, the customer who wants a right to terminate, however phrased, ‘for convenience’. If the customer wants an out for this reason, then the supplier client needs to be well aware of this and compensated for this flexibility.
Post termination
If the customer wants your client to assist with changeover to another supplier post-termination then the customer should pay. Why on earth should your client agree to help someone else to supplant it, without being paid in full? And on no account should the new supplier have any access to any proprietary element of your client’s product. If the new people are so great, they can start from scratch.
Change of control
Your client’s customers may want to have some form of veto over the supplier assigning its rights. Resist this, because it could mean giving them a hold over the company selling its business as part of a bona fide commercial deal.
Jurisdiction
If the supplier is a software house in England and the customer is a multinational with offices in New York, San Diego, London, Sydney and Tokyo – but wants jurisdiction in New York, there’s a good argument to be had. If there were a dispute and it had to be heard in NYC, the supplier may effectively be prevented from stating its case, whereas the multinational would not be prejudiced by English jurisdiction. It is a good argument, and one which can usually be won. Try it.
Yes, you can
Negotiating with Goliath can be effective and strangely satisfying. It is better than slinging a pebble. And your clients will love you for it, because not only will it have improved their position but their credibility in the eyes of their customers will be enhanced because they are well and expertly represented – and therefore good commercial partners not just useful dupes.
Paul Berwin is Managing Director of Berwins. Claire Armer is a Senior Associate there. Both look after the IT-related and wider commercial requirements of the firm’s clients in the technology sector: www.berwin.co.uk
