by

Back when we were putting together the grant proposal for ACCURATE, one of the questions that we asked ourselves, and which the NSF people asked us as well, was whether we would produce a “bright shiny object,” which is to say whether or not we would produce a functional voting machine that could ostensibly be put to use in a real election. Our decision at the time, and it was certainly the correct decision, is that we would focus on innovating in the technology under the covers of a voting system, and we might produce, at most “research prototypes”. The difference between a research prototype and a genuine, commercial system are typically quite substantial, in general, and it would be no different here with voting system prototypes.

At Rice we built a fairly substantial prototype that we call “VoteBox”; you can read more about it in a paper that will appear on Friday at Usenix Security. To grossly summarize, our prototype feels a lot like a normal DRE voting system, but uses some nice cryptographic machinery to ensure that you don’t have to trust that the code is correct. You can verify the correctness of a machine, on the fly, while the election is ongoing. Our prototype is missing a couple features that you’d want from a commercial system, like write-in voting, but it’s far enough along that it’s been used in several human-factors experiments (CHI’08, Everett’07).

This summer, our mission is to get this thing shipped as some sort of “open source” project. Now we have several goals in this:

Allow other researchers to benefit from our infrastructure as a platform to do their own research.

Inspire commercial voting system vendors to build better products (i.e., solving the hard design problems for them, to reduce their cost for adopting innovative techniques).

Allow commercial voting system vendors to build on our source code, itself.

All well and good. Now the question is how we should actually license the thing. There are many, many different models under which we could proceed:

Closed source + patents + licenses. This may or may not yield revenues for our university, and may or may not be attractive to vendors. It’s clearly unattractive to other researchers, and would limit uptake of our system in places where we might not even think to look, such as outside the U.S.

Open source + a “not for commercial use” license. This makes it a little easier for other researchers to pick up and modify the software although ownership issues could get tricky.

Open source with a “BSD”-style license. A BSD-style license effectively says “do whatever you want, just give us credit for our work and you’re on your own if it doesn’t work.” This sort of license tends to maximize the ease with which companies can adopt your work.

Open source with a “GPL”-style license. The GPL has an interesting property for the voting system world: it makes any derivatives of the source code as open as the original code (unless a vendor reimplements it from scratch). This sort of openness is something we want to encourage in voting system vendors, but it might reduce vendor willingness to use the codebase.

Open source with a “publication required” license. Joe Hall suggested this as another option. Like a BSD license, anybody can use it in a product, but the company would be compelled to publish the source code, like a book. Unlike GPL, they would not be required to give up copyright or allow any downstream use of their code.

I did a quick survey of several open source voting systems. Most are distributed under the GPL:

Adder



eVACS (old version is GPL; new version is proprietary)

Helios (code not yet released; most likely GPL according to Ben Adida)

OVC (GPL with extensions to require change histories be maintained)

Pvote

Civitas is distributed under a non-commercial-use only license. VoteHere, at one point, opened its code for independent evaluation (but not reuse), but I can’t find it any more. It was probably a variant on the non-commercial-use only theme. Punchscan is distributed under a BSD-style license.

My question to the peanut gallery: what sort of license would you select for a bright, shiny new voting system project and why?



[Extra food for thought: The GPLv3 would have some interesting interactions with voting systems. For starters, there’s a question of who, exactly, a “user” might be. Is that the county clerk whose office bought it, or the person who ultimately votes on it? Also, you have section 3, which forbids any attempt to limit reverse-engineering or “circumvention” of the product. I suppose that means that garden-variety tampering with a voting machine would still violate various laws, but the vendor couldn’t sue you for it. Perhaps more interesting is section 6, which talks about how source code must be made available when you ship compiled software. A vendor could perhaps give the source code only to its “customers” without giving it to everybody (again, depending on who a “user” is). Of course, any such customer is free under the GPL to redistribute the code to anybody else. Voting vendors may be most scared away by section 11, which talks about compulsory patent licensing (depending, of course, on the particulars of their patent portfolios).]