Can you imagine a world where the words "software" and "warranty" actually appear on the same page? Maybe it's time to try.
Can you imagine a world where the words "software" and "warranty" actually appear on the same page? Maybe it's time to try.Most of us know that computer software plays by a very different set of rules than other products. If an automaker sells a defective automobile, product liability laws compel them to issue recalls, provide warranty repairs, or even compensate injured buyers.
What happens when a company buys defective software? Tough luck. Read the software license, and you'll see that no matter what goes wrong, it is nearly impossible to hold software vendors responsible for selling flawed products.
The European Commission recently floated a proposal that would take the software industry off this legal pedestal. For the first time, software makers would have to accept the same legal liability as other companies that sell defective products.
As you can imagine, software industry trade groups are aghast at the idea. A Business Software Alliance spokesperson, for example, denounced the idea of subjecting digital content "to the same liability rules as toasters."
That is an evocative comparison. And in many ways, it's a fair one. As the BSA spokesperson explained to ZDnet UK, "the performance of a piece of software depends on the environment it operates in, how the code is updated, whether it is possible to adapt and modify the software, and whether the code is attacked."
In other words, toaster makers don't have to worry (yet!) about hackers hijacking their products. They don't have to fret about a toaster burning down someone's house because it couldn't network properly with the refrigerator. And they don't lose sleep over whether their products are compatible with the latest frozen waffle designs.
And what about open-source software? A company like Red Hat, which charges users a licensing fee to use its Linux distros, might have more to worry about than a project that distributes its software completely free of charge. Even so, these distinctions would take the European and/or U.S. legal systems years to sort out -- and the results are almost sure to look a bit different than anyone expects.
Experts are divided on whether software product-liability rules would cause more problems than they solve. Bruce Schneier, one of the most respected IT security authorities on the planet, is a big fan of the idea.
Schneier maintains that most open-source developers don't have to worry about "contractual liability" issues, since they don't enter contractual business relationships with users. Some of the readers who commented on Schneier's post, however, think he is being way too optimistic here.
Linux kernel developer Alan Cox certainly takes issue with Schneier's position. In 2007, Cox told the UK House of Lords that this type of legislation is impractical, given the fact that developers always face a tradeoff between security and usability. And Cox, like many other critics, points out that such rules could lead to unintended,very destructive, consequences as developers scramble to cover themselves.
While this debate may not seem relevant to U.S. companies, that may not always be the case. Now that the cat is out of the bag in the EU, I wouldn't be surprised to see U.S. lawmakers pondering the pros and cons of a similar approach.
I'm inclined to agree with Alan Cox and other critics: This is an idea that sounds appealing only until you dig deeper and consider the long-term consequences. Yet I also think this is a debate software vendors and their customers need to have.
Software vendors make a lot of assumptions about why their products should play by a different set of product-liability rules. For decades, we have allowed those assumptions to ride with very little critical scrutiny or public debate. It is time for that situation to change.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.