Slashdot Mirror
Taking On Software Liability - Again
An anonymous reader writes "You may remember an article in which a BBC correspondent wrote an article criticising current software licenses. In answer to the huge discussion that this brought about, he has written another article defending his views. From the article: 'It is possible to make error-free code, or at least to get a lot closer to it than we do at the moment, but it takes time and effort. Doing it will probably mean that commercially-available code is more expensive and cause major problems for free and open source software developers. But I still believe that the current situation is unsustainable, and that we should be working harder to improve the quality of the code out there.'"
I've got an idea. For non-software developers with great ideas. You program some piece of software for 5 years and then warranty against any bugs or failures. Oh btw, it must be priced competitively with current offerings. This guy can go wank himself in a corner somewhere. Perfect software doesn't exist. If you want something done right, your best bet is to do it internally to your company instead of outsourcing. Walmart is a perfect example. Do it right with people that feel they have ownership in the software they are creating and you'll get a better product. Plus, Arkansas (and my state too) are like Bangladesh anyway in the wages paid to software developers.
This guy sounds like he's just full of hot air because of a bad Norton AV installation. If one program causes something "devastating" to happen, who is to decide that it's not the user's fault, the compiler's fault, the programmer's fault, the OS creator's fault (and if it's OSS, who's package etc?), or the hardware's fault?
The computer world if full of many variables and I don't see this happening anytime soon, though with recent laws you never know.
$fortune
Tomorrow has been canceled due to lack of interest.
The fact is that the market has already decided the answer to this. People buy the least expensive software they can get away with. If the application is unreliable enough to regularly lose data it gets flushed out of the market. If it works well enough and is for the desktop it becomes popular. If it is used in critical applications where data loss is not tolerated they you have stuff like Oracle which people pay $50,000 per CPU for.
There is also a big difference between consumer software like word processors and web browsers, and the massive information systems used internally in large companies.
The companies writing the large systems usually have contracts which mean they are liable for damages, and this increases both the cost and the reliability of the resulting programs.
I must assume he doesn't work with internal apps much.
Snowden and Manning are heroes.
Everyone knows that most free software, by virtue of peer review, has fewer bugs and errors than commercial code does. If what he means is that you have to be licensed, bonded and "protected" by a corporate staff of 800 pound gorillas to write code, then free software will have problems. Such a missallocation of resources still won't buy him better code.
This whole issue is a troll the non free software companies come up with every few years. It's a mistake for them, however, and will blow up in their faces. Free software will overcome such nonsense the same way Good Samaritans do. Worse, what kind of society would outlaw exchanging of advice on how to do something? That's what sharing source code it. Why not outlaw engineering texts instead?
Friends don't help friends install M$ junk.
I've said this years ago: software liability should apply on programs you pay for but for which you don't get the source. If money you pay goes to make something you don't have source level control over then that implies the vendor thinks its of sufficient quality that you, the end user, should not have to fix it. If you get the source then there is no guarantee and the distributor should have no liability. This doesn't mean you have to have the right to re-distribute the source -- but you have to have the right to re-build it using commonly available tools so liability can't be limited to one "magic" libarary.
Bug free software is possible, so long as it is done right and people are prepared to pay for it. Right now, software is mainly "good enough" and "cheap enough". What is "good enough" and what is "cheap enough" will depend on what is being done.
Engineering is the art of compromise.
[ ] vendor guarantees that software works as advertised
could be another checkbox that all software companies are trying to reach.
"What? You don't guarantee works-as-advertised? Well, then I'm looking for a different product."
If computing magazines would update their testing methods and added this one checkbox, Microsoft just might say "oh, hey, we haven't covered that checkbox yet. We need to have every checkbox. Let's quickly drop by the legal department get this in order..."
The Lawyers will love it. They will launch massive class action law suites and will make millions. If you are part of that class action you will get one dollar.
The software vendors will not fix bugs because to fix them they have to admit they have them and will get the daylights sued out of them.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
The author has a point here. We accept a lot more ... "bugginess" in software than we do in any other product (Cars, Banks, Tools, etc.) And it's pretty much become the norm that if there are problems, folks just shrug, claim it's just software and move on.
But if the folks building bank vaults left as many holes in their products as software, people would be screaming bloody murder.
I've done software development as a hobby myself, and don't release my code to the public, because I know it's not even up to my own standards of stability, reliability, security.
Programmers/developers need to take more time with their products, and think security & reliability from the start of a project, not as an afterthought.
With as many products requiring patches within the first couple weeks of release, consumers do need to start getting angry about this stuff. Or, at the very least, start challenging software companies when the products they do release require more MB in patches than the software was originally....
-merlyn
Ah, so he wants people who right software to guarentee their work?
Things will then just never make it out of beta, for fear of the law. If the software breaks "Tough luck, it's still in beta, what were you doing using it for mission critical work anyway?"
This "eternal beta" is also used to avoid other sorts of legal wrangling . The most obvious example is Google News - it's "beta" still because google is worried about capitalizing on other people's news content. While unrelated to software quality, because it's an "unfinished beta", it doesn't get sued out of existance.
So, welcome to using software versons 0.9.9 forever... I can't wait.
However relatively bad the security of Microsoft's products are in comparison to what the free licensed and open source communities ( as well as practically every other vendor on the planet ) provide, Microsoft is not alone in the presence of vulnerabilities, this is a major issue for Linux/BSD and Unix as well as ever other OS and vendor.
From the Plimsoll Club history
The risks,issues and solutions for providing a more secure operating and application enviroment have been known for decades.
Those who do not already comprehend the issues and are willing to learn, should take some time out to listen to some of the speeches at Dr. Dobbs Journal's Technetcast security archives, starting with Meeting Future Security Challenges by Dr. Blaine Burnham, Director, Georgia Tech Information Security Center (GTISC) and previously with the National Security Agency (NSA)
The design and implementation of some applications and servers are just too unsafe to use in the "open ocean" of the internet.
Numerous security experts have railed against Microsoft's lack of security, best summed up by Bruce Schneier Founder and CTO Counterpane Internet Security, Inc who rightly said:
However Microsoft's products are not alone in the presence of vulnerabilities, this is a major issue for Linux/BSD and Unix as well as any other OS and vendor.
In a recent speech "Fixing Network Security by Hacking the Business Climate", also now on Technetcast, Bruce Schneier claimed that for change to occur the software industry must become libel for damages from "unsecure" software
Dan Bernstein has offered a guarantee for many years that djbdns and qmail are secure. Now, this is a rather vague guarantee, since the task of deciding if a reported problem is a security flaw lies with Dan Bernstein himself; but it's a start.
I'm currently writing some cryptographic code, and I intend to go considerably further: I intend to offer a guarantee not only that my code operates as specified, but also that it is not vulnerable to any side channel attacks within certain classes.
As the time-to-exploit of security flaws continually decreases, I see only one solution: Writing code which is correct in the first place. If you can do that, you can offer a guarantee. And hopefully once security becomes as larger issue to consumers, people will start looking for guarantees.
Tarsnap: Online backups for the truly paranoid
Making bug-free software is much harder than anyone can imagine.
Let us not forget the very modest program IEFBR14 - arguably the shortest
program ever written for use in a production environment. It ran on IBM's
System/360. (I rans it many times myself.) Its sole function was to
exit - nothing else. It was a whopping one machine instruction long - 2
bytes. It was even Open Source (BR14 is the assembly language version of
the instruction, which is the standard way programs exited). It was the
simplest possible program that one could write. If ever there was a
program that was going to be bug-free this was it!
It had a bug.
When a program exits on OS/360, it is expected to have set some bits to
indicate any errors. When a program is called, those bits are in an
unpredictable state. IEFBR14 had to be modified (doubling its length) to
clear the bits first.
Sigh...
When I ran Autopr0n, hooo... that code was awful. But there really was never any kind of economic incentive to fix it, I could just keep restarting my JVM (the thing was coded in java).
Or, look at metafilter.com. That site goes down like a $2 hooker, yet it's so successful that the maintainer was able to quit his day job and support himself based on the site. People don't care.
Even when you get to a desktop OS back in the '90s, quality just wasn't that important. Would you rather pay $10,000 for an OS, or $90 and loose work once in a while.
If the cost of the lost work due to software errors is less then the cost of writing the code so that it works perfectly, then it's not worth doing. Sure, for some programmers there's not a tradeoff, but those programmers probably cost a lot more to pay then 90% of the coders out there (who are idiots, IMO, just look at the existence and popularity of Visual Basic).
When the cost of the error increases, you'll find much more stable software (like on medical equipment, airplanes, and so on).
The secretaries spreadsheet just ain't mission critical.
Of course, now that all computers are connected together, they need to be at least secure and not targets for worms and trogens, etc. I predict that we move towards web services, the software quality will get worse and worse, but people will just pay a sysadmin to sit there and reboot the machine whenever it goes down, so people won't notice everything...
autopr0n is like, down and stuff.
Truly error free is not a likely state for software.
http://www.rootstrikers.org/
And you get modded down. Genius.
Seriously here people, most free software is complete tripe. The popular projects you hear about, Linux, Firefox, etc. are just a small fraction of what's out there. Peer review only works if people are interested in your project.
Open source tends to be written by/for people who care more about stability than features, and that's a major help, but it is not miraculously better. How many people here have actually sat down, and looked over the source of an open source project to check for bugs/exploits?
First off, I should issue a disclaimer that I'm an oldbie. I started programming in assembly language on punch cards, but no, this isn't going to be a rant about youngsters and their newfangled languages. (At least it better not be; my current job has me living, breathing, and eating PHP.)
The problem with bad software today -- just like it was thirty years ago -- is bad engineering. It's not because of the methodology du jour (or its absence), licensing, choice of language, or toolsets. You can write brilliant, bug-free, efficient software in COBOL using the basic procedural structured programming paradigm. You can write awful, buggy, resource-hungry software in object-oriented Java using XP. None of that shit matters.
Good engineering requires, among other things, a detailed understanding of the problem, thorough planning, the sheer experience required to distinguish between the clever and overcomplicated on one hand, and the lucid and elegant on the other, excellent communication between developers, foresight (also borne of experience), and rigorous debugging. All of these things, including the many other prerequisites not mentioned, require lots of time and effort. Too much time and effort, in fact, for most commercial software outfits to invest and still turn a profit.
That's the rub, really. All the methodology and language fads aside, the basic principles of good software engineering were worked out decades ago, and sometimes further -- good generic engineering practices in the abstract were worked out long before we harnessed electricity. It all comes down to this: the more time, effort, and care you put into a product, all other things being equal, the better the product will be. It's easy (and well-deserved) to mock Microsoft for the shoddiness of their major products, but that very shoddiness is why you can buy MS Word for less than ten grand. If MS built word processors the way engineers built the Golden Gate Bridge, the prices would be comparable.
The market does not reward that kind of quality. In the first place, no one is willing to pay thousands of dollars for a supremely excellent product when one that is good enough can be had for a couple hundred. Most folks couldn't afford that kind of software engineering even if they wanted it. In the second place, once you have the perfect all-in-one software package, why would you ever buy another one? Microsoft is in this position already with its good-enough products. No one needs an upgrade, so remaining profitable requires MS to churn out new versions of its increasingly resource-intensive operating system so that you at least have to buy new copies as you replace your older machines.
FOSS is at least theoretically invulnerable to these pressures. In theory, there will eventually be all-singing all-dancing FOSS packages covering all of the major software categories, and the age of commercial mass-market software will be at an end. I've been waiting for this day to come since well before the first release of Linux. I'm surprised that it hasn't come yet. I'm surprised that the majority of FOSS software is still as buggy, poorly designed, and -- almost without exception -- undocumented as its commercial equivalents.
I suppose I shouldn't be surprised. Excellence in software engineering is like excellence in any other field: it's really fucking hard. It's even harder when you have a day job; time constraints aside, after 8-12 hours coding at work, the last thing many developers want to look at when they get home is compiler output. Many of the remainder are either amateurs or students -- not to diss either category, but often the necessary experience is lacking, and the lone hacker often lacks the knowledge or the inclination to produce code that's easy for other developers to work with. I remain confident that we'll get there, though. (I am less confident that I will still care by then, but it will still be a boon to those who live to see that day.) I am equally certain, for the reasons
Proud member of the Weirdo-American community.
You mistakenly assume that just because someone is given the source code, they are capable of understanding it and making fixes. If your refrigerator manufacturer gives you the blue prints to the frig, does that mean they aren't liable if something goes wrong? Software shouldn't be treated any different than any other product. If there is a safety issue, then the manufacturer should be required to provide a fix. Source code or not shouldn't have any effect.
In the same vein, instead of trying to make every part of the code perfect, how about designing some redundancy into the code?
I leave it as an exercise for the reader to figure out what the hell that means.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
people demand that it sucks.
Seriously. For nearly every case, if there are two available pieces of software (OSS or not), most people will choose the one that is more feature rich. Sure, those in a mission critical situation or the poor people that get to install and support the software long-term will demand quality and maintainability. But, those people are far outnumbered by the masses that use software casually.
So, given a limited set of resources, quality will always be just barely up to what people will tolerate. Yes, even in open source software. Example: Mozilla Thunderbird -- They have a feature schedule out right now. About half of the planned features are in the current build. Do you think they'll wait until the code is 99.99999% error free in all situations before comitting time to add features? They have no deadlines, no financial burdens, no one telling them to ship the software. Yet, they will ship it. If they don't, their user base will entirely desert them and switch to a horrible, buggy, alternative (probably Outlook Express). This is simply because people demand cool crap. That's why they buy half the crap they buy, that's why the US has a $250 billion trade deficit with China. We collectively love crap.
Sure, let's have liability. The software must perform substantially as advertised - counting all advertisements, press releases, interviews given by publisher's officers, etc.. But make the amount of damages simply equal the price paid.
This would keep free-as-in-beer software in the clear. It would also have the side benefit of forcing Microsoft to reveal its OEM prices. :D
I like the source code as condition of immunity suggestion above too, but it would be futile without a licence like those the FSF approves, which would actually allow you to fix problems without violating copyrights and patents.
You realize what you said is true, circular and bad news for commercial software, don't you?
What you call "tripe" is what the author wanted to get done and what no commercial software vendor would provide. Score one for free software - meeting user needs.
The "popular" projects do indeed rock and will be better than anything commercial because no firm can match the development effort. Look at the gnu debugger. The last time I checked it had more than 87 authors. Show me a commercial debugger that gets that much attention. That's just one of the thousands of gnu projects that make free software actually work. Score two for free software - in the end, what needs to get done gets done better.
Finally, you are half right about peer review only working on projects that other people care about. If you can't find a single other person in the world interested in your project you have a rare project indeed and won't find any help. Most people are not so original and will usually find dozens of projects that do something very close to what they want to do. So far, so good, where did you go wrong? When you turned a blind eye to the most popular non free software getting no such help at all. For all your customers can tell it was written by a lone monkey paid in bananas who was forbidden contact with the rest of the world. Final score - free software 3, commercial software zero.
This message composed and transmitted on a system run with complete tripe that just happens to have more features and run much better than any commercial software available.
Friends don't help friends install M$ junk.
I thought about this the other day, asking myself why we can't have the same approach in software development as bridge building, or other engineering disciplines. The difference seems to be that of prototypes. When you build a bridge you create a prototype, test it as much as possible, tweak it where necessary and let the cycle continue until there is a working solution. Once that is done you are ready to build the bridge, based on specifications that in a certain sense are easier to follow than what software does.
Look at software and ask yourself where that prototype is, that can tweaked reworked until all obvious and so obvious issues have been tested for? You will end up noticing that the prototype and the final product is the same thing. While a bridge can be tested based on a number of complex mathematical formula, I am not so sure that software can be tested in the same way. Software is designed and developed based on a number of philosophies and sometimes these even have to interface with other programs based on other philosophies. Over time the complexity grows to a point where testing it 100% is like trying to predict what the stock market is going to do next week. I would like to give a figure to what we are able to predict, but that I will leave that for someone else, since I am not sure I am qualified to do so.
At the same time I will say that there are a good number of things for which you can create unit tests for and these help avoid the most obvious issues. The non-obvious issues, based on difficult to reproduce scenarios, variable dependencies are a little trickier.
Things are also improving thanks to libraries that implement much in the way of reusable code, but here too there is an issue. Imagine that you designed your program to be dependent on libraries x, y and z, and then the user adds libraries that effect the libraries you depend on, how can you predict what is going to happen?
You will notice that most mission critical systems are designed to have only the most essential features (as compared to desktop software) and are often coded with very precise memory management and sometimes even avoid the pointer type and instead using only primitives. Trying to develop most applications this way would be long and laborious and your users would be complaining that his complex office software doesn't do what (s)he wants (remember they can't agree on what they want), even if it is 99.999% stable.
I am not saying it is impossible, its just that I have yet to see an approach that is 100% effective and for 100% of cases. Yes I am a software developer, so I do have a certain bias.
Jumpstart the tartan drive.
I agree, to an extent. It makes no economic sense to shoot for as perfect-as-possible for all software. The reason we have minimum standards for other industries, such as as automobiles, is because a defect in an automobile can kill people.
But what we have today is practically anarchy. There's no way of telling if a product will work properly, or will work at all, and software vendors are allowed to get away with that.
A middle ground here might be forced labeling. Require software vendors to place a label that, in a standard fashion, describes how safe the software is, whether it is guaranteed to work as labeled and advertised, and maybe something about the known defects it has, or estimated failure rate. Don't let the vendor hide this in the fine print. And then hold them to it with legal measures.
That way, if a piece of software is targeted for home use, the labeling should make it clear that it's going to have significant defects, and will fail at a high rate. You might have a more expensive variant for office use, with fewer defects. And then you might have a stripped down, very expensive version intended for critical applications, in hospitals or infrastructure. The end user can then choose which one they want to buy, and instead of feeding a market where the customer buys the cheapest product because they think all products are buggy, they can buy the product that meets their needs, with the assurance that they will have legal recourse if the product fails to meet the expectations indicated by labeling.
The hugeass elephant in the room here is that for centuries builders have been relying on reusable components and clear standards, while massive numbers of programmers shun these despite their availability, and constantly reinvent the wheel. I'm looking directly at every dink on Slashdot that bitches XML is too complicated and trashes (ha!) on automatic garbage collection. (if someone has some obscure exception, keep it to yourself. The exception isn't the rule.)
Another difference is, typically if an engineer says something is unsafe, people actually fucking listen to her.
Oh yeah, and you can't hide how a bridge works. Proprietary code encourages cut corners.
I believe that good software is attainable. But that won't necessarily come from legislation, it'll come from the industry growing up.
Computer software has been mostly unregulated. This has allowed us to watch the "invisible hand" of the market in its purest form. Commodity programs have disclaimers, buy bespoke and you get guarantees, pay yet more and you get formally certified code. The cost of risk and the cost of the program are in effect two seperate purchases - product and insurance.
If you force programmers to carry the risk cost, you don't magically get bugfree code. You just delete the no-guarantees market. In effect you're forcing programmers to bundle insurance with every installation. "Free" disappears. "Libre" might survive in an attenuated form - edit "open source" and you become the liability carrier. You might do it in house, but few could afford to publish.
The guy points out that other industry sectors have this sort of law. Yup, they do, and I contend we're all worse off as a result. Amateurs are frozen out, because they can't afford to jump insurance hoops. Innovations are stifled. Saleable skills are wasted. Personal self-expression is denied. Even though all parties are willing, the law stands in between saying "no". This is nothing to emulate!
Nanny liberals would contend they are protecting buyers from risk. As an adult you have to accept that the universe has dangers. You can't wish it safe, and the utopia of your childhood was an illusion. Who then is best placed to decide when you should gamble and when hedge? Philosophically, no action can be said to be "better" or "worse" without a reference to a person whose goals it serves or thwarts. No person can know another's mind. Therefore, you alone are properly placed to weigh the options and decide on your own behalf. At best a law commands you to take your best choice. At worst, bans it. Neutral or harmful, and (given diversity) certain to be harmful to some. This is why regulation is never better than a free market, even in risk.
My car is way buggier than my software. My car is horrible at dealing with unexpected siutations and abuse. If someone attacks it, say by breaking a window, the window is broken and I have to pay to have it fixed. With software, I get mad and demand that they should fix the bug so the attack CAN'T break it. Likewise the car is not forgiging to unexpected operation. If I floor the gas in neutral, the engine will seize up. However I expect that software can deal with unexpected input and not have any ill effects. Also my car costs money for matenance. I have to regularly pay for things like oil to keep it working, however software I expect updates at no charge.
So all in all it seems I expect MORE out of my software than my car.
They are different things, you really can't compare them.