ecash developer software liability, round 809834

[Ryan Lackey]

(round 809834 because I'm sure this has been discussed 809833 times at
least on this and other lists, but google hasn't found anything
interesting for me)

(I was going to try to make a long posting on what I felt were the
good and bad of the state of play of ecash software development at the
end of 2001, but then I spent a few minutes poking through cypherpunks
archives and realized that's not much new to say which wouldn't need
to be explained in context not a lot of people have.  I'd rather spend
the time this freezing winter day developing some useful software instead.  
(configuring some semi-useful software, rather, right now) 
So instead just a few questions.)

What exactly *is* the legal or security liability if a person of
independent/offshore means develops and delivers an electronic cash
system in an open-source fashion, optionally with no continuing
personal involvement in development, or optionally with continuing personal
software development involvement but no operational involvement?  How
much of a difference do the various levels of removal make?

(in place of "ecash" feel free to substitute "anonymization",
"datahaven", "p2p", "assassination politics bot", etc....the argument
is probably generalizable to any unpopular code which involves money
and privacy.)

I'm unconvinced it's possible to develop any large piece of software
in a truly anonymous manner; anyone who *could* develop ecash has
enough information available about them online to understand what they
did, especially for something as intellectually complex as a workable,
vs. minimum-effort, ecash system.  There is a small enough number of
people who could develop such a thing that a bit of research would
show which ones spent every day for the past 3 months shirking other
professional responsibilities and contacting credit card processors,
writing code, etc.  (plus, of course, ego reasons make it unlikely
the developers of such a thing could remain anonymous)

>From nothing I've seen is the risk anywhere near as substantial as
some would suppose.  Worst case with ecash is that it is ONLY used for
criminal operations; perhaps the ecash operator could be attacked
under RICO?  I think perhaps the developer could be named if there
were more than arms-length interaction between developer and operator,
but this becomes more difficult if post-development the developer
disclaims ownership.  Lets say it is used by real terrorists to
finance the purchase of weapons for a weapon of mass destruction, in a
single transaction, with no other uses.  As long as the developer is
not linked to the operation of the system, and the operator of the
system is not linked to the end parties, I can see legal or extralegal
harassment.  (I am perhaps naively assuming US law is the only law
which matters; this may not be the case)  

But what is the absolute worst thing that will happen?  Extralegal
quasi-governmental execution?  Indefinite imprisonment without trial?
Successful prosecution under some law?  Asset seizure?  Being declared
a bad person by Ashcroft in a press conference?  Not getting invited
to FBI agent parties?  Scorn and slight regard?  You can't "unwrite"
code, and if something is done and shut down, but doesn't fail for
fundamental reasons, it's just a matter of time before someone else
picks up the still-shiny unbroken tools and starts again, perhaps a
bit more carefully.  If people stopped slanging rock every time
someone on the corner got knocked, the ghetto would have a lot fewer BMWs.

The DMCA/Dmitri case is certainly one of the most recent, but the end
result was effectively nothing.  I would be annoyed by spending a year
in a federal jail, but it wouldn't seriously impact my life.  Being
convicted of a felony would be slightly more unpleasant, but not
substantially so -- not that I'm convinced there's much which would
stick.  I don't really need to worry about asset forfeiture, being
declared "evil" by Ashcroft would be worth it, and I doubt I'd get 
invited to FBI parties anyway.  Being murdered by the state would also
be unpleasant, but is at least fairly rare and unlikely.  A
media/government character assassination attempt would be unpleasant
as well, but would be difficult to make stick given the disrespect
large segments of society have for the government and media already.

If the risks of developing ecash really are overblown, perhaps that
will make it more likely people would actively develop software.  That
is, aside from the standard "ecash is a complex system technically", 
"we need money to buy aeron chairs and feed ourselves", "you need to
be able to both develop and operate a system to bootstrap, and these
are different skills", "it's easier to spend time debating why such a
system can't be done or hasn't been done than to actually develop it",
"how will anyone make money from it?", "writing code is hard, let's go
shopping", "crypto-export regulations", "many have tried, all have
failed", "the actual lack of any clear market demand for such a
system, and active opposition on many grounds by those necessary to
deploy widely", "if I wait long enough someone else will do it for me,
and I am lazy", "moral doubts about the goodness of a world with such
a system", "the patent thing", "x, y, and z will sue civilly",
"writing papers and going to conferences/grad school/etc. is more fun
than writing code", and "the fact that a lot of crypto-software
developers are even flakier than normal software developers."

(I don't think just releasing code is productive, but I think there is
a code+limited deployment which would be productive, and is not
substantially more effort.  I think there are certain technical decisions
which must be made by an ecash system with some knowledge of how
things are done in practice, but there have been ~10 attempts at
developing such things in the past, with lots of info available by
talking to the developers or being involved.  Mainly what is important
is to do as little work as possible, the ultimate goal of any software
engineer, and to make sure that as little work as possible is required
to use the system.  There are certain very minor design, API, and UI
decisions which would logically have a very large impact on user
perception (end user and developer), adoption rate, and terminal success.

I also believe in "start small and imperfect, iteratively improve in a 
mostly hill-climbing fashion" and some other very simple rules of 
[open source/internet] software development which have not been
followed by previous projects (some of which I've learned myself at
some cost).  I share the belief that a capitalized,
startup-style, large and collaborative project is entirely the wrong
way to go about things, and would not invest $1 of my own money in
such a thing, but I disagree that it requires any substantial
technical *programming* skill beyond any other moderately-complex
network + crypto programming library; mainly one needs to know how to
avoid doing work.  Since to be useful the system must be integrated
into applications, a lot of thought needs to go into how to design it
to encapsulate nastiness, and integrate with a wide variety of
applications.

The number one thing required to successfully develop and deploy an 
electronic cash system today, though, is being simultaneously
smart enough to be able to do it, but stupid enough to do it anyway,
even given the past failures, lack of rational economic motive, and
potential risks.  People often do irrational things; sometimes this is
constructive, other times it is not, but it's usually interesting, at
least to me.)

-- 
Ryan Lackey [RL7618 RL5931-RIPE]	ryan at havenco.com
CTO and Co-founder, HavenCo Ltd.	+44 7970 633 277 
the free world just milliseconds away	http://www.havenco.com/
OpenPGP 4096: B8B8 3D95 F940 9760 C64B  DE90 07AD BE07 D2E0 301F