Slashdot Mirror


Software Product Liability?

ben writes "Reuters just ran a story about the increasing number of calls for liability on the part of software developers, with a not-too-suprising focus on Microsoft and its uber-fallible IIS webserver. Given that many other engineering disciplines have some sort of accreditation and licensing body to enforce codes of professional ethics, I'm curious what impact the demand for such a creature in the software industry could have on Open Source developers, especially the part-time hobbyist ones. That is, establishment of some sort of Software Developer's license means the developer is potentially liable for whatever havoc his bugs may wreak, and traditionally the only environment with legal resources adequate to deal with such liability has been the megalithic corporate one."

5 of 428 comments (clear)

  1. WHO is Liable for damages? by __aadhrk6380 · · Score: 5, Interesting

    Hi, long time listener, first time caller and all that.

    I think the question (ultimately) may come down to where the finger gets pointed. I saw a post reference to certifications for programmers, which KIND of goes to my point. Then, I read the post on gun companies getting sued for the actions of their customers. Getting closer. THEN, I read the post by "The Eric Conspiracy" about Doctors, Engineers, Lawyers, etc, and what they are liable for. This is what I was thinking.

    In a corporate networked environment (I am narrowing it down here, I know, but bear with me), who IMPLEMENTS buggy software? How about the Sysadmin? Maybe not his or her IDEA, but they actually implement it. It ain't Joe Blow at his workstation who uses it. You are the one that put it out there for him.

    "Hey, our software was tested at M$ (or wherever) and found to run ok. What's YOUR problem?" If it hoses your network, or you get rooted, or whatever, it happened on YOUR system! Your firewall, your OS mix, your internal and external apps.

    I know this sounds far fetched, but look at Enron. They played fast and free with almost everything they did, and Arthur Anderson went along with it. Now, since AA got convicted, the Enron stockholders are going after THEM instead of Enron. Responsibility was neatly deflected from one to the other because it was EASY to.

    If you implement software onto your network, my guess is that EVERYONE that had ANYTHING to do with making it will be pointing to you as the (ahem) "root" of the problem. After all, it happened on your watch. And, odds are, YOU have some certifications! Tsk, tsk, you should have KNOWN better!

    Paranoid? Probably. Hopefully, anyway. But look at everything that has happened from day one on this planet. When something either goes wrong finally, or has gone wrong for long enough that people complain, the finger of blame always swings over to the easiest target.

  2. Merchantibility by Arandir · · Score: 5, Interesting

    I think mandatory licensing for developers is stupid. Last thing anyone needs is a new bureaucratic office dedicated to extracting fees from developers.

    But warranties are a different matter. If you market your software as a commercial product, then it should have the same warranties as any other commercial product. This is common courtesy. It's also known as being ethical and moral.

    If you claim that your software is suitable to be marketed by actually marketing it, then you need to back that up by NOT disclaiming merchantibility. If I buy a toaster and it doesn't work as a toaster, it has a warranty that says I can get it repaired or return it for a refund. Commercial software should be the same. If I spend $199 on a word processor and it fails to process words I want recourse. If a patch is available then I want to be able to get that patch without having to pay for it. If no patch is available, then I want my money back. Is this so hard to understand?

    But before you all get your panties in a twist and start crying out that warranties will kill off Open Source, remember that this only applies to commercially sold software. No one expects merchantibility for freely downloaded software. Second, the warranty should reside with the seller, not the developer. So Redhat can sell your software and you are off the hook, because it is Redhat that is claiming the software is merchantable and not you.

    (liability is a different matter. I believe that every competent business should have liability insurance. But I don't see any problem with disclaiming liability so long as the recipient knows of the disclaimer before using the software)

    My current software has a warranty disclaimer. That's okay because I am not selling my software. If you wish to purchase my software, you will get a warranty with it. This warranty will cover replacement or repair of the software for one year.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  3. Re: Hey I'm an Architect that just finished a bank by Anonymous Coward · · Score: 5, Interesting

    OK, So I'm an Architect, and just finished working on a bank to boot.

    You are right that there is a reasonable level of liability and quality expected within my design for the bank.

    If the bank was to get robbed via force, I wouldn't be liable, for it was never represented by me, or required by my client, for the bank to be 100% robber-proof.

    My design was required by my client to meet their needs for security and safety, so it's more important that the vault is secure and that someone can't easily hold hostages within the bank than it is to make it so that someone can't walk in with a shotgun and run out with a few thousand dollars. It's impractical to make the bank 100% robber-proof.

    Now if a flaw in my design allowed someone from the Togo's next door to open a hole in the wall, and gain immediate and complete access to the vault- well then I would be liable, and rightly so. If I designed a bank with hidden corners and nooks where one could hold up and defend the bank in a hostage situation, and someone was gravely injured because of it, then I would be held liable. My design failed. I was negligent.

    See there is a scale to this, a level of reasonable liability and requirements.

    As an Architect, I am liable for everything I do, just like a lawyer or doctor or engineer. And just like a doctor or lawyer, I must complete tests and a certain amount of training to gain licensing to call myself an Architect and sign drawings as such.

    Now any kid could design a house. That doesn't mean the roof won't leak and that it will survive an earthquake. That's the point of licensing in Architecture; I gain the legal right to sign drawings (a requirement for anything bigger than a house) and the legal right to call myself an Architect (that's right, all you 'software architects' our there are technically breaking the law- it would be like calling yourself a 'software doctor'- no one takes this seriously, but still that's the law) at the cost of accepting the liability for the work I do and the advice I give.

    Now the software most Architects use is horrible. It doesn't perform as advertised, costs a fortune, and the licensing is draconian. It's frightening and sad. Now if it crashed now and then ok that's reasonable because there is no such thing as %100 stable software, just like there is no such thing as a %100 robber-proof banks.

    However when there are GLARING deficiencies in a design, I believe that the people should be held liable for their work. In every other industry and business this is the case.

    I don't think requiring licensing or liability for software development would have the 'sky-is-falling' response most of you geeks are saying it would. I think it would provide a much better, and respectable, industry in general.

    To compare this to Open Source software; just because I design a house and freely publish the plans doesn't mean I am liable for every house that SOMEONE ELSE builds from my plans. If you bought my plans, and built the house I designed; well it's on your head to make certain the roof don't leak. But if you hire me to sign those drawings, or design the house or oversee it's construction then it's my legal and moral duty as an architect to make certain that the roof don't leak. See the difference?

    (I am over-simplifying this; I know. But I'm proving a point here)

    So if I download Debian, and compile it myself, the Debian project is not responsible for how I did it, nor has any control over how I did it, so therefore they shouldn't really be held responsible for my actions.

    But if I hired someone to do it for me, or bought an off-the-shelf copy from Microsoft, and it has GLARING design deficiencies that cause it to fail in it's advertised abilities, well, I should be able to at the very least get my money back.

    Software Developers should be ashamed that they don't hold themselves accountable for their own products.

  4. Re:i've said it 100 times by Tony-A · · Score: 5, Interesting

    The problem with software is that when a virus/cracker compromises your system, any resulting damage can not logically be attributed to the software developer.
    The problem with Firestone tires is that when road conditions compromise your tires, any resulting damage can no logically be attributed to the tire manufacturer.

    If IIS blew up on it's own and erased your disk you would have a legitimate case. As soon as a third party maliciously tries to compromise it, the case is off.
    If Firestone tires blew up on their own and flipped your SUV over you would have a legitimate case. As soon as you subject the tires to actual road conditions, the case is off.

    Your contention is that Microsoft software is not fit for any actual use?

  5. The Key Is in the Code by gallen1234 · · Score: 5, Interesting

    Let me make a suggestion: If you produce a closed source product where you release only the executables then you should be held liable for any damage the product causes. If, on the other hand, you release the complete source code for your product then caveat emptor. In the later case the user/purchaser has all the information necessary to (a) evaluate the safety and security of the product and (b) make any modifications necessary to bring the product up to their standards. If they don't have the wit or the will to do so then they're on their own.