der Mouse said:
>>Changing liability laws on the other hand is a simple solution.
> But at what price?  It would kill off open source completely, as far as
> I can see, in the jurisdiction(s) in question.  (How many open source
> projects could afford to defend a liability suit even if they (a)
> wanted to and (b) had a won case?)
> Of course, if you don't mind that, go right ahead.  You don't say where
> you are, but looking over your message I see reason to thin it's the
> USA, and I long ago wrote off the USA as a place to write code.  I
> think it could be a very good thing for the USA to try such laws; it
> would give us hard data about what their effect is, rather than the
> speculation (however well-informed) that's all we have to go on now -
> and it quite likely would have the pleasant side effect of pushing most
> open source projects out into the free (or at least freer) world.

One solution would be to exempt open source software from such
liability, under the theory that:
* If anyone can read & analyze the source code, the real security
   of the product is much easier for customers to determine
   (directly or by hiring someone).  Part of the problem now is that
   vendors always say they're wonderful... and if it's closed source,
   it's too difficult to determine if that's true.
   It's usually pretty easy to determine if an OSS program is
   poorly designed or well designed for security.
* If anyone can change the program & redistribute those changes,
   then anyone can fix things THEY think are problems immediately,
   instead of waiting for a vendor (who may not bother or take
   years).  After all, the customer has the urgency, not the vendor.
* Requiring liability for open source software would kill a great deal
   of innovation, since a common model for distributing ideas &
   promulgating standards is to distribute an
   open source software implementation.  The Internet would probably
   never have gotten far, except that the BSD TCP/IP stack could be
   freely copied into arbitrary places (as code or as concept).
   The same for DNS, web servers, etc.
* If it's NOT open source, then the vendor is probably charging a
   per-use or per-year fee, and thus can afford insurance, lawsuits, etc.
   This often isn't true for OSS; a project could separately charge
   for liability insurance, but because it's optional, the group
   becomes much smaller than "all users".

There's even a precedent for this: U.S. export crypto laws essentially
give a free pass (in most cases) to open source software.
And in general, for important things the U.S. often requires either
disclosure or liability; this approach gives consumers a choice.

I'm not certain that liability laws for vendors are the way to go.
Generally such laws just make people buy insurance for the
lawsuits; if nothing else changes, that just means that the
lawyers get rich and nothing useful happens.  Sometimes, the
insurance companies impose requirements to get that insurance.
But those requirements are to reduce the insurance company risk,
not to improve the innovation or capability of products, or
even the security of the products as viewed by an end-user.
It'd be easy to kill the baby on this road.

If you go down this path,
you'd probably be better off creating a nice, narrow list
of common security flaws, and then say that you can sue
if it's something on THAT list.  That way, rather than something
vague, they can at least eliminate a finite set of problems,
that's short and manageable. Not perfect, but a start.

Another approach is to permit suits against people who CHOSE
the product.  This has some
advantages, but it's not perfect either.  Problem here is that
popular products generally get a free pass ("everyone else
chose this shoddy product!"), which means that this can
_disincentivize_ vendors of popular products from fixing their
wares, and it can disincentivize competition ("no one would
be willing to risk using my new product because they might get sued").

Sigh.  Nothing is simple!

Anyway, just a few thoughts.

--- David A. Wheeler

Reply via email to