RE: License for EVM?

From: Arnie Urken <aurken_at_stevens-tech_dot_edu>
Date: Fri Aug 15 2003 - 12:53:12 CDT

Doug,

I want to support what you said about "public" licensing and the importance
of developing a systematic licensing policy.

A few months ago--in a different context--you noted that quality control and
configuration management issues would make it difficult to produce a
reliable voting tool in a purely "open" environment. This is certainly true
if we are going to consider the development and/or use of formal tools such
as type-safe transactions, static program analysis, and model checking as
the software evolves.

Perhaps I am missing it, but wouldn't all of this be consistent with a
"community licensing" approach?

Arnie

-----Original Message-----
From: owner-voting-project@afterburner.sonic.net
[mailto:owner-voting-project@afterburner.sonic.net]On Behalf Of Douglas
W. Jones
Sent: Friday, August 15, 2003 6:42 AM
To: voting-project@lists.sonic.net
Subject: Re: [voting-project] License for EVM?

On Thursday, August 14, 2003, at 05:34 PM, David Mertz wrote:

> 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.

True, and it may be the case that none are applicable to a production
electronic voting application.

> At the very least, we should pick something that is OSI (Open Source
> Initiative) approved,

Not necessarily!

I should note, up front, that my quibbles with this only apply to
production voting system code, not to the prototype. I have no
objections if prototype code is thrown out into the public domain.

The problem arises in production voting systems, where the provenance
of each and every byte of object code must be fully documented and
the derivation of each bit must be clear. In that domain, open
source is an invitation to configuration management nightmares.

Of course, we may end up maintaining strict controls over our own
code internally, but the moment Joe Hacker takes a copy of our code
and enhances it, it's out from under the strict configuration
management that must be maintained.

In sum, we don't care who copies our code for non-voting applications,
but once copies are made out from under the control of the official
project, they ought to be viewed as inelligable for inclusion in
voting systems unless they're treated as being entirely suspect code,
and they must not be treated as gaining any stature because of their
derivation from what we hope will be a superior product.

> 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).

        A lack of copyright claim doesn't place code in the
        public domain. Under copyright law, everything is born
        copyrighted, so if we want to put someting in the public
        domain, we have to explicitly give away our rights.

> BSD:
> Largely the same principle as public domain...

        Except that it fixes the above problem.

> LGPL:
> 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).

        There are strong reasons to forbid the use of dynamic or
        late binding in voting systems. Similarly, there are
        strong reasons to forbid all interpretive execution in voting
        systems. The reason is, these must be audited with extreme
        care in order to guarantee that they can't be used to breach
        the security of the system.

        The current flap about the Diebold system, for example,
        includes allegations that there's a DLL hiding in the system
        that can be used to alter the record of the votes. This DLL
        isn't part of the OS that was approved for that system, and
        it isn't part of the application software, but rather, it's
        alleged to be "slipped into the system". None of this is
        proven, of course, but it illustrates the kind of threat that
        dynamic linkage or interpretation can pose. If these mechanisms
        are provably absent from the system, then configuration audits
        to check for trojans being slid into the system are far easier
        to conduct!

> 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.

        But note, none of the above approaches to the source solve the
        problem of assuring that sound configuration management is used.
        Therefore, all of these put us in a position where derived
        works done out from under our control are potentially a threat
        to democracy if they're used for voting.

        In fact, we really don't care if our code is used for non-voting
        applications. It's only the reuse of our code for voting
        applications out from under strict revision control that poses
        problems.

                                Doug Jones
                                jones@cs.uiowa.edu
==================================================================
= 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