Licensing issues for OVC production software...

From: Joseph Lorenzo Hall <jhall_at_sims_dot_berkeley_dot_edu>
Date: Sat May 29 2004 - 18:07:27 CDT

Hopefully this will start some discussion! -Joe

PS: If you don't like reading Markdown syntax, attached is an HTML
version of this.

# Licensing the OVC's Software
##### [Joseph Lorenzo Hall][jlh], UC Berkeley (SIMS)
(This document is written in [Markdown][] syntax.  Links are phrased
surrounded by square-brackets followed by and identifier which holds
the link URL below the paragraph. Markdown allows a document that is
easy to read with an ASCII text reader but also can be parsed into
HTML (HTML version attached to this email) for easy linking/
## Introduction
As I see it, there are a number of quite complex issues surrounding
the licensing of software that the OVC is beginning to produce. This
is meant to air a good deal of those concerns and to start a vigorous
I think the larger issues come down to the following list (I've listed
them in order of what I see as being the easiest to deal with to the
hardest to deal with):
1. Any open hardware licensing (and/or requirements).
2. Satisfying the institutions who donate employee time to working on
   OVC code.
3. Getting developers from multiple states and organizations to
   contribute to OVC code.
4. Ensuring that the OVC can make use of already-licensed code in the
5. Public Policy reasons for having the code licensed under one sort
   or the other.
## Any open hardware licensing (and/or requirements).
As Alan pointed out, the only piece of OVC-designed and created
hardware will likely be the PC cage.
Note, however that as the Secretary of State here in California [has
mandated that a very specific piece of the voting system should run on
open source software][mandate], he has said nothing about the hardware
running that software (or what he means by "open source").  It seems
like a natural extension, from a public policy point of view, that he
also mandate that the hardware running this open source software
should also be "open source". Note that this type of "open source"
will be very different from the software idea of "open source" as
merely delivering the technical specifications and documents (auto-CAD
files, etc.) that would allow you to build the object would not be
enough; you'd also need design documentation and other types of
relational information that allowed one to figure out what each
circuit was doing.
Hopefully, we'll get some clarity on this issue sometime soon and see
if Shelley defines what he means by "open source" and if this
particular mandate should also be extended to the hardware involved in
## Satisfying the institutions who donate employee time to working on OVC code.
Institutions primarily want to do a few things when it comes to
software licensing: make money and avoid liability.
On the making money side, I think that we'll get no hassle from
various institutions as the OVC's software isn't necessarily
commercializable and even then, as an open source project, it would
likely be under a services-based model or a dual-licensing model like
MySQL (where even the client libraries are licensed under the
[GPL][gpl] (instead of the [LGPL][lgpl] so that any proprietary
software development would have to obtain a propreitary license from
On the liability side, we can place a standard disclaimer of warranty
like that in the [BSD][bsd] license (or see the [UC example][uclic])
that will likely satisfy any institution worried about liability.
## Getting developers from multiple states and organizations to contribute to OVC code.
Developers are naturally concerned with the details of the license
under which a project that they are (or plan on) contributing to is
developed. I don't think I need to go into this too much seeing as the
current crop of OVC volunteers seem to be seasoned software
Some developers are reluctant to contribute to code licensed a certain
way. This won't be much of a problem with funded (paid) developers as
they won't really have a choice and they don't have the copyright in
the work they develop (this would be a work for hire).  However, this
will be a large consideration for any non-paid developers who do share
copyright with the OVC.
In this respect, it might be wise to have the copyright of all
contributions signed over to one organization (OVC, FSF, etc.).  The
benefit of this is that there is one organization with a board that
can make decisions on behalf of the project about copyright-related
issues.  If the GPL, LGPL and [FDL][fdl] is the licensing suite chosen
by the OVC, I can do my best to approach the FSF and attempt to get
the OVC's project assigned.
## Ensuring that the OVC can make use of already-licensed code in the project.
**I see the next two items as being the big show-stoppers that will
require a bit more collective thought.**
As I mentioned in a previous post to this list, there is an issue of
license compatibility.  That is, depending on the license the OVC
chooses to license their software under, OVC developers may or may not
be able to take advantage of other code.
This is often seen with GPL-compatibility problems.  That is, if a
license is more restrictive than the GPL, it is
[GPL-incompatible][faq1] and the two bodies of code may not be
incorporated into a larger work.
For example, anything more permissive than the GPL, is usually
compatible with the GPL. For a partial list of licenses that are
compatible with the GPL, see this list:
This list includes the modern BSD license (without the advertising
clause) which tends to be the favorite of UC (I believe).
I am of the mind that it would be wise for the members of the OVC to
think about what code they might want to incorporate into the OVC
code-base before starting development.  In this manner, we can see what
the licenses are for all that code and consider constructing a license
(or using one already constructed like the BSD or GPL license) that
would allow the OVC development team to use the code they need to get
the job done.
At a minimum, it would seem wise for the license that the OVC adopts
to be GPL-compatible (that is, as restrictive or less restrictive
compared to the GNU GPL).  As there is much much GPL-licensed code out
there, it would mean that the OVC code take advantage of any of this
code it wanted to. Note that incorporating GPL code into a project
will result in the whole project necessarily being licensed under the
There is also a lot of code licensed under other licenses like the BSD
license.  Note that you could not incorporate GPL- or LGPL-licensed
code into a BSD-licensed code base (and still license and distribute
the resultant work under the BSD license).
## Public Policy reasons for having the code licensed under one sort or the other.
There are public policy reasons for choosing one or another open
source license.  That is, the primary impetuses for having open-source
code is for transparency and auditability. (If you can think of others
let me know)
### Transparency
Transparency is easily enough facilitated by simply disclosing the
code. This is similar to (I believe) MS's Shared Source program or
what VoteHere recently did with disclosing their code base.  While
this does allow interested members of the public who have a lot of
time on their hands to read the source code, it does not allow them to
test the code using debugging tools and/or recompilation. While it is
possible to discover bugs and trojans via reading source code, it will
inevitably not result in all of them being found and this is horribly
grueling work with many inefficiencies and drawbacks.
To facilitate this, one merely needs a license that says something to
the effect, "You are allowed to download and copy this particular
format of our source code files (PDF, TXT, HTML, etc.). We reserved
the right of further distribution, modification and any derivative
works." Note this would not be GPL-compatible or even BSD-compatible.
### Auditability
As for auditability, testing people need at a minimum the original
source code files, all support libraries and operating system software
and ideally a hardware platform or trusted emulator that allows as
little modification of the original source code as possible. (What
else is needed?)
In terms of a the rights a testing body would need to this code: they
would need access to source code files, the right to copy these files
and the right to modify the source code. This could be accomplished
with a BSD-license.
What about distribution and derivative works?  That is, should a
testing authority be allowed to distribute modified versions of open
source election software (or just patches)? It would seem like a good
idea as long as there is a vetting process within the OVC, for
example, that would make sure the code patch being applied did what it
was supposed to do and came from a trusted developer.
It would seem here that the GPL's copyleft provision could be
helpful. That is, the testing authorities or developers would be
required to release their modified code or their patches under the
GPL.  Otherwise, with a BSD license for example, the testing authority
or developer could develop whole forked code bases where bugs were
fixed or repaired and features added, removed, etc. without giving
this code back to the original project.  This could be a bad thing,
but it could also be a good thing as it could create competition in
election software services and maintenance much in the way that we see
GNU/Linux service and maintenance competition... with the stark added
benefit that counties *must* have election systems in place in order
to operate as a democracy and that the OVC's will be much cheaper and
likely more capable. In this respect the OVC could become the "Linux
kernel" of voting software and even work in close contact with vendors
as is done in GNU/Linux development.

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain

Received on Mon May 31 23:18:13 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:17 CDT