software liability

Periodically, Bruce Schneier proposes establishing liability for software. I've responded with some concerns--I wasn't sure a liability rule is necessarily the wrong approach, but there are a lot of alternate ways to deal with the issue and liability might be the wrong hammer to turn this screw. But it's hard to discuss an abstraction, so I took a few minutes to try to write a statute that would impose liability for consequential damages on software manufacturers, just to see what sorts of issues I ran into. After going through the process, I think either it'd take a better statute writer than me to do the job well, or that a liability rule may be overkill at this point in the industry's development and risks some fairly significant damage to the software industry, in which case some of the other possibilities might be better choices.

Anyway, here's a blow-by-blow. First off, let's try to exclude open source projects.

(a) Except as provided in subparts (b) through (d) of this section, any entity that manufactures computer software for sale shall be liable for consequential damages caused by defects in that software, where such defects arise through the negligence of the manufacturer, its employees, or agents.

"For sale" excludes open source projects and people who give their software away for free, but it has some unintended consequences, too. Shareware authors will face liability under this statute, and adware (free software supported by advertising) probably faces no liability. Offering web-based applications, like the stuff all the rage at Google, Yahoo, and Hotmail right now, probably also doesn't constitute a "public sale." It's not clear what happens if you give away the software for free but make up your development costs on support contracts.

In fact, there's another, fatal problem in this language: very little software today is offered "for sale." Almost without exception, it's offered under a license to use it and specifically not to sell it. But if we write "for sale or license," the statute suddenly will apply to the GPL, LGPL, BSD, Artistic License, and anything else that's not public domain. In the end, it might be necessary to re-cast the statute in terms of generating revenue rather than selling software.

The plaintiff needs to show negligence, which imports the industry's ordinary standard of care into the statute. Notice that there's no limit on liability. That's a potential problem because it could either chill development or move manufacturers to jurisdictions that don't have liability rules. There's a lot of literature on product liability that may have some helpful suggestions for these issues.

Now, we want to encourage software houses to find and fix their bugs, so let's give them a safe haven exception for doing that.

(b) If, within sixty days of learning of a defect, the manufacturer corrects such defect and makes the correction freely available to purchasers of the software, this section shall not apply to damages that arise from such defect after the date on which the manufacturer learns of such defect.

So if you learn about a bug, and you fix it in 60 days, you don't face liability for problems caused after the day you learn about it. It's designed to encourage manufacturers to learn about their bugs as early as possible and to fix them within a reasonable amount of time. After all, we don't necessarily want them rushing those patches out the door. On the other hand, the statute doesn't say anything about bugs that the bug fixes introduce, and it says precious little about how they have to do the distributing. I'm having a tough time figuring out how to define a self-installing binary patch in statutory language, and freezing that definition into a law that might be around for 5o-100 years is likely to be a really bad idea.

Now, we don't want software houses to have to maintain support for their creaky old software forever--I mean, do you really want Microsoft to spend its time keeping Windows 3.1 on life support rather than chucking it and writing something with real security? On the other hand, we also don't want them to drop support the day before the software rolls out the door so they can avoid liability altogether. So how about a hold-down period?

(c) If the manufacturer publicly disclaims support for such software, this section shall not apply to damages arising after the Final Support Date, where such Final Support Date is determined as provided in this sub-part and sub-part (d) of this section:

(1) the Initial Sales Date shall be the date of first public sale of such software;

(2) the Final Offering Date shall be the latest of

(i) the date of the last public sale of such software,

(ii) the date on which the manufacturer publicly disclaims support for such software, or

(iii) the date one year after the Initial Sales Date;

(3) the Final Support Date shall be the later of

(i) the date one year after the Final Offering Date, or

(ii) such later date as the manufacturer may establish by agreement.

So if you sell software, you have to support it for at least two years. That might be a problem if you're a shareware writer. Individual consultants may get away without liability because there's no "public sale," though their customers can establish liability in the consulting contract. But suppose the customer puts that code into a product and then sells the product--then the consultant will be on the hook to provide support.

And there's another problem, here: (c)(2)(i) makes the Final Offering Date dependent on the date the software's last sold, so that mom-and-pop store with the dusty rack of ancient shrink-wrap code can keep the manufacturer in the support business. On the other hand, we don't want the manufacturer to say "no, really, we're dropping support" and keep pumping the product out the door and bringing in revenue from it. We also don't want the manufacturer to be able to disclaim support and then farm out the process of stamping disks to an affiliate that keeps selling the software. I haven't figured out a good answer to this problem, yet.

Anyway, let us forge onward. It sure would be nice if our manufacturer had the ability to sign separate support contracts with different people. ("OK, government entity, we'll keep supporting Windows 3.1 just for you, but it's gonna cost you because everyone else is moving to Vista.")

(d) A manufacturer may, by agreement, establish different Final Offering Dates and Final Support Dates for different users of the sofware, but in no event shall the manufacturer establish a Final Support Date which is earlier than the earliest date provided in subsection (c) of this section.

The "in no event" language is to keep someone from putting a 1 day Final Offering Date and Final Support Date in the EULA. Notice, though, that the "date of the last public sale" language may cause problems here, too. If you sell a copy of Win 3.1 to the government as part of a private support contract, is that a public sale? Also, the language is really clunky and could lead to differing court opinions on what the "earliest date" means.

Finally, we need to make it clear that you can't contract out of the liability. Otherwise, the software house will just put a clause in the EULA where the user agrees to waive liability.

(e) No manufacturer may waive liability under this section except as provided in subparts (b) through (d) of this section.

Hmm. This one needs some refinement for sure. Could you contract your support out to a dedicated support firm and send your liability along with it? What about to an undercapitalized support company that, if someone sues them, won't have any money to pay damages? If you do contract out support, can you get them to indemnify you for damages? If so, could you put indemnification in the EULA, so that the user suing you has to indemnify you for any damages that user might recover?

Finally, what happens if 47 states adopt this statute but Delaware, New Mexico, and, say, California don't? Notice that every EULA includes a choice of law provision ("the laws of the state of X shall govern this license"). You might expect those provisions to quickly swing over to whichever states don't impose liability.

Anyway, these are all issues to consider. As I said, I'm not expert at drafting statutory language, but the process of going through it has exposed a lot of ideas to consider with any push for software liability. These aren't just issues for the lawyers. Many of them are policy issues that determine what incentives we want to create and how we want the software industry to evolve.