Viewing entries tagged
OSS license

Comment

San Francisco Thinking Forward on Electoral Technology

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 responded to the RFI. However, in the process, we unintentionally misrepresented the status of OSI review of our OSS license, which we've now corrected.  Read on about our licensing to ensure adoption of OSS election technology, and some comments about San Francisco's thought leadership in researching open source opportunities for electoral technology innovation.

Comment

Comment

OSDV Foundation Public License Draft Published for Review

Happy Friday-Apologies for the apparent radio-silence these past few weeks since returning from the Overseas Voting Summit in Munich.  We've been very busy: handling 2 elections jurisdiction proposals and another large voter outreach group's request to adopt portions of our open source elections technology framework, with lots of related work effort.

But today, at the end of a particularly busy week, I am completely stoked to share a significant milestone with you:

The delivery into our Request For Comment process of the our draft public license for all of the TrustTheVote Project's software technology.

The OSDV Foundation Public License is being referred as the "OPL."

As promised several weeks ago, our Legal Department, in collaboration with and leadership from Heather Meeker of Greenberg & Traurig (our licensing counsel), has completed the first DRAFT of the OSDV Foundation royalty free open source License.

The draft is accompanied by a "Rationale Memo" which explains the reasoning behind decisions made in the drafting of this License under which all open source code from the TrustTheVote Project will be made available on a royalty free basis.

We are now passing these documents into the RFC (Request For Comment) process within our TrustTheVote Project Stakeholder Community, which numbers in excess of 200 individuals.  But we want everyone's comments, and encourage you to offer your input, even if you are not yet a Stakeholder Community member (you may request an invitation to join that community from stakeholder-replies at osetfoundation dot org.)

We wish to publicly thank Heather Meeker and her team at www.gtlaw.com for all of their wonderful support and guidenace in this effort.  Seriously, if you ever have any needs for technology licensing lawyers who have been at the center of the open source legal and policies issues since it all began, you need to check out Heather's team.

We believe these documents together will (finally) clarify our reasons for having to develop a new license and should put to rest the swirling rumors, theories, and opinions on our licensing strategy.  We look forward to your remarks nonetheless.

Have a great weekend! Gregory

Comment

8 Comments

A License to Adopt

Open Source Technology Licensing... We've been promising to respond to the chorus of concerns that we may drift from the standard GPL for our forthcoming elections and voting systems software platform and technology.  Finally, we can begin talking about it (mainly because I found a slice of time to do so, and not because of any event horizon enabling the discussion, although we're still working out issues and there will be more to say soon.)

gplv3-127x51From the beginning we’ve taken the position that open source licenses as they exist today (and there are plenty of them) are legally insufficient for our very specific purposes of putting publicly owned software into the possession of elections jurisdictions across the nation.

And of course, we’ve heard from activists, essentially up in arms over our suggestion that current licensing schemes are inadequate for our purposes.  Those rants have ranged from the sublime to the ridiculous, with some reasonable questions interspersed.  We’d like to now gently remind those concerned that we [a] benefit from a strong lineage of open source licensing experience dating back to the Mozilla code-release days of Netscape catalyzed by Eric Raymond’s Manifesto, [b] have considerable understanding of technology licensing (e.g., we have some deep experience on our Board and within our Advisory group, and I'm a recovering IP lawyer myself), and [c] are supported by some of the best licensing lawyers in the business. So, we’re confident of our position on this matter.

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.  So, let me start to explain why.

I condition this with “start” because we will have more to say about this – sufficient to entertain your inner lawyer, while informing your inner activist.  That will take several forms, including a probable white paper, more blog posts, and (wait for it) the actual specimen license itself, which we will publicly vet (to our Stakeholder Community first, and the general public immediately thereafter).

The Why of it…

The reasons we’re crafting a new version of a public license are not primarily centered on the grant of rights or other “meat” of the license, but ancillary legal terms that may be of little significance to most licensees of open source software technology, but turn out to be of considerable interest to, and in many cases requirements of Government agencies intending to deploy open source elections and voting technology in real public elections, where they’re “shooting with live ballots” as Bob Carey of FVAP likes to say.

It is possible that an elections jurisdiction, as a municipal entity could contract around some of the initial six points I make below, but the GPL (and most other “copyleft” licenses) expressly disallow the placing of "additional restrictions" on the terms of the license.  And most of the items I describe below could or would be considered "additional restrictions."  Therefore, such negotiation of terms would render a standard copyleft license invalid under their terms of issuance today.

It’s not like we haven’t burnt through some whiteboard markers thinking this through – again, we’re blessed with some whip smart licensing lawyers.   For instance, we considered a more permissive license, wrapped in some additional contract terms.  But a more permissive license would be a significant decision for us, because it would likely allow proprietary use of the software – an aspect we’ve not settled on yet.

With that in mind, here are six of the issues we’re grappling with that give rise to the development of the “OSDV Public License.”  This list is by no means exhaustive.  And I'm waiting for some additional insight from one of our government contracting lawyers who is a specialist in government intellectual property licensing.  So we’ll have more to say beyond here.

  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.

And this is the tip of the iceberg on the matter of providing an acceptable comprehensive, enforceable, open source license for municipalities, counties, and States who desire to adopt the public works of the Open Source Digital Voting Foundation TrustTheVote Project for deployment in conducting public elections.

At this juncture, its looking like we may end up crafting a license somewhat similar in nature to the Mozilla MPL.

Hopefully, we’ve started a conversation here to clarify why it’s a bit uninformed to suggest we simply need to "bolt on" the GPL3 for our licensing needs.  Elections and voting technology – especially that which is deployed in public elections – is a different animal than just about any other open source project, even in a majority of other government IT applications.

Stay tuned; we’ll have more to show and tell.

Cheers GAM|out

8 Comments