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.'"
not gonna happen its like asymtotical or something. you keep spending money developing and finding buys and keey going yet getting less returns out of it.
http://omgwtfmedia.blogspot.com/
Everyone knows that most free software, by virtue of peer review, has fewer bugs and errors than commercial code does.
No, I don't know that.
Would you mind telling me it's basis?
OSS software typically has fewer bugs because most OSS projects are so small in scope that it's possible to kill most bugs within the useful lifetime of the software.
The large OS software (Mozilla, Linux, OOo) that exists typically has as many bugs (or more, in the case of Firefox -- note all the exploits being released for it, now that it has market share) as it's commercial counterparts.
Where did I get that idea?
I pulled it out of my ass, just like you pulled that crap out of yours.
Lawyers and Judges would decide.
"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." As an IP attorney working in the industry for the last 14 years, this statement is just so....amazingly....stupid I would have thought the editors of the BBC would have caught it. It is wrong on so many levels. No non-on-the-ropes software developer will bet the company on error-free code. At the most, a developer will agree to correct errors. And MAYBE some limited liability for intentional errors.
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...
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.
You know that just because someone sticks the word "beta" next to a product, that doesn't actually remove any of the ethical or legal consequences for producing that product, right?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Of course, you'll then have to prove that the program generated proof is correct (because the proof generating program could be buggy as well). And if you do that with a proof checking program as well, you must prove that the proof checking program is correct. Not only at the source code level, but the actual running code on the actual machine (because it could be translated by a buggy compiler, or be running on a buggy processor).
The Tao of math: The numbers you can count are not the real numbers.