Forgot your password?
typodupeerror
United States

Free Software at Risk Under Lemon law 393

Posted by timothy
from the officialism-and-its-discontents dept.
mpawlo writes: "Newsforge published a piece I wrote on a lemon law for software. That is - what would happen if shrinkwrap limitation of liability clauses would be banned? I think Microsoft and the GNU Project would both suffer."
This discussion has been archived. No new comments can be posted.

Free Software at Risk Under Lemon law

Comments Filter:
  • by adam_megacz (155700) <adam@megacz. c o m> on Sunday May 12, 2002 @04:16PM (#3507012)

    Neither the federal government nor any state has ever had any sort of warranty/liability law that would affect gifts (transactions involving no payment or consideration), unless the defect was willful and intentional (ie trojans). There is no negligence protection for gifts. I highly doubt that any such software lemon law would break with this ancient precedent.

    The GPL clause disclaiming only nondisclaimable warranties exists solely for severability purposes; the "unless prohibited by law" clause appears in almost every warranty disclaimer.

  • by Shabazz (29233) on Sunday May 12, 2002 @04:47PM (#3507129) Homepage
    And you sir are an imbecil! :)

    I am a lawyer, and as such I know what a contract is. Last time I checked, it requires mutual consideration. If you allow people to download your software for fee, it's a gift, not a contract.

    Maybe you should check your facts before calling someone a moron.
  • Limiting Liability (Score:3, Informative)

    by fidget42 (538823) on Sunday May 12, 2002 @05:12PM (#3507211)
    The company for which I work develops custom software. IANAL, but one of the ways we limit liability is through collecting and documenting requirements for the software, and testing that those requirements were met. We also follow a strict software development process, which supports out ability to develop a quality product. By developing this documentation, we are able to pass liability off to our customers. I.e., They have agreed that our software meets their requirements and our tests are sufficient to prove that it does. Now, if we knew our software didn't meet the specification, that is different (usually called FRAUD).

    I would think that something like this would work for the larger Open Source projects. If they could have the requirements of the project documented (i.e., what it is suppose to do) and have tests written to verify this, then they may have a out. The problem is M$ case is that they know of the problem, or their quality process is not sufficient, and do nothing about it.
  • Re:Really? (Score:2, Informative)

    by RadioTV (173312) on Sunday May 12, 2002 @05:17PM (#3507224)
    Yes, you missed something. NT only became popular on x86 and had limited success on Alpha, but it ran an all four (x86, Alpha, MIPS and PPC).
  • Re:Really? (Score:2, Informative)

    by roybadami (515249) on Sunday May 12, 2002 @05:21PM (#3507237)

    No, you have it backwards. A well designed OS would not barf all over itself and dy because of a bad driver. The driver/device might fail, but the OS would chug right along.

    Well, that rules out most operating systems then. Most OS's run drivers at the same privilidge level as the kernel, and hence a broken driver can crash your system.

    In fact, many hardware architectures only support two privildge levels, so it's impossible to fix this in general (though x86 supports 4, which would allow the OS to protect itself somewhat from a rogue driver).
  • Re:Really? (Score:2, Informative)

    by cscx (541332) on Sunday May 12, 2002 @05:23PM (#3507246) Homepage
    Uh, yeah, you did. Since always. They dropped support in Windows 2000, but NT had it.

    Take for example this snippet from the Exchange SP4 upgrade info page: [microsoft.com]

    S20557 Sp4_40na.exe Windows NT Alpha client 5,874,326
    S20558 Sp4_40ni.exe Windows NT Intel client 4,342,909
    S20559 Sp4_40nm.exe Windows NT MIPS client 5,961,796
    S20560 Sp4_40np.exe Windows NT PPC client 5,150,868
  • Re:Really? (Score:5, Informative)

    by cscx (541332) on Sunday May 12, 2002 @05:35PM (#3507287) Homepage

    No, you have it backwards. A well designed OS would not barf all over itself and dy because of a bad driver. The driver/device might fail, but the OS would chug right along.


    Yeah, good thinking. Then we'd never see freezes like this, right?
    ---------

    Unable to handle kernel NULL pointer dereference at virtual address 00000016 printing eip: d18677ac
    pgd entry c14a1000: 0000000000000000
    pmd entry c14a1000: 0000000000000000
    ... pmd not present!
    Oops: 0000
    CPU: 0
    EIP: 0010:[]
    EFLAGS: 00010097
    eax: 00000004 ebx: c78306b8 ecx: 00000006 edx: cfaf1b40
    esi: 00000016 edi: c78306b8 ebp: c7830540 esp: c026ff14
    ds: 0018 es: 0018 ss: 0018
    Process swapper (pid: 0, stackpage=c026f000)
    Stack: 00000000 00000004 00000000 00000016 cfaf1b40 00000046 00000987
    000001a7
    00000001 c7830400 00002710 c011daa8 00000246 00000000 c02ad5a0
    003c0000
    c5829da0 24000001 00000003 c026ffa8 c010a30a 00000003 c7830400
    c026ffa8
    Call Trace: [<c011d1a8>] [<c010a30a>] [<c010a488>] [<c0107240>] [<c0107240>]
    [<c01090c4>] [<c0107240>]
    [<c0107240>] [<c0100018>] [<c0107263>] [<c010722e2>] [<c0105000>]
    [<c0100191>]

    Code: f3 a6 0f 97 c2 c0 38 c2 0f 84 d4 fe ff ff ff 44 24 08
    Kernel panic: Aiee, Killing interrupt handler!
    In interrupt handler -- not syncing

    --------

    I am so sick of this elitist bullshit around here. Software crashes!! Get it? OK?? Nothing is completely immune, you know, humans write OSes, there's bound to be a few bugs here and there. When drivers run at Kernel Level, and they fuck up, that's when shit goes haywire.

    That's the #1 reason Microsoft introduced "driver signing" in Windows 2000 and XP (and certification before that) --- to avoid shit like that. If the driver isn't certified by them, they're warning you, if shit goes wrong, it's your fault.
  • While IANAL, I did consult one about this once - when you give something away, you have no obligation to the recipient. Specifically, the recipient can't sue you if the product is defective in some manner.

    IANAL either, but I did take a business law course taught by a lawyer. What you said is not quite true (at least not in NY state). When you give somebody something (not for any consideration), then you are not liable for negligence. However, you are liable for gross negligence. Gross negligence is defined as negligence which "shocks the conscience of the court".

    My understanding is that it is very difficult to shock the conscience of the court, especially when you're giving something away for free. I suspect that as long as one doesn't knowingly include genuinely malicious code and keep quiet about it, that a software developer who gives away their code for free will be more than fine.

    I suspect, though this is just a guess, that RedHat could probably take the position, as long as they made it clear to purchasers, that they are providing an installation and aggregation service, they are not actually selling the code that they didn't write. Thus they would be liable for bugs in the packaging or installation but not in the aggregated software. This would be reasonable, IMHO, and probably legally OK, too. Of course, that's just pure speculation on my part.

  • attractive nuiscence (Score:3, Informative)

    by blonde rser (253047) on Sunday May 12, 2002 @06:31PM (#3507477) Homepage
    If I build a tree house on my property that is unsafe and someone tresspasses and uses this tree house (which I haven't even said he could use) and gets hurt then I am potentially liable both crimally and civilly. It's called an attractive nuiscence.

    I didn't charge anybody anything... I didn't even give permission for it to happen. Yet I am still at fault.

    Just because I don't profit off of a transaction doesn't give me a right to put somebody at risk - financially or physically - unless perhaps I am completely forth right; and even then often not. And simply saying "Well, at your own risk," is not completely forth right, not even close.

    The only different with purchasing the product is that the legal agreement is explicit. And in an explicit agreement risk can be accepted by the customer. But in the implicit agreement it is assumed that risk is accepted only if it obvious.Otherwise you're buying the right not to be put in a dangerous situation. Which u can't buy because u fundamentally own this as a citizen.

    As for the suggestion that there can't be a law suit because there is no company - I think it is pretty clear in the american litigation system there are no lack of defendants.
  • Patents. (Score:3, Informative)

    by himi (29186) on Sunday May 12, 2002 @11:55PM (#3508373) Homepage
    CMYK is patented, and licensing this patent is not at all cheap. Certainly, it's not something that's possible for a piece of software like the gimp.

    Claiming that a piece of software is inadequate because the maker of the competing software uses legal means to stop competitors from implementing a piece of functionality is really quite stupid.

    himi
  • Re:Really? (Score:2, Informative)

    by cookd (72933) <douglascookNO@SPAMjuno.com> on Monday May 13, 2002 @03:18AM (#3508886) Journal
    Basically, there is "kernel space" and "user space."

    Apps run in user space. They pretty much can't do anything except mess around in their own memory space and make calls to the OS's API. Thus, the OS can check parameters to any API calls. A good OS design would make it impossible for anything in user space to violate any security or stability rules -- any action on the app's part that would do so is rejected and an exception is raised.

    Drivers and the OS run in kernel space. Since the driver is by definition there to extend the functionality of the kernel into something that the kernel itself cannot do, the kernel in general cannot anticipate all actions by the driver. The driver has an API into the OS, but it also has direct access to all kinds of additional resources that it may need to get things done: kernel memory, device memory, IO ports, IRQ's, etc. But this also means that the OS has no way of knowing if the driver is screwing up.

    Whereas a user mode program screwing up generally doesn't do anything except shut down the offending program (Access Violation -- program terminated), a kernel mode program can screw up to the point of overwriting the kernel or something similar. At this point, there is not much left that can be safely done. Usually, some effort is made to bring down the system as safely as possible (flush all disk buffers, etc.), output some diagnostic information, and then halt the system. This is the UNIX kernel panic and the Windows Blue Screen of Death.

    There is research into the idea of avoiding these problems, but it has been considered expensive (in terms of performance) and complex. I haven't looked into the recent research much, so I can't comment. But the idea would be to have ALL system resources (device memory and IO ports included) virtualized. Design the kernel interface so that if the device driver fails, only that device dies. It would be cool -- just restart the video card when the video driver crashes! But so far, it hasn't gotten into any major OSes of which I am aware.

"Pay no attention to the man behind the curtain." -- Karl, as he stepped behind the computer to reboot it, during a FAT

Working...