Software development contracts – the good, the bad, and the ugly.

I recently helped a client put in a place a software development contract. It was one of those least worst-case scenarios – the client had already spent the money, the work had been done, but there wasn’t a signed contract in place. The client wanted to move away from that developer (the developer was charging the client to fix the bugs that the developer had, inadvertently, built in), but the product (a SaaS platform) was working ok.

So, I hear you ask, if the work has been done, the product is working ok, and the money has been paid – who needs a signed contract? Good question: but there are a number of reasons you might want a signed contract, and here’s one of the most important.

It’s IPR – you are the company that’s using the software, but what’s your IPR position? If it’s a licence to the software, what are the parameters of the licence? Is it a three year term, a five year, or perpetual? In what countries can you use the software – is it the home country, the EU, or is it worldwide? Is the licence limited to “internal business” use: this is a pretty standard term in software licences, but what does it mean in a SaaS context? And so on. If you are paying (or, in this case, have paid) for software you need to know what bang you are getting for your buck.

If you think that you have paid for the ownership of the IPR (ie. not a licence), has the property actually been transferred to you? Most software development contracts contain some kind of IPR transfer wording but a) the wording is not usually that great, so it might not be fully effective, and b) the ownership transfer is intended only to take effect in certain scenarios (ie. usually at a particular price point) so it’s not always clear whether the particular circumstance has materialised and whether or not the transfer of ownership has happened. And if you wait a couple of years, no one will be able to remember and the position will be even less clear.

You could take the view that this is all detail and, the real world, everyone just gets on with things: if a problem arises, you just sort it out and move along. That’s a perfectly legitimate point of view, but there’s a least two situations where it’s not the optimal approach. Firstly, when that piece of software is a core platform for your business. If something is a core platform, you need to be pretty clear as to what your rights are. Secondly, and this is inevitably related to the first point, if you ever want to sell the business, you need to be able to establish a clear chain of title. The first thing the buyer’s lawyers are going to do is carry out due diligence and, if you can’t show clearly that you have all IPR your business needs, it’s going to affect the price you get.

In this particular case, the client was expecting to own the IPR. Luckily, the developer also agreed with this (there had been a chain of emails to that effect) and, luckily again, the developer was persuadable that the ten words in their terms and conditions which were intended to transfer the ownership of the IPR were unlikely to satisfy a potential buyer of the company. He agreed to an additional IPR document which was long enough (a few pages) to demonstrate to potential buyers comfort that the company did own its core platform.

We weren’t totally out of the woods yet because, as is the case with most developed software, not every piece of code or routine had been written by the developer. A number of elements of open source were included (a separate subject in its own right), as were some third party licensed-in elements: as part of the transfer document, we also had to identify which was which, and the relevant terms and conditions that covered their use.

That fixed the key problem which was essentially a backward-looking one. The next problem was forward-looking. If we were going to carry on using this developer, could we live with their terms and conditions? And that brings us to a perennial problem: why are some many standard terms and conditions in the tech industries so poor? And to be clear, by poor, I mean a) they are badly drafted (lots of duplications and contradictions), b) contain clauses that have no real application in the context, and c) are incredibly one-sided.

This developer’s T&Cs had clauses lifted from other standard forms (eg. materials supplied by the client must not be obscene: really? What’s the likelihood of that being an issue in a business to business context), indemnities left, right and centre, the right to increase day rates at any time and by any amount, and a warranty period that was so short that my client was essentially paying the developer to fix the developer’s own mistakes.

When these issues were pointed out to the developer, the first reaction we got was: Yes, but these are our standard terms. But they don’t make sense. Yes, but these are our standard terms.

Once we go through that iteration, the sticking point becomes clear. The developer didn’t understand its own T&Cs and, as a consequence, was not comfortable changing them on its own. If they were going to change them, they would have to get the lawyer who had drafted them involved, and that would increase costs.

But pushing the analysis back a bit further, there were effectively two root causes to the problem.

First root cause. The original lawyer had drafted a set of T&Cs which were too complicated to allow his client to make changes without re-involving him or her. (A cynic would say that this was deliberate. I take the view that it’s just incompetence).

Second root cause. The developer was unable to distinguish between good lawyering and bad lawyering, and therefore had let himself be put in this position.

In the end, in this scenario, it didn’t make much difference. My client decided that they had enough of this developer, and so we just made the minimal (mainly IPR) changes that were needed to fix the immediate problem.

But it begs the question: why are so many T&Cs produced with so little thought on what’s really needed? And why do so many companies let lawyers dictate the general approach behind their T&Cs? For example, if you are a company that prides itself on being reasonable, fair and client-focussed, shouldn’t your T&Cs also reflect that philosophy? If you are a supplier or a buyer, how much time and friction you could save by producing T&Cs that are intelligent, fair, and comprehensible?

If you want to reduce friction by making your T&Cs intelligent, fair, and comprehensible (and if you want your whole contracting process to intelligent, fair, and comprehensible) then I can help.