Re: License for EVM?

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Thu Aug 14 2003 - 19:16:26 CDT

This is a very interesting subject, David. For the demo, however, I don't
think it's very important. When you say "EVM" I assume you're talking about
the demo. i.e., since the software is throwaway and has no conceivable use
other than demonstration purposes, I don't think it matters too much. I
suppose that while the overall demo system will be thrown out, it's possible
that some routines or snippets of code might be re-used.

The larger project where the production software would be produced is
tentatively called UCVS.

If the production software is developed under a core grant (or grants) to
the University of California, it's likely that the license agreement (where
the client is a county government) will be written by UC Lawyers. We can
make suggestions and recommendations, but it will be up to them to decide
the exact nature of the license agreement.

For the production software, I don't think Public Domain will do. It will
be important to identify a specific entity which owns the software and
handles version control and maintenance issues, as well as providing a site
for download of the authentic product (and perhaps tools to authenticate the

We're also talking about establishing an Open Voting Consortium. This is
will be developmented mainly as the vehicle that will deliver the eventual
hardware product. It could also own the software, although we need to think
that through a little more.


----- Original Message -----
From: "David Mertz" <>
To: <>
Sent: Thursday, August 14, 2003 3:34 PM
Subject: [voting-project] License for EVM?

> I believe we should explicitly declare what license our EVM software
> will have. We have always said it will be "open source" (OS), but there
> are many different OS licenses. At the very least, we should pick
> something that is OSI (Open Source Initiative) approved, but which
> particular one depends on how we perceive our purposes.
> I think we should choose one of the "big four" choices. Lots of
> projects like Mozilla, Apple, Alladin, have their own minor variations,
> usually to stick in a few clauses about the particular
> companies/organizations involved. But we don't need such extra
> complication. I perceive the choices as (simplifying the options):
> Public Domain:
> Not really a license at all, but the lack of any copyright claim
> in the first place. Anyone can do whatever they want with our
> code (except prevent us from using our own code, which belongs
> to no one).
> BSD:
> Largely the same principle as public domain. Anyone can use our
> code. Some variations require that they attribute us in any
> derived application. Some lawyers (but certainly not all) feel
> that the Berne Convention and later copyright law doesn't really
> have a concept of "releasing to public domain", so the BSD is
> more explicit.
> Anyone producing a directly derived work must release it as LGPL
> (or as GPL). However, developers may let their applications
> use "late binding" to our code without incurring restrictions on
> the license terms of their own code. E.g. they can utilize a
> .DLL, .so or .dynlib we produce, but not change ours (except by
> also releasing their enhancement).
> GPL:
> Anyone who uses our code as a basis for something else is
> required to release their application as GPL also. Derived
> works enter a contract to remain perpetually free.
> My own take is that we should call everything we do public domain. This
> seems consistent with the quasi-governmental nature of our project (in
> the good old days of democracy, all material produced by the gov't was
> automatically public domain). But I think being explicit about any
> option is more important than choosing this particular approach.
> I'm biased inasmuch as my own Gnosis Utilities are released to the
> public domain. Hmmm... what about wxPython/wxWindows?
> Yours, David...
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Aug 31 23:17:09 2003

This archive was generated by hypermail 2.1.8 : Sun Aug 31 2003 - 23:17:17 CDT