Would Vendor Liability for Bugs Kill OSS? 377
Glyn Moody writes "Bruce Schneier has written an interesting column for Wired suggesting that vendors should be made liable for bugs in their software. But where would this leave open source developers? Would what seems like a great idea actually be the death of free software?"
No, if... (Score:5, Insightful)
Re:No, if... (Score:3)
Re:No, if... (Score:4, Insightful)
How about products like MySQL which are often sold in installations with support contracts?
But the submitter kind of misses the point of Schneier's rant... he ends with the story of the italian anti-tax-fraud law. The question is not "will software liability kill OSS?" but rather "How do we align the interest of commercial software companies to ensure the security of their products?"
I think implicit in what Schneier says is that simply mandating that software authors be liable for their products isn't going to work, because it will be an inconvenience for those that don't make enough off their products to take that risk, and will cause price increases on commercial software. It's a good point, coming from someone who has rather simply favored such policy in the past, but I don't think he goes far enough in exploring exactly how we ought to go about it.
Re:No, if... (Score:2)
Why not ? Sell shit, be forced to pay back the price, even if it wasn't your shit in the first place - you still sold it.
Re:No, if... (Score:2, Insightful)
Re:No, if... (Score:3, Funny)
Oh don't worry, I will help myself.
Re:No, if... (Score:3, Informative)
As far as I am aware - they are selling the media, not the software.
MySQL, on the other hand, is selling a commercial license to the software, so yes, they would be liable.
Re:No, if... (Score:4, Interesting)
If you are simply "Licensing" the software and not "Selling" it (IE: If you are trying to control what happens to the software after it leaves the store shelf, by preventing copying or redistribution or modification) then you should be liable.
When a company chooses to no longer be liable for bugfixes and the like, the product should be made "Free" so that you can make copies and modifications yourself (as it should if the company chooses to stop selling it). Not that I expect users would fix all these bugs, but at least it would give us a chance!
As is, if they find some security hole in windows '95 or '98 that is truly critical and MS chooses not to fix it, you may be out a computer (assuming your are ignorant of Linux anyway)--let's say your computer will no longer serve the purpose you paid the money for it to serve.
Of course since laws in the US are being purchased by corporations, I don't expect this "Logic" to fly in any future I can imagine, but I can always dream.
Re:No, if... (Score:2)
Re:No, if... (Score:2)
Comment removed (Score:5, Interesting)
Re:You can add a multiply factor... (Score:4, Interesting)
This is getting way too complex. By mandating that software publishers are liable, you actually have to prevent people from entering contracts that limit liability. And if you start mandating bug fix windows, chaos will ensue. Vendors would just release "patches" that eliminate huge chunks of code to "fix" the bug and then nobody would download it.
Re:You can add a multiply factor... (Score:5, Insightful)
Here's a better idea, then:
Under such a scheme, open source/free/libre software would have zero liability (as it should be) because the customer would have access to the source code, and therefore would be able to (assuming sufficient skill) fix it themselves (or get someone to fix it for them). Closed source software would be liable unless there was a satisfactory workaround or the company could prove that they made a fix available within a timely manner of the bug being reported.
The logic is this: most bugs do not take years or even days to track down. Most bugs can be fixed in minutes. Most companies want to do a full bake cycle on fixes to make sure they don't break anything else. This sort of law would simply require that they make the interim build available to the person running into the bug so that they can get past it. It would also require that bugs continue to be repaired after a product is replaced with a newer version.
This protects against liability for unknown bugs, but sets limits on how long a company can drag their heels at fixing frequently-seen bugs, provides the customer a way out for obscure bugs that only three people in the world care about, and prevents abuses like companies abandoning products with major known bugs or requiring customers to pay for the next version to get critical bug fixes.
Re:You can add a multiply factor... (Score:3, Insightful)
The logic is this: most bugs do not take years or even days to track down. Most bugs can be fixed in minutes
And all those bugs have already been fixed. Those which are left are those which are hard to track down, require substantial code rewrites to be fixed, or are seen as harmless by the software creator.
Go to any larger project and search their bug database and you will find hundreds if not thousands of open bugs.
Re:You can add a multiply factor... (Score:4, Interesting)
If automobiles were gratis, you might have a point. If open source software were used in safety-critical systems, you might have a point. With neither of these being typically true, you don't really have a point.
If you build your business on a piece of software, it is your responsibility to protect your investment. It is your responsibility as a consumer to protect your investment as well. Losses due to the user failing to back up are the user's fault.
What is not acceptable is the existence of bugs that prevent you from doing something for an extended period of time. What is not acceptable is the existence of reported security holes that are easily exploited that go unpatched for months or years.
Oh, yeah. A few more bullet points:
Re:No, if... (Score:2)
Re:No, if... (Score:3, Interesting)
In a certain way software which includes free patches and rebates on upgrades is already of the mentioned type
Re:No, if... (Score:2)
Re:No, if... (Score:4, Insightful)
When, as a society, did we get the idea that when bad things happen to us somebody else should pick up the tab?
This isn't about punishment, vengence, or reparation, it's about discouraging something bad.
Re:No, if... (Score:3, Insightful)
If McDonald's negligently feeds you a poisoned hamburger, should their damages be limited to the $4.15 you payed for your Big Mac Meal?
Re:No, if... (Score:3, Insightful)
"The purpose of this software is to occupy 252 GB of disk space. Use as a word processor, spreadsheet or database is outside the intended use of this product and is not supported and Microsoft will in no way, shape or form be liable for any defects resulting from such use."
Compare that to the existing legalese on a box of cotton swabs: "not for use in ear canal"
I wouldn't. (Score:4, Interesting)
Re:I wouldn't. (Score:2, Interesting)
Or are you just mad because people are smarter than you and exploit the holes in your software you created?
Personally, I think companies should be held liable for bugs in their programs. PC Games would be in dire trouble if this occured.
paragraph by paragraph (Score:2)
Re:I wouldn't. (Score:2)
No one writes entirely bug free code all of the time. Working with a group means that your code is open to someone else's bugs. Sometimes declaring who is responsible for a bug is not obvious, especially if you were to bring up a lawsuit. Personally, I think companies should be held liable for bugs in their programs.
So what happens if the bug is in a library you are linking to? How about if you are
Re:I wouldn't. (Score:2)
Well, dipshit is poorly defined, according to ask.com:
dipshit (dp'sht') pronunciation Vulgar Slang.
n.
A foolish or contemptible person.
I'd assume the grandparent was going with the 'contemptible' definition (which is actually the definition I would have thought of as my best guess). A person can be reasonably smart, competent, able to create code exploits, and a jerk. In fact, to do so obviously requires that you be a jerk.
Re:I wouldn't. (Score:3, Insightful)
Lawsuits are lottery tickets that are ruining society and nothing more.
If a customer needs something that absolutely positively can not crash they could purchase a package(twice as much as a comparable one) and specify it in a contract to not crash. Infact such software companies exist and use strict methodolies and languages like lisp with real computer science graduate
TCO, purchase versus operation! (Score:2)
Why wouldn't they? If you could offer me a car that will make it 200,000kms without having problems or needing more than an oil change, would it be worth 80k instead of 55k? Possibly! Personally as a person who's time is valuable, I'd pay more for quality. Why is
And people don't want to deal with restrictions (Score:3, Insightful)
Now it makes sense, you cannot predict the interactions between
Re:Getting Away with Murder (Score:3, Insightful)
Would Vendor Liability for Bugs Kill Microsoft? (Score:5, Funny)
Re:Would Vendor Liability for Bugs Kill Microsoft? (Score:2)
Dont give me the argument that I could work for a corporation devloping inhouse apps? With all the now fired developers competing with me and the Indians for jobs my wages would be barely above minimal wage as everyone would be desperate to work,
Last its more expensive to design everything in house than to buy proprietary and custom
If you want vendors to be liable for bugs (Score:2)
Vendor Liability should == purchase price (Score:2, Insightful)
If I paid $$$$$ and it's broken, I get really upset. If I paid $0, and it's broken, I accept that it's my responsibleity to bring it from being wirth $0 to worth something.
Re:Vendor Liability should == purchase price (Score:2)
Now you find a bug in the software. Currently you would report it to the developer, and hopefully the bug would be fixed in the next patch. All would be well.
But here you want your money back... and the SolidCAD people then tell you "Ok, we give you your money back - but you give us back the software and the protection
Software with no bugs? (Score:5, Insightful)
Not even close (Score:3, Informative)
No way. There are far more of us who develop custom in-house software than people who write stuff that gets sold. You might severely hurt the software-as-a-product industry, but wouldn't touch the software-as-office-automation economy.
Re:Software with no bugs? (Score:2, Insightful)
Let's calculate:
money back for purchase price: $0
court costs: $5000
attorney's fees: $500000
punitive damages: $7 million (because it made me spill my coffee)
Total result: Software industry ends. Lawyers buy yachts.
Re:Software with no bugs? (Score:3, Insightful)
My main argument against this is that no human, not even a team of humans, is perfect. Bugs happen, even in production environ
Re:Software with no bugs? (Score:2)
Yes that would explain why Oracle is such a cheap product. Sarcasm aside, software producers don't limit their liability, they say that they have no liability for any flaws in their product. I'm having trouble thinking of another industry that would get away with that for the length of time that the software industry has.
Regulation hurts the small players (Score:5, Insightful)
Re:Regulation hurts the small players (Score:2)
Lets face it, there isn't that many people around who make bug free code in the first go. Granted it is possible, theres even certain language where you can proove the correctness of your program, but still...
Ohh and who gets to say if it's a bug or a feature? And how do you distinguish between what _your_ program caused and what the hell the client PC was infected with?
What terrible reasoning (Score:3, Funny)
The only interesting part is the anecdotes (Score:5, Insightful)
The simple fact is that this is too hard to police anyway. Where did the bug occur? Was it in the program, or some library it called? Now we have to establish whether the programmer could reasonably have known there was a security update to the linked library. Just proving where the fault occurred would be a huge legal SNAFU. Sure, such a thing would kill OSS first but it would effectively destroy the computing world. Only a luddite could seriously believe that this is a good idea.
The only proper way to handle this is through contract - not an implied one, but an explicit document which clearly describes the areas and extent of liability. There is a market for this kind of software, and it exists already. This is the only reasonable solution - get a contract, and if you don't, caveat emptor.
Re:The only interesting part is the anecdotes (Score:2)
Sendmail authors, beware!
Re:The only interesting part is the anecdotes (Score:2)
Re:The only interesting part is the anecdotes (Score:2)
solutions to already solved problems. Most new software is solving new problems,
not old problems. I agree that there is value in knowing the classics, but knowing
the classics says nothing about your ability to solve new problems.
Re:The only interesting part is the anecdotes (Score:3, Insightful)
Certifications are to determine that you are rigorous and methodical in your discipline, not to measure your creative problem solving skills.
How does proving that you do follow well-established engineering methodologies and procedures, including exacting standards, stop you from solving "new problems".
THe only thing it would stop is high-schoolers or college flunkies from calling themselves "software engineers".
And, maybe it would get some respectability into the software engineering pro
What a content free story... (Score:5, Insightful)
Here's a tip, Mr. Schneier: analogies can be good for illustrating a point, but going on for 2 pages about your anaology without actually using it to make a point is just dumb.
My guess, since the story was posted at 2AM, is that he had a deadline to meet and wrote this piece of crap in 15 minutes while drunk.
Re:What a content free story... (Score:4, Funny)
Vendor Liability (Score:3, Insightful)
I have a little more faith in OSS than that! (Score:2)
And hypothetically, hell DID actually freeze over with flying pigs, then I would still assert that I don't believe it would be the end of OSS. Not by a long shot.
RedHat comes to mind. They have their Enterprise offering that is anything but cutting edge. Everything is tested quite well and the response to fixes is rather rapid. I do
I'll believe it.... (Score:3, Insightful)
I don't think there's been a single issue which has come up with the gov't where they've agreed to some type of compromise, only to return to their prior behavior within a fairly short period of time (and the gov't hasn't yanked their leash to bring them back to the table).
I'm not anti-Microsoft. They've been a good source of income for a long period of time.
But facts are facts.
Until then, this is factors beyond a pipe dream.
This is a non-issue. (Score:2)
Failing that, if a peice of code is developed FSF/OSF style, exactly who do you sue for redress if a bug causes you fiduciary loss? The author? Go prove that his code is actually the source of the bug.
"That's not a bug, that's a feature" - isn't that Microsoft's mantra?
Re:This is a non-issue. (Score:2)
Sure, but they're not worth the paper they're printed on if the law says they're unenforceable.
Sometimes industries collectively act against the best interests of the public, and regulation is required to prevent this. Under those circumstances, it's quite normal to legislate that the industry may not enforce certain one-sided contractual terms. The whole idea of monopoly abuse and antitrust legislation is one big examp
It depends (Score:3, Insightful)
But does the coverage make any distinction between a game-ending bug and a conceptual bug? By this I mean bugs that cause the program to perform differently than the program was being marked as and bugs that are only causes by deliberate/incredibly unique settings/actions? The first should be held as legit bugs while the latter seems hard to argue for. If the bug only expresses itself when you setup a special case that is never seen in the real world, is it really a bug? After all, ALL computer programs have bugs, even the simplest of programs. Even Hello, World! (which almost always depends on system libraries to display, and as such inherit any bugs that they contain).
The simple answer to this is to allow for software to be given away on a "no liability" way. FOSS could be allowed to exist since those that are creating the software are not making money to how many copies they "sell". Those that produce software for a living, like MS, would still be held accountable for their products. But then, IE would not be covered since it is "given away".
There probably is no simple answer to this. Either allow things like FOSS to exist and limit the liability that all software producers have, or open them up to real liability and kill FOSS.
what if? (Score:3, Insightful)
How do you know vendor X wont come after you to pay for their court costs?
Also businesses would purchase liability insurance. Mabye their agreement with the insurance company is to sue others and use that money to help pay the insurance company so they can maximumize profit by minimizing losses when they got to court.
Also many vendors would go out of business and if y
What If Based On .... (Score:4, Interesting)
The prices are for the full product. Upgrade editions count as the full product for liability
something similar can be sorted out for large installations, bulk licenses, etc.
Just thinking out loud
Re:What If Based On .... (Score:2)
How about making this a touch simpler... Basing the liability limit as a multiplication factor of the purchase price of the software - something like 10x purchase price. If you paid $0 for the software, then 10 x $0.00 is still $0.00. Now, if you paid $139 for an oem license of WinXP, then the liability would be $1,390. Seems fair to me...
Re:What If Based On .... (Score:2)
"Substantial?" Hardly. Even if the software maker was paying out a $1000 fine once a week, that only comes to $52,000 per year. If it costs them $75,000 per year to hire someone competent enough to keep their software working reliably, guess what course of action they'll take?
"More than $10,000" for faulty software in the NATIONAL SECURITY arena? Are you freaking insane? Even $100,000 is less than a single executive
offer a refund for FOSS.... (Score:2)
It could help OSS software... (Score:2, Interesting)
But since legal liability tends to chase those with the deepest pockets, I can see where the commercial closed source software vendor would face the greatest exposure to expensive litigation from "bug liability". Distributed development pro
Easy Solution... (Score:4, Funny)
Are bugs even mentioned in TFA? (Score:3, Informative)
GPL, warranty (Score:2)
Better Idea (Score:2)
That depends (Score:2)
Where is the Vendor? (Score:2)
Charging for support of a free product would be a little trickier if a change that you advised caused a problem, but most companies providing support probably indemnify themselves against that kind of thing an
Re:Where is the Vendor? (Score:2)
As for the article, I manage an open source product used only by business users. These would be the most likely to sue under any vendor liabiliy laws as they have the lawyers and the deep pockets. Personally, I would not take the risk of
Re:Where is the Vendor? (Score:2)
1. You're only liable when money changes hands. Liability covers "sales"; period.
2. You're only liable for binary distribution, not source. Contributing to the Linux kernel doesn't make you liable.
3. Minimum levels of damage per incident. A floor of $10,000; Jane Doe is going to have a hell of a time proving you did $10,000 of damage to her Windows install.
4. Work for hire puts liability on the intellectual property holder, not the creator.
5. Buy some insurance! If you're making mone
Killing OSS Softly... (Score:2)
1) OSS coders would be responsible for their code, and if a security bug was found that, oh, caused some big disclosure of personal information under some law like HIPAA, then the coders could/would be sued by a corporation that ran the software. Thus, coders would NOT contribute to OSS, thus killing OSS.
or
2) OSS software would be exempt from such a rule, meaning that implementation of OSS software by a company would mean it would become liable for it's misus
Re:Killing OSS Softly... (Score:2)
If someone downloads your software, under say, a public domain license, and then proceeds to misuse it. You're not liable for a dime because you never agreed to warrant the software.
There are many parts to civil liability law [in Canada and elsewhere I imagine] but the jist of it is you have to be responsible for the damages. If you give out free software as p
Paradigm Confusion ... (Score:2)
Everything would be exactly as it should be in the proposed model. Microsoft sells you their garbage and it no longer pays. If Red Hat advises running 'rm -Rf
cameras (Score:2)
OSS Agreement (Score:2)
Re:OSS Agreement (Score:2)
This is because the UCITA excludes software from most forms of liability.
Which is bullshit; you buy it like anything else. Why shouldn't you have recourse if you buy something worthless?
I'm legally protected if I buy a car that's a lemon. If I buy software that's a lemon, I can't return it once I open it. That's outrageous. I bought a game published by an Interplay Company (FatCat software, IIRC). It never worked. Not once.
Re:OSS Agreement (Score:2)
Yes it sucks, and yes there should [and is] a remedy. But often it's just buyer beware. Now for things like MSFT the bigger complaint is that XP and the like aren't exactly "new". So why are we finding flaws that stem from the Win95 code base all the way into this century?
The problem with software is manyfold but mostly can be summed up with two statements.
1. incompetent "developers" [aka scriptmonkeys]
2
Working Software Liability (Score:2)
1. It only applies to distribution of binaries. Not source. Contributing a patch to Darwin's Kernel != makes you liable for Apple's sales. On the other hand, even though Linux is open source, if you distribute a binary kernel, you may potentially be liable.
2. It only applies in cases where money changes hands. No free distribution. You don't want non-profits forced into paying for insurance for freely distributed products. Besides;
The "Sony rootkit" was "free software"... (Score:2)
Just an observation.
Free software (Score:2)
God-awful submission! (Score:5, Informative)
Near the end, Bruce mentions the concept of "software liability" as an example of how interest can be aligned with capability. Bad on Bruce for not defining how he uses the term, but bad on the submitter for not researching it before sending in this FUD. Anyone who has followed what Bruce has done knows that he's a huge supporter of OSS.
When Bruce talks about software liability, he's talking about making software makers liable for their marketing claims about security, not for "bugs found in software". OSS would be safe, as long as those project don't say "we're secure" when they aren't.
And on this point, I agree: if I buy a security product that claims "secure file storage", and I find out that they implement this single-DES encryption -- and espeicially if my data is compromised as a result -- the vendor should be liable. They made a false claim!
Re:God-awful submission! (Score:4, Insightful)
Making a false claim is already actionable - it's called fraud. No additional regulations are required.
Nope. But it might hurt the OS companies (Score:2)
When I give it away, or better, throw it away for someone to pick it up and do "what he wants" (GPL nitpickers read that quotation marks right!) with it, I take no responsibility. Use it or don't. I didn't say you should use it. I didn't sell it to you. In fact, I just put it there so people who want to take a look can. I'm not saying it does anything useful. I'm not even saying it doesn't do anything harmful. All I say is that it
The responsibility to fix bugs should be based on (Score:3, Interesting)
If the responsibility of upkeep becomes too much, a vendor can always abandon the software.
Microsoft can't be expected to fix windows '95 bugs forever, but on the other hand, people have paid for a working product that they should expect to be able to use forever. Seems to make sense to me that when they abandon upkeep, they should lose the responsibility over that product as well as the ownership, it becomes public.
A law making it so could replace much of the copyright law system. We could use the same concept with products, music and books, once they are out of production, out of print or unatainable by commercial means, they lose their exclusive license to the product and anyone can distribute it.
Getting Ridiculous (Score:5, Insightful)
How did we get to this state of affairs?
Whether or not a software vendor should be held liable for bugs in their software depends on what they promised to the customer. They should be held liable for no more and no less than that. It's the same as with a vendor of any product, not just software products.
If you go to solutions provider X, and hand them a list of your requirements, and they agree to provide a solution that satisfies those requirements, and you both sign a contract that embodies that agreement, then of course they should be held liable if they fail to meet their burden under the terms of the contract.
If you buy a box of software from Vendor Y that says that its purpose is to enable you to write letters to your grandma, that is an implicit contract, since you are exchanging your money for the product's functionality. Depending on where you live, you might have legal recourse, if the product fails to live up to its stated purpose.
The obvious escape from this, which all software vendors take, is to not state that the software enables you to do anything specific, and to explicitly disclaim fitness of use, for any purpose, in the software EULA. They can then say that the name "Grandma Writer(tm)" was merely meant to convey that the product is so easy to use, that even your grandma could use it, and not that it is guaranteed to facilitate communications between you and your grandma.
So, for example, if you download gcc and your airplane crashes because gcc generated incorrect code for your embedded processor, then you're shit out of luck if you want to sue the core gcc dev team. The license agreement for gcc explicitly states that the software is not guaranteed for any purpose whatsoever, so use it at your own risk. By accepting the licence, you shoulder the responsibility for any damage that results from your use of the software.
In the case of the Vendor Y, the EULA is to cover the vendor's ass, so they can make some profit, instead of spending all their time and money in court. In the case of gcc, the license is to cover the developers' collective ass, so they can continue to develop gcc, instead of spending all their time and money in court.
Vendors: Do what you promised you were going to do. You have a contract with the user. Live up to it. But don't expect users to rush to buy your product if you don't actually promise that it will do anything.
Users: Vendors are responsible only for what they agree to be responsible for. If you need the software to do more than that, then renegotiate your contract, certify it yourself, or get a third party to certify it. The vendor is passing the buck, and it's up to you to either walk away, pass it on or accept the responsibility. You are the solutions provider here. You have to decide who's going to be first against the wall when the revolution comes.
FOSS and small commercial devs would be hurt (Score:3, Informative)
And as I said in another post, large commercial vendors would survive, as they'd simply buy software liability insurance (ala medical malpractice insurance). Smaller vendors would be hurt if they couldn't afford such insurance.
So FOSS is hurt (corps won't use it because FOSS "vendors" can't be held liable for bugs), small commercial vendors are hurt (since they can't afford software liability insurance), and large commercial vendors thrive since FOSS and small vendors are eliminated.
On the flip side... (Score:3, Insightful)
What goes around, comes around (Score:3, Interesting)
Should self-proclaimed security experts, like Bruce Schneider, be liable for bad security advice?
That is, if Mr. Schneider tells people that a certain thing is secure, and then it turns out to not be secure, should he be liable for it? For example, if he had told me to use MD5 ten years ago, could I sue him now that MD5 has been discovered to be "insecure"?
Re:What goes around, comes around (Score:3, Funny)
Absolutely! Of course Bruce has always acknowledged that there is no such thing as proven secure algorithms ... the only question is, should we hold you liable for your own idiocy?
Self proclaimed ??? There is only one question left to ask ... should people who aren't smart enough to "self-proclaim" themselves as
It would kill *ALL* general purpose comnputing. (Score:3, Insightful)
The only safe language to code in would be assembly, and you'd have to write all the code yourself, unless you wanted to be liable for the output of the compiler or the libraries you linked to.
Shared libraries and loadable modules couldn't be trusted, since if your application had them, someone else could substitute a different library or module, and your code would never know the difference. If you added checking mechanisms to *for sure* know the difference yourself, you'd have to trust the FS.
All applications would have to be embedded applications, since you couldn't trust an OS vendor - what would happen if the system call behaviour was changed by the OS vendor? What if it wasn't by the OS vendor - what if the OS vendor trusted third party companies to write drivers?
What about firmware? The OS trust the firmware to load it! What if the firmware changes, or isn't exactly the firmware you expected?
What about the hardware? What if the instruction set on the CPU changes? You'd have to tie your software to particular hardware; historically, for example, 6502 processors were mask-programmed, and had "in between" op codes - they'd do something, but what the side effects were depended on the chip stepping. Your code could work in testing, but not in production unless you guaranteed the same chip lot, since it might be working as a result of a serendipitous error that was fixed in the next chip.
Down this road, you'd only ever have software sold by people who made the OS sold by the people who wrote the firmware sold by people who built the hardware... and maybe the components of the hardware themselves.
So basically you'd have... what... nothing left, but IBM from the 1950's?
-- Terry
Re:Free Software or All Software? (Score:3, Insightful)
Plus, most free software is in a perpetual beta version 0.99.9.999 and very rarely in a version 1.0+... You can hardly blame a developer if you have been using the not-ready-to-be-released version. Does that mean Microsoft would sell Windows Vista Beta v 0.99 too though...?
Re:Duh. (Score:2)
Oh, by the way, it doesn't really seem like that great of an idea, either.
I disagree. As a software engineer I get annoyed with the way in which people bandy about the title "software engineer". As in, "I completed a six week course at DeVry on Visual Basic, therefore I can call myself a software engineer". Nobody goes through a three day Red Cross course on basic first aid and then presumes to call himself a doctor or a nurse, so why the same with engineer?
Don't get me wrong, I don't think that the
Re:Duh. (Score:3, Insightful)
It would also do wonders for the cost of software. So you would hold the developer of some stupid game, or even a word processor to your vaunted "professional" standards of expensive testing? Give me a break! Nobody has yet AFAIK come up with a foolproof mathematical way to certify that any program of even moderate complexity is bug free. The only way to
There still has to be a balance (Score:3, Insightful)
Just becasue the failure of some software doesn't maim or kill people, or is not the direct cause of millions of dollars in losses, doesn't mean that consumers shouldn't be warranted against defects. Commercial software is notoriously lax in comparison to most other consumer goods--for example, about all Microsoft warrants against is damaged physical media. The law i
Re:How do you know customers won't want it? (Score:3, Insightful)
How much money would a 99% crash or error proof OS, such as Windows or OSX cost? How long would a MS or Apple have to test and how much would it cost? With material products, there are mathematical methods by which it is possible to predict performance and reliability. Only a limited amount of testing is needed of prototypes and production goods. This is NOT the case with software which is NOT a ma
Re:Duh. (Score:2)
we are already locked into a few vendors unfortunately, but up-and-comers that can't seem to debug simply don't make sales.
Re:Delayed Liability (Score:2)
What's wrong with that? (Score:2)
Re:WTF?!?! (Score:2)
However:
To address the topic of the article (which had nothing to do with its content), I'd say this. Yes, vendors who are SELLING software for profit, and are supposed to be supplying support resources for said product, should be held liable for bugs. I don't know why he doesn't think that they aren't. If a piece of software is buggy, people will flood their tech support lines, and if not fixed will stop buying it! Duh, again!
Vendors are not held lia
Re:Sometimes whackitude comes in a sensible wrappe (Score:2)
I haven't covered all the bases, but its pretty close. I earnestly believe its possible.