[amh]

I think the uncertainties inherent in writing software that depends on many other complex libraries/frameworks will tend to discourage strong liability for bugs. The average Win32 program or Java web app has a dizzying list of dependencies and it would be impossible for the programmer sitting on top of that software stack to make any guarantees about the stuff underneath.

In certain highly restricted domains (typically embedded systems), liability for bugs becomes somewhat more realistic.

[gloob]

The average Win32 program or Java web app has a dizzying list of dependencies and it would be impossible for the programmer sitting on top of that software stack to make any guarantees about the stuff underneath.

That, divorced from further arguments, is not an extraordinarily strong argument against liability for defects. After all: the engineer who builds upon such a stack has presumably, more or less consciously, made the decision that defects are acceptable - otherwise they would have chosen something less complex. Is there any particular reason someone should not be held accountable for that decision?

[jbri]

The question is, would we expect authors of libraries to indemnify other developers against liability if the fault is in the library itself?

[jarek]

If it's life critical software, then yes.

You don't get to blame civil engineers for structure failure if the steel provided had material faults (that couldn't be detected by said engineers exercising due diligence).

[j_baker]

Yes. The fact that more than likely it was their PHB who made the decision, not them.

[jarek]

That just shifts the responsibility onto whoever made the decision after being presented with an accurate assessment, PHB or not.