Isn't the onus on the customer to define what sort of contract they enter into with a manufacturer (software included)? Lumping every bit of code under "software" serves to obscure the different circumstances under which expectations are met, much as would referring to "machine parts" without considering the application of such parts.

Examples:

  1. An person's OS crashes and causes me to lose last week's bank transaction records.
  2. The accounting software for a corporation fails, backups have been destroyed in a fire, months of bookkeeping are lost and millions are spent correcting the mess.
  3. An air traffic control subsystem suffers from a buffer-overrun and redundant backup systems fail, indirectly causing a mid-air collision where hundreds die.
  4. The firmware of a dialysis machine goes haywire, causing the hospitalization of a patient who incorrectly believed his blood was being scrubbed.
  5. The guidance subsystem of an experimental army missile goes haywire, the self-destruct failsafe does not work, the missile rips through the middle of a suburban apartment building 500 miles away, killing 10 people.

Let's just say that all of those examples involved a software licensing agreement along the lines of "authors of this software are in no way liable for any harm resulting from the use thereof" etc.

Example 1 is the throwaway example, because this is one of the most common cases that the market will bear. The individual in question probably has no recourse, assuming he could even reliably prove that the software vendor was at fault. This is a broad-based software market, and in this case the market seems to be willing to bear lax responsibilities on the part of the manufacturer.

Example 2 is more grey. Should the corporation in question have demanded a more stringent contract with the vendor of the accounting software? Probably. If they are publicly traded then they might very well be punished via their stock evaluation due to gross mismanagement. If it's a smaller company the fiasco would probably just be swept under the rug of hard knocks. Smaller companies, in particular, are subject to bullying by the likes of monopolistic software providers who simply refuse to do business with any entity that does not accept the boilerplate contract.

All of the remaining examples are cases where the purchaser of the software would under normal circumstances be fully expected to hammer out a contract that clearly defined levels of responsibility and liability. These are areas of application where you should be run out on a rail for accepting any agreement where the vendor throws up his hands and says anything along the lines of "we think we know what it does but you can't sue us if it doesn't".

None of this changes for "open source" solutions. As much as I hate to say it, I'm not sure I'd really want any military contractors using open-source guidance systems, for example, because normally there are more stringent requirements in the development cycle for such systems.

So it does a disservice to the whole issue by lumping all software into the same wad of potential litigation without paying attention to the associated risks for the areas of application. No blanket solution will work without taking into account risk analysis.

The markets can decide what sort of contract they are willing to accept. What we need to be on the lookout for is silly laws that legitimize broad-based EULA's in consumer software.

If you'll excuse me, I must now return to my open-source ocean liner thrust-vectoring and collision avoidance control software. It's generating a lot of interest in the ocean liner hobbyist circles.

Matt

In reply to Re: OT: Software & Liability by mojotoad
in thread OT: Software & Liability by cjf

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.