dead. The reason for this trust is that
shoddy construction has had negative
consequences for builders for more
than 3,700 years. “If a builder builds
a house for someone, and does not
construct it properly, and the house
which he built falls in and kills its
owner, then the builder shall be put to
death.” (Hammurabi’s Code, approx.
Today the operant legal concept
is “product liability,” and the fundamental formula is “if you make money
selling something, you’d better do it
properly, or you will be held responsible for the trouble it causes.” I want to
point out, however, that there are implementations of product liability other than those in force in the U.S. For
example, if you burn yourself on hot
coffee in Denmark, you burn yourself
on hot coffee. You do not become a
millionaire or necessitate signs pointing out that the coffee is hot.
Some say the only two products
not covered by product liability today
are religion and software. For software that has to end; otherwise, we
will never get a handle on the security
madness unfolding before our eyes
almost daily in increasingly dramatic
headlines. The question is how to
introduce product liability, because just
imposing it would instantly shut down
any and all software houses with just
a hint of a risk management function
on their organizational charts.
a software Liability Law
My straw-man proposal for a software
liability law has three clauses:
Clause 0. Consult criminal code to
see if any intentionally caused damage is already covered. I am trying to
impose a civil liability only for unintentionally caused damage, whether
a result of sloppy coding, insufficient
testing, cost cutting, incomplete documentation, or just plain incompetence. Intentionally inflicted damage
is a criminal matter, and most countries already have laws on the books
Clause 1. If you deliver software
with complete and buildable source
code and a license that allows dis-
abling any functionality or code by the
licensee, then your liability is limited
to a refund. This clause addresses how
to avoid liability: license your users to
inspect and chop off any and all bits of
your software they do not trust or do
not want to run, and make it practical
for them to do so.
Would it Work
There is little doubt that my proposal
would increase software quality and
computer security in the long run,
which is exactly what the current situation calls for.
It is also pretty certain there will be
some short-term nasty surprises when
badly written source code gets a wider
audience. When that happens, it is
important to remember that today the
good guys have neither the technical
nor legal ability to know if they should
even be worried, as the only people
with source-code access are the software houses and the criminals.
The software houses would yell
bloody murder if any legislator were
to introduce a bill proposing these
stipulations, and any pundit and lob-
byist they could afford would spew
their dire predictions that “this law
will mean the end of computing as we
all know it!”
To which my considered answer
would be: “Yes, please! That was ex-
actly the idea.”
CTO Roundtable: Malware Defense
All Things Being Equal?
B. Y.O.C. ( 1,342 Times and Counting)
1. hofstadter, d. Gödel, Escher, Bach. basic books, 1999.
2. thompson, K. reflections on trusting trust. Commun.
ACM 27, 8 (aug. 1984), 761−763; http://m.cacm.acm.
Poul-henning Kamp ( phk@Freebsd.org) has
programmed computers for 26 years and is the inspiration
behind bikeshed.org. his software has been widely
adopted as “under the hood” building blocks in both open
source and commercial products. his most recent project
is the Varnish httP accelerator, which is used to speed up
large web sites such as Facebook.