I used to be an IT lawyer. Before I moved in-house and developed a specialism in the legal vertical known as jackofalltradeslaw. But even now, I like to think I know the difference between a software licence and a support agreement and most of the time I get it right.
IT law used to be easy if you were acting customer-side. You stuck in some wacking great warranties which referred to what IT lawyers biblically defined as "the Specification". You drafted 3 pages of accepance testing provisions which no right minded individual would ever want to try and follow. And if you really knew your onions you blathered on about the criticality of escrow and forced the client to spend money with the NCC depositing source code which no-one would ever be able to really use anyway. All safe in the knowledge that if the project went wrong then best case the supplier was firmly on the hook or worst case you could blame the client for providing a poor Specification (anyone ever seen a good one?), not doing the acceptance testing properly or forgetting to deposit the seventeenth version of the code update into escrow. Job done.
IT software/maintenance/services also used to be expensive. Which meant, when acting customer side, one could negotiate a liability cap that had meaning and could cause the supplier a degree of pain if they failed to deliver a product on time which danced and sang as the biblical Specification said it would.
On the whole, the legal risk in IT agreements used to be balanced, more or less, in favour of the customer. And as in-house counsel at a company which buys IT services this was not an unhappy situation to be in.
Unfortunately though from a customer perspective this is no longer the case.
First came the web, HTML, XML and all that followed. Suddenly the words "source code escrow" seemed to have any real resonance. Although in practical terms the benefits to the customer of source code access was always questionable, the threat of an escrow trigger hanging over the supplier was a useful incentive to ensure that suppliers kept their side of the bargain, simply because they always hated the idea of handing over the crown jewels in a wost case scenario. I think (and willingly stand to be corrected by any devs out there) that the value of the jewels reduced when the commercial web came along and HTML coding started to replace more proprietary software packages.
Then came open source. It had always been in the background a bit, but with the advent of the web came an increased usage of open source by the dev heads. Not only did this really put the final nail in the escrow coffin but it also allowed suppliers to start cutting back the warranties they provided their customers, even the customary IPR warranty backed up by the accompanying juicy indemnity.
The negotiation see-saw had begun to tip, sending the customer up in the air. And if a lack of warranties in respect of source code was not enough, now the customer also had to worry about ensuring compliance with third party open source licences, some of which require the customer to deposit modifications of the open source back into the software community.
Still, all was not lost from a customer perspective. Customers still had our theoretical hundred page specifications to rely on (often of course drafted as six bullet points with "full specification to be agreed by the parties within 30 days of signature of this agreement". Yeah, right) and the lovely warranties that went with it. Didn't we?
Well, we did until the concept of agile development started to become mainstream. For the uninitiated, agile development works using the concept of "sprints". A sprint is broadly a series of project segments or stages which take a project from conceptual idea to final delivery. But the problem for lawyers is that the project is defined and developed in the course of those sprints. There is no specification at the beginning of the project, it is iterated and re-iterated over the course of a project. The customer pays the supplier to develop something that does not really become properly defined until some way into the project. So by now, customer-side lawyers also had to throw their specification warranties out of the window. But we do at least get to define the word "Scrum Master" to show that we were still down with The IT Crowd.
During the time that these developments were taking place, the cost of IT services was reducing. Good news for customers. Bad news for customer-side lawyers, because as project values came down, so too did the value of liability caps, sometimes to such a degree that it would barely be worth suing the supplier even if a project did go a little bit Pete Tong. Luckily (*coughs*) that rarely happens in IT projects so would never be an issue in practice.
And now we have "the cloud". Whoever came up with this term deserves a creativity medal for finding a way of making an IT solution based on thousands of inter-connected boxes across the world sound exciting. The Cloud has a futuristic, almost mythical air about it, it makes you think This Is The Future. The reality for customers is that your supplier is now not even telling you where they are hosting your data or website. But don't worry, it's The Cloud so all will be well my friend.
Except the cloud requires the customer to carry out a barrel load of data protection due diligence as data flies across the world and, better still, suppliers seek to protect their liability position even further both by way of reduced caps, both because prices are yet again reduced and also cloud providers are able to say, in a way they couldn't in the days of more traditional outsourced hosting, we are not taking full responsibility for the entire gig.
As a result, the customer-side lawyer's role is becoming one of due diligence and risk identification, rather than one of negotiaton.
A colleague of mine described it thus: certain IT services are now effectively akin to buying a utility service. Does your electricity provider offer service credits if the mains go down? Will the water company promise service uptime? Will your telco agree to fix a problem with the line within a defined period? Of course not. Buying certain IT services, even some critical ones, is just like ordering an extra Sky channel.
It's obviously wrong to consider the change in landscape solely or even primarily from a lawyer's perspective. Customer-side CIOs are in a happy place. The tech has improved which keeps the CIO happy. The cost has gone down which keeps the CFO happy. The ordering process is easy which keeps the procurement team happy. And the customer-side lawyer must just learn to wrestle with the philosophical reality that commoditised utility service contracts aren't really negotiable - which naturally makes us unhappy. But no-one is going to lose too much sleep over that.
Anyone got a solution? Am I getting it wrong? Answers on a post-card please. Or even better (out-housers) in an email – put it down to pro bono or biz dev, I promise not to tell anyone.
I should disclose I am not a lawyer, never mind an IT lawyer, but have worked on the supply and customer side of enterprise IT for 25 years.
ReplyDeleteThe Cloud changes the delivery mechanism and what is delivered. In the traditional model of business requirement->specification->code->working solution, the contract with the supplier is focused on step 2-3. In the case of The Cloud, which is predicated on the delivery of one-many services, the contract with the supplier is focused on the working solution. As an IT user you don't care much about step 2-3 - just as you don't care how the electricity grid or PSTN works. As a result, the contract negotiation has to switch to the Service Level Agreement - uptime guarantees, performance guarantees etc - and demands frequent reviews to monitor whether those SLAs are being achieved and, if not, what is going to be done about it (perhaps a sliding scale of reduction in subscription costs in line with performance below SLAs). Essentially the focus is on fitness-for-purpose as it should have been with the traditional model (but typically wasn't because the specification was an inaccurate representation of what was actually required).
The Cloud model necessarily also emphasises the importance of contracts that guarantee non-functional characteristics - security, compliance - and risk mitigation.