Examining Software Liability In the Open Source Community 241
snydeq writes "Guidelines from the American Law Institute that seek to hold vendors liable for 'knowingly' shipping buggy software could have dramatic impact on the open source community, as vague language around a 'free software' exemption could put open source developers at litigation risk. Meant to protect open source developers, the 'free software' exemption does not take into account the myriad ways in which vendors receive revenue from software products, according to a joint letter drafted by Microsoft and the Linux Foundation. As such, the guidelines — which, although not binding, are likely to prove influential on future lawsuits, according to attorneys on both sides of the issue — call into question the notion of liability in the open source community, where any number of coders may be responsible for any given defect."
microsoft and the linux foundation agree ? (Score:4, Funny)
Re:microsoft and the linux foundation agree ? (Score:5, Funny)
Google would have joined them, but Beta software doesn't count.
That and the Universe asploding
I believe almost every free software I use has.... (Score:5, Informative)
"NO WARRANTY OR GUARANTEE IS IMPLIED. USE THIS SOFTWARE AT YOUR OWN RISK" or some combination of that. Even my home server says that every time I SSH into it.
So.....you're going to sue a developer for a defect, intentional or not, even though they said it was not warrantied and use at your own risk?
Re: (Score:3, Insightful)
And so does every bit of commercial software. How do you differentiate?
Re:I believe almost every free software I use has. (Score:4, Interesting)
I suspect that in commercial software, there is an implication of warranty (because the customer paid for it), and that warranty can't always be signed away by a contract (because of things like consumer protection laws).
I would think that if a piece of software is free as in beer, it would be easy to explain to a judge that the project authors had no business relationship with the user, and thus could not be held liable.
It's sort of like the "I am not your lawyer, this is not legal advice" disclaimer--the person giving advice is less likely to lose a malpractice suit if he/she says "I have no business relationship with you, so don't take this with the same gravity that you might take my real legal advice."
Re: (Score:3, Funny)
Oh, and I'm not a lawyer. And if I were, I probably wouldn't be you lawyer. In which case this would not be legal advice...
Re: (Score:2)
Not all Open source software is free and in beer. The free as in beer model isn't even required for free software especially the GPL or BSD or similar licenses.
Re: (Score:2)
You're right, I didn't really mean open source software. I'm talking about software that doesn't cost anything--freeware, essentially.
Re: (Score:3, Funny)
Not all Open source software is free and in beer.
I should think not. The last time I tried to download FOSS from a server that was in beer I kept losing the connection, and the time I drank beer with FOSS in it, was even worse.
Re:I believe almost every free software I use has. (Score:4, Insightful)
As the American Law Institute appears to not hold with that belief, lets see how far they get in their goals WITHOUT ANY SOFTWARE! Ha ha ha ha ha ha ha ha ha!
Re: (Score:3, Insightful)
A business relationship does not require money to change hands. I suspect that like contracts all that is required is that both parties receive some sort of "consideration", http://en.wikipedia.org/wiki/Consideration [wikipedia.org] [wikipedia.org]. Consideration is obvious for the user(s), they get the software, but consideration for the author(s) could be quite varied. Passing along the author's work (as the GPL requires), reporting bugs back to the author, mere use of the software enhancing the author's standing in a community (or maybe just stroking the ego), ... I'm sure a real lawyer could get quite creative, as they have successfully done with consideration under contract law. Unless of course the legislation gives OSS authors a special status which they currently do not have.
These is no contract involved in using software provided under the GPL. The GPL only covers distribution, not use. If no consideration was provided to the author from the end user, no business relationship exists. A distributor of GPL based software has a contract with the author, but that contract only involves distribution, not use of the software. Since that contract states pretty clearly that the software is provided for distribution only if the distributor disclaims that it is fit for any specific
Re: (Score:2)
Re: (Score:3, Insightful)
But if I just give away my leftovers from my restaurant to some soup kitchen free, would I still be liable? May be. If I give away left overs from my home to a passing vagrant would I be held liable? What if I b
Re: (Score:2)
Re: (Score:2)
You should really change your MOTD to something more interesting.
Re: (Score:3, Interesting)
This comes up every time warranty issues are raised. The problem is that for that warranty to be effective, the parties had to agree. Hence, those that say open source software is not an agreement (or that one does not have to accept the terms of the GPL etc.) have a problem. I've said it before, certain of the terms of the GPL are not merely license language. The community cannot have it both ways.
Either this clause in unenforceable because their is no agreement (one party did not agree to it), or the
Re: (Score:2)
But why should the clause be necessary at all if the software was free-as-in-beer? If there is no consideration, there should be no obligation either; this is basic contract law.
Attempting to make people who give things away entirely for free liable for the consequences is a very dangerous path to tread.
Re: (Score:2)
Not everything is given away free.
What about a project who used the GPL but charges for the product like Redhat enterprise server or something.
Re: (Score:2)
That's why I said free-as-in-beer.
If you want to take money from someone, there is an expectation that what you're offering in return is of a reasonable standard. In software, expecting totally bug-free consumer software is not reasonable, but expecting that it doesn't (for example) silently install malware, trash all the other data on your hard drive, or contain known serious security flaws is fair enough. Whether the source for the software happens to be open is, IMHO, irrelevant to this, and Red Hat et a
Re: (Score:2)
It is not an agreement. The GPL licence says:
==
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program.
==
Re: (Score:2)
If there's no agreement, there's no warranty. If you accept the terms, there's no warranty. There's no attempt to have it both ways. The "NO WARRANTY" notice is
Re:I believe almost every free software I use has. (Score:5, Insightful)
So.....you're going to sue a developer for a defect, intentional or not, even though they said it was not warrantied and use at your own risk?
No lawyer will sue individuals developers . . . they have no money. They will try to sue a big company, um, like what SCO tried with IBM. Lawyers go after the money.
Some big companies even forbid their programmers from working on Open Source projects on their own time . . . unless they are approved by their employer, of course. Because the lawyer suing will try to twist it so that the employer is responsible . . . because only a big company has enough cash to make it worth their effort.
Re:I believe almost every free software I use has. (Score:5, Interesting)
"NO WARRANTY OR GUARANTEE IS IMPLIED. USE THIS SOFTWARE AT YOUR OWN RISK" or some combination of that. Even my home server says that every time I SSH into it.
There is no reason that a legislature cannot pass a law saying that this disclaimer is contrary to public policy and won't be respected in the courts.
For instance, in my State, contracts to purchase a car that are "AS-IS" are not legal. You can write those terms into the contract and the buyer can sign it, but if she turns around and sues you the Court won't give effect to that part of the contract.
Another example, I cannot rent an apartment or house "AS-IS", I am required by law that my rentals conform to a general standard of habitability. It doesn't matter how many times in the rental contract I disclaim any warranty of habitability, I still have to provide a habitable dwelling.
Consumer protection statutes are full of these sorts of provisions that forbid the use of certain kinds of terms and conditions. You can't sell food without a warranty of non-contamination or edibility, you can't sell children's playground equipment without a warranty of safety, .....
TL;DR version: the law does not have to respect your right to contract under whatever terms you see fit (I'll leave the normative argument of whether it should for another time & place).
Re: (Score:3, Interesting)
Of course you can - I can happily sell a device that looks just like a car, with wheels, can be driven, but make it clear that this is not intended to be driven on roads. If you do so, that's your problem.
If it's a model that was road-legal, no you cannot. That is you can't sell your old beater Honda Civic if the seatbelts are broken, even if I want to use it as a bird house.
But I can damn well sell a substance that would be inedible, and it's your own fault if you eat it.
You can't sell rotten apples as "non-food-substance" no matter how many disclaimers you put on it.
Yes, you can't sign or agree away rights allowed under law, but since these disclaimers aren't contracts or agreements, that's not an issue. They're disclaimers - no different to the disclaimer that says that the "car" you bought is not intended to be driven on roads. If that's allowed for physical products, why should software be held to a different standard?
I should have stated it this way: there are some warranties that the legislature will not let you disclaim. The legislature is not required to respect every possible form of disclaimer.
Re: (Score:2)
The question is what happens when an open source product is used in a sold product. Is the seller of the end-product solely liable, or is the producer of the open-source (and free) component also liable?
Everyone likes to pass the buck. If I successfully sue Sony because their battery melted my thigh, is the company they contracted to manufa
Re:I believe almost every free software I use has. (Score:2)
Sure sounds like it, but i think the true intent here is to create a new market for 'software programming insurance' ( and government certifications and bonds that go with it ), which will be priced out of reach of the small hobby coder contributing to OSS or a small code shop trying to make a living in their tiny niche market..
And besides, what software doesn't have at least ONE bug in it?
Re:I believe almost every free software I use has. (Score:4, Insightful)
I can see it now....rogue programmers, up late at night working in secret groups on some highly illegal, highly explosive software. Their code may not be perfect but it's the illegal cool factor that makes it worthwhile.
Re: (Score:2)
print("hello world!");
it works, even on my toaster.
Queue comments pointing out special places where even this would break.
Building Reliable Software (Score:2)
Bug free software would be insanely expensive! (Score:5, Insightful)
Bug free software is possible, it's just very very expensive to produce!
I've worked on DoD projects that required bug free software. It is possible, it just requires $150 Million to produce 100,000 lines of code.
Do you really want to force Microsoft or Apple to produce bug free operating systems? Who could afford them?
Re:Bug free software would be insanely expensive! (Score:5, Informative)
If you read the report from a better news source [yahoo.com] you'll learn that this only applies to fraudulent concealment of bugs, not simply their existence.
Re: (Score:2)
Would a Microsoft backdoor / killswitch be considered a fraudulently concealed bug?
Re: (Score:2)
Would a Microsoft backdoor / killswitch be considered a fraudulently concealed bug?
Very interesting question. Its not inconceivable that a closed-source vendor like MS would 'harvest' undisclosed bugs as they found them, for use as backdoors (with a kill switch being a specific kind of backdoor) at some later time. Then in an emergency a special client like the US Government could "stumble" upon the vulnerability and exploit it.
Re: (Score:3, Insightful)
Frankly, forcing Microsoft to produce a bug-free OS sounds a great idea. (They'd go bankrupt trying. How much better do you want??)
As for the fraudulent concealment of bugs, I don't think it should matter who produced the software, how, or why. If the bug was fraudulently concealed, that should be what matters. This would likely impact security notices (ie: we'd get them sooner, rather than later) and that sounds a great idea to me too.
I'd consider ANY fraudulent concealment to be a problem, though, not jus
Re: (Score:2)
Or very, very small.
Re: (Score:2)
I'd be interested to know how, because I work in the field (including having done formal analysis of military systems) and although I know of methods to get exceptionally low bug rates, I'm not aware of any techniques that offer bug free for any but the most trivial program. And I've seen software houses make claims of bug-free software that have been accepted by safety regulators but that have subsequently been found to be wrong as bugs have been found.
Of course, it's possible the DoD knows how but is keep
Re: (Score:2, Interesting)
Simple: Add to your specification: "The program is not intended to be run." If anyone runs it, then he's operating it outside of its specifications. Anything unforeseen therefore isn't a bug :-)
Re: (Score:2)
Are you familiar with the Gypsy Verification Environment and the Message Flow Modulator work, done by Don Good's group at The University of Texas at Austin in the late 1970s and early 1980s?
The Message Flow Modulator was a small (ca. 1000 lines of code, 1500 lines of type declarations and specifications) program, but it was by no means trivial. When it saw the acceptance test suite for the FIRST time, at the acceptance test at PAX River, in front of the customer, it passed. On the first time. No deviatio
Re: (Score:2)
It is possible to produce defect-free non-trivial software. Generally, though, it is better and more cost-effective to produce defect-tolerant software.
Defect-tolerant software is any software that probably contains bugs but where the bugs simply don't matter. It's a simple extension of the method used to produce a secure general-purpose OS - you have a security kernel that is guaranteed to be defect-free AND guarantee all arcs must go through that security kernel such that no potential vector in any other
Re: (Score:2)
Oh, I'll add in how to write non-trivial bug-free programs: eliminate ALL programming AND non-programming elements that cannot be proven correct in advance. The programs are just a part of a system and if the system is flawed, the program is flawed.
Occam was an attempt at just this. The processor and the programming language were developed in tandem (which meant you had a provable platform), dynamic structures were verboten, everything was strongly-typed and even the syntax for coding was tightly-defined to
Re: (Score:2)
I believe they're arguing that vendors shouldn't KNOWINGLY ship buggy software. If you found it before shipping, fix it. I suspect this will just cause software developers to just cut down on QA...
Re: (Score:2)
What about a "that bug is a feature" type of bug? What if we can't agree on categorizing its severity level? What if the bug affects 0.01% of the population and not worth fixing? What if the bug only appears occasionally when executing on runtime library 1.0, but never on 2.0? What if it works on a clean install but not when driver Y is installed? What if the bug is due to the user not keeping their OS up to date? What if the issue stems from data corruption? What if your code is script run inside of a 3rd
Re: (Score:2)
Re: (Score:2)
How many copies of XP were sold? If Microsoft has sold 300 million copies, than at $150m development cost they could sell the OS for $2 and make a $150m profit.
Re: (Score:2)
Yes, but the quote was $150million for 100,000 lines of code.
XP had over 40 million [wikipedia.org] lines of code, so assuming the costs scale linearly (which is optimistic IMHO), it would cost $60 billion dollars to develop a "bug free" version of XP.
For reference, Red Hat 7.1 contains approx 30 million [dwheeler.com] lines of code
Re: (Score:2)
Re: (Score:2)
Bug free software is possible, it's just very very expensive to produce!
It may be possible, but no-one has ever worked out how to do it.
Even the Cleanroom guys have non-zero bug rates. They're very impressive, maybe an order of magnitude or two better than typical consumer products, but there are still bugs.
And to pick everyone's other favourite example, while TeX may now be as close to bug-free as any consumer software ever gets, there are plenty of people with framed cheques from Don Knuth to show that it wasn't always that way.
God damn you, lawyers. (Score:5, Insightful)
Another stupid babysitter law to protect idiots.
At a previous job I asked my boss why we used Oracle and he said that if anything ever went terribly wrong, the company would have someone to sue. Of course, suing someone doesn't restore customer confidence, data, or revenue. No verifiable technical reason, just that OUR lawyers got warm and fuzzy with contractual language that would never, ever get exercised and if it ever did try to sue anyone we'd have run out of money before they dipped into their free soda fund.
Anything that executes code is buggy. Applications, frameworks, libraries, protocol stacks, drivers, bios', FPGAs and microchips. Grow up and deal with it.
Re:God damn you, lawyers. (Score:5, Insightful)
At a previous job I asked my boss why we used Oracle and he said that if anything ever went terribly wrong, the company would have someone to sue
Next time you encounter this attitude, you should find the relevant clause in the EULA, which disclaims all responsibility for the software containing bugs. If a company like Oracle provides your software then, generally, the only response you have to bugs losing your data is to not buy from them in future (unless, of course, you've just built a large in-house application that depends on Oracle...)
Re:God damn you, lawyers. (Score:5, Informative)
Another stupid babysitter law to protect idiots.
At a previous job I asked my boss why we used Oracle and he said that if anything ever went terribly wrong, the company would have someone to sue. Of course, suing someone doesn't restore customer confidence, data, or revenue. No verifiable technical reason, just that OUR lawyers got warm and fuzzy with contractual language that would never, ever get exercised and if it ever did try to sue anyone we'd have run out of money before they dipped into their free soda fund.
Anything that executes code is buggy. Applications, frameworks, libraries, protocol stacks, drivers, bios', FPGAs and microchips. Grow up and deal with it.
First of all, this is not "another stupid babysitter law". It is NOT a law at all.
Second of all, the guidelines are intended to prevent product vendors from selling products they know are defective. Just as it would be unacceptable if an auto company sold a car whose brakes wouldn't work whenever the car was going 72 miles per hour, it would be bad if a software company sold a system that it knew had a defect that could cause data corruption.
Re: (Score:2)
Re: (Score:2)
Uhhh, yes it does. That's the whole point of suing.
Re: (Score:2)
Of course, suing someone doesn't restore...revenue. Uhhh, yes it does. That's the whole point of suing.
Nah, Winning a suit restores revenue, (if the defendant had not already gone bankrupt). Suing only costs money to both.
Re: (Score:2)
I bet you subscribe to CIO magazine.
Re: (Score:2)
I would have been escorted from his office laughing, right after he got "sue Oracle" out of his mouth.
bollocks (Score:5, Interesting)
I'd say that ye olde standards of gross negligence and recklessness should cover any profoundly careless bugs.
The trick is to get them to apply to corporations like MS.
Sue who for what now? (Score:5, Interesting)
First point, if someone working for hire at Red Hat, Novell, or IBM knowingly (how's that defined?) ships buggy open source software, why shouldn't the company be held liable, if they would be held liable for shipping buggy closed source? Second point, who is going to sue some no-name contributor who doesn't have any money anyway, especially if you have to prove that that particular developer knew there were bugs? I love open source, but I feel that if we as a community want to be taken seriously, we should be held to the same standards as closed source software.
Re: (Score:2)
More generally, while concealing bugs is a super sleazy behavior, there are loads of situations where buggy software is preferable to no software. Virtually any software product of any complexity ships complete with a "known issues" section, which is nothing more or less than a list of bugs and omissions. Somehow, we all muddle through. I don't see FOSS vs. proprietary as differing markedly in that respect.
Re: (Score:2)
What constitutes 'knowingly distributing?' What do their guidelines call a bug? If the bug is disclosed, can the lawyers still sue?
Could someone please answer these questions in the form of a car analogy for me? This is Slashdot and I'll be damned if I'm going to read the article.
Re: (Score:2)
Fight Club: "If the cost of a recall is more than the average cost of an out of court settlement ... we don't do one."
Re:Sue who for what now? (Score:5, Funny)
If the car explodes when you turn the ignition key, it's a bug.
If the car explodes but the driver can escape and sue, it's a disaster.
Re: (Score:2)
So, are you suggesting that these American Law Institute guidelines will simply be null and void if the end user agrees to a EULA? Problem solved! We EULA them too, and we're off scot-free.
Somehow, I don't think it works like that.
Re: (Score:2)
In general, maintainers are not distributors. They may work for distributors, but they aren't the ones who package it up and sell it. If anyone could sue anyone who ever worked on a project that had bugs in it, that would be bad. Nobody would sign such an asini... well, maybe they would, but I doubt it.
If Microsoft really stands to benefit from suing open source maintainers, why are they against this as is clearly stated in the summary.
Re: (Score:2)
People who want to make money off of open source. People who want to use open source contributions on their resume. Pointy haired bosses who get to decide if we use open source in our workplace.
Bad idea (Score:4, Insightful)
Vendor liability for software is a good idea only in *very* limited fields, with *very* strict parameters. If the problem domain allows for exhaustive testing (every possible input, every possible code path), then this sort of liability is reasonable. Embedded control software for vehicles is a good candidate. But to apply the law to general purpose computers like we would for mechanical devices is absurd. They aren't a monoculture; they can run anything, which means anything can break them. Every general purpose OS out there suffers from the occasional crash (Windows, OSX and *NIX included), and the very nature of the machine means that you can't always determine the cause. If one kernel level process writes into the memory space of another, overwriting pointers and code, the eventual crash will appear to be the fault of the innocent process (after all, it tried to dereference null). The forensics required to assign blame unquestionably would cost more than the lawyers would.
Much like patent law, this is one field where hardware can go that software should not.
Why should general liability even exist? (Score:5, Insightful)
For software purchased as a custom/customized enterprise type setup, with guys in suits, and contract negotiations, and spec documents and whatnot, surely the parties involved can settle any questions of bugs, liability for bugs, responsibility for timely fixes, etc. as a matter of contract between themselves. Perhaps it would be convenient for a de-facto standard set of terms to exist; but I don't see why any legally binding assumption needs to be made, beyond what was specified in the contract.
For the consumer/shrinkwrap/non-custom stuff, I'd be strongly in favor of a right to return for refund if defective(though deciding exactly what level of buginnes qualifies as "defective" could well be tricky, and settling the issue of whether or not "being able to run on joe sixpack's box-o'-spyware-and-rootkits or timmy the tweaker's bleeding-edge-super-nlite-professional-l33t-3dition-h4x0red-windows-box" is actually a reasonable expectation could be a nuisance); but liability beyond that, unless actual damages can be demonstrated, seems unreasonable.
Already, if software is being used as a component of a system(medical, aviation, whatever) where bugs matter, it is subject to those standards, establishing a set of liabilities for software generally just seems like a good way to encourage ever more onorous disclaimer contracts and quash free/OSS/cheap software.
'knowingly' (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why should there be an exemption for FOSS? (Score:3, Interesting)
I'm not anti-FOSS in any way, I'm just wondering why it would be exempted...
Re:Why should there be an exemption for FOSS? (Score:4, Interesting)
I'm not anti-FOSS in any way, I'm just wondering why it would be exempted...
Would you spend years of your life making something useful, then give it away freely, and subsequently be sued to the point of losing your house, just for fun? At least commercial businesses are actively trading risk for gain; the open source developer only gets the risk part of the equation here.
I can see an entire industry spring up around finding bugs and sueing the maker of the software (much like the patent-sharks of today). You don't even have to read the source, just download a copy of whatever you want to hit and look in its Bugzilla tracker...
Re: (Score:2)
First, that's a very inaccurate description of what FOSS is. There are FOSS developers who make a living just doing FOSS, for example, charging for support, training, prioritization of bug fixes/feature requests, et cetera. Second, and most importantly, what has that got to do with basic fairness?
Whether you charge for software or do not charge for software should not affect your liability in the legal system for issues with that software.
Re: (Score:2)
In any case, for a lot of open source software, the bug database is also open, so making sure any bug you find is reported in a timely manner should be a good defense. Putting it in the database discloses it while making sure it is timely means you cannot be accused of keeping it secret.
It does create an incentive for projects to keep open bug databases.
Re: (Score:2)
Contract? Nobody is talking breach of contract, this is a push for legislative bindings that would punish people who 'ship' software with bugs knowingly. Whether you charge for your code or not should be immaterial to whether you can be sued for knowing publishing buggy software for people to use. Why should FOSS be exempted? Many major FOSS projects are only 'sort of free' in any case, charging for support for example (again, there's nothing wrong with that.)
Personally, I think that issues like this sh
Re: (Score:2)
Suppose I write some software and put it up online without charging for it or even claiming that it's any good.
If someone else downloads that software and uses it, it's up to them to decide whether or not it's good enough for their purposes.
On the other hand, if I buy a piece of software from a commercial vendor and it crashes my system and destroys my data then I think they should be held responsible to a certain extent--at least enough to cover the time and costs of recovering from backup and replacing an
Re: (Score:2)
It's not a good analogy at all. You did not create the goods in question that you donated to charity, but if you DID create the goods (like a bicycle for example) and you knowingly donated it knowing it had seroius flaws and someone was hurt - how does it matter that you gave it away for free?
New guidelines (Score:3, Insightful)
Re: (Score:2)
Or how about entitled to the source so they can fix it or pay to have it fixed by a contractor?
Re: (Score:2)
I think you are on to something as a legal argument here:
The open source license and the source code is the warranty. Essentially it is full disclosure and the responsibility of the user to evaluate the suitability of its use in a given situation. It is the 'if I screwed up making this software, here is the code for you to find, fix, or improve' warranty 'but I did not build it for any particular user and thus we are not in some sort of implied contract'.
For example, if you buy a car and get in a car accide
Re: (Score:2)
Re: (Score:2)
I think bugs should be allowed as long as they are documented and the documentation is available to the customer.
I also don't think that a license refund is sufficient. They should also be entitled to additional funds to cover the cost of removing the software and repairing the damage.
Interesting (Score:2)
Re: (Score:2)
The code base would have to have no known defects (bugs) regardless or scope or scale of the bug/defect.
I imagine you can get around this by publishing the URL of your bug tracker in the contract.
Of course, this URL would probably go to a server that was configured to display no bugs past $DATE and to only display the initial bug report or title, not the ensuing discussion (at least for secretive companies).
Bigger companies (those that sell shrink-wrapped software) might have to just keep a public bug track
no *hidden* defects (Score:2)
Notice the "hidden" in there.
My reading of that is that the software vendor could just make their internal bug-tracker publicly accessible and they'd be compliant because the bugs would no longer be hidden.
License (Score:2)
Could this be worked around with some language in the license along the lines that 1. We disclaim liability. 2. If such a disclaimer is not valid in your jurisdiction, we do not extend you license to use this software?
-Peter
Can a "level" of liability be set fairly? (Score:2)
One point that I
Option (Score:3, Interesting)
Or add an exemption to any company that gives a list of known bugs at release. If they blatantly say they know something is buggy, then that would be fair to me.
There goes the Video Game Industry (Score:2)
Well hell there goes the Video game industry.
No more just ship it and we'll patch it later mentality. Because at that point you "knowingly" shipped product with defects.
Either that or Quality Control esting will drop to Zero and bug databases will get wiped right before shipping.
Re: (Score:2)
Either that or Quality Control esting will drop to Zero and bug databases will get wiped right before shipping.
Oh the ironies
Quality Control Testing
Does this mean.. (Score:2)
Does this mean that if someone informs a vendor of a bug in their software they immediately have to prevent all downloads and inform retailer to remove the product from their shelves until the bug is fixed and replacement software can be shipped ?
Does anyone have a link to the full text of these guidelines ?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Problem is knowing. So close your eyes. (Score:2)
what nonsense (Score:2)
Every company I've worked for has knowingly released software despite KNOWING there are bugs. That's just the nature of the business. Get every single major bug fixed, bring low priority bugs down to a minimum and release. Open source or not, this is how it works. Sometimes the new features of a new version is more important than making sure a particular button in the UI is properly translated in the different languages you support. It's still a bug, and it was KNOWINGLY SHIPPED with that bug, but it wasn't
Agency regulation? (Score:2)
If you read to the end of the article, they are suggesting that instead of a law, what is needed might be agency regulation. I'm not really sure which of the two is more frightening, or more stifling for the industry...
Here's one for the lawyers (Score:2)
Unlimited liability for lawyers who make arguments which don't hold up in court.
How is this a problem? (Score:3, Interesting)
The article quotes the requirement as being "contains no material hidden defects".
That idea would superficially (I am not a lawyer) appear to allow any open source off the hook as long as you have a public bug tracker.
Re: (Score:3, Funny)
Put the chair down, Steve.