Slashdot Mirror
Outlining a World Where Software Makers Are Liable For Flaws
CowboyRobot writes with this piece at the ACM Queue, in which "Poul-Henning Kamp makes the argument for software liability laws. 'We have to do something that actually works, as opposed to accepting a security circus in the form of virus or malware scanners and other mathematically proven insufficient and inefficient efforts. We are approaching the point where people and organizations are falling back to pen and paper for keeping important secrets, because they no longer trust their computers to keep them safe.'"
It will just cost 100x more, just like healthcare with the torts. Time to take out software developer insurance, similar to the healthcare insurance of approximately 1 million dollars a year paid by doctors these days.
This space for rent.
"There should be a law!"
No. No, there shouldn't. There also shouldn't be disclaimers that "this coffee can burn your ass," "don't point this gun at your face" or "don't use this curling iron to stir your bathwater while it's plugged in."
If organizations see pen and paper as the only alternative, then they're probably getting the quality of IT support that they're paying for.
!#@%*)anks for hanging up the phone, dear.
The problem, of course, is that nobody wants to pay that much. So it's not going to happen.
Yeah, let's drive the cost of software through the roof. That will solve everything! Companies will employ a lot more people to do testing but will still have to invest in huge insurance policies just in case they miss something. Your next copy of Windows will cost more than a well equipped car.
Software is complex enough that even the most diligent programmers produce bugs. It's nigh impossible to create 100% bug free code. I think this would pretty much kill the industry as well as be detrimental to hobbyists.
In a world with software liability laws, the costs would be prohibitively expensive. You'll create a new industry for "programmer insurance" where the premiums will be astronomical. Open source would die because who would put themselves at risk of a lawsuit for contributing to an open source project.
The few software products that survive will turn out updates only once every few years because beta testing time would need to be increased.
Finally, software companies would raise their prices to cover the inevitable losses they would take from bug-related lawsuits.
BAD IDEA!!!
"You can't trust code that you did not totally create yourself."
I can't trust the code that I did totally create myself, either.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Just another effort in our modern crusade to make everything Not Our Fault. Push the blame to someone else, then sue them when things go awry. Lovely.
From TFA:
So if you're distributing the source code (and license it correctly) the most you'll be out (aside from malicious intent) is a refund.
I need you to design a bridge. We've already promised the customer that it'll be light and strong, but we only have budget for paper (so we're ok on 'light', just make sure that it's strong), and the deadline is next Monday.
If you think it can't be done, I have the "outsourcing provider" on the phone telling me that there are 500 engineers who would do it. I need an answer in two hours. I know that you've just bought a house and have a new baby on the way, so think again before you protest.
By the way, we've also accepted liability. If anything goes wrong, I'll say that you told me it wasn't a problem.
Just another attempt in the modern crusade to make everything Not Our Fault. Push the blame to someone else and sue when things go awry. Lovely.
Beyond the arguments about it being more costly, developing software to the degree of security we're talking will basically cause it to grind to a halt. Look at the popularity of Linux (with all its modern features) vs OpenBSD (with all its security).
> other mathematically proven insufficient and inefficient efforts
What are you going to do, have all software put through mathematical proof? I'm not even sure it's in any way feasible...
You can overbuild a house, it generally makes it stronger. You over code a piece of software it just adds to the number of possible points of failure. The two really aren't good analogies for each other. That doesn't even consider things like how maintenance of both is handled, interactions of hardware, varying setups, and just simple complexity.
Hey, engineering in general is a profession. Bridges and skyscrapers get built. And if the engineers mess up people can die. And there's liability for flaws.
Should all software hold to this standard? No. I didn't involve a civil engineer building a clubhouse as a kid. But there are places where correctness does matter and is worth the extra discipline and professionalism.
//TODO: signature
Can be had, at a cost. My clients procure their systems that way. I advise them (amongst other things) on keeping risks and liability squarely in the vendor's court.
I vote against it. -Software developer
All that would happen is vendors lock down the system totally and only allow signed, vetted code. Approved websites only. Pre-scanned emails only.
I'll take my chances.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Unfortunately, that costs both time and money. It requires that you have a formal systems engineering approach; Independent Verification & Validation; Testing and first of all; Formal Requirements that are traced to the implementation.
You can't get away with doing it "On the cheap". I don't know many countries that allow Rail Traffic Control system to run their railways, without formal process. Most of those that don't, are 3rd World countries and only pay lip service to the principle.
... All we need is love and Free Software. And even the love is not strictly a requisite.
Let's say everyone owns Free software, so nobody (i.e. everybody) is liable for faulty Free software. Everybody (i.e. nobody) pays.
In other words, sure, let the proprietors of proprietary software pay for software behaving badly.
If the software is free it's everybody's and nobody's responsibility. It's like culture and language in general. We do it together.
Who's with me?
Some of my favourite people are from th US; Vonnegut, Chomsky, Bill Hicks.
The solution seems a little too simplistic. Just look at any very large software project, like an operating system. Even a simple operating system like an iPod has a huge set of sub-licenses (go check out the Legal menu item, at least twenty on my nano). Large commercial projects often have code contributed from other sources; some open source, some not. If the problem comes from one of those contributions or sub-licenses, what happens?
I could definitely see Microsoft setup a fully owned subsidiary that gives free code to only Microsoft under Clause 1 (limited to refund) while the main shop sells it as a full operating system. "Oh, your computer is part of a bot-net? Sorry, that was a bug in the browser code. But since they gave that to us free, you get a refund of $0."
And people resort to writing trade secrets down on paper? Who knew there were so many luddites at ACM?!
There are already far too many lawyers sucking overhead out of software development companies. Increasing liability for code will drive up how much it costs; software is only cheap because it's relatively low risk to release.
I make my living working on open-source projects. Given how many imperfect components I work with, in a world with liability issues my full time job would become contract paranoia instead. It's already extremely dangerous to try and make a living from open-source work due to the huge patent minefields you're exposed to. If something like this happened, the only companies who would still be able to afford the risk of coding would be corporations with large legal departments. I'd have to move to a country that doesn't have these laws instead, which is exactly where all the software jobs will migrate to (even faster than they are already migrating now).
In this context, "over coding" software refers to, for starters, defensive programming techniques (i.e. checking the return values of all the functions you call, fully validating external inputs, etc). It does not reduce the number of points of failure, but it does require the programmer to consider them and the gracefully handle them or transparently report the problems it can't handle. It does bloat the code somewhat, making it less concise, and it usually increases the amount of time required to make changes, but the transparent reporting of issues to the user significantly reduces the amount of time needed to debug flaws. Fewer bugs escape testing and the bugs that do escape can be accurately reported, are more likely to be reproducible, and are more easily fixed.
The responsibility for preventing security problems with PCs should strictly fall into 2 places, the User, and the OS.... however... not the way 99.99% of you are thinking about it.
The user should decide what resources a program NEEDS in order to do a task, such as which folder it can access, what network connections, etc. This allows the user to decide ahead of time what they are willing to risk. Once that determination is made, the user then would give that list, along with a pointer to the program, to the operating system.
The OS should then enforce the users choices.... if it's not in the list, the application shouldn't even be able to find it, let alone access it. If the OS fails to enforce the users will, then the OS is at fault.... if the User gave away the store, well... they gave away the store.
This requires a simple change to the base design of operating systems, instead of permitting everything, and limiting actions of a running program to that of the user's account... the OS should limit the actions of the program to a short list of resources supplied by the user... and nothing else. Of course, the refactoring of everything to add this additional layer of logic is a massive undertaking.
There would still be the traditional user rights, access control lists, etc.... but there would also be a level of control where the user decides which of the resources they have should be given to the application. This is called "capability based security", or cabsec for short.
It's going to take somewhere between 10 and 15 years before people are fed up enough to make the switch.... but it will happen eventually.
Security isn't an application issue... it never was, and never will be.
I've been told by a lawyer that some laws actually contain the equivalent of "memory leaks". In other words, a law will refer to another law that's been repealed. None of these legislators ever eat their own dogfood of course...
I will quit writing code and find another profession. Maybe Italian underwear modeling, who knows.
So who is held libel when the user gets an email that says they've won millions of dollars if they click this link, ignore the security warning telling them they probably shouldn't click the link, and proceed to install some malware from god knows where?
If you're telling me that I am... well that's fine, becuase you're no longer allowed to click links. Or install stuff. Or do anything other then what I've whitelisted. Congratulations, you no longer have a PC.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Doctors don't have to be perfect to escape a law suit. They just can't be grossly negligent. In other words, if they make a mistake that the someone of their training and qualifications should have foreseen or avoided then they have a problem.
As a software developer, a law against bugs scares me a little but looking at our 'profession' I could see some value forcing us to take responsibility for our selves.
Not a week goes by that I don't read about some site, business or service that gets taken down or broken into because of a simple sloppy programming. Is it really asking too much to protect a website against SQL injection attacks? Is that beyond our skill set?
What if we were liable if we were grossly negligent as software developers? Let's say we used the "SANS TOP 25 Most Dangerous Software Errors" (http://www.sans.org/top25-software-errors/) as a starting point. If your software causes harm and a panel of software developers examine your source and see that you didn't take the most basic of precautions against these extremely well understood risks, you have to pay up.
The advantage for paper is that you need physical access to break its security. Paper in a safe is even better. And every educated person understands the characteristics of pen and paper, while understanding IT security requires an expert (I am one). I personally have some things on paper that I would not put on my computer.
So, yes, this is an indication of failure on the part of rolled-out IT security, but it is not a problem. At least I do not see one here.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Why are more laws always the first answer? If a company is concerned about losses due to software defects then I'm sure some private insurance company would be happy to sell them a policy. With that policy would come audits of software installed, browsers used, plugins used, etc. to determine the cost. You don't need to pass laws to make these sorts of agreements possible. In fact, some Playboy model just insured her boobs for $1 million, no laws required.
Ensuring software quality is not about building more. It is about testing more.
I was under the impression that manufacturers generally are not held responsible for the consequences of a third person cutting through the break cable of a parked car, soldering out the safety catches or adding arsenic to a hot coffee on a desk.
The authors fobs off the real meat of the topic - what constitutes "used normally" - to the legislature and courts, but my understanding is they already do that. If a product ships with code that itself will do damage surely they're liable. Whether there is liability resulting from the actions of others is rather a difficult subject. Even the maker of a safety helmet may only be liable for a injury the helmet could reasonably be expected to protect from; something highly unlikely to include scenarios that involve a third person intentionally trying to injure the person.
If the consequences of the poorly written code are negligible, who cares.
If the user can take well known preventative measures to avoid damages, and don't, then they are liable.
If a software fault causes damage to life or property, then the liability of the developer is a serious consideration.
A lot of research has been done to improve software engineering practices to make software more reliable. A lot of research has been done in computer science to prove algorithms. If you're writing mission critical software and ignore that research then you are doing something wrong and perhaps you should be paying the price.b
There's nothing wrong with pen and paper. Computers don't "replace" pen and paper, they "add" to pen and paper. That's always been the case. Just look at data storage. Pen and paper, subject to fire and flood, but otherwise reliable for ages. Computer storage can die for any number of reasons, but you can duplicate it thousands of times easily. That's the safety net.
Today, welcome to the internet, your computer is accessible -- by the way, you didn't need to plug it in -- so it's accessible to all. Blaming softway flaws is like blaming your locksmith because someone chiselled out your front door.
It's easy to build software without holes. About as easy as it is to build a lock for a bank. And it'll cost about the same.
But you never needed a perfect lock. Ethan Hunt can always get in. You wanted to deter, detect, and determine.
My home has a camera at each entrance. Not because they're anywhere near good enough to identify the person who stole the family jewels, nor to assist the police in catching the criminal. They are there to prove that the house was robbed -- to the insuance company. They decrease insurance fraud.
People forget the original intent.
Have you purchased windshield wipers for your car? Why? You can just take them off of any parked car you ever see.
Such a law would cripple open source / free programs while increasing cost of paid programs as well as killing off most software based companies. Security issues are a natural part of software. It's not the fact that they exist that worries us, it's the fact that companies don't proactively try to protect against them. Mozilla firefox is a good example of dealing with security issues yet they still have them due to the complexity and nature of the code.
A law dealing with intentions are also hard to prove so are useless as well. Rather then a laws, certification bodies would be a much better and more "capitalistic" solution. Something we already do for more security conscious places. And as shown, it's expensive to audit code as it takes alot of human effort.
In strict mathematical terms, you cannot trust a house you did not totally create yourself, but in reality, most of us will trust a house built by a suitably skilled professional.
Can you sue your lawyer if you go to jail and you are later found to be innocent? and the judge?
Can you sue every car driver out there for global warming?
Can you sue the president if he did not performed all what you think is best for the country?
In contracts for software projects, rules to guarantee certain safety and security levels are already present. In embedded systems and trading platforms, there are even laws in place which define how safe something has to be. For example the Safety Integrity Levels are used to define how many failures may occur before violating the law. Similar stuff exists for security. The real problem is, that no one in low risk areas is willing to pay for higher safety and security levels. Present end user software is too complex and to badly written to verify or validate them. They are not even using unit tests. And when they use them, they do not test the right thing.
You will have to rewrite most software and use verification and test methods alongside to ensure higher standards. If you establish SIL 2 or higher and similar security levels for software by law today. Most software can no longer be sold or used. As none of it will comply to these standards.
However, helping people to start using such methods might be a step in the right direction. And how can we apply such methods in OSS projects?
have things set so that REASONABLE EFFORTS are required. Now the lawyers can sort out the meaning of the term but if you have done everything possible (input checking and not using known unsafe code ect) then you should be safe from being sued.
Also if something is later found to be "unsafe" then the required patch/update should be given out free to existing customers (no fair bundling an error fix with a program feature update just to be able to sell the update). Now yes this should have a reasonable limit (you should not have to provide patches for an 12 year old program just because you have customers that have yet to upgrade to a current version) but trying to force updating just to get a bug fix should be forbidden.
Any person using FTFY or editing my postings agrees to a US$50.00 charge
player who had been killed by a specific weapon, after his armor had popped, had his death cam actually become the 1st person vision of the enemy who did the deed.
I fail to see how stricter software product liability laws would help that. But for creating work for lawyers based on Godel's Incompleteness Theorem? Pure genius.
No, he had it right. Adding defensive programming techniques is ANOTHER layer, with MORE potential for failure. When it comes to software, less is more.
Stand behind your work like an engineer...
Or get a job serving hot coffee
Who owns your data?
This is bald propaganda against open-source software. Companies like Sony SHOULD be responsible for user information. Who has reprimanded them besides the consumers?
You can't penalize something that's free. When you give it a value, and you de-humanize the relationship between software developers and users. Forget about open-source software existing in a culture like that. This guy is just jealous that the open-source community can write code for free, and he's trying to rope us open-source developers into his capitalist trap. F*ck off
If I had to be liable for flaws in software i wrote then i would stop writing software and become a gardener or something. Humans aren't perfect so problems will always occur. It just can't be helped.
Software is still an immature engineering discipline.
There is no set of rules that, when followed carefully, will guarantee perfect, bug-free, secure software.
Demanding perfect software today is like ordering a bronze age blacksmith to build a Ferrari.
Is there not a programing language by the name of ADA specifically designed for this? Used by the US military for mission critical software/firmware?
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
I have a root kit called EYES the can hack paper in nano seconds.
Free download.
Poul-Henning writes buggy code and has no business writing this sort of article
Adding defensive programming techniques is ANOTHER layer, with MORE potential for failure. When it comes to software, less is more.
There was an interesting comment about this on a mailing list I'm on some time back where a guy who builds satellites was talking about their flight computer design; they considered making it 'smart', but given that the software has to absolutely work all the time or cost a few hundred million dollars in lost satellite, their solution was that any fault would make it drop into safe mode and wait for someone to tell it what to do.
You could also argue that defensive programming contributed to the AF447 crash, because from what I've read the stall warning turned off if the aircraft was flying too slow for a reliable angle of attack measurement, leading to the paradoxical result that increasing speed -- even though it was the correct thing to do -- caused the stall warning to come on as the inputs suddenly became valid.
Unlike civil engineering, there are no rules for software development. There are suggestions, guidelines, methodologies, samples, etc., but no rules.
Liability only works if there is a way to make things bullet-proof, which is what engineering and construction standards do for their profession. But software is a house of cards, and the finger pointing and blame-mongering that go on when there's a critical system failure make it pretty much impossible to assign blame.
Arbitrarily blaming the software creator instead of the database provider, systems configuration, hardware problems, etc. is asinine.
There is no such thing as perfect software.
Businesses want liability so they can sue someone when things go wrong, and liability means you'd be responsible for their business losses, not just the value of the software. If you want to kill the software industry, go ahead and impose liability.
Me, I'll keep the "not suited" disclaimers in my code, and to hell with any American customers if the US decides to put through such an asinine proposal.
I do not fail; I succeed at finding out what does not work.
So how about corporations start PAYING for quality software instead of hiring the cheapest, fastest code monkeys to slap something together and get it shipped?
No? Makes too much sense? Oh, cuts into profits. My bad.
"There is little doubt that my proposal would increase software quality and computer security in the long run, which is exactly what the current situation calls for."
Nice troll too.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
Just let the free market work, the scanners that only degrade system performance will be slowly pushed out of the market by scanners that work. The problem is, people think they "don't know computers" and do whatever the "computer" or people on TV tell them. When the "computer" says it has found 18,323 viruses and needs a payment of $29.95 to delete them, they often pay it. When the guy at Best Buy recommends Norton, they buy Norton. When the TV tech "experts" say you need a firewall, they go out and buy a $30 firewall. Things like that will keep happening so long as people think that they "don't know computers" and don't make any effort to know them.
/much/ better track record of ensuring quality than government ever has. This isn't a market problem, this is a problem with society and people refusing to take responsibility for their own decisions.
The free market has a
Taxation is legalized theft, no more, no less.
Stand behind your work like an engineer...
Only when I get the same absolute power of veto on shipping a product I'm not happy with for any reason that a real engineer has, and all my coworkers on the project are vetted and qualified to a high standard like real engineers, and (this one's the kicker) the software industry has established robust, reliable mechanisms to build safe software like a real engineering discipline.
Approximately none of those things is going to happen for a long time within the world of general software development.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
We are approaching the point where people and organizations are falling back to pen and paper for keeping important secrets, because they no longer trust their computers to keep them safe.
I see that as a Good Thing. Use complex technology where it helps you. Where it doesn't, keep things simple.
Most people understand the factors that affect security of pen and paper. Understanding what you are doing and what other people can do with that is a big part of security, computer or otherwise.
Please correct me if I got my facts wrong.
PHK is a really smart guy and a great programmer but he's wrong on this. Show me the car designed to resist a mechanic or the bridge designed to resist a demolition crew and I'll show the software designed to resist a talented hacker.
Most high level security breaches are internal and involve social engineering or physical access. Most consumer targetted malware is spread via user error. Let's do the car analogies and someone remind me again, what is the liabilty if my vehicle protection system fails after I provide the thief with the keys? How about if I put my car into reverse instead of forward and smash into a wall, what's the manufacturers liabilty then?
I already have somethibg that actually works: Free software.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
You can overbuild a house, it generally makes it stronger. You over code a piece of software it just adds to the number of possible points of failure. The two really aren't good analogies for each other. That doesn't even consider things like how maintenance of both is handled, interactions of hardware, varying setups, and just simple complexity.
Software isn't built. It is designed. An overdesigned house isn't necessarily any bigger. More time is simply spent covering possible uses and failure cases.
Likewise, overdesigned software may not be more complex. It will almost certainly be bigger and slower. Careful study of use and failure modes means that some optimizations can not be trusted. If the behavior of a section of code can not be well enough understood, it may need to be replaced by something simpler, more predictable, but less efficient. It may also be less flexible, resulting in more frequent but better handled degredation.
Most malware and viruses expliot no flaws of any kind. Most often they expliot gullable users and the execution environment within which they find themselves. Open me to win $1000 instantly!!1!
If I sold a popular mission critical software system and the underlying systems environment were compromised or suffered a failure (cosmic ray strike, disk failure) leading to a disaster how much do I have to spend to defend my product against false claims? How much money does it take to prove in a civil case my product had nothing to do with a breach that effected the operation of my product? Even if a vendor does nothing wrong they get to waste time, money and resources defending themselves against user error, user stupdity and IT failures. From personal experience these cause the majority of downtime issues.
The paper uses a tired old structural engineering false analogy. "In strict mathematical
terms, you cannot trust a house you did not totally create yourself" This is nothing but specious dribble.
âoeif you make money selling something, youâ(TM)d better do it properly, or you will be held responsible for the trouble it causes.â
I've lost track of the number of engineering defects I've encountered in various vechicles and products where a quick google search finds thousands of others having the same problems and for which the user is left holding the bag out of warranty.
The only thing vendors are on the hook for are safety issues. Exploding batteries, exploding cars, catastrophic loss of steering control...etc. If a crappily designed $5 gasket causes engine components to fail and a $2k repair bill YOU still get to pay.
"If you deliver software with complete and buildable source code and a license that allows
disabling any functionality or code by the licensee, then your liability is limited to a refund"
If your customers do not know what source code is or have no method to benefit from it then what good is that other than a great loophole for vendors to dodge responsibility.
"your longtime vendors visits and delivers new product documentation on a USB key. You plug the USB key into your computer and copy the files onto the computer. This is âoeused normallyâ and should never cause your computer to become part of a botnet"
What if they plug the USB stick into one of your (infected) computers which installs an autorun virus on the USB. Then the stick is withdrawn from your computer and placed in a second computer at your location. Is the salesperson responsible for "infecting" the uninfected computers? How much does it cost to figure that out in court? If the USB stick is then used to infect other customers of the salesperson are YOU liable?
"And that is it, really. Software houses will deliver quality and back it up with product liability
guarantees, or their customers will endeavor to protect themselves."
As we've seen recently with the RDP worm successfully explioting hundreds of thousands of commonly used totally insecure administrator passwords even if software were magically 100% bug free and reliable you would still be left with a massive heap of catastrophic security issues caused by human failure.
"It is also pretty certain that there will be some short-term nasty surprises when badly written
source code gets a wider audience."
The number of long standing security bugs which continue to be found in popular open source operating system stacks is depressing in itself. Sunshine is better than nothing but insufficient to effect outcome.
âoethis law will mean the end of computing as we all know it!â
The idea is batter outcomes and increased value for end users. Have you provided a showing of evidence to establish this is the case or are you simply stating your opinion?
By the lack of any serious effort to concider the possible side effects and downsides of your proposal it makes your work look sloppy.
" To which my considered answer would be:
âoeYes, please! That was exactly the idea.â"
Hollow sound bites only waste the readers time.
Yes, but.... what happens when the software that is landing a plane miscalculates the height above ground and it crashes? Wouldn't you hold the software developer accountable for that?
Give me $150,000 and 3 months and I'll give you a relatively bug-free version of Hello World (no guarantees about the hardware though). If you want some more complicated software, I could put together a team to do that too; the price and time requirements will go up exponentially though.
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
I've done two big projects recently.
One, is critical to my employer, and if it goes wrong, it will be dramatic. Apparently when one of our competitors screwed up, it made the news.
The other, is kinda... y'know, it's nice if it works, but we want it cheap.
The first is 2/3rds the size of the second, a fraction of the complexity, and took 6 times as long to develop, and was considered to be developed an ambitious timescale.
We are not talking about putting a bit more effort and a few hours in here and there to bring quality up, we're talking an entirely different development process, and it would drive costs through the roof.
If you want to assert a patent or copyright, your software has to work flawlessly. If it doesn't, then you can't assert a software patent or copyright.
Seems fair to me.
It also makes it harder to unit test all code paths.
But i agree with the principle.
Liability is not on you as a grunt employee. Liability is on the company. If you don't want the software to ship and the company ships it anyway you are not going to be sued, the company is going to get sued. This is not new stuff, many companies already have liability for software and hardware whether through contracts or legal requirements. No one in the trenches ever gets absolute veto power because then just one disgruntled employee could ruin a company.
"Real engineers" don't magically get the absolute power to tell the CEO to stop shipping, but any engineer at any level and at any company already has the ability to warn others of problems.
I am not sure if the article writer actually thought this one through. In engineering as I understand it there is a category of engineers called professional engineers, which are allowed to sign off on work done and are held liable for any defects that may arise through normal, non extraordinary use. Bridge falls down under a normal load limit and well within expected age, s/he's on the hook. Building collapses with no reason, s/he's on the carpet explaining themselves. These engineers are for the most part licensed on a state by state basis and are mostly concentrated in the civil/structural engineering field, though there are others.
For fields in which there is no state by state regulation, or products which are not confined to a single state (cars, airplanes) there is a thing called an industrial exemption, which basically stipulates that engineers are exempt from individual licensing and liability in designing and manufacturing products while under the employ of a company. The thought behind this is twofold (or more):
Now given my semi understanding of the field of professional engineering licensing, which I will admit is only based on heresy and 10 minutes of Google research, I am wondering which model of licensing the author is proposing? The once where licensing is done on a state by state basis, which would effectively kill any sort of large software distribution, including Microsoft, Linux, Google, and any thing else that grows beyond someones the locale city website. Or the one in which software is treated as a product, covered by all the end user license agreement and statements that it is delivered as-is, with no guarantees of suitability for purpose and which does not actually require a licensed engineer to make?
Now obviously IANAL nor am INAE, but I think that maybe his proposal will not work out the way he thought it would.
Of all tyrannies, a tyranny sincerely exercised for the (supposed) good of its victims may be the most oppressive
How about just testing out software before you buy it. People are idiots if they buy software that doesn't work, or ask for a refund right away when it does not. As for unforseen bugs, well they're unforseen. Live with it, it's life.
The net effect is to disallow EULA liability disclaimers rather than allowing customers to ask (and pay) for high reliability if they need it. If no one wants to offer such a feature, does it make sense to force them if it means that a useful product has to be removed from the market?
This will eradicate any small companies that manage to survive the new US patent laws, or force them to open their sources (which is ethically bad by definition.) Even if sources are only provided under NDA as part of a license, it will make the software cost more with no benefit for 99% of users.
You can overbuild a house, it generally makes it stronger. You over code a piece of software it just adds to the number of possible points of failure. The two really aren't good analogies for each other. That doesn't even consider things like how maintenance of both is handled, interactions of hardware, varying setups, and just simple complexity.
Another factor worth considering - when your house fails, it's generally very expensive to get the house back in a working state. With software, restarting the application, or, failing that, restarting the computer will generally correct the problem. Granted, if the application is fundamentally flawed, most people aren't using it anyway.
Sure I'm paranoid, but am I paranoid enough?
The fact is, no computer system or software application will be without flaws. Period. You cannot argue this and there's no proof otherwise. The only way to protect your data is with diligence and multiple layers of security. You protect your information with firewalls, good coding, good maintenance practices, redundancy and backups, and encryption, then pray for the best. The harder you make it to get the information, the less loss there will be, but the goal is keep any loss tolerable. You will inevitably have answer the question "What was stolen?" but will you answer include, "And they sold/published our customer data, too."?
Furthermore, when your mom makes toast... she doesn't have to worry about the toaster somehow accessing every previous piece of toast it ever had access to and suddenly sending those atoms to a temperature of 10000 degrees.... it's obvious when you have a toaster running what the inputs and outputs are.
Okay I write a piece of software. It results in a security breach. You lose 50 million dollars.
Oh, but you're okay because of liability, which legally makes it my fault!
I just have to cough up 50 million dollars, and everything is okay. Only problem is I don't have it. :)
Oh, I get it. The mere threat of liability will shape everyone up so there are no bugs. The reason there are bugs in software is that nobody is scared enough. That's it!
The reason isn't that a bug-free software development process is orders of magnitude more expensive and time consuming than one which works by tolerating some bugginess and reacting to it.
If we are scared enough, we can be jolted into making bug-free software, and consequently we can boldly take on that liability --- all at no extra charge to the customer.
Most people can do quite well with just a locked down system in a walled-garden.
Most, but not all. There will always be plenty of people who need more than "just a locked down system in a walled-garden", such as students doing their computer science homework or hobbyists trying to build their hobby into a business. Will a system that is not locked down remain available at reasonable cost to home users, or will people have to affiliate with an established business to qualify to use an open system?
Would be held liable for all the flaws and dumbass bugs in your shit?
If you're writing the software for a flight control system and it fucks up, YOU'RE ALREADY LIABLE FOR IT. If you crash a plane, the FAA will fuck your shit up, no matter what kind of contract you trick your customers into signing. What point were you trying to make?
I think your analogy is flawed.
In terms of "overbuilding a house", you are using that phrase as equivalent to building to a higher standard. The classic benchmark for that is the Building Code, so you would be building to a higher standard than the applicable Building Code.
In terms of "over coding software", you are using that phrase as equivalent to building additional function points, modules, or whatever your metric for software capability is.
Therefore the implicit basis for comparison is entirely broken. You need to square up your comparison model. To change "overbuilding a house", you need to think in terms of building a larger house. To change "over coding software", you need to think in terms of adding quality. There are lots of ways to do this, including formalized test plans, separate QA teams, code walkthroughs, etc.
Anyhow enough with theoretical analysis. I've constructed several software systems and it has always struck me that the most successful ones ARE somewhat over-engineered. Not to a crazy proportion, but always a bit more than they strictly needed to be. The over-engineering always concerned support for "out there" conditions and really unusual input, or runtime circumstances. Since the programs contained a lot of support for edge cases it makes the system more flexible and reliable. The resistance to crashing and unusual failure modes tends to create confidence in all the people who use and support the system.
Software costs make up such a tiny portion of the cost that the consumer won't see the price increase. Making software an "Engineering" job will push up wages and limit off-shoring due to liability hazards (if they can't find that fly-by-night developer then the CEO and friends are held liable & It's much harder to sue a third world company than one in your own country). I predict this whole liability thing will be good for business.
People want software to be perfectly safe and stable in a world of unlimited interactions. They want that someone can do something malicious to it, and yet it still has no problems. They want to be able to totally disregard proper usage, and still have it not break.
This isn't something we demand from houses, or any other physical good. If someone comes and burns your house down, you don't scream at the builder for not making it incapable of being burnt down. If you decide to cut the load bearing supports and your roof caves in, you can't sue them for failing to prevent you from doing that.
While I'm not saying that cases of misuse or malicious use are the only times software fails, they account for a large part of it. Houses, cars, etc all have tons of known flaws that they don't fix, they just tell you to not do that. A known flaw of my car is it can't survive a frontal impact over about 40 mph. That will cause the crumple zones in the car to cave in the engine cavity, completely disabling it. It will be a lost cause, have to get a new one. This is a known problem, and they aren't going to fix it. The solution is for me to not run it in to shit. Likewise my house is built primarily form wood, and thus can be burnt down fairly easily, wouldn't even take an accelerant, just a fire in the right place. However nobody, me included, is rushing to fix it. I just know to not light fires in it, and keep an extinguisher on hand.
It is only with software that some people somehow feel justified in demanding perfection in every aspect. It should run on any system and never crash, it should take bad input and not have a problem, it should be totally impervious to malicious attacks, and so on. They then get mad at the vendor if it is in any way less than perfect.
It actually turns out there ARE systems that effectively never fail. Things like the computers that run the phone system. However they are very expensive, you aren't allowed to mess with them at all, no installing software or anything, and they can only be accessed in approved ways, where inputs are sure to be valid.
I'd wager that for every 1000 programmers out there that aren't validating external data and the results of their function calls, testing all code paths is the last thing on about 999 of their minds.
If you design a vault door for a bank that can be opened with a hairpin then it's your fault.
You could also argue that defensive programming contributed to the AF447 crash, because from what I've read the stall warning turned off if the aircraft was flying too slow for a reliable angle of attack measurement, leading to the paradoxical result that increasing speed -- even though it was the correct thing to do -- caused the stall warning to come on as the inputs suddenly became valid.
What I see here is an error condition that the user was not informed about. It's not defensive programming when you simply discard a critical error you successfully identified.
The problem with holding the programmer responsible is that security is at least as dependent upon the actual installation and operation, as it is on secure coding. Apache is very secure-able; it just also has a variety of insecure ways to deploy it. You can't hold a programmer responsible for a client who doesn't provide a secure environment or correctly follow the implementation guide.
The practical effect of this would be that, in any real lawsuit, there would be years of discovery and litigation over exactly who was at fault, the programmer or the customer. And if you couldn't afford to fight that out, then you wouldn't risk it. Goodbye freelance web developers. Goodbye online ecommerce that costs less than six figures to deploy.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
it's not equatable to the torts on health care.
I agree increasing the liability would seriously impact cost. We might try and actually get them to fully disclose all known risks, or something like that as a nice split the middle. I personally hate it when I get snagged on software that doesn't do what it says it does, or worse, does something it does not say it does.
The torts on health care are a entirely different animal, and equating those is trolling in my book.
You can make the case for software liability being bad, without trying to make the case that we need to reform torts in health care. And you should, because torts in health care are not the cost driver. private insurers operating on VERY THICK operating costs, and poor distribution of risk / poor management of resources is what drives our costs up so high.
We pay twice what France does per person, and we don't cover everybody, and we don't use our resources wisely. Torts are a minor league part of that.
Outcomes in France are better, and in fact outcomes in most modern nations doing either regulated private insurance, or nationalized programs are better, and their costs are significantly lower than ours are too.
Blogging because I can...
a law that says just fix the damn thing rather than "you'll have to upgrade to the next version" or whatever the alternative is.
"It does bloat the code somewhat, "...that is putting it mildly. Building a super small single purpose utility for use by an end user, at least 75% of your time (and LOC) is spent checking methods return values and error handling.
I object to power without constructive purpose. --Spock
Users don't want to think about resources at all.
Users want it to just work, and be so simple they don't have to fire a single neuron to get it to do what they want.
Good luck with your vision.
real engineers build things that can kill people if they do things wrong. they have all the same pressures from management, but they still (theoretically) have standards, and licensing bodies, and like, rules and stuff.
Trust an assembler? Who wrote it? The closest I've come to creating software of my own hand has been on a PDP-11 test station, and the embedded processor it tested... writing hex values directly into memory. But even while massaging words by "hand", I was still relying on someone else's tools to get my intention from the keyboard to the flip-flops, and thus still suffering from more levels of abstraction than any civil or mechanical engineering effort.
Luke, help me take this mask off
You should not have to overbuild your code. The OS should be rock solid and your app should have no vector to get out of user space.
It is impossible to built a secure app on a unsecured OS.
Think about evaluating software vs bridge building in terms of failure risk:
Some factors:
1. The number of novel components (e.g. a software procedure which has likely not been written before).
2. The number of novel pair-wise interactions between components, whether the components are novel or not.
I would venture that on this sort of metric, the average 2-year software project is probably running somewhere
like 100,000 to one more inherently risk-prone than the average 2-year bridge project.
So the cost of "fault insurance" that would need to be passed through to the customer would be on the
order of "a gravel truck to a pebble" more than that needed for the bridge project.
Where are we going and why are we in a handbasket?
There is a simple solution, they buyer pays when they sign the no guarantees contract.
Wow, that was simple, but doesn't that mean the buyer needs to test for themselves? What a farce! You can not test a bridge for earth-quakes and you can not test an appli...oh wait...
..because they are trying to impress you with their "understanding" of that book's contorted logic and numerous mental ramblings. I read that book, back in the 80s when it was in vogue by the intelligentsia in the hope of being 'enlightened' but instead of this I realised it was just a load of confused wordage puzzles. If you haven't read G-E-B then I can assure you you aren't missing out on anything. The only good bit is the picture on the cover of a block profiled to sillhouette G, E and B on its faces. Poul-Henning Kamp just wants to appear smart, that's all.
1. Doctors want tort reform so that they don't have to practice defensive medicine. Anyone who tells you that defensive medicine is not a significant cost driver is delusional.
2. Do your homework and find out what the actual rates are. Obstetricians and Neurosurgeons typically pay over $100K per year for Malpractice Insurance even if they've never been sued. And don't overlook the fact that any Doctor who closes / leaves their practice has to carry Malpractice Insurance for a State mandated period (typically 3 years or until the patient reaches the age of 18, which ever is longer).
Take it from someone who's been on the inside and has seen the industry first hand.
I proposed, back in 2000, that Microsoft be required to provide a full warranty on their products as part of their antitrust remedy. "Full warranty" has specific meaning in US law; see the article. A few vendors have provided full warranties and not found it too expensive. Notably, GTech, which builds gambling systems, is held financially responsible for errors made by those systems. This costs GTech less than half of one percent of their revenue.
It's time for the computer industry to grow up and take on warranty responsibilities. The auto industry had that forced on them by Congress in the 1960, over the screams of the auto industry. Cars rapidly became safer and more reliable.
It said that security is worth a lot less than you think. That it is better to deal with the occasional consequences than to secure our software. Same with privacy. If this doesn't make sense to you, you're probably underestimating the total cost of security and privacy. The monetary costs are huge, but the total costs go far beyond monetary to what can even be accomplished, and, *gasp* even threaten convenience. I don't know if you've met any consumers, but they value that pretty highly. Thinking they are wrong and demanding control over their products is, well, morally wrong and economically discredited.
Clause 2. In any other case, you are liable for whatever damage your software causes when used normally.
This is too broadly stated. Define "when used normally". If the purpose is well-defined and performance is agreed to by spec via signed contract, then yes Clause 2 is fine. Now let's go into the real world shall we?
In the real world software is continually modified, changed, enhanced, etc. Thus "when used normally" is difficult to nail down.
A glaring omission of this software liability discussion is the area of software testing and, even further, software certification. The bottom line here is that such a simplistic treatment of software in terms of product liability is doomed.
--- You are in a little twisty maze of comments, all different.
The same liability that a PE accepts when he puts his stamp and number on a design? That's the point. It's not about tricking customers into signing something, it's about people who are designing things accepting responsibility for that design. Why should software engineers be given any different treatment?
If you design it before the invention of the hairpin?
It is not always hard to create liability, it is just done through contract.
I produce software which you can get this assurance on, however it comes with a few restrictions the general use version does not.
1) It will cost you far more than otherwise (think the 100x range), the exact usage scenario and liability is explicit in a contract.
2) We provide the computer, you may not use your own. You additionally may not use it for any purpose other than the one we provide it for (and have no easy ability to do so anyway, as you would need to open it and void the warranty in order to do so.)
3) No network access (easy if using an alternate operating system with no included network stack.)
It is not hard to assure that a piece of software will pretty much always work when used for its intended purpose, just expect it to behave more like your toaster than your general purpose computer.
Making a guarantee that the device will always work when used for its intended function means the intended function becomes clearly defined. I bet you void all sorts of provisions of the warranty on your car if you replace the engine, or start moving parts around between vehicles.
If full liability becomes commonplace you will suddenly end up with a large collection of computing devices, all of which will refuse to talk to anything not explicitly approved by the vendor. This is not usually worth the tradeoff, but would be the realistic way what you ask for is accomplished.
Be careful what you wish for.
I'm a signature virus. Please copy me to your signature so I can replicate.
that I don't want even to comment about it.
TFA and all the comments so far assume that "software makers" are not already legally liable for "flaws." They are.
The law of products liability, and the law of warranty (Article 2 of the Uniform Commercial Code), applies to software just like any other product or human activity. The reason it is impractical to sue over defective software in all but the biggest-money cases is the cost of litigation.
In order to prove that a given software product is defective, or its developers negligent, you need expert witness testimony. You need to have expert witnesses either disassemble the code, or to analyze source code that one has obtained by means of a subpoena or through discovery. The expert witnesses would then testify that the coding does or does not meet the standard of care that would have been used by a reasonable developer. You also need an expert witness to testify as to causation, in other words that the identified flaw caused the harm or damages suffered by the plaintiff.
And expert witnesses aren't cheap, they charge many hundreds of dollars per hour.
This is why early commercial software developers quickly came to demand End User License Agreements that disclaimed all warranties, so they could not readily be sued and subjected either to the caprice of nontechnical judges, or to an infinite-spiral of expert witness costs.
A flight control system will be a combination of hardware and software, and will have very strict usage limitations.
I find it very unlikely that someone would produce a flight control system that runs on the average windows computer and accept liability for anything that may happen.
If you control the entire solution, ensuring that it will work reliably is much easier.
Start modifying the flight control system, and I bet liability goes very quickly.
I'm a signature virus. Please copy me to your signature so I can replicate.
Woohoo!!! quality assurance job security!... oh, wait a minute, the company will go out of business under such liability and unrealistic expectations....no more jobs for QA...no more jobs for anyone...
BAD IDEA, and just when I started wearing my superman outfit to work!!
The contributors to GNU software do not form a legal entity, reside in multiple jurisdictions, and quite often do not reveal real-world identities. Good luck finding someone to sue.
There's a great quote about the current state of software quality:
We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer -- and keep pouring our sewage into our water supply.
-- Tom Van Vleck
Software makers will still make mistakes, even if they know they're liable. They'll just hope that their code is secure and nothing bad will happen, and ship it. And besides, what does the grunt programmer care about the firm's liability if it's a big one? And when would those things be prosecuted - probably just in a few high profile cases. And this wouldn't do a thing about users clicking on links from emails which is the way security is compromised most often.
I'm tired of my house being robbed but I want to leave my keys in the lock. We have to do something.
I'm tired of kids driving my car but I want to leave the windows down and the keys in the ignition. We have to do something.
I'm tired of my doctor misdiagnosing me but I refuse to know anything about my body, I refuse to eat healthily, I don't like to exercise. I drink and smoke like there's no tomorrow. We have to do something.
I'm tired of politicians stealing money and behaving irresponsibly but I refuse to learn law, know what's going on, build a community and exercise sovereignity. We have to do something.
I'm tired of everyone being a shallow idiot but I enjoy watching shows about people stupider than me, I'm in love with my iDevice and refuse to pay attention for more than 10 seconds. We have to do something.
I'm tired of thinking that we have to do something. We have to do something.
How many times have we heard of this kind of proposal? Is it really even worth mentioning? Especially when its a random flame-bait article rather than actual legislation proposal?
By giving attention to this, you are encouraging the ACM (of all people) to produce more of it.
Next it'll be another rendition of "taxes on email".
So you can't touch your hardware/software combo without it being checked by some certified dude. All changes have to fit in with approved lists and procedures have to be followed to the letter and signed off (by a certified - hint, expensive - dude). Then there's the anuual compliance checks.
Yup, sounds like a real improvement to me.
If you don't give source code out, you're responsible for bugs.
If you stop supporting code, you have to give out source code and let the copyrights lapse.
As long as you have the copy right, you have the responsibility to make the product work as advertised, including all bug fixes.
That's free markets. No government barriers to entry. Ergo no copyrights, no software patents.
Let the Free Market work!
"Life for me has been beyond unfair."
Sounds to me like you had a cushy job in a .com until your lack of skills got found out but you're trying to present it as some elite having it in for you. More likely you're some HTML/javascript hacker who can't cut it doing real (ie non web) programming but wants to blame everyone else for that.
"Wouldn't you hold the software developer accountable for that?"
Which gets to why this idea by itself won't work.
First, who is the "software developer" of a system that uses lots of modules from a variety of vendors (including hardware aspects)? You have an entire ocean of people involved with a big project like that from designers to coders to testers to users...
Second, companies will just use corporate law to create liability shields where each part that could go wrong will be in its own sue-able unit with minimal assets.
Third, let's say something does go wrong, and you can point at a bit of offending code. But, was that really the problem? What about the compiler not smart enough to catch a *semantic* error? What about the simulators that were not good enough to discover the bug in advance? What about the testing procedures? What about the broken CS training programs that focus on theory and not practice? What about the managers who picked a poor development platform because it was popular? When you can go up a chain (or web) of responsibility, why blame the coder at the bottom when there are so many factors involved in making that accident, some of which operate on different timescales?
This whole issue is part of the reason why things like Forth and Smalltalk were so wonderful as small and understandable self-reflective systems, but we got mainstream adoption of buggy C/C++ and bloated Java instead. When the plane crashes from a pointer error, maybe we should blame those who did not choose to support Smalltalk decades ago?
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
You can overbuild a house, it generally makes it stronger.
Problem is, you have to massively overbuild, because a slight overbuilding makes it rigid where it should be flexible and causes it to break itself in an earthquake.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Your point is taken, but at the risk of taking an analogy too far, let's look at the PE's web of responsibility:
The PE signs off the design. He might not have been 100% the creator of the design (it was most likely a design team), but he is the one who takes the ultimate responsibility and risks liability issues if he doesn't examine every detail and is confident the design will work and will be safe. He has numerous tools available to him to ensure that design is good, and he is responsible for ensuring those tools are up to the task. He also specs the steel for the girders, the concrete for the bridge and the depth of the pilings to support the building. He might have a civil engineer or or structural engineer participate, and sign off, on design and construction of those elements. If those people don't construct to his spec, he holds them accountable, but once he signs off on the final construction, it's his neck.
I see this as empowerment and a change of status software developers. The guy who has to sign off can choose the right language, compilers, testing methodology, and whatever else might be necessary to ensure his neck stays out of the noose. Otherwise he doesn't sign off. What's more empowering than that?
put the liability on the company and let them figure out how to best implement software.
open source software isn't about the price. it is about treating software like infrastructure having everybody improve it. our problems are too big to be solved by a few thousand programmers in redmond.
New tools will be created over time that will make programming easier and more robust while having fewer flaws. For the most part, we don't write in Assembly anymore.
20 yeasr from now software development is going to look much different.
So when you hold vendors accountable for software...you make them liable, where they can be taken to court over things like encryption that does not work, etc.
MS brought out the "push out a faulty product and offer patches later" business model to where we stand today.
Everyone jumped on that same band wagon, except the airlines, and car makers etc....
If an airplane crashed every second day, because of a blue screen of death on the cockpit dashboard....we would all stop flying...
so is it any wonder that people are going back to paper if every second day, their computers crash???
At the other end of the spectrum, you have the users that are so cheap, that they use illegal copies of windows without any patches, as they are not
serviced because they are illegal....so you have all these bad pcs that are part of some botnet spamming lots of emails...
and crashing because of all the viruses..... and yet people expect that it should work no problem.
I have a windows xp, that is not legit, running in a vm environment with no AV and guess what, ....for since longer then i can remember, have never had
viruses, and even if i dont, i change the image back to its original form at the start of every month......
now ask me if this is truly a way to live....not really....
I have a legit windows xp that is 100% patched, that has no AV, yet has run ok for many years now...
It is possible to make what we have work, but we should definitely push the vendors to be more accountable for security...especially when mom and pop use their pc to do their online banking and get their info stolen...
You can overbuild a house, it generally makes it stronger.
The better analogy here is an "overthought" piece of software wherein functions are all clearly defined and documented, the hiearchy is well thought out, reuse reduces chance for copy or confusion errors, and every end combination of use cases has been thought of and tested by an automated system that can re-test the whole product after any change.
For anything more complex than a soda vending machine, the price (in time required) to do this well becomes surprisingly large compared to just dashing off something that will probably work, testing it a bit and shipping it.
I think the real problem is that most people are exposed to a lot of software that was developed as "a bit of fun", like Twitter or Facebook, and then they attempt to use it for things they should consider to be mission critical. If you can't handle the risk, play a different game, the new and cool stuff will never be rock solid.
You know all those posts on Slashdot that make fun of the legal profession for its ignorance of technology? Unsurprisingly, IT professionals are just as ignorant of law. Of course, it's not a bad thing to discuss laws, and the layman should indeed do so, but anyone who wishes to be taken seriously must take the time to educate himself in these matters.
First: You haven't clearly articulated what liability standard and what type of damages would be covered. Are you positing strict liability or negligence liabilty? Are you saying that software coders should be liable for indirect and consequential damages? These are legal terms of art with specific definitions.
Second: There are problems with causality here. To what degree is a malware exploit "caused" by bad code? What if that code is actually better than all other code ever created, but still vulnerable? What if there was no possible way to protect from that vulnerability while providing adequate functionality? In your example of the salesperson delivering an infected USB drive, there are many unanswered questions. What if the salesperson caused the malware to be on the USB drive while using it for personal use, unauthorized by the company? Is the company still liable? This question has an answer under current law, but what do you think the answer should be under your new law?
Third: This can already be done through private contract rights. It is for this reason that every software EULA or vendor contract explicitly disclaims warranties. The concept here is that the user must get insurance for their risks. If instead we make it mandatory for the vendor to assume liability, what we are really doing is shifting the burden of purchasing insurance from the user to the vendor. Usually, the law tries to shift this burden to the party who has the best ability to prevent damages, in order to minimize costs. One might think that the proper party to insure against this risk is the software vendor, but this is not clear. The vendor clearly has more ability to fix its own software, but it has almost no ability to determine what damages would be cause by badly-coded software. This is because the damages caused by bad software are mostly indirect and consequential damages. The user of the software (and their insurance company) is thus better able to judge the risk that will come from using a particular piece of software, because they know what sensitive or private information they have, and they can judge the consequences of its compromise. Finally, having software vendors function as insurers for their users would necessitate enormous litigation costs, rather than the comparatively smaller costs of carrying insurance for the users. False claims might also be a problem.
Software liability is a worthy topic, but this analysis is not nearly sophisticated enough to merit serious consideration.
GTFO!
a broken word document does not. If your software runs a device that people's lives depend on, then existing negligence laws cover the device just fine (e.g. pacemakers and whatnot).
Software Liability is just the big companies trying to take control. Nothing else (well, there's a healthy dose of fearful stupidity there, but those people are silly, so I don't count 'em).
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
So software is like clothing?
Bad jokes aside, there is a need for software QC standards.
Some of the new age internet trolls may need extra features
Depends on your definition of "over".
Overengeeering software does not mean slapping on more stuff. You're right, that will only end up in another Windows ME.
Overengineering means more emergence. Meaning: More general concepts (which are harder to come up with) that work right in more detailed situations.
One example would be Newtonian mechanics compared to quantum mechanics. Even though it's partially a bad example as quantum mechanics are more complex. But they offer a lot more right answers. Not by adding rules. But by creating more general ones.
I made it my work philosophy, to always create the most emergent, elegant and efficient code possible for the resources. I prefer to merge two things into one elegant one over adding another function.
*waves order papers in the air*
Okay, so you add software culpability laws. But where do you draw the line of culpability?
.Net, Gtk, etc - to build upon. Is the application provided culpable for the bugs in the toolkits? Or do they simply say "that's a toolkit bug" so the user has to go after the toolkit vendor directly? or are we going to end up with a fantastically lawsuit encouraging environment where the user goes after the application developer who has to turn around and go after the toolkit vendor who...
Most software uses a toolkit of some sort - WxWidgets, Qt, MFC,
And of course, then you get into the hard-to-replicate bugs. What kind of bug is allowed to be sued for? One that occurs once but kills all the data? Or must it be repeatable? For that matter, how to you certify that the bug is indeed in the application and not in the hardware? Or even which application it is in?
For example, Compaq had a big bug in their Floppy Controllers years back that would randomly cause the floppy to not write data to disk. They later settled. But how would you prove that the bug was not in say Microsoft Windows or Linux and that it was indeed in the Floppy Controller? And who would the user have to go after? Would they have to go after the application vendor, who would go after the OS vendor, who would go after the hardware vendor?
Furthermore, how do you define that it is a bug? Do you specify a reference platform? Can each vendor specify a separate reference platform or does the law specify the platform? If the law, how does innovation in the platforms occur without the reference platform becoming obsolete? How does the vendor, how to does the user stand to win anything if their system doesn't match the reference platform? Either way, it's self-defeating.
Where does it end?
The problem with software, as compared to the rest of the world (and even computer hardware), is that the rules are all off when changing environments and nearly every computer is different from every other computer. Take two computers with Windows installed - even the same version of Windows - and you'll likely have them installed to different patch levels or have different device drivers - even if you bought both at the same time from the same place and bought the same models; and if you didn't 100% lock it down directly after the purchase before any user got on it, then there is likely different software installed too, so they quickly diverge to become different environments.
No other industry has that kind of change in environment for their products. In some respects its amazing that software manages to work at all given all the changes between when developers make the software and when the user actually uses the software the developers released on their computer.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
It will be a blast to deal with the various opinions of right decisions of various master planners or, let call them what they should be called, software architects in a court when something has gone wrong. That leads to regulation of individual solutions and parts of solutions like in the building industry here. This wouldn't be much different situation from now as the regulations and standards are already influencing software in various fields. The engineering company pays its liability insurances anyway and the individual designer, programmer or an architect won't lose his house and life savings. The consulting software architect pays his as well.
This would lead to more standardized industry wide solutions and emerging of interoperable components. On the other hand, customized software would be much more expensive and the pace of innovation would slow down for the most of the industry.
If I write some custom code and you sign off that I've delivered what you have asked for, that is on you. And if I wrote any packaged software, I'd have to put in my EULA that by using my software longer than means you have tested it and certify that it is suitable for your purposes for which you intend to use it. Additionally, you would have to agree that any change in the environment in which my software is installed invalidates any warranty or guarantee. This would include changing hardware beyond a simple unit swap, modifying or updating drivers in any way, or installing other software that could potentially use the same resources (such as memory) that my code is using. OS patches and upgrades would clearly be completely indemnifying. Welcome to software as an appliance.
We can't paint it all with the same brush. There are situations in which a company provides software designed for protecting valuable data. If I sell software to a bank that is easy to penetrate then I should be held liable unless the bank behaved improperly in the use of the product. However if I write a game program that is intended for non critical computing environments and some defect allows bad people to gain access to the family computer I should not be held liable. The simple fact that penetration of most PCs will not reveal a worthwhile economic gain makes it unlikely that it will be attacked in the first place and trivial if it does occur in most cases. Crooks prefer to go after good targets. The chances are that most system penetration has to do with sloppy behavior of the system users and not what software they happened to purchase.
So, I can sue Buick now if someone breaks into my car?
I can understand the expectation for a reasonable amount of quality and security, but when there are literally thousands of people actively trying to break into your computer, you have to assume that occasionally one is going to be successful.
This kind of thing happens out of rampaging ignorance. People don't understand how the damn things work, and assume that computers can be absolutely locked down, while at the same time travel the universe, virtually speaking.
My Heathkit H89, built in 1980, has never had a computer virus in 31 years of service. Of course, it's not connected to the internet either.
Madness.
Proverbs 21:19
While what you outline sounds sensible, there are at least three big issues that are problematical with an analogy to physical things like bridges or houses.
Unlike building a physical bridge using well known technologies to get specifically from point A to point B (a requirement almost anyone can understand), new software generally has vague requirements and often uses new technologies. From:
http://gamearchitect.net/Articles/SoftwareIsHard.html
"Rosenberg's Law: Software is easy to make, except when you want it to do something new. The corollary is, The only software that's worth making is software that does something new."
If software did not have vague requirements, chances are you could just use an off-the-shelf solution. That is a big difference between software (easy to copy) and bridges (a copy somewhere else costs about the same as the original). That is why so much of CS is BS, because a lot of it is about formal proofs that systems satisfy requirements, but if the requirements are buggy (or incomplete), then what is the point of proving they are met?
So, if a big part of the project is coming up with the "spec", what do you do about a bug in the "spec"?
Also, in practice, people generally don't get to pick what tools they use for all sorts of cultural reasons (previous tools used by an organization, availability of staff, issues with future maintenance, and so on). For example, if bridges could be made out of 10,000 different types of materials, all with very different properties and each needing specialized expertise to maintain, with those materials quickly coming and going in fashion, what material would a bridge-builder pick? Worse, what if the material most in fashion was the worst designed, hardest to use, most unsafe stuff that was only popular because somebody pumped a billion dollars into marketing it? Contrast that with designing a lot of bridges where it is true there are some choices of material, including a variety of mixing proportions for concrete, but the range is not so large. So, being a professional software engineer signing off on things would be a much harder job in a rapidly changing industry than being a professional physical engineer.
Also, just as another problem, it is very rare in physical engineering that someone would suddenly say, your bridge is broken because the road leading up to it is suddenly ten times wider and has a monorail track down the middle, but that is what happens in software all the time. :-)
With that said, I generally agree with the other person who replied AC to your post, that we'd see an increase in use of standards. We might see better standards.
Which leads to my second reservation. Personally, as someone who has been programming for about thirty years, I think the world suffers from too many programmers -- although also too little knowledge about programming. :-) Part of what I mean by that is that the world does not need so much software in practice, and in the end, most programmers just end up making work for each other with incompatible standards, an endless variety of ad-hoc data formats, implementations of languages and applications that include "a half-implemented buggy version of Common Lisp" and so on (not to say Common Lisp is that great). How many accounting systems do we really need? How many word processors? How many programming languages? The software world might be much more stable and functional and secure if we had only 1% of the software developers we had now making the software that ran our world (the top 1% however we define that) given the difference in nature of software than bridges, that you can easily copy a good solution. Our competitive economy tends to prevent that though, where good solutions from long ago (Lisp, Smalltalk, Forth) get passed by for new proprietary solutions with a lot of marketing dollars behind them, and even those good solutions (like Smallta
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Most programs would fall under the 2nd clause but would now be sold as "for entertainment purposes only". Some might offer a version rated as suitable for purpose but it will cost 100x as much. Nobody will buy it.