There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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:
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
|
|