Slashdot Mirror
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.
The problem is not with programmers but as to how they are managed and how the result of their labours is marketed.
Linux, and software included with it, is not generally provided with massive claims as to it's
improved functionality. There is no secret that there are bugs in linux, but you can find out what they are. Linux has very successfully done
its own marking without it making claims - the users do it for them. Only recently has IBM, Oracle, and others joined the Linux bandwagon.
For Linux and its stability they make no claims.
Torwalds himself sits by and says nothing...
Let MS post its change logs for windows.
This is not demanding open source from MS - does anyone really want to see it. It would be like
trying to keep the memory of a loved one in memory
as you are gazing at his/her rotting corpse.
Software is copyrightable.
Books are copyrightable.
Software is manipulating a language to control
a microprocessor.
The purpose of a book is to manipulate a mind.
Which is more important.
If I wright a self-help book which contains principles to supposedly improve my life (let's
say a get rich quick book) and I sincerely follow
those principles and can document it - and these
principles don't work - can I sue for the immeasurable pain caused by dashed hopes, and the
immense amount of time wasted by putting those
principles to the test???
Probably not - the legal experts will say - because the principles are not warrented.
Read the EULA's of practically every shrink-wrapped software package.
MS doesn't warrent its software for use in Nuclear
Power Plants and other places where things can get
critical.
No one warrants Linux, but the FAA is rumored to be testing linux for its later deployment in Flight Controlling Centers. Does this say anything???
Programmers are idealists - programmers do not generally like criticism of their efforts, but
programmers do appreciate the capababilities of
more experienced programmers who do not brag about their position in a company or exert authority based solely upon the fact that he had a
few beers together with the manager and found that they were passionate about the same football
team.
A Good Senior Programmer or Team Leader does not
innately want to critizize the work of another. The goal of the Leader is to promote learning - evalation is involved. The best way to do this is
to provoke the implementor to ask questions of himself - and on his own to maybe find a better
way.
In a code farm like the one MS maintains, and with
deadlines imposed my managers who have shown in there resumes that they can drive cattle, and marketers whose job it is to use pavlovian techniques to make the masses want more RIGHT NOW,
how can good programming techniques be taught and
good programs be written not knowing about what
goes on in a programmers mind. But probably,
the concept of 'mind' is non-existent with managers and marketers...
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
Sad, but those of us not in the Land Of The Free may have to consider this eventually, sort of an inverse case of the situation that used to exist with encryption and the US. Sigh.
I hereby inform you that I have NOT been required to provide any decryption keys.
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
Code has to be run before any bugs in the code can manifest themselves. The bugs only turn into damage when the code is deployed. In addition, the same code in another deployment might not cause any damage. Therefore, you cannot hold a programmer responsible for bugs. You can only hold him liable for damages done through bugs.
When software bugs cause damage, that implies the software was being run, probably doing something useful, perhaps operating on valuable data. The software breaks *because* it is part of a workflow, part of a system.
This is when you can hold liable the person that sold you the *system*. Some people, notably IBM, will do this.
HOWEVER, if you download and install applications willy-nilly, and play games, and don't reboot properly, and thus proceed to *construct your own system*, then *you* are liable.
What people do not realize, is that by dragging icons and windows across the screen, they are picking the fruits of over 40 years of work by other programmers, who made programming a computer as easy as dragging icons and windows across the screen.
Pushin' 'n dealin', shovin' 'n stealin'