Everybody's sick of those jokes comparing software development to automobiles. But here's a twist that's new--and thoughtful. I heard it from Shlomit Wagman of Yale Law School at a presentation she gave tonight at Harvard's Berkman Center.
At the beginning of the twentieth century, automobiles were sold only to a small number of enthusiasts by companies that explicitly rejected any liability. If the wheel came off or your engine fell out of the chassis--"Fix it yourself." It was only when cars became an indispensable part of everyday life that courts overruled these agreements and said tort law must apply--in other words, manufacturers were responsible for providing safe cars.
Wagman thinks it's time for software to mature in a similar manner. Does this mean you can sue Microsoft for a calculation bug in Excel? By no means. Wagman--who was an extremely capable programmer before she entered the field of law--has a much more nuanced view of applying tort law. To get the full scope of it, you'll have to wait for a definitive publication from her. But I'll try to summarize the direction she's going in here.
First, the principle should not be compensation (paying for the damage caused) but repair and restoration. Bugs are inevitable, at least during our lifetimes. Software companies should be willing to respond to customer needs and have policies and processes in place to get bugs fixed.
Oddly, Wagman never uttered the words "open source" during her talk. But a few of her ideas touched on the idea, such as holding code in escrow (a practice some big customers already insist on). And software vendors, even if they keep code proprietary, should be willing to share extra information with customers to help them work around a bug they find, or fix it if the vendor lacks the resources to do so.
Software vendors should help to preserve or restore data in case bugs corrupt it. The more fundamental their role, the more responsibility they should have; thus operating systems bear more responsibility than applications.
Companies won't be sued just because their software is buggy. They can create safe harbors that protect them from liability by following best practices: working well with communities, providing prompt bug fixes, and allowing the restoration of lost data. (A "safe harbor" is a common legal term, known to readers of this blog perhaps because of its use in the DMCA to refer to protections for ISPs. When you engage in actions that could lead to liability, the law tells you what to do in order to avoid liability; that's the safe harbor.)
Security presents a special challenge, because the flow of responsibility is not simply from vendor to customer, but also from the customer to to the world at large. Modern networks allow customers to become sources of toxic traffic. Vendors can once again provide safe harbors by providing security patches promptly, but Wagman is searching for a way to urge customers to be responsible as well and keep their systems secure.
Wagman says that companies like to present software as a service, but really it functions more as a product, and should be regulated that way. This probably makes sense from a legal standpoint, but she also tossed in another suggestion that I found even more fertile: software as a collaboration between the vendor and the customer. Good vendors pay attention to what their customers want and react quickly (part of the agile movement as well). Smart companies can tap their customers' expertise and accept their offers of help. And if all companies did these things, we'd need less law.
November 8 follow-up: I exchanged some email with Wagman and got a better idea of her perspective on a couple points.
Open source: she considers it a very important movement, and encourages companies to open their software in order to fulfill the requirements of her suggested legal framework. But making software free is not enough. If the code lacks documentation, for instance, the customers may not be able to do what they need. To comply, free software would still need such features as easy recoverability in case of data corruption, and the ability to move data to an another system.
Of course, being free makes it easier for the community to help a vendor bring the software up to snuff. And the requirement that data be relocatable would invalidate many DRM schemes and the licenses that depend on them.
Finally, I should emphasize that Wagman's special approach to tort law is based on a recognition that software is a rapidly evolving industry that needs a clear legal space to promote innovation. Her essential concept of "repair, not compensation" may be a useful model for any field experiencing rapid change.
Comments (3)
One of the things I wonder about is whether globalization would have an impact on any attempt to tighten liability in the software industry.
We seem to be moving from shrink-wrap to online services, and online services can be hosted anywhere. If one country tightens liability it could push more of the software industry offshore.
Cars were a bit different. We had a large number of manufacturers in the US and import was expensive.
Posted by Michael Feathers | November 8, 2007 9:55 AM
Shopping vis-a-vis liability rules works in several ways. Given the track record of the software industry, how much would you be willing to pay, as a customer, for a vendor who was willing (or forced) to give you some strong assurances?
Some of us believe that the move by very conservative companies to buy services outside of their home country is driven by despair that their rights against nearby vendors are no better than their rights against distant ones, and their bargaining power with distant vendors might be better. I was making this argument/prediction back in 1997 at legislative drafting meetings, as American software publishers were working (successfully) to gut their liability in contract to their customers.
Another factor is that liability often attaches in the place the service is delivered. So even if you move your company to NoLiabilityLand, if you harm a California customer, you may be accountable in California. The USA is a large enough market that there will always be vendors willing to accept American liability rules--and price their products and services accordingly.
The question of whether any expansion of negligence liability is possible under the Zeitgeist of American law is a difficult one. I don't expect to see it happen over the next 10 years. However, we may see a resurgence of liability for fraud and breach of contract. The American Law Institute is working on an interesting project, Principles of the Law of Software Contracting, which may be influential in this respect.
Posted by Cem Kaner | November 11, 2007 4:11 PM
There are some basic things being overlooked here (glossed over, really).
It is a fact,a basic result of computer science, that no one can say for certainty that a program has no bugs. In fact, you can't even be certain what a program of any complexity will do with a given input. If you want programs and the benefits they bring, you have to learn to live with that.
Are we going to litigate through stack traces and have juries decide if, in fact, it was vendorX 's program that caused the general protection fault and it was in fact, a bug (and not a feature)? Perhaps a lack of documentation constitutes a bug? Come on. Only someone completely ignorant of very basic computer science would propose this scheme, and the fact that this lawyer was once a programmer doesn't gain-say very basic science.
Further, any type of regulation for "data retention" or "best practices" is, on the one hand, onerous to small shops and on the other chimerical. Best practices is a fantastically ephemeral concept that is regularly revolutionized and the subject of huge debate.
It's pretty clear, just out of the box, that this would have the effect of driving small software vendors from the market. Small software vendors- teams of 5 and 6 people- have created most of the really good software Microsoft et. al. sell you. Killing that goose may be good for very large players , but bad for society.
I once had a professor whose publications were known for the thoroughgoingness with which he attempted to disprove his own results in his own papers when he published them. His results were solid. Lawyers who propose laws and regulations should be required to submit an analysis of the various ways bad-faith actors could weaponize their proposed legislation and what the economic consequences might be.
People affected by such predictable consequences should be able to seek redress against the legislator. How does THAT sound?
It sounds a lot like what you're trying to do to me. That's how it sounds.
Posted by softwarevisualization | December 1, 2007 9:50 AM