Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Courts Government News

Software Product Liability? 446

Posted by michael from the sign-on-the-dotted-line dept.
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."
This discussion has been archived. No new comments can be posted.

Software Product Liability? More

Software Product Liability?

Comments Filter:

  • Software liability (Score:2, Informative)

    by ezs ( 444264 )
    From my own experience most software vendors actually limit their liability by way of the EULA (End User License Agreement).

    Of course having to undo the shrinkwrap to read the EULA, and by having read in the EULA that by undoing the shrinkwrap you therefore agree with it.. that's another issue altogether

    • Re:Software liability (Score:3, Interesting)

      by alienw ( 585907 )
      You can't always limit liability. For example, you can't sell a car and say that you are not liable for design defects. You are, no matter how many EULAs you write. The same could apply to software.

  • heh (Score:2, Flamebait)

    by doooras ( 543177 )
    just blame your bugs on bad drivers.

  • So many possibilities to cover... (Score:2, Insightful)

    by Anonymous Coward
    What if they blame your software, when in reality it's the fault of some other software used in conjunction with it? Or it's a hardware problem? Or it's a user trying to cover their own ass when they screw up? It's not quite as easy to see what happened after the fact as it would be if say... a building fell down.

    It's more analagous to doctors prescribing medications. They do their best to make sure the patient is in the right condition to take them, but they can't control what the patient takes them with, or how they might misuse them. But of course, malpractice insurance is quite expensive...
    • ``What if they blame your software, when in reality it's the fault of some other software used in conjunction with it?''
      In MicroSoft's case that's hard, though. If I exploit a buffer-overrun in IIS or the infamous chat control, the fault is certainly in the software that has the buffer-overrun vulnerability. If a ``printer driver tanks the system'' (from the Reuters article), then obviously the system isn't very stable. Part of an Operating System's task is to ensure that one program doesn't interfere with others, and if a printer driver can affect the whole system, apparently the OS is flawed (there are those who would disagree with this point, but I for one expect my operating system to be stable).
    • No, no, no, no, no! We *can* control it. We *can* build fault tolerant systems. We *can* take our time to ensure that our application will only respond to valid input/requests/etc. If you build the OS, make sure that nothing using your OS has a chance of crashing it. If you build a webserver, make sure that feeding it crap in the URL will not cause it to respond "The root password is 'imadip'".

      What happened to the idea of a program having a well defined set of inputs and only causing it to respond to those inputs? And if something goes wrong, where are people getting off trying to blame it on the user be it a person or another program using that well defined interface? Argh.

      Word did not crash Windows. The printer driver didn't crash Windows. The stupid user who pressed the wrong things in the wrong order didn't crash Windows. Windows just crapped itself.

  • good question (Score:3, Insightful)

    by caseydk ( 203763 ) on Sunday June 16, 2002 @07:01PM (#3712465) Homepage Journal
    This is a serious question that always seems to be glazed over by the open source advocates. Most seem to see it only as a method of attacking MS.

    Well, if liabilities become a reality, EULA's won't protect the company, otherwise every company just puts a clause in it and the liabilities cease to exist. The law would be required to allow very few, if any, exceptions.

    If the open source community has to face this, what will happen? The next time there's an error (such as the recent Bind exploit) do the lawsuits begin?

    • Re:good question (Score:3, Interesting)

      by gorf ( 182301 )

      Most seem to see it only as a method of attacking MS.

      I think that's a bit unfair, since people (in general) pay MS, but not the author of free software.

      That does raise a tricky issue though; would a company that resells free software be liable for it?

    • Re:good question (Score:4, Interesting)

      by analog_line ( 465182 ) on Sunday June 16, 2002 @08:08PM (#3712745)
      I wouldn't count the EULAs out just yet. The latest victory for them is the Blacksnow v Mythic Entertainment lawsuit that was mentioned here previously. (For those who can't remember and don't want to reread stuff, Blacksnow had people using macros and other aids to build characters fast within Mythic's Dark Age of Camelot MMORPG, and selling the characters and items for real world cash).

      Mythic got a judge to rule that the arbitration clause in the EULA is legal and enforcable, and they (of course) expect that arbitration to conclude that the prohibition against item-selling is legal as well.

      Yet another precedent of EULA enforcability and legality. Just one more reason to READ THE DAMN EULA.

      If you can't read the EULA before you purchase the product, don't buy the product. If you do, tough shit if you can't get your money back. The product was obviously more important to you than protecting your rights.

  • Code is free speech (Score:2, Insightful)

    by splorf ( 569185 )
    And requiring programmers to be licensed is no more legitimate than requiring journalists to be licensed.

    There can certainly be some kind of liability for bad code that you deliver to clients under a contractual relationship, just like there can be malpractice if your doctor gives you bad advice.

    But liability for a program that you've published on the net or sold retail? That's as bad as liability for publishing a book advising people to plan their finances by astrology or go on some quack diet to prevent cancer. Those books are published all the time and it's (rightfully) up to the buyer to take the advice or not take it.

    Most buyers simply know better than to believe such stuff. And sooner or later they will hopefully know better than to run Windows. It's just a matter of the field getting more mature.

    • Re:Code is free speech (Score:3, Informative)

      by caseydk ( 203763 )
      I think the premise of code = free speech was defeated in the DMCA case in NY. Remember, code in executable form was considered a breach. Any other form was okay...

      • Re:Code is free speech (Score:2, Insightful)

        by splorf ( 569185 )
        The NY DMCA ruling will hopefully be overturned. Anyway, source=speech isn't so bad. Publish source so the world can see your bugs and make its own evaluation, and you're protected. Keep the source secret (like Microsoft) so people have to rely on your representations, and you're responsible for whatever happens.

        That's consistent with the book situation--you're free to publish that quack investment book because anyone who reads it can decide for themselves whether it's crap.

        I should have mentioned this in the earlier post but wasn't thinking about binary-only programs. A binary is more like a pill, where you can't tell what's inside--you can only swallow it and see what happens. With source code, where you tell the reader what you know, and short of actual malice (similar to libel etc.) you should be protected.

        • Well said, sir! That is the most intelligent observation I have yet read in this thread.

          Blockquoth the parent:

          Anyway, source=speech isn't so bad. Publish source so the world can see your bugs and make its own evaluation, and you're protected. Keep the source secret (like Microsoft) so people have to rely on your representations, and you're responsible for whatever happens.
          This is it: the solution to the problem of software liability vs. free software. For big companies like Microsoft, there will be two choices: take responsibility for bugs and failures (read: bugs get fixed) or open the source (read: bugs get fixed). That's a win-win situation.

          For free software, the worst case is that this would kill off binary distributions. Red Hat et al might just get insurance and go on as usual, but LFS, Gentoo, etc. will definitely become much more popular.

          May I repeat: if this were to happen, it would probably be the best thing to happen to the computer world since... I don't know... since commodity PCs.

    • Commerce != speech (Score:3, Insightful)

      by fw3 ( 523647 )
      Generally businesses, people working in their professional contexts do not enjoy the proceess rights.

      What is sold as a product is not speech. If the courts have not been uniformly easy on code which expresses scientific ideas, written in an academic context, then certainly commercial software will not (and I think should not) enjoy protection as speech.

      What would have to happen to change the current setting where commercial practice (and law) considers all software to be 'without warranty' is another matter.

      The obvious reason that SW is presently very much a 'caveat emptor' instance is that most nontrivial software products are both comple and can be run in such a wide array of hardware and software environments that solid analysis of potential failures is clearly infeasible.

      • What is sold as a product is not speech.

        Whew! That certainly takes care of all those freedom-of-the-press concerns. They only apply to press which is given away free!

        and can be run in such a wide array of hardware and software environments

        Now there you're onto something. The person who installs the software on the hardware effectively creates the warrantable device. Which, if this were the business model, would mean that /.'s parent could have gotten a fair premium selling those boxen, and no sane vendor would sell systems with MS OS installed.
        ___

        • No, he's about right. If you go to your lawyer to get legal advice, he can be held liable for it. His ability to speak freely is totally irrelevant. No one is saying that you cannot say whatever you want -- only that you may be held liable if it is injurious. (e.g. if your lawyer told you to do something criminal, or which harmed you in a proceeding)

          Frankly, and I say this because I've been doing some work with consumer fraud recently, courts simply do not like a caveat emptor approach to business. They prefer an ethic of honesty and frankness that favors the consumer, and aren't afraid to enforce it.

          There have always been limits to the breadth of free speech. It doesn't protect you in cases on treason, or libel, or slander, or incitement, or copyright infringement, or a host of other things. It's extensive, but it is not intended to shield actual wrong doers after they have done some actual harm.
    • disclaimers? prehaps for those "book" they have disclaimers and stuff ......

      just like those "Psyhic (sp?) Friend Network" ads they have subtitles "for entertainment purposes only"

      and labels on peanut choclate bars that says "this may contain nuts" (I know peanuts is not a nut but geeze).

      people are STUPID enough to belive these things...
    • If I build my own device, and I am harmed, or give it to somebody with a warning and they are harmed it is my fault and that other person's fault for trusting my non-certified device.


      If, however, I am the head engineer for a project, and it fails, my head should roll. This goes for things I would manufacture and sell.


      If I putz around with some code, and share it, no big deal. As soon as I am in the software BUSINESS, and sell that code, however, I have a responsibility to the folks who use that code.


      Most folks who write stuff in their spare time, write it first and foremost for their own use. Since they made the effort, many folks decide to share it with the world. Of course it won't be polished, but at least they try not to hurt themselves with it, so it follows they wouldn't be hurting others with it either.


      Software vendors make software for a profit. And do a shitty job of it. They SHOULD be held accountable for their inferior shit that hurts individuals and businesses with lost productivity and data.

  • Oh boy... (Score:2, Insightful)

    by symbolic ( 11752 )

    This could lead to all kinds of nastiness. If a software vendor wants to limit their liability, they may tie their software to a very specific hardware configuration. This could result in the unintended consequence of giving M$$$$ an unprecedented amount of control over the hardware manufacturers and resellers. So, instead of purchasing software to solve a particular problem, you purchase hardware to meet the requirements of a software package. This seems^H^H^H^H^H is half-assed backward.
    • This has already happened. Customers who buy large machines to consolidate tons of small servers onto one or more larger, more expensive and reliable systems, have found this. It's not only the hardware configuration, but also software. If you run vendor X's software on your machine, you can only run vendor X's software on that machine. Install anything else and you risk losing your support contract.

      In some limited cases (e.g. servers that cost a million bucks), this makes a lot of sense. It's a configuration that you know will work. If it doesn't work, you know that your configuration is supported by your vendor, can be replicated and can be debugged.

      I think we'd both agree that this sort of limitation is bad for average (home) PCs. Maybe my desktop or my personal web server can handle a little downtime. A machine that handles revenue for my company is an entirely different matter. That machine has to work and I'm willing to accept limitations on what I can do with it in order to guarantee that it will function.
      • This is sort of what Apple does with their extended support deal, Apple Care. They will not support the use of ANYTHING else and tell you to uninstall it/blame it for any problems you have. They gave my mom a rasher of shit because she put Opera on there instead of Exploiter.

  • Classic Microsoft Quotes in the Article (Score:5, Informative)

    by tupps ( 43964 ) on Sunday June 16, 2002 @07:04PM (#3712482) Homepage
    Couple of quotes in the article I like:

    The products are even less buggy than others, in terms of per capita usage, Microsoft Chief Executive Steve Ballmer has said.

    So does that mean that because more people use Microsoft software they can have more bugs in it? This sort of statistic is like using "Revenue over number of employees named Frank" as an accounting measure for companies!

    And the other one:

    Mundie said. "Microsoft can't control that process. If the printer driver tanks the system, who do you hold liable?"

    Now *that* explains what caused all those holes in my locked down IIS server!

    • > "Microsoft can't control that process. If the
      > printer driver tanks the system, who do you
      > hold liable?"

      On drivers specifically, this is a valid complaint . While I don't suggest that Windows is a highly stable OS, the image of Windows instability is partially undeserved.

      There are many badly written (non-microsoft) printer/file filter/device drivers that make things go horribly wrong on Windows, and near as the end user can figure, it's just Windows crapping out.

      Such a liability law would likely require Microsoft to increase it's legal department just to keep up with the number of cliams wrongly filed against it --- if Microsoft's business practices remained unchanged.

      This problem is relatively straight forward for Microsoft to get around. Come up with an exhaustive certification program for all Windows drivers, offer no MSI support for uncertified drivers, and change their increasingly restrictive EULA to state that the use of uncertified drivers is a violation of the "agreement."

      As a side effect, such a program might make Windows too expensive of an OS for companies to develop for, and then we'd get flood of devices and low quality drivers showing up on Linux.

      ( I can't believe I just came out in defense of Microsoft... I've got to go take a shower now )
      • There are many badly written (non-microsoft) printer/file filter/device drivers that make things go horribly wrong on Windows, and near as the end user can figure, it's just Windows crapping out.


        What's a printer driver? A printer is an I/O device that is on the OTHER SIDE of an industry standard port. In essence it is a "remote device." What business does that sort of software have running in "ring 0?"

        I am aware that many "printers" are dependent on "drivers" because they are missing hardware, but who's idea was that . . . ? Blame goes to: Microsoft.

        I'm not sure what you mean by "file filter" but the same argument almost certainly holds. Blame goes to: Microsoft.

        Beyond that "windows device drivers" aren't really drivers anyway, they are plugins to the (Microsoft) class driver. If they crash the system it is still Microsoft's fault, because the interface is poorly defined or the class driver does insufficient error checking. Blame goes to: Microsoft.

        I have no sympathy at all.

        -Peter
    • Mundie said. "Microsoft can't control that process. If the printer driver tanks the system, who do you hold liable?"

      OMG, this is exactly the same thing a guy said to me when I was complaining about Windows stability... I mean, really, if the printer driver tanks the system? Build a solid OS and the printer driver might not work, but it sure won't tank the system. If the operating system crashes, it crashes.

      If me running Microsoft Word on Windows 98 causes my system to crash, the flipping OS needs fixed (Yeah, I was stuck with that combination for the first year of school and yeah, it sucks). No wonder the old quote "If we built houses like we do software, the first woodpecker to come along would destroy civilization" holds true.

  • Being liable is clearly a problem if you release your software for free (i use both meanings here). I think software companies should be liable if their software is not free. When you agree to give up money or "freedom" for software, It is my opinion that you should get a quality of service granted in exchange.

    This should usually be handled by the invisible hand of competition, but huge software companies are so well-established that they can afford to give up on quality. I think that such a measure would protect the consumer from such abuses.

    This is just an idea, it's certainly flawed and incomplete. Does anyone care to contribute?

    • I tend to agree with you. Any 'lemon laws' should have a clause to deal with 'free software'. After all, if a hobbyist releases a tool he wrote for his own use that others may find useful, yet doesnt charge for it, he should not be liable for his free tool causing prolems with something company X used it for.

      However, if he packages it and charges for it, he should be responsible for it's correct and accurate operation., within reason. If the software requires certain hardware, he should not be made responsible if customer y doesnt meet said requirements.

      It's a really tough question, because while we would all like to see large corporations made responsible for their mistakes/bugs/poor code... No one wants it to hurt someone who gives away the fruits of their labour in an effort to be helpful.
      • What if somebody else packages and charges for it? If I write a neat little util, and it winds up in the RedHat distro, who takes blame for it when somebody installs it on their server, and it works about as well as you'd expect for a 'version 0.4' release?
      • After all, if a hobbyist releases a tool he wrote for his own use that others may find useful, yet doesnt charge for it, he should not be liable for his free tool causing prolems with something company X used it for.

        I disagree. If anyone -- be it a hobbyist, or a company like Microsoft -- releases software with a disclaimer to the effect of "this is a piece of junk, don't trust it with anything important", then they shouldn't be held liable. Of course, that might significantly impair Microsoft's ability to sell their product.

        Conversely, if someone releases or distributes software while giving the impression that it will work, it should work. If I install qmail, someone finds a security hole, and I suffer damage as a result, djb should be liable -- not just because he distributed subjuctively insecure code, but because he distributed subjunctively insecure code while making statements which lead me to believe that it was secure.
  • I think this would be an administrative nightmere for open source... Don't give me some B.S. about open source getting some kind of exemption cause its not gonna happen... also don't give me B.S. about open source not having security bugs... they DO!

    Lets say this becomes true and Microsoft gets sued cause HyperTerminal (part of Windows) has an root exploit. Microsoft pays damanges and then will probably sue HillGrave Software (or whatever company they sub-contracted to write it). (or they have insurance). This will drive up the cost of software for sure..

    Lets take a look at the open source way. Lets say some company using package X get rooted cause of an bug in package X. It sues the maintainer of package X. The maintainer then pays out. What does the maintainer do? sue the developer who wrote the chunks of code?

    This will particularily bad for open source software for the following reason: large companies can afford insurance against this.. open source cannot... once open source gets one or two lawsuits cause of this... I expect more and more open source projects/developer to give up cause they can't afford to pay out..
    • You could also flip this around and look from the point of view of someone in a company considering what software to buy. If Microsoft software goes bad, then they know who to sue and they have lots of $$$. But if they buy open source, then who do they sue, and do they have any money anyway?

      This could generate an answer to the question "What is the difference between Red Hat/Debian/random-distro" of Linux -- the difference could be in how much they guarantee the liability in their software. Sure it's a risk for a distro to do so, but if they really believe the "many eyeballs == better software" theory, it's a risk someone may take.

      - adam

  • Sensible liability. (Score:2, Insightful)

    by danamania ( 540950 )
    I doubt software vendors could continue to exist, if there were a level of performance required where NO bugs/faults were required. What may work though, especially when it comes to software like IIS and all of its fun vulnerabilities, is lemon laws similar to for cars.

    A model of car needing a recall is no big deal - it's a bummer and an inconvenience most of the time, much as most software has the odd patch/upgrade for reasons of bugs appearing publicly. Continual faults/bugs/etc are a different matter entirely.

    The notion also, of Unstable, Stable, Testing versions of software seems pretty sensible when it comes to the liability in open source software. Letting a user know what they're in for when using an Unstable product limits liability by saying "OK, this really could be crap" - miles more than IIS, to use one example.

    a grrl & her server [danamania.com]

  • Est. $60,000,000,000/yr in USA. (Score:5, Informative)

    by Black Parrot ( 19622 ) on Sunday June 16, 2002 @07:13PM (#3712512)


    The NIST commissioned a study [nist.gov] (sorry, 1.4Mb .pdf) that analyzed the cost of bugs^w "inadequate software testing infrastructure" in a couple of industries and then estimated how the cost scaled up to the entire USA. Result: $60 billion per year.

    If you don't want to download the report, there's a brief summary in RISKS Digest 22.11, on comp.risks. If you do download the report, the final numbers are on p.174

    • Re:Est. $60,000,000,000/yr in USA. (Score:4, Interesting)

      by Gorobei ( 127755 ) on Sunday June 16, 2002 @07:26PM (#3712571)
      $60B/year sounds reasonable: 100 Million users, with an average wage of $10/hour = 60 hours/person/year wasted, Or about one and a half hours per week for your average person.

      This is less bad than traffic jams, and somewhat worse than income tax forms.

      But, so what? Would America benefit for bug-free software? Would spending $300 billion so that ATMs didn't crash, Microsoft Expedia always worked, Verizon's DSL billing was perfect, really be a good use of resources (even if we could do those things?)

      We expect stuff to fail. Let the free market decide what level of error we will tolerate (e.g. I can deal 1 crash per year on my home machines, my parents don't mind 1 crash per day! - we have different needs and price points.)

  • quick solution (Score:3, Interesting)

    by Alien54 ( 180860 ) on Sunday June 16, 2002 @07:14PM (#3712513) Journal
    I would define software into several broad categories:
    • Non-Comercial For which money is not charged
    • Commercial for which money is charged
    • Licensed Commercial For which Money is charged, but for which no sale is made.
    Commercial software would include the obligation of support, although the require period of time is open to debate. I would advocate 5 years, although this could be set to several classes, such as 1 year, 3 year, 5 year, and 7 year. Each with a degree of obligation of support, liability, etc.

    Non Commercial would not be subject to the warranty, and so would cover open source, donation ware, shareware, etc.

    Shareware, etc. would probably have to be sorted out as software where no payment is required.

    I advocate that any software not sold but merely licensed must have complete liability coverage and support for the duration of the License.

  • Two observations on the article (Score:4, Interesting)

    by SirKodiak ( 585894 ) on Sunday June 16, 2002 @07:14PM (#3712514)
    In general, Microsoft says it is unfairly targeted because of the popularity of its software, which run everything from PCs and handheld devices to servers and game consoles. The products are even less buggy than others, in terms of per capita usage, Microsoft Chief Executive Steve Ballmer has said.
    It seems like Steve Ballmer is trying to suggest that software with 10 users and 1 bug is of equivalent quality to software with 10,000,000 users and 1,000,000 bugs. I don't think I see the justification for this.
    "Society has benefited from high-volume, low-cost software and a rapidly evolving ecosystem" where disparate computer systems, software and hardware link up, Mundie said. "Microsoft can't control that process. If the printer driver tanks the system, who do you hold liable?"
    This seems like a solved problem. If a subcontractor delivers a part to the construction of a bridge that isn't within the tolerances laid out by the bridge designer, and the bridge fails as a result of this, then the subcontractor is at fault. So, it seems like this is only a problem if Microsoft's documentation for the creation of printer drivers isn't specific enough. This is a situation that can be handled with well-defined APIs.
    • Your example is too simplistic for the issues that must be resolved. Instead, consider:

      Motherboard "A" works fine with SoundX soundcard VideoV video card. You (the consumer) hear about the new VideoVx with 3 trillion instructions per second it makes quake look like a movie.

      Now you install the new card VideoVx. After doing so, the system crashes. You pull out the sound card and everything is fine.

      Now who is at fault?
      The Video card maker:
      Do we force every hardware update to be backwards compatible with every combination of hardware?
      The Sound Card maker:
      VideoVx was not even available when SoundX was created. Do we force every hardware maker to test and supply fixes for every new piece of hardware made available everyday?

      The mother board maker:
      They let the hardware conflict in some fashion or the system would not have died? Picture the permutations of hardware that would need to be tested to ensure that every possible combination of sound, video, cd, dvd, scanner, camera, hard drive, chipset, bios and operating system worked in any combination.

      The OS supplier:
      Face it, they did not prevent the interaction that allowed the failure. Of course, everyone was using them as stated, this specific combination however was not forseen when you bought the OS two years ago.

      People keep mentioning architects/structural engineers/etc. Consider building a bridge where the materials changed four times a year. Would you know that mixing bolts of MaterialX with sleeves of material "Z" were an issue until a reaction (created by runoff from the surface of the road) happened? Of course not, nor do we expect them too.

      This is why new materials are so slow to move into construction. We cannot afford to have buildings fall down.

  • Re: (Score:2, Troll)

    by account_deleted ( 4530225 )
    Comment removed based on user account deletion

  • Death of Linux (Score:4, Insightful)

    by BWS ( 104239 ) <swang@cs.dal.ca> on Sunday June 16, 2002 @07:30PM (#3712599)
    lets consider two facts..

    1) RedHat/Mandrake/Suse/Caledra has been the big push of open source for the business world... without them Linux would be dead in the business world...

    2) companies in (1) released products for sale (you buy them) and they sometimes have security bugs (a lot of them has a recent exploit in SSH recently)..

    3) companies who uses products by companies in (1) who get 'rooted will sue the companies in (1)

    4) companies in (1) will die (they have lot less $$$ then MSFT)..

    5) bad for Linux...
  • I don't care what software package you are talking about, but I can find at least one bug in it. And I can set it up so that the bug in questions causes me some amount of damage. Then I just find a lawyer and sue. I could make quite a living. I just buy a new piece of software each week and manufacture another lawsuit.
  • traditionally the only environment with legal resources adequate to deal with such liability has been the megalithic corporate one.

    Professional engineers, doctors and lawyers are subject to liability claims arising from negligent behavior. There is also insurance available to cover these circumstances.

    Megalithic corporations do not have any special exemption from disaster due to product liability claims. Many are driven into bankruptcy as a result of liability problems (Dow Corning, Johns-Manville, and Soon Arhter Anderson).

    • The way I recently heard it, Arthur Anderson will be, barring some appeals court miracle, out of business due to an SEC rule that prohibits any company convicted of a felony (obstruction of justice in A.A.'s case) from performing audits on publicly traded companies. Not really a liability problem.
  • As a developer, I cringe at the thought of being liable for my code. We all know its next to impossible to make something completely bug free.

    However, as a consumer, buying software should not be a risk. It should do what it says on the box, and if it doesn't, I should be entitled to have it fixed.

    Of course, these sentiments are ingrained from my days as a Windows user. With Open Source, its a whole different kettle of fish. I've paid nothing for it, so I've gained by merely having the software. If it doesn't work, big deal, I either move on to another app, report it, wait for it to be fixed or if I'm really desperate dig the code out myself. At the end of the day, the worst situation that I can be in is that I'm back to where I started, it hasn't costed me anything.
  • If I recall correctly, all products have "implied" warranties that cannot be voided. So, if you ever sign something that "voids" your warranty when you buy something from a merchant ("as is"), it really doesn't mean anything if the product is deffective. Lawyers just like putting phrases like that in so that the people who don't know any better will say "shoot, I can't sue because I signed that paper . . ."

    I think "common law" applies to non-merchants and is very different (your hobbiest), but I better shut up before I post some big mistakes.

    Anyway, to begin, I am assuming that expecting hobbiest to be liable for their code is total BS. It is like making someone responsible if their post causes someone damages or to kill themselves. Not only do I think current "common law" would imply hobbiest to be free of liability, they could always just use an alias for their code contributions, making enforcement impractical.

    However, as a merchant, I think that by giving out the source code of your product, all related parties would effectively have the ability to check the code before they use it, which would shift the responsibility to the consumer. Yes, this is impractical! However, why do you think CPA's exist? Accounting information is extremely impractical for each individual to analize, so we have something called "auditors" to do this for us. It wouldn't be weird if a "software auditor" were to come to be and would give an "unqualified opinion" if everything was in order in your favorite distro.

    Companies who didn't release their source, however, would not be allowed to void their implied warranties because there is no way to check if the code will do damage or not.

    This would be a drastic change but would probably increase the quality of software, in general. MS would probably be the only company left that could afford not to open their source, but that is fine by me. At least they would be responsible when their software deficiencies indirectly impair my bandwidth.
    • I think that the idea that introducing liability for all code in all software is not so good an idea at all.

      What I do propose is that there be some sort of 'tiered liability model.' This means that if software developers choose, they can do the necessary expensive licensing and develop software for which they are liable.

      They would want to do this because this liability model would include laws where systems where malfunction would result in physical harm to humans must run only software for which the developers are licensed and liable.

      If someone is running a regular web server, they can still get BSD + apache and whatever other Free items they want and pay $0 for software (or even an unlicensed commercial OS/server) but not be able to sue the developer. On the other hand, they could choose to pay big money to get liability-licensed software so that if their server goes down and they lose 50 million dollars in business, they could sue.

      The good thing about this model is that it introduces liability and responsibility where such things are absolutely needed, while it gives more options but not more restrictions to everyone else.

  • This is more a perception problem on the part of end-users of software, which has come about due to the poor marketing practices of companies selling computers and computer software. People have been convinced that computers are easy to use, when they are not. Whether or not they should be is debatable and I won't go into it, but it is unreasonable to assume that a general purpose computing device should be as easy to use as a special purpose appliance like a microwave, or a car, or a VCR, and we all know how much trouble people have with these devices.

    Now, ratifying this unreasonable expectation of software in law is misguided. There are already sufficient principles in law to handle the situation. People should be educated to understand what 'use at own risk' means. If you wish to have a piece of software that absolutely must work (and has been proven to do so) then you will need to pay the price to have such software developed. The fact that you desire mission critical software should not prevent me from obtaining and using 'at risk' software for my own use.

    People sue too much as it is. Grow a spine and take responsibility for your own actions for once. You bought and installed the software. You have taken the risk and the responsibility. If that's unacceptable, cough up the dough to get someone to write a bulletproof webbrowser. Or use a typewriter.

  • It just won't fly. Engineering has been around for thousands of years, so the "natural laws" behind it have been sufficiently understood.

    On the other hand, program writing is too young a discipline to have yet evolved a set of absolutely-proven "natural laws" yet, especially when programming paradigms (high-level/structured/oop) change every generation or so.

    Those "natural laws" just won't happen for a while, especially if the architecture eventually changes from Von-Neumann to something else (parallel/neural/photonic).

    The main problem behind attribution of liability stems from the lack of "natural laws" governing programming itself, thus making the analysis of software failure a shaky endeavour.

    Finally, the programming establishment will simply not accept liability, and, most importantly (to the point of dooming the whole liability scene), no underwriter will accept to back software liability insurers either.

    • The main problem behind attribution of liability stems from the lack of "natural laws" governing programming itself, thus making the analysis of software failure a shaky endeavour.

      Natural laws of programming not understod? Maybe not by your Chubb institute hackers, or their pointy-haired bosses. But clearly the mathematical foundations of software are understood.

      The fact is that SOME software is unreliable because people are not willing to pay for making it reliable, or companies like Microsoft don't view software quality as something that will make a difference to them in the market place.

      There are software systems that ARE reliable. Telephone switch software has an excellent reliability record. Software for embedded devices is generally written to much higher standards than PC software. Midrange and mainframe systems generally are far more reliable that what we run on PC's.

  • I am having too many thoughts tonight (time to meet some beer). this would also be fairly bad for code resuse.

    Lets say I own WangCorp and market a commerical linux application which say uses zlib. Now lets say that a bug in zlib causes my application to crash. One of the clients, SingerCorp lost some data cause of this.

    1) does SingerCorp sue WangCorp or the writers of zlib? does it matter if zlib is GPL code?

    2) assume that WangCorp does not link to zlib but instead another similar library but commerical. does that change the issue?

    3) will the writers of a library be liable for damanges that the library causes if it used in another application?

    4) for example: VMWare includes a copy of Samba for file sharing. lets say that Samba get rooted. do you sue VMWare Incorperated or the Samba people?
  • "The first ant to come along would destroy civilization in a day"

    I don't know who wrote this but it's a standard article of faith(sic) in the IT industry.

    The only case I can think of in which a vendor provides a meaningful statement that a system operates with a particular fitness for purpose would be systems evaluated under Common Criteria [commoncriteria.org] orTSEC [ncsc.mil]

    And these systems differ from the vast majority of operating software systems in that:

    • Certification is made only wrt a specific hardware configuration
    • In the case of A - level MLS systems there has been a formal proof of security
    • B - level MLS systems require extensive design and audit validation
    • None of the above necessarily guarantee the absence of coding errors / holes

    So the current state of the art is "software is too complex to guarantee performance", this is codified in commercial code and practice. What this means for now is that entitities which use software cover themselves with insurance. (I have no idea what it costs to insure a commercial web-presence.)

    I think changing things to hold producers of commercial software and systems would be a good step. I can't see however how this would happen without forcing considerable change in the practice of software design and development.

    Either tehcnology and QA need to change, or software systems would need to become simple. Given the current set of assumptions it is effectively impossible to perform an analysis of any non-trivial code and determine that it is safe in the expected execution environment(s).

    Simplicity sounds great on paper. At present there isn't a market for simple software that works with high assurance. (Look at the tiny marketshare for the BSD's). Even the systems that run over unix-like / oss show a degree of bloat that continues to push reliability out the window.

    Prudence and solid engineering practice in operations dictate that we use the simpler / more robust tools in key locations. So BSD or secured versions of linux get deployed as firewalls etc, and critical application and database servers are run with various redundancies (clustering / failover etc), which effectively throws hardware at solving the software 'problem'

    Which is just another name for insurance.

  • will this lead to code bloat? I mean think about this...

    most software use a lot of libraries... you get into a lot of problems if the libraries are slighty different...

    Lets say that my products works with a shared library version 2.4.292. Lets say that the implementors of the shared library makes a slight change in version 2.4.293. Lets say someone who uses it with version 2.4.293 crashes...

    am I responsible? If I am... I am sure hell going to compile my executable statically linking every single shared library... (eek. on the code size)
    • "am I responsible? If I am... I am sure hell going to compile my executable statically linking every single shared library... (eek. on the code size)"

      That's why Commercial Linux programs are soo big. They have to include every library for them not to have "error in loading library". It's big, but it works.

      Perhaps on some programs, having static libs ARE a good idea.

  • Comparing Software "Engineering" to others... (Score:5, Insightful)

    by darkwiz ( 114416 ) on Sunday June 16, 2002 @08:03PM (#3712726)
    ... is really pointless. The argument is: an architect designs a house that doesn't blow over, or a bridge that handles the traffic load without collapsing. However, in these cases, anyone who does something out of the ordinary with the house (fills it with water, tries to open the inside door without opening the screen door), would be laughed at if they called it a design flaw.

    Take the usual punching bag for example: IIS. IIS, when used properly, works quite well. You might argue about the functionality/performance/cost compared to [insert favorite httpd], but pass over those arguments for now.

    Security is a common complaint for IIS. However, if a person broke into your house by going in through a weak point (a window, the chimney, etc), you wouldn't blame the architect.

    Zealots might say that backdoors in software are like using doors without locks. But this is ignoring the fact that software is often not an integration of existing, proven solutions, but an exploration of ways to attack a problem. Also, these failings are plain to the layman, whereas software bugs are often obscure to the guru. You simply cannot have the expectation that software will *NEVER* crash.

    An architect has a given set of solutions for common problems (building codes, pre-existing designs, etc). If they can't solve a problem with an existing, proven solution (or a mild derivation of such), they probably wouldn't take on the job. Programmers do not have this luxury. We are inventing these solutions on the fly -- and we will make mistakes.
    • Yeah, but what if he marketed it as a veritable vault?
    • If I owned a house that I'd determined (through some of my own testing) had a chimney which was more like ly to allow breakins because the architect has designed too large a hole at the top, and I then tried to publish information about the security concerns about that chimney, could the architect bring suit to stop me? I'd like to notify other homeowners to secure their chimneys, but the architect is trying to get laws passed saying that *I* am the danger to society - I'm causing more breakins - because I'm talking about the chimney. Is that right? That seems to be the direction the big boys want to move in (not just MS, but many large software companies, from what I gather).
    • Security is a common complaint for IIS. However, if a person broke into your house by going in through a weak point (a window, the chimney, etc), you wouldn't blame the architect.

      However, if the architect represented the window as unbreakable, and afterward told you that they couldn't forsee someone using a hammer, I think you would have plenty of reason to blame the architect.
    • Security is a common complaint for IIS. However, if a person broke into your house by going in through a weak point (a window, the chimney, etc), you wouldn't blame the architect.

      Maybe not. But if I were building a bank and the architect forgot something like a lock on the vault, I would feel justifiably aggrieved.

      What's needed here is some concept of due diligence or reasonable expectations. As you say, it is impractical to expect software to be perfectly secure or robust. It is simply not viable with the nature of the beast, and with the methods known today, to provide such a product.

      However, there are some tests that should be routine in any shop. If a software company allows its coders to write in a style that lets in buffer overflows, a common and well-known class of bug that is easily preventable with just about any development tools available today, then that should be treated as negligence. This is very different from expecting someone to write encryption algorithms today that can't be broken in 50 years with all the unpredictable advances in computing power and mathematics that may bring.

      This is really no different to any other engineering discipline. I wouldn't expect someone architecting a bank to make the safe unbreakable in the face of the military weapons of 2050. I would expect them to put a lock on the front door and install an alarm system that did something useful in the event of a break-in.

      • Re: Hey I'm an Architect that just finished a bank (Score:5, Interesting)

        by Anonymous Coward on Sunday June 16, 2002 @11:23PM (#3713470)
        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.

    • Re:Comparing Software "Engineering" to others... (Score:5, Insightful)

      by Lumpy ( 12016 ) on Monday June 17, 2002 @05:48AM (#3714320) Homepage
      You simply cannot have the expectation that software will *NEVER* crash.
      Umm, the aircraft and space industries certainly do.

      if your flight computers software weren't sure to never *crash* then it would never be used. there are many hyper-critical systems out there running software that doesn't crash. (because if they do lots of people die!)

      I cant stand the cop-out I hear from programmers.. Yes, you can make bug-free and software that cannot and will not crash. Industry and the companies that make it choose to release buggy/crappy products. New features are more important than security/stability.... this is not always the case though, the OS running the allen-bradley RC5 and newer PLC's is rock solid and doesn't crash.... it can't, because it would kill people. these plc's are running 500 ton presses, high speed laser cutting systems and water filtration facilities. it is purely unacceptable to have a PLC crash and fail to an all outputs or arbitrary outputs on state as it will kill the operator, destroy the equipment, and in a water filtration facility, poison from 100,000 to millions of people.

      any programmer that says you cant write a program that doesn't crash or doesnt have bugs, is not a programmer. Yes that is a huge slap in the face of most of the "programmers" out there. but it is a slap they all need to have and require. It can be done and it is done every day.
      • You simply cannot have the expectation that software will *NEVER* crash.


      • Wrong, formals method can ensure that it is possible to claim that software will always fail in a predictable provable way.

        If they can't solve a problem with an existing, proven solution (or a mild derivation of such), they probably wouldn't take on the job. Programmers do not have this luxury.

        Wrong, Design Patterns are designed to make Software Engineering predictable in the same way that other Engineering is.

        We are inventing these solutions on the fly and we will make mistakes.

        Wrong, the Capability Maturity Model is designed to avoid, or catch mistakes and prevent the need to 'invent on the fly'.
  • Here is the problem as I see it. It's one of scale.

    It is easy to certify most engineering professions. If you build a building, it must meet certain tolerances. A weld between two I beams would support so much weight. This is easy and empiracle (sp?).

    You learn this, and are tested on it to get your license. How ever, in the current state of software engineering, you deal on a much more fine grained scale. How does an extra iteration of a loop affect the stability and security of the program. There is no algorithimic way of determining this, like building a building at the molecular level.
  • Negligence in software development costs other people/entities money. Cleary, liability is an issue.

    I'm not sure, however, if all you programmers really want this cat out of the bag. Could you imagine someone suing you because something you developed didn't work and caused someone to lose money?

    -Sean

  • Murder (Score:2, Interesting)

    by Lucas Membrane ( 524640 )
    As an independent doing a few thousand dollars in sales in a good month, I can't afford that. My customers know that I sell by reputation and word-of-mouth mostly. I do everything a 1-person shop can do to make the product high-quality, but it's not perfect. I offset the advantages of the bigger firms I compete with by giving strong service and by being the lowest on price by about 50%. That's a fair deal, and my customers like it. But if the law makes me guarantee quality, how in the world could I do that?

    This would vastly reduce the number of software firms and the availability of low-priced specialty software.

  • WHO is Liable for damages? (Score:5, Interesting)

    by __aadhrk6380 ( 585073 ) on Sunday June 16, 2002 @08:12PM (#3712762) Journal
    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.

  • Slight mistake ... (Score:3, Interesting)

    by crovira ( 10242 ) on Sunday June 16, 2002 @08:21PM (#3712806) Homepage
    "the only environment with legal resources adequate to deal with such liability has been the megalithic corporate one."

    For "deal with" substitute "avoid"

  • Merchantibility (Score:5, Interesting)

    by Arandir ( 19206 ) on Sunday June 16, 2002 @08:21PM (#3712807) Homepage Journal
    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.
    • 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.

      This is where I think you're wrong. If I advertise that I am giving away widgets which can make foo, I am responsible for those widgets. Just because I don't charge money for them doesn't mean I can falsely advertise them. So if you advertise a program that does X (and you must advertise somehow (even if it is only a web page), otherwise no one would ever know about it to d/l it, and it doesn't do X, you could be held accountable. Think of it this way, if I stand on a street corner and give out nails and tell people they are the best thing you can use to nail a house together, I will be held responsible if they can't hold a house together. If something is free, that doesn't mean the people giving it away can't be held accountable for it.
    • I develop some software that I've released free (as in beer and speech) under the GPL. I have a simpler way to deal with this problem.

      Anyone who downloads my software and isn't happy with it is entitled to a full refund for purchase price.

      Since the price happens to be $0, I'm not concerned. Then again, I wasn't concerned in the first place because I doubt that any such laws that would be passed in the U.S. would pass in Canada too.
    • Right on. The one thing a high price tag always buys is a high price tag, and the right to complain if something doesn't work as expected.

      No one expects merchantibility for freely downloaded software.
      If I spend $199 on a word processor and it fails to process words I want recourse.
      The exact same word processor could sell for $199, $19.99, $1.99, or downloaded for free. The recourse available for each of those prices would be substantially different.
    • Good ideas. And, I believe that is the way it works already. That is why fitness for purpose, merchantibility, etc. is disclaimed in most software licenses. I used to keep a copy around the desk, but I shuffled it over the weekend, so can't quote chapter and verse from a current MS EULA. The trick is, you should have access to the EULA on the outside of the 'retail' package and should have to sign a EULA before ordering your shiny new Dell. (Unless you are one of the unfortunates, like myself, who live in VA or MD, where it is binding anyway).

      Ahh, just found it.

      ...disclaim all other warranties, either express or implied, including, but not limited to implied warranties of merchantibility and fitness for a particular purpose with regard to the SOFTWARE, the accompanying written materials, and any accompanying hardware...NO LIABILITY FOR CONSEQUENTIAL DAMAGES...not be liable for any damages whatsoever...


      Yup. Binding on me, a resident of the People's Republic of Maryland.


  • The level of liability in other industries is dependant upon the job/product contract
    where included in the contract may be a required level of liability coverage and like
    insurance, the more coverage you pay for the greater amount of liability you are
    covered for.

    And I'd imagine that like health insurance where you get a discount on the cost
    of the coverage for being a non-smoker or practicing preventitive medicine, the
    same sorts of liability coverage would apply and take into account software
    licenses approved by the OSI, such as GPL.

  • i've said it 100 times (Score:5, Insightful)

    by bilbobuggins ( 535860 ) <bilbobuggins@@@juntjunt...com> on Sunday June 16, 2002 @08:32PM (#3712841)
    "Today, Firestone can produce a tire with a systemic flaw and they're liable,"

    This will probably be viewed as a troll but I feel I have to say it:

    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.
    Nobody is out there expressly trying to break and/or compromise Firestone tires. They were sued because the tires malfunctioned of their own accord.
    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 someone broke into your house would you sue the lock maker? Likewise, if someone deflates your tires you have no case against Firestone.
    If you can show me one case where code in IIS itself was responsible for damage (i.e. damage occurred while the code was running normally without any provocation) then I'm all for this, otherwise (as much as I hate to stick up for MS) you can't possibly blame them for Code Red etc.
    The real solution is just to get a better product; if you are having a problem with break-ins buy a better lock, don't just try to shift blame for your bad purchase decisions on someone else.

    • Re:i've said it 100 times (Score:4, Funny)

      by alexburke ( 119254 ) <alex+slashdot@NoSPam.alexburke.ca> on Sunday June 16, 2002 @10:35PM (#3713319)
      They were sued because the tires malfunctioned of their own accord.

      In actual fact, I think most of the vehicles affected were Explorers.

      (Sorry.)

    • Re:i've said it 100 times (Score:5, Interesting)

      by Tony-A ( 29931 ) on Monday June 17, 2002 @12:00AM (#3713608)
      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?
  • ...and I wish they'd pass a liability law, 'cause then I'd sue Larry Wall for a refund of the entire amount I paid him for it.

  • software liability is not a good idea (imho) (Score:5, Insightful)

    by Dr. Awktagon ( 233360 ) on Sunday June 16, 2002 @08:44PM (#3712884) Homepage

    I'm a firm believer that, in general, ALL SOFTWARE (including Linux, BSD, and Windows) is full of show-stopper bugs, with a probability in proportion to the number of lines of code raised to some power. If one piece of software seems more secure, it's just because the bugs haven't been found yet. And this will get worse as time goes by.

    (How the bugs are handled after they are found is another story, perhaps we should be focusing on that instead.)

    Microsoft has lots of smart people working for them. Free Software has many smart people looking at the code. Yet, most of this code has bugs. When I write a 10-line Perl script, it has bugs (for instance, what does it do in a full disk situation? What does it do when run by root? What does it do if a Perl library is missing or upgraded?).

    Making software writers/distributers liable for bugs is simply impractical. Software is simply not like a bridge or a toaster. Software is incredibly complex, and it runs on machines that are also highly complex, connected to other machines with equal complexity. All the interactions can't possibly be comprehended.

    And just what is a bug? If the program malfunctions under certain unforseen circumstances, but when it was written it met all the specs, is that a bug? If you use a formal system to "prove" correctness, are the rules correct? Did anybody make a typo setting it up? Is the program that does the check itself bug-free?

    I can understand that if Microsoft promises you a secure webserver, and it's found not secure, you feel Microsoft is to blame. But perhaps a "secure webserver" cannot exist. Even if it did, once installed, it would interact with other software to create a security hole (example: Apache + PHP + anonymous uploads into the web-accessible area + MySQL running as root).

    If a law for software liability were passed, it would instantly kill all but a few software companies. Free Software would wither or go underground because no programmer would want to touch it. You would get zero support for your software, unless your setup was 100% EXACTLY the same as the one the corps will support. This would probably be enforced with some draconian DRM. Our lives would get worse.

    Of course you say, they could make an exception for Free Software. But what would the criteria be? Exception for no-cost? No, that would mean you can't charge for Free Software beyond the cost of media. No more PayPal buttons on your web site, no corporate sponsorship. And Microsoft would just turn IIS into a free download. Exception for source-code-included? That would be better for little guy (no more binary-only distro though), but Microsoft could just invent a very-high-level language where MS Word is 5 lines, and distribute that along with it. They would find some other way to get around it. Any liability exception would be unfair to someone.

    If anybody should be liable, it's the person or company who chose and installed a particular system. This entity put together the components, so this entity is responsible for knowing they all work together without bugs. But like I mentioned before, I don't think this is possible. And even just one small change or upgrade and you don't know any more if your system is still secure.

    In 40-50 or more years, the software industry might stabilize to the point where all basic computer tasks are performed using well-known, publically available, stable components and formal systems, and then you could use the term "engineering" and you could conceivably have more predictable software. But I don't really think we're anywhere near that point now. Computer science is still in its infancy.

    I'm not optimistic!

  • Engineer analogy (Score:4, Insightful)

    by peterdaly ( 123554 ) <petedaly@ix.ne[ ]m.com ['tco' in gap]> on Sunday June 16, 2002 @08:45PM (#3712889)
    Say instead of being a software engineer, I was an enginner who built bridges. Can you image a boss coming up to me and saying:

    "I need a bridge built in this location to move some things across the river. We will lose out to our cometitors if this takes any longer than three months, you have two and a half. Tell me tomorrow how much steel you need ordered and I will have the iron workers (actually guys off the street who could spell iron) to start putting it together."

    Would you go across a bridge built like that? I wouldn't if I had a choice in the matter. How different is this from many software projects? Not very. Management doesn't care about the software quality since they don't understand it anyway, the coders are passivly taught not to care either because it costs more to write well architected, well tested code. Code can be solid if effort is placed on writing solid code. There will still be bugs, but nothing like is prevelent today in commercial software. Think of all the VB monkeys that managers consider real programmers. (Not that there are good VB programmers, but by and large...)

    Welcome to the world of software. As long as the current market drivers are in place, nothing will change.

    -Pete

    • Re:Engineer analogy (Score:2, Interesting)

      by Anonymous Coward
      Unbelievable.

      Do you have any idea how close you are to reality?

      I'm a structural engineer, and. yes, that is an apt description of the conditions under which it means to be a true engineer.

  • Simple Solution... (Score:2, Insightful)

    by lordvolt2k ( 301516 )
    Make those who sell their software liable for the software sold. For example:

    Sell a $100 software 'release' product, you are liable for damages.

    Give away a demo of software, or free beta, or otherwise free test/development software, you are not liable.

    I really think this would help shore up the QC at places like microsoft. Sure, microsoft may not like it, but look at it this way, if a contractor builds a building, and even overlooks a problem with the supports (never made aware of it, never caught it during building...), but then the building collapses killing people, would the contractor not be held responsible to a certain extent? yes, they would, and as a result, they do everything they can to do a good job when building the building. Who really thinks software corporations weigh security and stability over deadlines and profits?
  • There are no bad corporate politics, only issues for engineers to master. Speak no flames, invite no trolls - everything is everything, happy happy joy joy.
  • Underwriter Labratories certifies all sorts of consumer goods by actually trying to break them. Most software compamy QA departments only try to get their software to work in a few conditions (I blame marketing pushing release schedules). Maybe what we really want is for software to be subjected to something like this; where in order to get a stamp of approval or rating their product has to perform under adverse conditions, not just run through a test script once on a freshly ghosted machine.

  • The Key Is in the Code (Score:5, Interesting)

    by gallen1234 ( 565989 ) <.gallen. .at. .whitecraneeducation.com.> on Monday June 17, 2002 @06:20AM (#3714384)
    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.

Slashdot Top Deals

Computer programmers do it byte by byte.

Close