Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

Would Vendor Liability for Bugs Kill OSS? 377

Posted by Zonk from the code-clean dept.
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?"
This discussion has been archived. No new comments can be posted.

Would Vendor Liability for Bugs Kill OSS? More

Would Vendor Liability for Bugs Kill OSS?

Comments Filter:

  • No, if... (Score:5, Insightful)

    by ivan256 ( 17499 ) * on Friday June 02, 2006 @02:46PM (#15456457)
    It wouldn't kill OSS if the liability was limited to the purchase price. That's plenty of liability to keep commercial vendors interested in fixing flaws, and it doesn't hurt the little guy.
    • Just nitpicking, but OSS != Free as in beer software.

      • Re:No, if... (Score:4, Insightful)

        by s4m7 ( 519684 ) on Friday June 02, 2006 @02:59PM (#15456613) Homepage
        Nitpicking perhaps, but you make a good point. What about the guys that sell Debian or BSD CD's for those unfortunate souls who don't have broadband or three days to tie up their phone line for the download? would they be liable for other people's code?

        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.

        • Nitpicking perhaps, but you make a good point. What about the guys that sell Debian or BSD CD's for those unfortunate souls who don't have broadband or three days to tie up their phone line for the download? would they be liable for other people's code?

          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)

            by saider ( 177166 )
            Just make sure you sell the service of downloading, burning and mailing instead of the software itself.

        • Re:No, if... (Score:3, Informative)

          by IAmTheDave ( 746256 )
          What about the guys that sell Debian or BSD CD's for those unfortunate souls who don't have broadband or three days to tie up their phone line for the download? would they be liable for other people's code?

          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)

          by bill_kress ( 99356 ) on Friday June 02, 2006 @05:23PM (#15458060)
          As I said in another message elsewhere, the differentiation is control after the sale.

          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.
      • Your point being?
      • and to the extent that it's not, liability is ok- it's really the intersection of free as in beer and free as in freedom we're interested in.

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Friday June 02, 2006 @02:53PM (#15456543)
      Comment removed based on user account deletion

      • Re:You can add a multiply factor... (Score:4, Interesting)

        by jadavis ( 473492 ) on Friday June 02, 2006 @03:29PM (#15456926)
        multiply the purchase price by 10 or so...should be a standard time-to-fix

        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)

          by dgatwood ( 11270 ) on Friday June 02, 2006 @04:26PM (#15457524) Homepage Journal

          Here's a better idea, then:

          • For the purposes of this statute, the term timely is defined as "within a period that a reasonable person would expect to have to wait for shipping and repair of a defect in a non-software product".
          • Liability is waived if any of the following conditions are met:
            • there is a workaround for the bug.
            • the customer is given a fix for the problem in a timely fashion.
            • the customer is given the materials necessary to allow someone of sufficient skill to fix the problem themselves.
          • All companies shall have a bug reporting mechanism that, at minimum, allows the person reporting the bug to obtain the bug's general status and to receive interim patched versions in a timely fashion.
          • Notwithstanding the fix for the reported bug, liability shall not extend to any bugs introduced in interim builds obtained as part of a fix for reported bugs.
          • All bugs reported prior to the release of a published update shall be fixed no later than the subsequent update unless fixing them is technically infeasible.
          • Upon reporting of a bug whose fix cannot realistically be fixed within this time frame, the customer must be given the option of a refund of the full purchase price in a timely manner. This offer may have two possible outcomes:
            • By accepting this remedy, the customer waives liability for this bug until such time as it is reported by another party.
            • By refusing this remedy, liability for this bug is maintained, but limitations on the timeliness of the fix are waived.
          • Source escrow shall be required for all software with a retail purchase price of $100 or more (in 2006 dollars, adjusted for inflation by the CPI). This source code shall be released by law should the company file for bankruptcy or deem it unprofitable to continue the development and maintenance of the software.

          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.

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

    • And you think commercial vendors wouldn't come up with some sneaky way around that? For example, giving the software away for free, but requiring an expensive support contract.

      • Re:No, if... (Score:3, Interesting)

        by Sique ( 173459 )
        But with the support contract come Service Level Agreements. And at this point the software vendor is interested in keeping the Service Level Agreements without too much additional work for him, especially if the support contract is of a "cover all" type (additional fees for some actions might give the vendor the incentive to redefine many support cases into cases which requires additional payment).

        In a certain way software which includes free patches and rebates on upgrades is already of the mentioned type

  • I wouldn't. (Score:4, Interesting)

    by Anonymous Coward on Friday June 02, 2006 @02:47PM (#15456466)
    I wouldn't contribute to OSS if I'd be exposing myself to a lawsuit because some dipshit found a creative way to exploit my code. They're the guilty party, not me.

    • Re:I wouldn't. (Score:2, Interesting)

      by Araxen ( 561411 )
      dipshit and creative...isn't that an oxymoron?

      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.

        1. dipshit [reference.com]
          n.

          A foolish or contemptible person.

          Not an oxymoron at all.
        2. Meaningless pop psychology
        3. Welcome to the entire fucking debate. What you think is a suitable definitive closing statement to simply spit out, the rest of us call 'the topic at hand'.
      • Or are you just mad because people are smarter than you and exploit the holes in your software you created?

        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

      • dipshit and creative...isn't that an oxymoron?

        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.

  • Would Vendor Liability for Bugs Kill Microsoft? (Score:5, Funny)

    by Anonymous Coward on Friday June 02, 2006 @02:48PM (#15456481)
    "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 Microsoft? Would what seems like a great idea actually be the death of proprietary software?"

    • great until you develop software for a living. How would I support myself? My landlord wont give me free rent if I donate my time for free so why should proprietary software die?

      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
  • specify that in the contract, and leave everyone else alone.

  • Vendor Liability should == purchase price (Score:2, Insightful)

    by Anonymous Coward
    When I get broken software I want my money back.


    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.

    • Ok, you went out and bought some SolidCAD s/w package that is essential to your business. For example you are manufacturing kitchen cabinets, and all your designs are in SolidCAD format.

      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)

    by frogie ( 752234 ) on Friday June 02, 2006 @02:49PM (#15456496)
    This would not only kill OSS, but the whole software industry would go bankrupt in no time.

    • Not even close (Score:3, Informative)

      by Just Some Guy ( 3352 )
      This would not only kill OSS, but the whole software industry would go bankrupt in no time.

      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.

  • Regulation hurts the small players (Score:5, Insightful)

    by vijayiyer ( 728590 ) on Friday June 02, 2006 @02:51PM (#15456514)
    As usual, regulation increases the barrier to entry for a business. By making software vendors liable for bugs, they make it difficult for OSS and small shareware developers to compete. Keep in mind that the question is not whether the OSS developer will be found liable, but whether they will be sued in the first place. The legal fees alone are enough to hamper or even kill small scale software development.
    • Was thinking the exact same thing.

      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)

    by linvir ( 970218 ) * on Friday June 02, 2006 @02:52PM (#15456524)
    Employee theft in shops, ATM fraud, tax fraud... all rolled into one unsymmetrical ball and used to argue in favor of software liability. What?
    Have you ever bought an apple? Did you notice that you could just take it and eat it pretty much as soon as you wanted? Apples are really cool, though they are a little vulnerable to flies. The vendors' solution is to sell apples more cheaply.

    Oranges are no different. For years I have argued in favor of ready-to-eat oranges. Orange vendors are in the best position to do this. But unfortunately, they don't have much interest. Features and profitability are more important. Ready-to-eat oranges will change all that. They'll align flavour with convenience and synergise exciting new solutions.

    One last story.... bananas thought they had a great idea: having a thick peel that was also easy to remove. But then monkeys found out and we all know how that ended.

    That was a great idea, but it didn't work very well. Customers, especially monkeys, don't like to be stopped by peel.

    Flavour must be aligned with convenience, but you have to be careful how you synergise solutions.

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

    • I can see it now, cops beating down your door because some software giant is getting some heat over a bug in a library you wrote over 20 years ago.

      Sendmail authors, beware!
    • Of course, we could have a formal accreditation program, you know, like every other engineering profession in the world
      • That would accomplish nothing. All it would show is that you know the standard
        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.
        • What utter bullshit.

          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)

    by geoffspear ( 692508 ) on Friday June 02, 2006 @02:52PM (#15456529) Homepage
    Probably not, but since TFA contains absolutely no information about how "liabilities" would work in the author's view and very little about software at all, I see very little reason for Wired to be publishing this column, let alone someone on Slashdot trying to use it as a jumping-off point to discuss the ramifications of the author's non-existent proposal.

    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.

  • Vendor Liability (Score:3, Insightful)

    by DragonWriter ( 970822 ) on Friday June 02, 2006 @02:54PM (#15456548)
    Very often, if not usually, there is no vendor with free sofware, so vendor liability wouldn't affect it at all (it might make commercial software more attractive, since there would be someone to sue for bugs, OTOH, it would make it less attractive to make commercial software.) With free software, very often the user acquires it from someone other than the creator, and gives no consideration of any kind to either the distributor or the creator to acquire or use the software. Often, a contract is created, if at all, only when the person who acquired the software decides to distribute the software, and even then, the consideration (in terms of limitations accepted by the new distributor) is in exchange for the right to distribute, not the right to possess or use, the software.
  • First and foremost, if we are going to discuss OSS vendor liability, you have to get the CLOSED SOURCE vendors to accept liability. You can't even TALK about OSS until then.

    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)

    by 70Bang ( 805280 ) on Friday June 02, 2006 @02:55PM (#15456566)

    ...when I see Microsoft on the list of responsible parties; i.e., they can be held accountable as well as anyone [else].

    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.


  • Do the words "no warranty, either expressed or implied" ring any bells for anybody?

    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?

    • Do the words "no warranty, either expressed or implied" ring any bells for anybody?

      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)

    by Aadain2001 ( 684036 ) on Friday June 02, 2006 @02:57PM (#15456584) Journal
    If the liability coverage being suggested is vastly more than the purchase price of the software, then yes it has the potential to kill OSS. I can imagine that the intent is to force software producers to own up to damages and lost income caused by bugs in their software. On the surface, this makes sense. If a tire company *cough*Firestone*cough* produced a tire that had a defect(bug) that led to the death of people or damage to the car/property, you can bet that those injured would want compensation.

    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)

      by Billly Gates ( 198444 )
      What if you write an api or even a program and some commercial vendor uses your code. THe bug was found in your code and the vendor gets sued.

      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)

    by Alien54 ( 180860 ) on Friday June 02, 2006 @02:58PM (#15456602) Journal
    Software that you pay for should have some sort of liability. This could be on a sliding scale

    • Free/no monetary cost = non liability
    • (homeuser non commercial product) up to 100 dollars = refund, and the additional penalty equal to cost of the software
    • Commercial Software - 100 to 1000 dollars each - something more substantial as a penalty
    • Industrial Software - 1,000 to 10,000 dollars each - something even more substantial as a penalty
    • Gov Grade, National Security, etc - more than 10,000 dollars - Bend over and ......

    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

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

    • Commercial Software - 100 to 1000 dollars each - something more substantial as a penalty

      "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

  • I can see it now: Satisfaction guaranteed or your software is free.
  • First of all, I think this is a dubious solution. While it could very well make software less buggy, it would likely also curtail technological innovation by driving the QA cost of developing any new software functionality (commercial or open source) through the roof.

    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)

    by aardwolf64 ( 160070 ) on Friday June 02, 2006 @03:02PM (#15456643) Homepage
    Just make the fine equal to some percentage of the retail price for the product multiplied by the total number of users...

  • Are bugs even mentioned in TFA? (Score:3, Informative)

    by Lord Grey ( 463613 ) on Friday June 02, 2006 @03:07PM (#15456705)
    The title of the article is "Make Vendors Liable for Bugs." Nowhere else in the article does the word "bug" appear. The closest Schneier even comes to talking about software is in this paragraph:
    Computer security is no different. For years I have argued in favor of software liabilities. Software vendors are in the best position to improve software security; they have the capability. But, unfortunately, they don't have much interest. Features, schedule and profitability are far more important. Software liabilities will change that. They'll align interest with capability, and they'll improve software security.
    Maybe the original, unedited version of the article did talk about bugs. I don't know. But this entire thread is a little OT compared to what article really says.
  • Doesn't the GPL containa a disclaimer of warranty anyway?
  • A provision like this should indemnify vendors who provide source code. The thought behind this is that if the customer has access to the source code, he can perform his own audits and the vendor has made a good-faith effort at full disclosure (as far as the vendor itself is aware). Also, many eyes looking at the same code will reduce the likelihood of fault. If the customer chooses to use the software without audits or tests, then the customer is 100% accountable. If the customer performs sloppy tests
  • If this was structured like most liability laws, what would happen is that vendors would be forced to raise their prices in order to pool the money in a big liability insurance fund. This fund would then be harvested by unscupulous lawyers using sympathetic clients whose claims pulled on the heartrings of juries, like: I spent so much time trying to keep my browser from crashing that I forgot to feed my cat and she starved to death; or I got so mad at my filesystem for losing my files that I smacked my kid
  • Having the word "vendor" in there implies that the is some sort of financial transaction involved with purchasing the product (or a license to use, etc, etc.). In that context, Free Software doesn't really have "vendors". The implication is that it is a best effort, but all code is provided "as-is".

    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
    • Free, as in speech, software certainly does have vendors. Some charge for the software, some only work for donations and some just do it for free; however, they still are all still vendors. Just because a product is open source does not mean that it has to be given away.

      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
      • This is easy to resolve.

        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
  • Well, such a proposal has two possible outcomes:

    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
    • You can't be liable for something without actually causing the damages or agreeing to be responsible if something you did indirectly did cause them.

      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
  • The question reveals a lack of understanding that OSS is a service model, while proprietary is a commodity model. They are two different paradigms. OSS isn't sold; support is sold. "Linux vendors" don't exist ... Red Hat, Yellow Dog, Debian, Ubuntu, et. Al. are Linux support vendors; they sell a service, rather than a product.

    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 /' as root in t
  • I see cameras by cash registers alot more than I see the "free if not given receipt" note.
  • A lot of open source stuff says "Free to download! Enjoy - but Note: This comes with no warranty / use at own risk" etc. Beat that.
    • All software carries that notice, non-OSS and OSS. Windows carries a similar notice.

      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.
      • Let's see... car cost $12000 and game costs $40... I wonder why there are lemon laws for only cars...

        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
  • How to create efficent software liability laws without hobbling the industry.

    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;
  • ...and I seem to recall someone mentioning that they (Sony) ought to be liable for the trouble its bug(s) caused...

    Just an observation.
  • No, I'll still write it and distribute it. If you want me to take responsibility for what it does, then we'll have to negotiate a specification, a contract, and a price. I'll make the software do what I want; if you want me to make it do what you want, that's extra.

  • God-awful submission! (Score:5, Informative)

    by Proteus ( 1926 ) on Friday June 02, 2006 @03:43PM (#15457086) Homepage Journal
    The article is horribly misrepresented, here. The core of the article is about the security principle of aligning capability with interest -- that is, when you want something done, you find out who can do it and take steps to interest them (offer them money, the potential of something free, a fine if they *don't* do something, etc.).

    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)

      by blitz487 ( 606553 ) on Friday June 02, 2006 @08:39PM (#15459345)
      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!

      Making a false claim is already actionable - it's called fraud. No additional regulations are required.

  • When I sell a product, I'm kinda liable for its functioning according to spec.

    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)

    by bill_kress ( 99356 ) on Friday June 02, 2006 @04:06PM (#15457328)
    licenses. If your software is licensed including the requirement that you don't modify it and don't duplicate it, then a responsibility should be implied that they take care of said software.

    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)

    by aquabat ( 724032 ) on Friday June 02, 2006 @06:07PM (#15458349) Journal
    Oh for crying out loud...

    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)

    by I'm Don Giovanni ( 598558 ) on Friday June 02, 2006 @06:15PM (#15458419)
    I see many here saying that only those that sell software should be liable, while those that give it away for free should not. If such a law were passed, you can bet that FOSS would be killed off in the corporate world, as corporations would gadly rather work with software vendors that can be held liable than those that cannot, as the former have something to lose for having bugs while the latter is free to produce bug-infested crapware. It makes no differnce if the "free" software is actually good; corps would feel safer using software produced by someone that could be held liable.

    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)

    by Guppy06 ( 410832 ) on Friday June 02, 2006 @06:47PM (#15458638)
    Would OSS be so popular if customers were able to hold (closed source) vendors accountable for their bugs?

  • What goes around, comes around (Score:3, Interesting)

    by Percy_Blakeney ( 542178 ) on Friday June 02, 2006 @07:50PM (#15459067) Homepage
    I just have one question:

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

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

      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?

      Should self-proclaimed security experts, like Bruce Schneider ...

      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)

    by tlambert ( 566799 ) on Friday June 02, 2006 @10:50PM (#15459909)
    It would kill *ALL* general purpose comnputing.

    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

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close