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.'"
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.
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.
[ ] 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 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
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...
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.
Large software companies are now getting to a point where they would LOVE this. Current software companies has had 35+ years to build market share with EULAs that say that their products are not guaranteed usable for any particular purpose. The opportunity to change the rules now gives a huge advantage to current market leaders by creating an enormous, artificial, barrier to entry into the market. This would be the best way to kill the growth and competition in the software market. Look at all the other businesses that are encumbered with huge legal liability requirements and you will find business sectors that contain huge, multinational, 50-100 year old companies.
If a company wants to shop around and find a guarantee, fine. Requiring legal liabilty of all software vendors will just create another mess of goverment regulatory groups, certification boards and happy insurance salesmen.
Insert pithy comment here.