Free Software at Risk Under Lemon law 393
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."
How many times do I have to say it? (Score:3, Informative)
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.
Re:Wouldn't Affect Free/Open Source Software (Score:3, Informative)
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)
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)
Re:Really? (Score:2, Informative)
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)
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)
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.
Re:Wouldn't Affect Free/Open Source Software (Score:5, Informative)
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)
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)
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)
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.