Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
The Courts Government News

Cure For Bad Software? Legal Liability 456

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."
This discussion has been archived. No new comments can be posted.

Cure For Bad Software? Legal Liability

Comments Filter:
  • Liability for bugs (Score:4, Interesting)

    by Violet Null ( 452694 ) on Wednesday March 13, 2002 @03:50PM (#3158478)
    Liability for a bug that's known for more than x amount of time and is not publicly disclosed is one thing; the company here is obvious being negligent in neither fixing the problem nor alerting its customers.

    However, I shudder about the day where a company can be sued simply for a problem in the software. There's enough ways to sink a small company as it is, without the thread of "If your software isn't perfect[1], you're gonna pay".

    1: And we know that no software is perfect.
  • by SuperDuperMan ( 257229 ) on Wednesday March 13, 2002 @03:54PM (#3158507)
    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.
  • by jms ( 11418 ) on Wednesday March 13, 2002 @03:59PM (#3158555)
    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.

  • Re:no good (Score:2, Interesting)

    by Petersko ( 564140 ) on Wednesday March 13, 2002 @04:02PM (#3158582)
    If you are a responsible employee, you're situation doesn't change. Right now, if you can't deliver quality on time, you should:

    1) Inform your supervisor that the demands cannot be met with quality.
    2) If that is ignored, inform him in writing.
    3) If the expectation still does not change, then let the deadline pass. "I'm sorry, it's not ready. Here's why" - and show him the letter from #2.

    I work in a similar environment to you - I design internal software for an industrial company. Deadlines slip - it happens. Life goes on. I will not provide half-assed code just because the timeframe is running long.
  • by aridhol ( 112307 ) <ka_lac@hotmail.com> on Wednesday March 13, 2002 @04:02PM (#3158589) Homepage Journal
    so if there is a bug, who is the fault?

    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 [tesco.net] should be fixable immediately or subject to penalties.

    IMHO, of course.

  • by delta407 ( 518868 ) <slashdot@nosPAm.lerfjhax.com> on Wednesday March 13, 2002 @04:03PM (#3158600) Homepage

    The RFC states that:

    3) If another reporter has not properly followed the process and publicly announced the vulnerability, then the Reporter MAY announce that the Reporter was responsibly following the disclosure process with the Vendor and involved Coordinators.

    ...showing in a nutshell that the proper procedure is notifying the vendor and the vendor alone. Scott Culp says:

    Most of the security community already follows common-sense rules that ensure that security vulnerabilities are handled appropriately. When they find a security vulnerability, they inform the vendor and work with it while the patch is being developed.

    Please, if you would -- explain how these two are "in direct opposition" of each other. (Good luck.)

  • by jridley ( 9305 ) on Wednesday March 13, 2002 @04:34PM (#3158858)
    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.
  • by Anonymous Coward on Wednesday March 13, 2002 @04:47PM (#3158956)
    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...
  • by drew_kime ( 303965 ) on Wednesday March 13, 2002 @05:03PM (#3159095) Journal
    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.
  • New License? (Score:2, Interesting)

    by belroth ( 103586 ) on Wednesday March 13, 2002 @05:41PM (#3159368)
    Is it time to start work on a new software license to cover this? Add a clause to the GPL running something like "This software may not be used in the United States of America" and appropriate warning screens/click throughs indicating the same.

    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.

  • by MongooseCN ( 139203 ) on Wednesday March 13, 2002 @07:03PM (#3159850) Homepage
    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.
  • by Pussy Is Money ( 527357 ) on Thursday March 14, 2002 @07:12AM (#3161781) Homepage Journal
    The reason why you cannot put liability on a piece of software is the same why you cannot use a single benchmark to predict the performance of a whole system.

    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.

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...