A License to Adopt
Gregory Miller
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.)
From 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.
- 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).
- 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.
- 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.
- 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.
- There is a potential enforceability issue. Fact: Contracting with states often requires waiver of sovereign immunity to make licenses meaningfully enforceable.
- 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 responses to “A License to Adopt”
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Is there any reason you want to restrict usage?
Personally, I have never – since the first posting on USENET – been fond of the GPL, as the GPL is coercive. (A bit of irony there – forced free use of software? Seems to miss the point, somewhat.) A coercive license is a stick to force a particular kind of usage. Maybe this makes sense for the idealogical aim of the GNU folk. No way of knowing whether it helped more than it hurt.
I would not worry about commercial adoption. If even some local venues require public audit, and forbid use of restrictive patents, then maintaining private commercial branches will not be feasible.
No need to come up with the “mother of all licenses” to handle every conceivable case. Better to recommend requirements for local venues to adopt. Even if each subset varies – especially if each subset varies – captive source commercial variants will prove impractical.
Offer a menu of requirements for local venues to adopt.
1. Public audit of all source code.
2. Open-use assignment of any patented additions.
(No doubt you could think of others.)
The base license could be:
” Use this in any way you see fit. ”
Is there a good reason for anything more complicated?
Preston,
There may well be a requirement for a base license that is more than
” Use this in any way you see fit. ”
If so, the requirements would come from the procurement folks in the government organizations that might acquire TTV software in the future. That’s why why we’re in the process of drafting, review by gov’t officials in elections organizations, review by outside counsel with specialty in gov’t IT contracting and licensing etc. The goal is not to make a mother-of-all type of licensing and contracting templates, but rather pretty-good templates that would be “not known to not work” for gov’t orgs that we think may be typical of the full set of acquiring organizations. The simpler the better, of course, and certainly not cast in stone, as it will likely evolve as real acquisition occurs.
With that in mind, another way of answering your question “Is there a good reason for anything more complicated?” is “Could be – and we’re working on finding out.”
— EJS
Hi Preston-
Good points raised, and John seemed to summarily field them for a non-lawyer techie! 😉 As for the recovering lawyer techie, I’ll add that [a] you might want to gander at my response in this posting discussion to Alan Bell of the Open Learning Centre in the U.K.; [b] we definitely see no reason (or desire) to make this any more complicated than absolutely minimally required to get adoption and deployment, but we do need to bear in mind that the majority of OSS licenses are intended to support “automatic downstream recipient licensing” which is not our principal driver; [c] we’re tending toward an MPL (Mozilla Public License) model for a variety of related reasons; and [d] there is an increasing possibility that we will ultimately issue two licenses: one for production deployment by elections jurisdictions (subject to State law) and one for development purposes (far more copyleft friendly). Thanks for your replies! This is precisely the discussion we need to have.
I am a little unclear why this can’t be solved with a standard license such as the GPL, plus a contract. The license defines how the user may use the software and what they may do with it. The contract defines how you and the user conduct your business together. Thus, a contract may well lay out that you and your customer agree to a particular jurisdiction being the place in which you will resolve disputes, this covers 1 and 2, it does not place any additional restrictions on the use of the software.
For number 3, copyright assignment agreements are commonplace.
4, again this is the government paying for work to be done under a contract. Obviously patents and software don’t mix, I don’t see a licensing implication as long as you don’t want to enforce the patents against users of the software.
5. really not sure what you are worried about enforcing. Firstly, I don’t see why the state could not waive it’s sovereign immunity with respect to this project. That waiver is a single party statement or promise. Not a license or contract, and it does not conflict with any license as far as I can see. To be honest I can’t quite see the harm in the state retaining their sovereign immunity with respect to the license. That wouldn’t enable them to curtail other people’s freedom to use the software under the original license.
6. again, I see no problem. They can certify certain releases. It would be better for them to digitally sign certain versions and make their machines only run signed code in a Tivo style. Note that this is different to Tivo from a freedom perspective as the state owns the hardware. They are restricting their own hardware to run only certified software. They are not restricting other people’s hardware to run only certified software.
Alan-
Thanks for your reply. We’re sorry to be so busy the first half of this week, so responses may be brief and not fully explanatory. Rather than reply to each and every one of your good points, let me cherry pick two:
#1: I am not sure of your understanding of contract law, the interplay of technology licenses, or the like (you may even be a lawyer, but if so, then we’ll need to take this off line because you already should know what I am about to write 😉 ). A separate contract could incorporate by reference a license (say a GPL), but not necessarily vice versa. And unless we have parity between those two instruments we’d have potential problems. It is well settled (don’t believe this recovering lawyer, I’ll refer you to our outside expert counsel this) but the GPL disallows “additional restrictions” which any additional terms (such as a contract to recite legal venue; waiver of march-in rights, et al) constitute such terms under most legal interpretations of the GPL.
#6 We agree in part: the certification-related matters might not need to be incorporated into a license (and probably shouldn’t) though they may need to be represented somewhere (but see #1 above), and if so, then nobody would be happier than us. However, we are doing the homework on this issue, and it will not be brief, as it may require involvement from NIST and/or the Federal EAC. But bear in mind another comment I made in my post: we may be drifting toward an MPL-style (Mozilla Public License) OSDV Public License because given the Certification issue, it is likely that source code copied or changed under the terms of the license, must stay under the license (similar to MPL). Admittedly, this is a weaker copyleft license, but again our direct beneficiaries (the States’ elections jurisdictions) will be under certain regulatory restrictions requiring certain assurances of what they’re actually deploying in public elections service. The rest of us — the citizens who rely on this stuff to ensure continuity of democratic processes through fair and accurate elections — are indirect beneficiaries, and thus our needs in a license are secondary to the elections jurisdictions hopefully deploying this work.
To ameliorate this nuance, we’re also considering another strategy: a license option: a “deployment” license for production use of the certified source tree, and a “development” license. Under the terms of a development license, the copyleft characteristics would be far stronger to maximally encourage further innovation. Of course, such innovations, if intended to be incorporated into the certified tree, would require an incorporation vetting process managed by the Foundation.
One other point: I am intrigued by your TIVO suggestion; its not the first time its been raised, but I think novel nonetheless (in this environment of elections technology) and I invite your further comments and thinking on that approach.
One other quickie, then really gotta run: I concur that there is no apparent reason why a State couldn’t waive sovereign immunity, but the question lives in the legal world: that is, they could, but would they or should they? Blame it on the a slippery slope doctrine, but the problem may be one of legal restriction… that is: never make exceptions. One exception leads to another, until the rule is the exception. So regardless of how reasonable waiving sovereign immunity seems, if they do it once, the flood gates of exception requests are opened. That said, sovereign immunity is the least of our concerns for now.
I think between myself and our outside counsel, we laid out the issues pretty clearly in the post (and those aren’t all of them). If you do a little research on who our outside counsel is, you may reflect that these issues aren’t simply excuses for avoiding the GPL, but born out of a mandate to listen to our Stakeholder Community — those who need to adopt and deploy our work, lest our efforts be merely an academic exercise resulting in a Smithsonian exhibit. Thanks for your comments!
I am not a lawyer, I just have an interest in the technology area of law, data protection and licensing. You raise a very interesting point about contracts and additional terms. I would not have interpreted a contract as being an additional term to the license, because it does not bind non-parties. The situation is Alice and Bob have a contract where Alice writes some software, Bob pays Alice and Alice provides Bob with the output of the work for hire under the license agreed in the contract. Alice and Bob are parties to the contract and as long as the contract does not contradict the license they are bound by both. Bob (or Alice for that matter) can now give a copy of the work, under the license to Charlie. Bob is permitted to do that by the license, and by the contract (or it would contradict the license). The important thing is that Charlie is not bound by the contract. The contract is entered into by specific parties agreeing to it, the conditions of the contract are not tied to the license because they don’t travel with it. If this isn’t a permitted scenario under the legal interpretation of the GPL (MPL is a perfectly good license to use by the way, just GPL is the best one to use in abstract examples as it is the most studied) then it really should be, I would consider it a bug in the GPL if not.
Preston, there is nothing ‘coercive’ about the GPL. It doesn’t force you to use it, or the software licensed by it, that is your choice. Releasing software under the GPL is my choice, just as Microsoft made their choice about how to release their software. Microsoft doesn’t force you to use their software either.
As to whether the GPL is appropriate for voting software, I don’t know, it’s not something I’ve looked at. However I am of the opinion that any license which allows the code to be taken proprietary such as the BSD and Apache licenses is not appropriate for voting machine software. That would be equivalent to allowing someone to take your Constitution proprietary!
Good luck going forward.
Wayne