Forgot your password?
typodupeerror
The Courts Government Programming The Almighty Buck GNU is Not Unix News IT Technology Your Rights Online

Examining Software Liability In the Open Source Community 241

Posted by timothy
from the three-letters-starting-f-u-d dept.
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."
This discussion has been archived. No new comments can be posted.

Examining Software Liability In the Open Source Community

Comments Filter:
  • by godrik (1287354) on Thursday August 06, 2009 @03:28PM (#28977305)
    I am sure hell is frozen now.
  • by Seakip18 (1106315) on Thursday August 06, 2009 @03:30PM (#28977321) Journal

    "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)

      by sqlrob (173498)

      And so does every bit of commercial software. How do you differentiate?

      • by piojo (995934) on Thursday August 06, 2009 @03:48PM (#28977619)

        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)

          by piojo (995934)

          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...

        • by sumdumass (711423)

          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.

          • by piojo (995934)

            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.

        • by Greyfox (87712) on Thursday August 06, 2009 @06:19PM (#28979733) Homepage Journal
          Pretty much every EULA I've read states that you not hold the vendor accountable for defects in their software or any data loss of yours that occurs while using their software. I don't recall exactly what the Windows one says but I seem to recall that Microsoft is at most liable for $2 in damages if anything goes wrong with their software.

          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!

    • There are things that can't be warrantied away like that(and in some cases, this is a good thing; but; I just don't think that software is one of them). "Delicious candy may contain succulent lead, eat at own risk, non-toxicity not warrantied" would not make selling tainted food any less problematic.
      • Re: (Score:3, Insightful)

        There are things that can't be warrantied away like that(and in some cases, this is a good thing; but; I just don't think that software is one of them). "Delicious candy may contain succulent lead, eat at own risk, non-toxicity not warrantied" would not make selling tainted food any less problematic.

        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

        • by jargon82 (996613)
          I believe you would. I once worked in retail, and we couldn't give away food that was still in date and in good condition to food banks (but which for some reason or another we had to get rid of), because of liability concerns.
    • by AndrewNeo (979708)

      You should really change your MOTD to something more interesting.

    • Re: (Score:3, Interesting)

      by reebmmm (939463)

      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

      • 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.

        • by sumdumass (711423)

          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.

          • 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

      • by elgaard (81259)

        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.
        ==

      • by russotto (537200)

        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.

        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

    • by PolygamousRanchKid (1290638) on Thursday August 06, 2009 @04:04PM (#28977901)

      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.

    • by Wrath0fb0b (302444) on Thursday August 06, 2009 @04:08PM (#28977955)

      "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).

    • State law in the US often directly mandates certain warranty conditions for sold products. There are certain warranties that cannot be signed away, disclaimer or no.

      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
    • 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?

    • Building Reliable Software is possible, see TeX by Knuth.
  • by onionman (975962) on Thursday August 06, 2009 @03:30PM (#28977325)

    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?

    • by sys.stdout.write (1551563) on Thursday August 06, 2009 @03:37PM (#28977459)
      Of course not. The article was terrible.

      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.
      • by Jaysyn (203771)

        Would a Microsoft backdoor / killswitch be considered a fraudulently concealed bug?

        • by Burz (138833)

          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)

        by jd (1658)

        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

    • by SirGarlon (845873)

      Bug free software is possible, it's just very very expensive to produce!

      Or very, very small.

    • by digitig (1056110)

      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)

        by maxwell demon (590494)

        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 :-)

      • 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

      • by jd (1658)

        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

      • by jd (1658)

        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

    • by nomadic (141991)
      Do you really want to force Microsoft or Apple to produce bug free operating systems? Who could afford them?

      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...
      • 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

        • Not everything can be controlled by you, but certainly every exception can at least be handled gracefully. Otherwise we call it a bug.
    • by mcgrew (92797)

      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.

      • by Zalbik (308903)

        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.

        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

      • if they sold it for $2.. wouldn't that be $450m profit?
    • 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.

  • by synthesizerpatel (1210598) on Thursday August 06, 2009 @03:33PM (#28977367)

    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.

    • by TheRaven64 (641858) on Thursday August 06, 2009 @03:46PM (#28977567) Journal

      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...)

    • by jdgeorge (18767) on Thursday August 06, 2009 @03:49PM (#28977645)

      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.

      • I hate to tell you this but software is released with known bugs ALL THE TIME. Every version of Windows, for example, ships with thousands of known bugs and some of these can render your system inoperable. They release it anyway because they believe the risk is low to the typical user. If software were never released because it could make your system inoperable or cause corruption, then no software would ever be produced (except for the space shuttle where the cost per line of code is ~$1000).
    • by nomadic (141991)
      Of course, suing someone doesn't restore...revenue.

      Uhhh, yes it does. That's the whole point of suing.
      • 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.

      • I bet you subscribe to CIO magazine.

    • by Jaysyn (203771)

      I would have been escorted from his office laughing, right after he got "sue Oracle" out of his mouth.

  • bollocks (Score:5, Interesting)

    by shentino (1139071) on Thursday August 06, 2009 @03:33PM (#28977375)

    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.

  • by spun (1352) <loverevolutionary@nOSpam.yahoo.com> on Thursday August 06, 2009 @03:33PM (#28977387) Journal

    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.

    • The "same standards" should allow shipping plenty of horrors...

      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.
  • Bad idea (Score:4, Insightful)

    by ShadowRangerRIT (1301549) on Thursday August 06, 2009 @03:34PM (#28977407)

    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.

  • by fuzzyfuzzyfungus (1223518) on Thursday August 06, 2009 @03:35PM (#28977427) Journal
    Other than the fact that people hate software bugs, which is fair; but insufficient reason, why should a general liability be presumed to exist?

    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)

    by oldhack (1037484) on Thursday August 06, 2009 @03:35PM (#28977431)
    That's the weasel word to generate extra lawyer business. Scumbags.
    • by nomadic (141991)
      So...you're saying there should be strict liability? If you ship software with a single bug that it would have been almost impossible for you to find, you should be held liable?
      • ALL non-trivial (non-TeX :D) software is either shipped with known bugs, or it costs 1000+$ per line of code (aviation, DoD, NSA - that kind of stuff).
      • by oldhack (1037484)
        Strict liability with limited scope is better than "knowingly" clause which simply encourages lawsuits.
  • by Assmasher (456699) on Thursday August 06, 2009 @03:37PM (#28977455) Journal

    I'm not anti-FOSS in any way, I'm just wondering why it would be exempted...

    • by johannesg (664142) on Thursday August 06, 2009 @04:08PM (#28977951)

      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...

      • by Assmasher (456699)

        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.

    • Because its free, so no contract is formed between the user and the supplier.

      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.

      • by Assmasher (456699)

        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

        • by Chirs (87576)

          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

  • New guidelines (Score:3, Insightful)

    by SirGarlon (845873) on Thursday August 06, 2009 @03:40PM (#28977501)
    How about these for new liability guidelines: if the vendor knowingly ships buggy software, the customer is entitled to a 100% refund on the license cost.
    • by i.r.id10t (595143)

      Or how about entitled to the source so they can fix it or pay to have it fixed by a contractor?

      • by cenc (1310167)

        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

    • by Soukyan (613538) *
      This becomes a hard guarantee to make. As a poster above stated, it can take millions to produce a relatively small amount of bug-free code. Not that it is impossible. It is costly and time-consuming, but certainly possible. Doing an analysis between the costs of bug fixes and shipping a bug-free product might provide more insight, but then again, there's the issue of what caused the bug. Was it a platform issue? Was an interaction with other software? Was it an untested configuration? We might begin to see
    • by Chirs (87576)

      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.

  • IANAL - NDIPOOT (Nor Do I Play One On Tv) From the Article: A key passage -- Section 3.05 (b), if you want to look it up -- says that user agreements contain an implied warranty that purchased software "contains no material hidden defects of which the transferor [the seller] was aware at the time of the transfer." What's more, no matter what language the vendor places in the user agreement, the warranty still stands. Wouldn't this make it tough to ship a product at all? The code base would have to have no
    • by piojo (995934)

      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

    • 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.

  • 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

  • While a number of coders could be responsible for a software defect, it would be the responsibility of a given software project to correct that defect in a timely and effective manner. The reliance on an open source application can be guaranteed in part through support contracts, but simple ethics would dictate that the developers should hold themselves accountable for the final product. I wrote an essay (Liability, Reliability, and Safety [indigospot.com]) that briefly touches on this topic back in 2007.

    One point that I
  • Option (Score:3, Interesting)

    by sanosuke001 (640243) on Thursday August 06, 2009 @03:49PM (#28977643)
    Just add a stipulation for software that has source code available as exempt.

    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.
  • 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.

    • 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 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 ?

  • Any law/guidelines that discourage developers from creating/distributing "known bug" lists is just retarded.

    Solution:
    Change the guideline to "knowlingly selling software with undisclosed bugs".

    Then you are just encouraging developers to make known bugs known to their customers, which I think we can all agree is usually a good thing.

    • by CastrTroy (595695)
      Good point, although I would changed it to "knowingly selling software with known bugs which are undisclosed". All the unknown bugs are obviously undisclosed, and you wouldn't want a software company fined because they didn't disclose bugs that they didn't even know about.
  • So you could be liable if you knowingly ship defective software. The correct solution is then not to look at bug reports and other feedback. Then you could not be accused of knowingly shipping defective software. That is why Microsoft refuses to acknowledge the existence of security holes widely reported and widely being exploited. By saying "We are still investigating the alleged security violations" and making these "inspectors" not communicate with developers and mangers charged with shipping the product
  • 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

  • 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...

  • Unlimited liability for lawyers who make arguments which don't hold up in court.

  • by adamkennedy (121032) <adamk@c[ ].org ['pan' in gap]> on Thursday August 06, 2009 @09:09PM (#28981375) Homepage

    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.

"All my life I wanted to be someone; I guess I should have been more specific." -- Jane Wagner

Working...