For those who've been too busy to notice (and for those who have), last month San Francisco issued a fast-tracked Request For Information ("RFI") to obtain insight, knowledge, and a reality check on the potential for adopting, adapting, and deploying a next generation voting system that is based on open source software technology.  We say "fast tracked" only because the turn-around time allotted given the deadline was (from our experience) rather tight.

So, our response is available on their public site and available directly from us here.  You might want to download our latest copy because we trapped some grammar errors and a couple of mistakes we want to clarify below.  This does not materially or substantively alter or change our official submission--we stand by what we submitted save our rushed grammar goofs and one point deserving clarification, which we do below along with a comment about the RFI in general and the underlying goal of San Francisco, as best we understand it. Let's start with the clarification and close with the commentary on the RFI (because the latter is brief, but the former more important).

Amplification and Clarification First

First, and foremost, we want to apologize for an unintentional mistake made in our haste to meet the filing deadline--a failure to accurately edit and represent one issue we take very seriously: the license under which we want to catalyze election jurisdiction adoption of open source technology provided by the OSET Foundation -- directly via the TrustTheVote Project, or indirectly as a consequence of the OSET Foundation serving as a public repository and distribution agent for any election software technology that may be a material part of a voting system for which an elections jurisdiction is making a commercial acquisition that incorporates said software.  Let's take this one point at a time.

Adoption Goals; Licensing as a Distribution Means
A hallmark of what the OSET Foundation is about is catalyzing the innovation of electoral technology (at least the underlying software) as publicly-owned critical democracy infrastructure.  Our goal is adoption of innovative open source solutions that dramatically improve the integrity of election technology and catalyze a reformed commercial market for their delivery and deployment.  And this includes not just technology resulting from the TrustTheVote Project, but any software-based solution, where the software technology is intended to be a public asset as part of a commercially adapted, delivered, deployed, and supported finished system.  So, for instance, if either L.A. County or Rice University, or Travis County, TX, or any developer wants to produce open source software technology of this unique type and would like to find a release and distribution service, the OSET Foundation is offering such a home (and licensing framework) for that technology. 

Why is that necessary?  Well, electoral technology is unique in that it is subject to certification requirements, a recorded disclosure and download process, and more scrutiny as to its integrity and security given its unique role in the operational continuity of our democracy.  We have spent (literally) years interacting with and learning from elections officials all over the country to understand their requirements, not only for how systems need to perform, but for how they must be verified, protected, certified, acquired, and distributed.   And to this extent, "optics" plays an important role.  From that "learning" in the trenches of the front lines of democracy, we determined two things:

1. We would likely have to invest in developing a unique variation on OSS ("open source software") licensing precisely "tuned" to the particular acquisition requirements and regulations of local and regional government agencies; and
2. It would provide a further sense of trust and efficacy if such electoral software technology, intended for commercial implementation or actual production use in binding public elections, were subject to a slightly more rigorous process for distribution.  This namely includes some recording, accountability, and audit loops for download (intent and purpose), an expressed-consent to the license, and the ability to offer downloads for continued R&D or educational purposes verses downloads of "frozen" certified release versions ready for integration.

This meant investing a significant amount of money in both, particularly the licensing element first.  In fact, we're not overly focused on the distribution services yet--that is still some time off, but coming.  The license, however, is important because we already have jurisdictions adopting code the TrustTheVote Project is producing.  For us, open source licensing is more about distribution and assurance of adoption than a means for development.  So, licensing unintentionally became an important aspect of our efforts.  And that is the segue to our point of correction (and public apology) today.

REALITY CHECK:  As a side bar, we want to make as clear as possible, that we would never sink money into an unnecessary effort.  That would be a terrible waste of incredibly important dollars that could be spent making better software, and arguably a dereliction of duty in utilization of our philanthropic support.  In fact, we've invested six-digits into the work of licensing research and development, again out of necessity, not some imagined motivation or distorted vision of reality.  It is also important to note that generous grants and partial-grants of services, from the firms of Foley Lardner, Greenberg Traurig and O'Melveny Myers have helped make this licensing work possible.  In fact, we owe a great debt of gratitude to Heather Meeker leading this.  Heather is one of the top licensing lawyers in the world, part of a small and exclusive group including lawyers Andrew Baluch, Larry Rosen, MIchael Epstein, Michael Lennon,  and others.  And Ms. Meeker is worth every dollar she earns doing what she does.

Respecting and Engaging the Open Source Community
So, one of the very important things we want to do while we are deeply engaged in the nuances (technical and policy) of electoral technology design and development, is to make sure the open source community at large is aware of our work, and "gets" the unique and nuanced aspects of making open source work in this specific sector of government administration.  We're nearing the point where we will launch an aggressive developer recruiting campaign, so abiding by, acknowledging, participating in, and respecting important OSS community governance initiatives is an important step.  Leading that, is earning acknowledgement and approval of our open source license, which is a necessary variation of the MPL and we believe clearly within the definition of an open source license.  That requires participation in the Open Source Institute's process and becoming a good contributing citizen of the OSI community.

MEA CULPA
And we (I) tripped-up on that important first step.  You see, in the submitted version of the RFI response from us you will note that we unintentionally misrepresented the state of approval of our license (at the time we submitted our RFI) in our haste to "get 'r done."  The RFI Response states that the license is OSI compliant and under review for acceptance.  At the time we submitted the RFI, although I believed that to be a true, a bonehead communication breakdown resulted in that being dead wrong.  And again, as I've done in other forums and directly to the OSI management, I apologize for that stumble.

We have, since a week ago Friday, properly submitted our license, and it is now being vetted.  I cannot comment on how that is going or how we think it will come out, except to say we remain confident that the process is intellectually-honest and the OSI should find in favor of our application.  Regardless: we procedurally goofed up in reporting a condition that had not been met at the time of authorship.  We want everyone to know that at all times it has been our intent to properly earn the designation of OSI approved OSD compliant license for the OPL.  We take the OSI process seriously, and did not mean to diminish or disrespect that in any way by our misrepresentation.

So, why is the license and OSI approval so important?
(For our election professionals who follow us here)

We want to be in lock-step with the open source community about our work in order to have their heartfelt support and participation.  Part of that is going to the same efforts every other open source project goes through where a special license is required.  We are not exempt or exceptional, and as much as we're committed to serving election professionals and citizen voters with our work, we respect the global open source community. We respect their desire to ensure the long-term viability of making software intellectual property publicly available for those types of applications, where it makes the most practical sense to do so.  Licensing is an important aspect of open source software because it is what derives the legal rights and obligations for this unique category of intellectual property.  We took a long and careful look at the necessity to crafting another license because it meant a lot of time, work, precious dollars, and this process of approval.  Consider, for example, that research alone required us examining procurement regulations for all 50 states plus territories and over 3,100 counties.  We did not take this on lightly.

A Final Point on the Licensing Issue
I want to close this aspect of today's post with a comment on licensing need, and then finish with some comments on the important RFI process that took place in San Francisco (which is after all, the title of this post.)

Some have asserted that the GPL (v3) is "more than sufficient to handle the licensing needs for open source software in the electoral administration world."  If we believed that were the reality or that had been our experience, I can assure you, we would never have spent the resources to do anything else (and we could be much further along in our mission).  I am strongly opposed to "building solutions in search of problems."  The problem with the assertion about the sufficiency of GPL in this unique setting is that it seems to ignore facts on the ground in county procurement settings, and it does so in an unintentional manner.  You see, many look at existing OSS adoptions by many branches of government and conclude that it is being done without issue, so there is no problem.  Well, not exactly.

You see, what is actually being done is the download and adoption of OSS for applications where no associated purchase as a "bundle of technology" occurred or was required.  In those cases, without incurring the review and approval of purchasing and procurement officers or administrators, such acquisition was not subject of an RFP, purchase order, or contract, so no one noticed (or cared).  Adoption in that sense, was without pecuniary cost or risk.  But once the OSS in question becomes part of a purchase order or procurement contract, then every single related legal agreement, condition, or term, is subject to review and must abide by the terms and conditions set forth by the adopting agency's attorneys.  It is that nuance that we believe has tripped up many critics of special licensing requirements in this unique sector of government I.T.

Now, About San Francisco's RFI

OK, back to the original point of this posting: the forward-thinking of San Francisco on electoral technology.  I want to first observe that while we believe S.F. is taking a smart first step toward genuine innovation of critical democracy infrastructure, undoubtedly S.F. government leaders have been influenced by Los Angeles City and County efforts to develop a next generation voting system utilizing open source principles, and the enabling legislation of S.B. 360.

S.F. is looking to lead in a similar, yet unique manner.  It is similar in that they are pursuing a publicly owned system based on open source software, and unique in that S.F. supports Ranked Choice Voting (sometimes referred to as "instant run-off" see here to learn more).  To help shepherd this, S.F. is fortunate to have one of the smartest up-and-coming technically savvy elections officials in the nation -- Chris Jerdonek.  His leadership in this regard is highly commendable.

The RFI should inform S.F. that while there is a great deal of potential and opportunity for an open source software-based voting system, today none are ready for production.  If S.F.'s time frame for acquisition is in a 2-3 year window, then there is a good possibility a solution fitting their requirements will be ready.  There is also the possibility they could accelerate that with an investment of their own -- in other words, act proactively rather than passively.  Of course, such presents far greater risk for the reward, but potentially far more manageable today than it would've been back in 2001 when I was part of the S.F. Voting Systems task Force first looking into this.  And we (OSET Foundation) are confident now that such an investment would be no more expensive than what they are likely to make to acquire any solution based on currently available commercial systems. 

The Cost Component
What might that cost look like?  While we did not dive into costing detail in the RFI, our hope is S.F. will engage with us to learn what our experience has been in cost engineering what it will take to complete our work.  That information can be used to inform any development modelthey might consider.  What we can say is that working with financial analysts last year we modeled the cost-to-complete for the TrustTheVote Project, plus built a model of what cost-to-complete might be for the Rice University inspired STAR-Vote technology in Travis County, TX, and developed some costing models based on provided software and the necessary commercial efforts to adapt and deploy finished systems using more or less off-the-shelf commodity-based hardware.  Turns out that in all likelihood the cost should be about 1/6th of today's commercial pricing of currently available solutions. 

Would that kill the commercial viability of the market for election administration and voting systems?  No, it doesn't and not by along shot.  It does catalyze a considerable restructuring of the market and business of election technology by shifting from a proprietary systems vendor model to a systems integration model.  But that's not a bad thing by any measure.  Ask Red Hat how that's worked out with the open source Linux operating system in the enterprise computing market.  We're fortunate to have a deep pool of product management talent who has been shepherding the development of digital products for decades.  They know the cost realities.  They know how to forecast and budget.  So, we're confident of the cost-to-complete for a system of this required caliber, integrity, and magnitude.  We're available to share what we've learned and what we know today 8-years in.  We are not calling for S.F. to adopt and adapt what we're doing or to finance our work.  We are not doing that at all.  But we do think we offer a tremendous amount of acquired domain expertise on the matter.  We're a project of, by, and for the people, located in San Francisco's backyard.  So, we hope we can be of advice and counsel at least.  That's up to them.  But we were pleased to have the opportunity to submit a response.

Where-to, Likely From Here?
There is no open source voting system complete, production-ready, and shipping today (or likely to be in the next 6-12 months at least).  But there is great potential outside of that window, from a couple of sources (not just the TrustTheVote Project although we believe we have a breakthrough innovative solution driven by elections officials input).  So, there is opportunity at hand, but lots of work to be done. 

We provided some candid comments on S.F.'s originally commissioned draft report and study.  And we've provided a response to their RFI.  We're intrigued to see where the City of San Francisco goes from here; we have an idea but we'll withhold further comment for now.  Regardless, we stand by ready, willing, and able to help with a well aligned and calibrated non-profit cause to do so (and a bunch of technology in design and development S.F. is encouraged to leverage.)

Some have asked, "If everyone knows there really isn't anything shipping today or in the next several months, why bother with an RFI?"  We believe there is good reason to push the envelope (and the market) on this issue and that's why S.F. is taking the early initiative.  They need to plan.  They need to determine costs and challenges to understand risks and potential results.  And they need to run a reality check on their potential to be a true leader in this regard.  They sit at the northern end of arguably the greatest digital innovation center in the world; with San Jose at the southern end.  With thought-leaders like Chris Jerdonek driving innovation demands of this sector of government, they know exactly what they are doing.  And we suspect they have a plan.

Stay tuned.