Principles of Open Voting

From: Arthur Keller <voting_at_kellers_dot_org>
Date: Sat Jul 02 2005 - 06:20:35 CDT

At 6:41 PM -0700 7/1/05, Alan Dechert wrote:
>If a vendor joins OVC, they have to adopt principles of Open Voting
>-- including the ballot printer architecture. It is understood
>that they can't change the way they do everything overnight. As
>long as they are moving in the right direction ... public source,
>commodity components, ballot printer, etc., and they work with our
>committees to develop open specs, we will be pleased. This doesn't
>mean we'll blindly accept anything they do. Trust but verify is
>what you old buddy said (or what his writer gave him to read).

1. I'm not convinced that the choice of the ballot printer
architecture is part of the principles of "open voting." I think
that hand-marked optical scan ballots along with electronic ballot
markers for blind/reading-impaired/language-accessibility/etc. is a
perfectly reasonable alternative architecture. If someone wants to
market a completely open and secure/inspectable/auditable/etc. DRE
with AVVPAT as part of an open system, where they do AVVPAT right
(for some reasonable definition of right), why should we prevent such
a company from joining the OVC?

2. To me, the notion of "open voting" have much more to do with the
use of open (inspectable/published) source, open processes, open
specs and requirements. I personally don't have the revulsion that
some others do to proprietary systems as long as they are completely
open to inspection by anyone and that no trade secrets are employed
(other than to the values of security codes and locks). Similarly,
if some degree of non-commodity (or even proprietary) hardware (such
as enclosures) considerably reduces the weight, usability, security
or deployability of an otherwise open voting system, I would not rule
it out provided that the designs and specs, etc., were publicly
inspectable. That being said, I have no intention to create
proprietary stuff as part of my work with OVC and the University of
California, but I do not automatically object to others creating
proprietary but open stuff. For example, I don't object to the
principle of software patents, but do object to inappropriately
issued individual software patents. To me, the tradeoff of
patents---publish your invention and how to practice it in exchange
for the privilege of practicing it exclusively for a limited period
of time---is a fundamentally sound one. However, the patents should
really represent some invention, not the reapplication of an existing
practice to a computer environment with minimal addition of new
intellectual inventive insight.

3. Some of the existing voting machine vendors are likely to continue
in that business. While I want new vendors to be established using
the systems created by or for the OVC, I believe the movement is
better off if we collectively try to get some of the existing vendors
to adopt open voting principles than if we refuse to work with any
existing vendor. After all, if an existing vendor joins the OVC, is
the vendor co-opting the OVC or is the OVC co-opting the vendor?
Probably both. What's important is that the OVC stand up for
principles of openness and not be lured by the potential payments
that might come from membership by existing vendors. I do not
receive any income from the OVC and never have nor intend to do so in
the future. If UCSC gets an R&D project to build open voting
systems, I do expect to be paid for my time working for UCSC and I
don't expect any residuals. I do other work to earn a living, as I
have done over the last two years I have volunteered for the OVC.

4. Digressing further, I want to make the distinction for open source
of open to public inspection vs. open to public contribution. It is
my intention that the systems developed by UCSC be open to public
inspection and that the "public" may contribute through commenting,
testing, bug reporting, discussion groups, reviewing, etc. Unlike
our current EVM2003 prototype, I am not envisioning the software
development to be by a cadre of part-time volunteers. First, it is
hard to keep to a schedule with volunteer software development.
Second, typical open source contributory software development is made
possibly by the employers of the contributors covering the cost of
the employee/contributor's time. That isn't in general the case
here. (Jan may be an exception.) One should no more expect to write
portions of the production central tabulator than should one expect
to write portions of the next release of the Linux kernel. Selected
and vetted volunteers will be engaged (just as is done with the Linux
kernel) and contributions will be reviewed by paid staff who will be
responsible for developing quality systems on time and within budget.
Anyone will be able to make comments, suggestions, bug reports, etc.,
but the specs and code won't be a Wiki editable by just anyone.
After all, we must insure that some "volunteer" does not introduce a
trapdoor or intentional flaw at the last minute in order to harm the

Best regards,

Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Sun Jul 31 23:17:11 2005

This archive was generated by hypermail 2.1.8 : Thu Sep 15 2005 - 11:43:09 CDT