Obviously you don’t negotiate with Goliath; you put a pebble in a sling and launch it from a safe distance. However – 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’s 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’re 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 while then, we’d hope, you’ve been able to create a form of licence which is specific to the product – the way it’s licensed, the way it’s delivered and used, the pricing and support model; and which is 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 a hundred licences; in only one, 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, so 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 – this might be happening all the time. The customer may want ownership or exclusivity in this, at least, and there’s a beguiling attraction to this, but one to resist. 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, any where, 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’re 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. It’s 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; so that (such as under the most popular licence, the GNU General Public Licence) the open source nature of the component virally transmits its nature to the proprietary product, and compromise its proprietary nature as well as the safeguarding of the source code.
So – 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 Intellectual Property Rights 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 importance 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, the installation of further modules. The customer may, in some cases, be wanting to delay pulling the trigger. Some of the impetus for the project might have dissipated; there may be other projects on which are taking time and attention; there may be budget constraints 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 supper has committed financial and human resources. There should, for instance, be deemed acceptance if acceptance or rejection hasn’t taken place within a limited time of deliver; delivery rather than installation, because the customer might take delivery but delay installation.
Limits of liability
What’s 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, and it’ll 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 it’s not going to cause a high level of financial loss, you’ll 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 it’s that critical – you 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 licenses, let’s face it. It doesn’t seem to help telling people that they happily settle for a three month warranty on Microsoft Office software (I only have this 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 won’t contain a functional specification; try getting that off the 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 – 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 wouldn’t 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 can’t, and by reasonable explanation 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 – and how often is that necessary? – it shouldn’t pretend it can. There’s no point 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’s not to the customer’s advantage to have an impecunious supplier.
And service credits – the answer’s no, isn’t it?
Finally, some 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
Briefly – 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 they’re so great, they can start from scratch.
– Change of control
Your client’s customers may want to have some form of veto of the supplier assigning its rights; resist, because this 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 wouldn’t be prejudiced by English jurisdiction. It’s a good argument, and one which can usually be won. Try it.
Yes, you can:
It’s better than slinging a pebble – negotiating with Goliath can be effective, strangely satisfying – 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.
