should software companies be liable for the code that they create?


Today, software vendors are largely protected from the adverse effects of any software that they write. End-user license agreements are notoriously draconian. These long swathes of legalese are designed to get software developers off the hook. They effectively make users accept that they’re running the software at their own risk. It imposes a ‘sold as seen’ approach, even though the code is, for the most part, unseen by the user.

And yet every year, users get hit by security exploits that cause millions of dollars of damage. Users are forced to clean or in many cases simply reinstall their operating systems. Hundreds of millions of files are lost.

blaming the vendors

Some security advocates argue that software vendors should be held responsible when their code is so easily attacked. While I can’t think of an easy way to implement this, maybe there should be some punitive damages levelled against second-rate software.

After all, if a motor vehicle was as crash or bug-prone as the average piece of software, the recall notices would quickly spin into a lawsuit and significant brand damage. However, dodgy software frequently hangs machines and disrupts productivity with no implications for the vendor.

blaming the users

Vendors would argue that software shouldn't be compared to vehicles. The average car driver doesn't get the opportunity to install all manner of third party applications with conflicting code on their car’s engine control unit. And you won't see a pickup truck labouring along the road, crippled by a piece of spyware that the user naively installed at a gas station.

And the user, too, must play some part in this. You need a license to operate a road vehicle, whereas anyone can boot up a PC and get online. The user has some responsibility, whether consumer or in the enterprise, to understand what they're doing.

shifting responsibility

Things are changing, albeit slowly. An independent team of security advocates has created theApplication Security Procurement Language (ASPL) as a living document that organisations can use to bake security into procurement contracts with their vendors.

What kinds of things should we address? Background checks on software developers is one good idea. Documentation of secure development processes (such as Microsoft’s Security Development Lifecycle, for example) is another. Clauses for proper software maintenance, update notification and patch testing will also go a long way towards tightening up software security.


photo: © kanchokostov -

Stewart Baines

I've been writing about technology for nearly 20 years, including editing industry magazines Connect and Communications International. In 2002 I co-founded Futurity Media with Anthony Plewes. My focus in Futurity Media is in emerging technologies, social media and future gazing. As a graduate of philosophy & science, I have studied futurology & foresight to the post-grad level.