Software liability ruling: 'Supplier beware', says IT brief
Ts & Cs offer chocolate-fireguard grade protection
Analysis A software developer's assertion that it wasn't liable for the shortcomings of its software has been rejected by the UK High Court in a case that has implications for other vendors and channel partners.
As previously reported, London's Kingsway Hall Hotel had all sorts of problems when it installed hotel management software from Red Sky. Instead of helping to increase revenue and occupancy rates the hotel was obliged to hire extra staff to cope with the shortcomings of the application.
Kingsway eventually decided to ditch the application and find an alternative supplier. It also sued Red Sky for damages over alleged violations of the Sale of Goods Act, which states that purchased goods need to be fit for the purpose for which they are sold. Red Sky relied on its terms and conditions in contesting this suit, arguing its was only responsible for maintenance and support. It resisted attempts to supply a refund and pay Kingsway's extra costs.
However, in a ruling handed down by His Honour Judge Toulmin last week, the High Court sided with Kingsway and against Red Sky. The court ruled that the supplier had mis-sold its product which, regardless of its merits elsewhere, failed to match Kingsway requirements.
Experienced IT lawyer Dai Davis, of solicitors Brooke North, said that the case has implications for software developers and channel sales partners more generally.
"Courts continue to dislike limitations of liability included in contracts or licences," Davis told El Reg.
Contracts for software also invariably include limitations of liability but this does not necessarily means that they will withstand a legal challenge when something goes wrong.
"The wider the limitation (e.g. an exclusion) the more likely the court will strike it down," Davis explained. "Here, the court disliked a clause saying that if the software did not work, the customer (licensee) must look only to support/maintenance for a remedy. This clause is common in IT contracts, so suppliers should beware!," he added.
Red Sky's sales practices counted against it in the case, Davis concluded. "The case illustrates:that if the supplier fails to inform the customer of the terms & conditions before the contract is entered into, the supplier cannot later rely on those terms & conditions, and in particular on the exclusions in those terms & conditions," he explained. ®
hmmm would this apply to Microsoft as well ?
having had the pleasure of decades of fun and games with Microsoft products does that mean they to are now liable for for the time and effort I've spent resolving issues with their shoddy software ?
...that this is the first in a line of court judgements that finally put paid to some of the ludicrous shilly-shallying and denials of responsibility that are common in most software licence agreements (both negotiated contract and shrink-wrap).
The IT industry in general has got away with delivering shoddy products for far too long now - and largely on a seeming basis of "Ohh, it's computers, it must be complicated, so don't blame us if it goes wrong!" If the industry wants to be taken seriously as an engineering endeavour, then perhaps it's time it started acting like one, rather than promising the earth, but delivering poorly-designed, badly-implemented and inadequately-tested balls of crap.
Of course, the customers need some education too - the next time that some snake-oil merchant cons you out of your hard-earned cash to supply a box of useless bollocks, then stuff it back down his throat with your boot and demand your money back. If enough companies get sued by enough people and enough of the cases are made to stick, then that will probably do more to improve the quality of software than any amount of SSADM, OO, rapid prototyping, UML, agile development, SOA or whatever the latest flavour of the month methodology happens to be.
Re: Ignorance (@AC 17/05/2010, 14:11)
OK, so shoot me for my choice of wording when I said "latest flavour of the month methodology"
However, over the course of a couple of decades in the IT game (before I got sick of it and bailed out a few years ago) I heard all of those things - and many others - being described as the one and only true way in which the software industry would finally be able to ensure that it produced quality products.
Now, I didn't necessarily believe this whenever I heard it because (a) I'd heard most of it before and (b) the person saying it was usually trying to sell me (or my employer) something, whether that was training courses, consultancy, books or some kind of gee-whizz development toolset.
Of course, all of those different things - development methodologies, software technologies, architectural development styles, call them what you will - can help you to produce better software. However, they don't guarantee it and, I'm prepared to bet, never will. I've seen hacked-up last minute fixes, produced on a diet of adrenaline and caffeine, that were still better designed, better implemented and more thoroughly tested than other bits of software that were supposedly developed according to all the strictures of "Method X" and which, basically, ended up as nothing more than extensively (although usually inaccurately) documented crud. That's just the way it is - give a good engineer bad tools and he'll still do a pretty good job, while a bad engineer can still produce complete abominations even if he's using the best tools in the world.
But that's not the main point here. My main concern is that we seem to have created a whole marketplace that operates in the basis of having the latest, whizziest bit of technological know-how in place as quickly as possible. Who cares if it isn't really ready for prime-time use? Who cares if we're not completely sure about whether it's really an appropriate solution to the problem? Some techno-dweeb has wittered on about it on his blog, Wired.com has picked up on it and convinced half the corporations in the western world that they simply MUST be using "Millikan's Magical Customer Extractor" or they'll be left behind in the ecommerce equivalent of the dark ages, so the accountants and sales-droids who are, basically, running the whole show on both sides go into a frenzied, collective orgasm of pushing the latest bit of lunacy on us all.
Meanwhile, it's the poor designers and developers who have to try to deliver the cock-eyed thing with insufficient time and resources. And it's the poor end user who has to live with the inevitable inadequacies when it all proves to be nothing like as magical as people were led to believe.
And, of course, thanks to the wonderful "Get Out of Jail Free" card that is your typical software licence agreement, it's the customer and end-user who ends up feeling most, if not all, of the pain.
That's the reason that I think that getting some software companies sued until the pips squeak might be a good thing. It might finally hit home with the management (i.e. accountants usually) that over-promising and under-delivering has really bad consequences for them, not just for the customer.
Mind you, better educated customers would probably help too. Having someone in a company in a position of authority who can look at the latest outpourings of the "next must-have technology!" brigade and say "Yeah, right, very interesting but we don't actually need it and we've got better things to spend our money on" is a good thing. If they also know enough to meet with the vendors who are trying to flog the stuff and say "No, you're talking bollocks and your system isn't really going to work like that at all, is it?" then that's even better.
This, interestingly, does appear to have been a slight failing on the customer side in this particular case. Although I still agree with the way that things went - until such time as software houses are made fully accountable for the quality of their products in the same way as most other companies are, there won't be a real incentive to get things right.