Which Licence for Open Source Digital Voting?
Here's a provocative thought:
We’ve dared to suggest that the GPL as it stands today, or for that manner any other common open source license, will probably not work to adequately provide a license to the software sources for elections and voting systems technology under development by the Open Source Digital Voting Foundation.
It's an important issue, since applying open source software to digital voting is something that you really want to get right - for the sake of open source and democracy.
Here are just some of the key issues that the Open Source Digital Voting Foundation faces: 1. Open source licenses rarely have “law selection” clauses. Fact: Most government procurement regulations require the application of local state law or federal contracting law to the material terms and conditions of any contract (including software “right to use” licenses).
2. Open source licenses rarely have venue selection clauses (i.e., site and means for dispute resolution). Fact: Many state and federal procurement regulations require that disputes be resolved in particular venues.
3. There are rights assignment issues to grapple with. Fact: Open source licenses do not have “government rights” provisions, which clarify that the software is “commercial software” and thus not subject to the draconian rules of federal procurement that may require an assignment of rights to the software when the government funds development. (There may be state equivalents, we’re not certain.) On the one hand, voting software is a State or county technology procurement and not a federal activity. But we’ve been made aware of some potential parallelism in State procurement regulations.
4. Another reality check is that our technology will be complex mix of components some of which may actually rise to the level of patentability, which we intend to pursue with a “public assignment” of resulting IP rights. Fact: Open source licenses do not contain “march-in rights” or other similar provisions that may be required by (at least) federal procurement regulations for software development. Since some portion of our R&D work may be subject to funding derived from federal-government grants, we’ll need to address this potential issue.
5. There is a potential enforceability issue. Fact: Contracting with states often requires waiver of sovereign immunity to make licenses meaningfully enforceable.
6. In order to make our voting systems framework deployable for legal use in public elections, we will seek Federal and State(s) certifications where applicable. Doing so will confer a certain qualification for use in public elections on which will be predicated a level of stability in the code and a rigid version control process. It may be necessary to incorporate additional terms into “deployment” licenses (verses “development” licenses) specific to certification assurances and therefore, stipulations on “out-of-band” modifications, extensions, or enhancements. Let’s be clear: this will not incorporate any restrictions that would otherwise be vexatious to the principles of open source licensing, but it may well require some procedural adherence.
Interesting stuff. At the moment:At this juncture, its looking like we may end up crafting a license somewhat similar in nature to the Mozilla MPL.
Views, anyone?
Follow me @glynmoody on Twitter or identi.ca.
Posts
