So, the liability should perhaps be placed on those that actually make money on promising something will work. If I give you my car for free, you don't have much to come with if you complain that it breaks down on you on the way to an important meeting - probably not even if I promise it will hold forever. If you pay me for it however...

That way, of course, it would also be allowed to put someone to the wall for not doing a good job installing or maintaining even free products. Lots of open source business is done by doing the work for the customer, while the product is free. I guess it is fair to hold the work done accountable to some degree, if, and only if certain promises were made.

Then, we can always dicsuss if liability for software is really something we want at all - those that got hit hard my Microsoft viruses, and know people that didn't due to running apache or any non-Outlook mail program probably thinks so. I think those people are very upset that they paid lots of money for something that cost them even more money.

In conclusion, I guess I can support that if something costs money, it should have some kind of enforcable warranty - blatant, and/or expensive errors should be possible to get retribution for. However, free "no-warranty" products should not be covered by this. Maybe. It's too tough an issue for this little brain. :)

Still, good luck to anyone trying to convince the legislators there is a difference... *sigh*

So, the liability should perhaps be placed on those that actually make money on promising something will work.

I think this is the crux of the matter. If I develop a piece of software and release it under an open source license then, when you go to use it you do so at your own risk. You have no contract with me for supply of software because there has been no exchange of consideration. Hell, there's been no offer, no acceptance, there's not even been an invitation to treat.

Quite how anyone could try to hold me liable when there's no contract is something of a mystery to me.

In the US, at least, there's some minimum amount of liability that you're not allowed to get out of in many cases.

The act of creation and distribution of something, regardless of its cost, imparts some measure of liability on the creator. You made it and you gave it to someone, or put it somewhere where someone could reasonably take it with your approval, which leaves you responsible in some measure for the performance of the thing. The law sets a minimum amount of liability you can have and, while you can go over that (by claiming that your creation does particular things), you can't go under it.

This isn't, on the whole, a bad thing. It ensures that the manufacturers of things take at least a minimum amount of care in the production of whatever they make. I'm pretty sure that doing due dilligence and making what would be considered the best reasonable effort will limit your liability, but that's something to check with a lawyer about.

There are actually "shared source" cars. New Jaguars have standard Ford parts (source), Lexus and Toyota share many of the same parts. Going even further, look at Disk-Brakes as a module, nearly every car built uses that module, they may have tweaked the module for thier own uses, but essentially most of the "source" is the same. Many vehicles also use the same licenced patents, more shared "source" :)

"Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

Although this may be entirely irrelevant;
Lexus and Toyota are the same company, so I don't know if that example counts.
Lexus/Toyota/Daihatsu would be the Japanese equivalent of Lincoln/Ford/Mercury.

JP,
-- Alexander Widdlemouse undid his bellybutton and his bum dropped off --

Maybe the way to start with liability is to start by holding the users of software liable for bad things that happens as a result of software they bought fucking up. This will hike up the insurance costs of the users in the case where they have software that disclaims all liability because the insurer can't recoup its costs by suing the software supplier.

This increased cost to the user results in them being more likely to pay the increased costs for warranted software. The software house uses this extra money to take out liability insurance (the total cost of which will be somewhat less than the total cost of the increased premiums of all the customers who used the unwarranted versions), bites the bullet of warranting their software and works to reduce the risk by improving the quality of their software.

This could be seen to be an inhibitor on the takeup of open source software, but in fact it creates a market opportunity for the likes of Cygnus/Redhat/Whoever who is prepared to fill the market requirement for warranted software by selling warranted support contracts for open source software.

one point you don't touch on is the effect on cost of software.

As I pointed out, improving the quality/security of software will cost the manufacturers more. This cost will most likely be passed on to the consumer. Is this a bad thing though? Think of the auto industry for a moment. Was putting in seatbelts a bad move because it made cars more expensive to produce?

How many software companies will close up shop because they cannot deal with this increased costs?

Probably a fair number, but if they can't ensure the quality of their software, should they be producing it in the first place?

If Quake 7 crashes your system because your video drivers are to old, do you get to sue because they said they supported your card?

If you drive at 200k/h with 10 year old tires down an icy road, is the car manufacturer liable for your accident?

Was putting in seatbelts a bad move because it made cars more expensive to produce?

Bad analogy. Seat belts are a marginal expense on a car (I have a hard time believing that they would even add $500 (3%) to the cost of a $15,000 car). The reason that so much current software is so shoddy is because doing it Right would increase the cost of development substantially. Add insurance, bonding, auditing, and other methods of protecting against the possibility (certainty) that a bug slipped past QA on top of that, and you're looking at software production costs increasing by an order of magnitude or so. And that's probably optimistic.

Old Video drivers versus 200 miles per hour is not right. My point was more like, do you know the torque of your motor mounts in your car? and if you do is every operator supposed to know that about thier car? and if they don't it's thier own fault if the tranny separates from the engine at high speed?

For the folks (at least most of us) who hang out here in the monastary, we can maintain our systems without a "mechanic", what about those who can't? With the version and patch hell we have already created (and would only get worse) no software company can or will ensure that kind of stability.

I guess my point is: "Where are the lines drawn? and who draws them?"

"Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

Life in the software industry is truly changing. tilly's trevails became quite real in a hurry. Plus, issues like the ones raised in this thread are quite real too, and becoming more mainstream. As we need to address these issues more and more, it looks like we'll need become much more sensitive to best practices and pushing to have a wider variety of talent involved in many projects. cjf, what were your conclusions about all this?

The question is - would holding companies liable for faulty software increase the quality of software, and if so, would this gain outweigh the possibilities of reduced innovation in the industry?

A good deal of this has gone on all along anyway. For instance, software running machine tools has been known to crash the tool into expensive stock, and the developer had to cover the cost (often a great deal of money) for the stock. This liability may often get handled out of court for customer-service and pubilicity reasons, but it's accountability nonetheless. I'm guessing that software improved thereafter, so it's reasonable to assume that this could work. But, given the legal system's inability to understand technology, it could also fail miserably.

Software development company lawyers must have worried about this from the start considering standard licensing phrases such as (paraphrased) "you're buying this license as-is". Additionally, many (most?) licenses claim liability only extends to the sales price of the software itself.

And then comes the argument "define fault". Could a CRM development company be sued for omitting a feature the industry accepted as a Best Practice? Is that faulty software? Can laws extend to software development companies in niche fields that assume those companies are 'professionals in the vertical field' each of their software's cover and they're therefore expected to know all the appropriate best practices?

Or is it more likely they will only be held liable if their product doesn't do something they said it would do, or something a reasonable buyer could reasonably expect it would do?

Or, should we expect and trust that any legislation would be sensible and apply reasonable standards only to instances of damages? (Man, would I hate to have to find those 12 jurors at this time, anywhere in the world, who could reasonably understand the problem.)

Also, there's quite a distinction between liability for security and liability for general quality eh? And considering that precisely defining those two concepts (for all time) is almost impossible since the problems those terms address are moving targets - well, given that the DMCA happened, I guess we could assume anything's possible in law-making.

In this article the author points out that under the so-called lemon laws, Open Source projects would face the risk of liability suits.

If software or security liability becomes more of an insurance issue rather than statutory, it seems that open source products could benefit. If actuaries actually produce statistics that, say, Apache is more secure than, oh, some nondescript product like IIS, then insurance premiums would rule preemtively in many cases. The article indicates this may already be true.

If you add thousands of multi-million dollar lawsuits into the mix, the situation would change rapidly. Would this make the software business far less profitable and slow the rate of progress? Would small software companies be quickly bankrupted by a few lawsuits? Are these necessarily bad things?

Yup, things would change rapidly indeed. Less profitable? Absolutely, especially if the court was unclear about the findings. If they are instead knowledgable and specific about the faults and findings and companies knew what to do as a result, it wouldn't be quite so chaotic.

In most cases, just one unreasonably sized lawsuit could kill most software houses I'd guess. That would ruin the world in my view.

He continues with the auto industry comparison saying the current state "is like Ford designing a car that a twelve-year-old can cause to crash...

I hate muck-raking analogies like this; designed to inflame readers, with an over-simplified, wrongly generalized simili justified with something like "I'm just making it more real to my readers - making it so they can understand it." It's simply obfuscation. (Note, the article's author made no such justifying statement in the article.)

I looked up Mr. Banisar and found something about him here. While I sympathize with his interests in privacy issues, it seems clear that he's into social responsibility issues and legislative cures, at least on this issue. I wonder what pissed him off? In that same article he writes, "It is time to start considering imposing some legal liability when companies release products that have gaping security holes in them." One can easily sympathize with the problem. However, I'd be much happier letting courts continue their routine handling of brought complaints, evolving with and learning the issues, than having some un-named entity "start considering imposing" anything.

This clearly would not provide developers with the greatest incentive to contribute to Open Source projects.

I wonder if open source projects would find some kind of solace in the already commercialized arguments like 'there's nobody to call for support', 'they aren't professionals', 'you get what you pay for'; these could all work to the advantage of open source. Commercial entities have already admitted these things, and maybe the 'nobody there to sue' concept would win out. Plus, 'you have the code, you got it free, you can fix it' may come up.

OTOH, if legislation occurred, that would instantly make or reinforce a market for commercial entitires offering pro support for open source products (along with their insurance policies in full force).

I'm a cynic in the face of legislative cures. My bias is showing...

what were your conclusions about all this?

Hey, I just ask the questions, I don't provide answers ;-).

Seriously though, it is a very difficult question with a lot of points to consider. Currently I would lean a bit more towards being opposed to legislation holding software manufacturers liable. This is due to:

• Lack of understanding of the issue, as you pointed out. Just look at the DMCA and the SSSCA (or CBDTPA or whatever it's called now) for examples.
• Legislation may not be needed. People are slowly becoming more security-conscious. Add in the insurance industry and this may start to sort itself out.
• Effect on free software. As Elian pointed out above, just because something is given away for free doesn't mean they can't be held liable.

Taking these into consideration, I'd definately want to see a fair bit of research done on the subject before any law passed, but I'm beginning to think legislation isn't necessary at all.

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

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.

It may interest you to learn that this nearly happened in Australia (Darwin, I think). It was widely reported in newspapers at the time that someone's ute was destroyed by a missile seconds after he parked it and got out. The story goes that an air force plane was starting to land when a 'software glitch' 'released' one (and only one) of the missiles it was carrying, which fell into a populated area. The Air Force offered no further explanation. However I'm guessing that they write their own software.

____________________
Jeremy
I didn't believe in evil until I dated it.

Isn't the onus on the customer to define what sort of contract they enter into with a manufacturer (software included)?

Have you tried arranging a meeting with Microsoft to change the contract a copy of Windows is licensed under? Did you have to check with your car manufacturer to make sure the car doesn't blow up when it hits 20km/h?

Lumping every bit of code under "software" serves to obscure the different circumstances under which expectations are met

How else would it be done if they're all licensed under 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".' It seems the difference here (if software manufacturers were no longer protected) would be how much the manufacturer is liable for.

Have you tried arranging a meeting with Microsoft to change the contract a copy of Windows is licensed under? Did you have to check with your car manufacturer to make sure the car doesn't blow up when it hits 20km/h?

This was partly my point, though perhaps not clearly stated. All else equal, suppose that everyone actually had artificial hearts and that what we were buying from Microsoft was control software for these devicies. The dynamic for ridiculous EULA's would instantly change, because on average the stakes have just shot through the roof. The market would no longer be as willing to forgive the risks.

Granted, this can be abused in monopolistic environments, but I think people would also pay a hell of a lot more attention to what they were actually buying if it literally made their hearts tick.

The point of the other examples was illustrating that when you're in high-risk business you are less likely to accept foolish terms from a vendor. Regardless of your clout -- if there is a market there, competition will arise. Since you are (hopefully) aware of the nature of your risky endeavor, you go the extra mile to actually read a contract.

With operating systems for individuals today, there is not enough risk associated with purchasing an inferior product, therefore better options remain in a niche market. The market bears the ridiculous EULA's.

Matt

I read with much interest through the many very good replies in this thread and found one aspect of liability and accountability that was only briefly touched upon - appropriate use. While I agree there remains many issues of quality and liability which need to be addressed with delivered software, there is also the issue of appropriate use of this software by the end user and the voiding of liability which inappropriate use may impart.

If an end-user were to accidently run fdisk on their system with the intent of increasing the size of their primary boot partition, in turn loosing all data stored on the drive, should liability be retained by the supplier as a result of lack of appropriate disclosure or product information? While all appropriate-qualified computer technicians would be aware of the ramifications of deleting and reinstalling partitions with fdisk, the program is supplier as part of the end-product to the use and as such, does it carry any further liability for this fact? Even if a supplier, where to appropriate document the product, supplies said documentation, therein lies a minefield in itself with regards to the quality and delivery of documentation and appropriateness for the widely-ranging end-user and intended product audience. Is liability then voided where an end-user from outside the intended audience employs a product and finding the documentation lacking, causes harm to their system?

While an example of "drive at 200k/h with 10 year old tires down an icy road" has already been raised in this thread, examples less extreme and more "grey" in nature are far easier to highlight within the realm of computer support. Does the user installing a piece of software have legal recourse if installed libraries conflict with existing software? Can the automatic registration of file associations be construed as an anti-competitive measure?

The path that this measure of liability leads to can be demonstrated within the medical profession where a doctor can be considered "negligent" if they fail to inform a patient of a 1 in 400,000 potential complication following a procedure - The effect that this measure of liability in turn has caused on medical insurance has led to many doctors abandoning the profession as a result of spiralling insurance premiums and a perceived attitude of guilt. In many cases, the claimant will receive compensation, not because of medical negligence, but because of the cost of the litigation.

While increased ligitous pressure on software companies may produce better software, it does open the door to more wide-ranging claims and insurance pressures on companies which may be counter-productive to the end-goal of improved competition and better end-products.

However, if I am working for an organization that then sells that software, the company gets to disclaim all warranties and liabilities. Now, Caveat emptor is an old and valuable legal principle, but it does look like something of a double standard from where I'm sitting.

But then, I don't have a monopoly hold on my market.

May I suggest we start looking at this issue in terms of performance categories, starting with safety-critical software as an example?

Imagine, for a moment, a fly-by-wire jet (one where all controls transmit signals electronically, not mechanically) that uses Windows 95 as the basis of its flight-control software. If Windows BSODs in flight, everything stops working, and the plane becomes a very expensive hole in the ground.

No insurance underwriter would cover that plane. The odds of failure are too high, and the cost of failure is too great. You can build equivalent examples for heart-lung machines, radiotherapy machines (can you say Therac-25?), countless industrial control systems, and an ever-increasing amount of automotive electronics.

Nobody uses Windows (or any COTS operating system) for those devices, because all the commercial-off-the-shelf vendors state quite clearly that their software is not adequate for safety-critical use.

So there's our starting point.

Now let's talk about uptime: the traditional notation for uptime is the N-nines rating. A 3-nines system is one that guarantees 99.999% uptime (roughly 5 minutes unscheduled downtime per year). A 5-nines system is one that guarantees 99.99999% uptime (~5 minutes down per 100 years).

Insurance companies could set their rates based on an N-nines rating for various desirable qualities: uptime, data integrity after failure, resistance to external compromise, amount of data exposed in the event of compromise, likelihood that one compromised system will be used to compromise others, etc. Those numbers don't need any buy-in from vendors, insurance companies could base their initial figures on educated guesses, then refine their ratings based on what they have to pay out on the claims they receive.

In that environment, it wouldn't take vendors long to announce N-nines ratings for certain products in certain configurations. It would be a selling point: better software == lower insurance rates. Once they do, that promise will be built into the EULA, and customers will be able to sue vendors for failures above the announced rate.

Once that happens, customers will be able to compare the various insurance rates to the cost of maintaining a given rating. If a 5-nines system drops to 0-nines unless you buy new hardware every year and install an average of three patches per month, customers will probably find it cheaper to pay the 0-nines insurance rate. Then they'll quote the exact figures involved to the sales rep when it's time to renew that software license.

IMO, that would be a fairly balanced system. Insurance rates would be based on actual performance, as measured by the carriers who pay out on claims. Apache and ssh will be rated on their actual performance in the field, right next to the corresponding commercial products. Vendors will be liable for any promises they actually make, but won't be subject to state-imposed rules about what constitutes 'good' software. Customers will gravitate to whatever configuration gives them what they want for the lowest cost. Customers will also find themselves liable for any unpatched servers or ignored security warnings, and will start learning to figure the TCO of running acceptably secure and reliable systems.

The fallout for Perl hackers will be a need to adopt some 'no guarantees unless otherwise stated, and yes this may ruin your insurance rating' language, and a fee schedule that reflects the value of software that offers a higher rating.

If a vendor sells you a black box that they say will turn bananas into monkey dung, then all you have is their word on this.

If you can look inside the box and see that there's a monkey inside waiting to be fed a banana, well then you have a reasonable expectation that the box will do what you've been told, without ever having to risk a banana.

Open source palpably changes risk assesments.

Matt

I think the difference is important when judging risks associated with the use of the software in question.

I agree, but one thing you have to keep in mind is that many businesess/individuals will not have the time and/or expertise to ensure the quality of the software. An open source vendor who makes obviously false claims should be held just as liable as a closed-source software company.

Yes, this is true. This is what should drive the market for 3rd party auditing and certification. Open source software makes such audits easier, more reliable, and most importantly, verifiable.

Matt

At first glance, this just seems like another case of foolishly considered legislation holding back US progress in the computer field. We already saw it with encryption standards (the US has never caught up from the damage that treating encryption software as munitions did,) we are now seeing it with the DMCA and now this lemon-law (and the product liability issue that Elian speaks of) will most likely lead to a shift in certain types of software development out of the states to Europe and the East. (For instance it is arguable that developing a disassembler or debugger could be considered felony offences under DMCA.) Of course for me, living in Europe this probably would be a good thing...

A second thought is that product liability for security breaches would IMO probably be good for the open source community. Inividual developers and small software houses would find it impossible to check their security levels without peer review and as we all know peer review is all but impossible without open source.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Sadly, what will probably happen is that eventually some court will throw out one case of the "we aren't responsible" weasel words that appear in every sofware license. Then the lawyers will get a lot of money thrown at them in a very disruptive process that will cause a lot of damage but will eventually lead to more reliable software.

A better alternative would be to encourage the professional organization of "software engineers" like other types of engineers that have to be licensed/accredited and are recognized as being required to keep abreast of and adhere to the current best practices in order to ensure reliability, security, and safety. Then encourage government contracts to require a licensed/accredited software engineer be assigned to and responsible for the project. Then managers can try to tell the engineer to cut corners but the engineer knows (as does the manager) that bowing to such pressure risks the engineer losing his license and thus having to work as an "ordinary" programmer at a lower pay.

Then more and more industries that use software in important places will require licensed software engineers supervise and approve the software.

And then all manner of consumers of software (from individuals to huge companies) will have the option of paying extra for the software with the "Engineered for quality" emblem on the box, a registered trademark of some software engineering accreditation umbrella group.

And the market can determine what software warrants the extra reliability, safety, etc. and at what price.

Making this type of change primarilly through lawyers or government regulation is going to be much more painful and much less effective (as has been shown over and over again).