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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.