Cure For Bad Software? Legal Liability
satch89450 writes: "SecurityFocus had a column that I missed when it was first published a few days ago, titled 'Responsible Disclosure' Draft Could Have Legal Muscle, but I discovered it when researching an answer to a comment on the CYBERIA mailing list. In this article, Mark Rasch discusses how the Draft would set the rules for reporting security vunerabilities, and in particular define the boundaries of liability assumed by bug-disclosers. By adopting a "Best Practices" RFC, the IETF could help the reporters of security-related bugs do their job, and put the onus of fixing the bugs on the vendors who make the mistakes, where it belongs. (The RFC draft described in the article, 'Responsible Vulnerability Disclosure Process, is here at the ISI repository.) This is, of course, in direct opposition to the process that Microsoft's Scott Culp, Manager of the Microsoft Security Response Center, would like to see. As Microsoft is more part of the problem than part of the solution, I believe that the path to a formal process would better serve the entire community - and that community includes Microsoft's customers. I'm taking this seriously because the mainstream press is talking about the issue, and what it's going to take to fix it. Here is an example from BusinessWeek that scares me silly. I'm glad I'm looking to change careers from software development to something safe, like law."
I agree. I would never consider contributing to the OSS movement if I knew I could be held liable and there is no reason I shouldn't be because I did it for free vs being paid. Linux will not be held to be above this process.
I'd hate to be responsible for ZLib.
Any liability law should offer an exemption for software that is distributed along with buildable, commented source code.
The reason is simple. The end-users of open source software are in a position to verify the integrity and correctness of the software. Even if such an end-user is not a programmer, they could, if they were concerned, pay someone else to inspect the code. They have been provided with the ability to protect themselves, because the source code accurately describes the actual operation of the product.
The end-users of proprietary software are in no such position. They are absolutely dependant on the software vendor to verify the integrity and correctness of the software. They are powerless to protect themselves, and without the source code, they are only left with a representation of the operation of the product. This is far less information then the source code, which specifies the actual operation of the software.
Therefore, only proprietary software vendors should be held liable for bugs in their software.
For every active open-source project, there is a maintainer. It is the job of this maintainer to ensure that released software is bug-free.
I think that, if we're going to have penalties for insecure open-source software, we should:
hold the maintainer liable
Only have penalties for release-level software. No alphas, betas, or cvs nightly builds. I also believe that a vendor or maintainer should be given a reasonable amount of time to fix a bug. There shouldn't be a penalty for a security hole that exhibits itself at one second after midnight on a full moon if the year is divisible by 7 when an attacker uses the root password as a user name. However, if this combination is discovered, and isn't fixed, then hold the maintainer/vendor liable.
OTOH, a crash that's caused by pressing the backspace key too many times should be fixable immediately or subject to penalties.
IMHO, of course.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Speaking for myself, I'm all for this. How many times have you wanted to do a better job but were given impossible deadlines, leading to shipping something you knew wasn't tested well enough, and hoping to fix the bugs later? Most programmers WANT to produce good software, but are not given time or tools.
I hope that something like this will cause managers and execs to provide proper tools and sufficient time to produce truly stable programs. I do believe that, like other forms of liability, though, unless intentional negligence is shown, liability must stop at corporations, not individual programmers.
Also, there must be still a way for free software to escape liability. If you're getting something for free, you can't expect the author to take liability.
I would think that in this situation, Microsoft should WELCOME liability law; it would be a great selling point for them in the face of Linux, if they could say "if you use free software, nobody is liable if it destroys your business, but Microsoft IS liable for any harm caused your business by our software." I imagine that many corp execs would give that argument a lot of weight.
However, at the same time I don't know if it would be 100% effective, because by now enough CTO's have realized that Linux (and other free solutions) is a more reliable platform for many applications, and it's still better for all involved to use something that works than to use something that causes you monetary loss and then try to recoup it in court.
Merchanitability is not liability. As far as I can see, this already covers software, correct?
Most modern EULA's specifically disclaim merchantability to any purpose whatsoever. The poster you're replying to is simply saying that if your software doesn't do what the seller said it would, then they owe you your money back.
You downloaded it for free? Then they don't owe you anything. You paid $50,000 for multiple installations and several hundred user seat licenses? They owe you a refund.
Nope, no sig
Let's say MS buys some code from a small competeing company. MS runs the code and it crashes one of their servers and causes some minor damage. MS then, using these new laws about accountability, sends it's massive legal department after the small competing company. The small company, having no finances to put up against MS, will cease to exist.
Sure the new laws of accountability sound nice but it takes money to enforce them.
Outdoor digital photography, mostly in New Engl