[CAVO] [License-review] Submission of OSET Public License for Approval

[Tim Mayer]

Perhaps a review of the best, in my view,  fundamental and unique principal
for securing our electronically captured and tabulated vote is appropriate
at this juncture.

That most important principal, again in my view, is the notion that the
more folks that have access to the software code, including all the various
code produced for the data base of captured and counting purposes, but the
various machine codes, firmware, etc., the more folks that can and *will*
actually evaluate its effectiveness, the better. Quite deliberately
anathema to security through obscurity. Therefore, it would seem,
proprietary software, whether disclosed, open, free, public, or otherwise,
would have a negative impact on the fundamental notion of getting as many
eyes on the code as possible.

My understanding of the impact of having a particular license to go with a
particular way of developing code, is to increase the involvement in the
ongoing process by encouraging as much involvement as possible to get as
many eyes as possible on the code.

Whatever license and development process accomplishes this fundamental
goal, that would be the way to go.

It seems, that although Oset, and other schemas as well, may be
alternatives that can be considered, my view is that ultimately, whether a
license is OSI approved or not, that license must still be considered in
light of alternative licenses development for the same purpose.

Presently, the GPLv3 license, coupled with an open source community
developed software, is by all measure, the electronic voting software
solution that best reflects the fundamental goal of getting as many eyes as
possible on the code.

Whether Oset, or any other schema, can deliver, or even wants to reflect
the fundamental principal of as many eyes as possible on the code, is the
question to be answered.

All other issues regarding licenses and code development are, although
relevant, substantially immaterial to this fundamental principal.

Thank you,

Tim Mayer

On Mon, Sep 7, 2015 at 11:39 AM, Lawrence Rosen <lrosen at rosenlaw.com> wrote:

> Heather Meeker wrote:
> > If there is a difference, it would be a matter of national security or
> > necessity of public interest that is not embodied in any law.
> > I would expect that to be rare, but the clarification was important
> > to our constituency.
>
> Now we get to policy issues that seriously concern me.
>
> What are these necessities of public interest that are NOT embodied in
> law? Why should those ambiguous (so-called) national security or public
> interests affect source or binary FOSS code in any way? These are OUR
> elections we're talking about. There is enormous fear about OUR elections
> software being restricted or abused for private reasons. There is an
> important element of trust that certain FOSS licenses can help provide.
>
> That is why open source elections solutions are so critical to all of us.
> That is why FOSS licenses matter for this solution stack.
>
> While it is true that the OSET license may be approved by OSI, it does not
> mean that we should ever allow elections software to be affected by vague
> "national security or necessity of public interest" that our legislatures
> don't put into law.
>
> When they DO put it into law, of course, we'll all obey it regardless of
> what our copyright licenses say.
>
> /Larry
>
>
> -----Original Message-----
> From: Meeker, Heather J. [mailto:hmeeker at omm.com]
> Sent: Monday, September 7, 2015 11:01 AM
> To: Josh Berkus <josh at postgresql.org>; License submissions for OSI review
> <license-review at opensource.org>
> Subject: Re: [License-review] Submission of OSET Public License for
> Approval
>
> I was sidetracked because Section 4 is, for the most part, already in MPL
> 2.0 (whereas 3.5B is the new language we added).  In Section 4, we added
> "national security or necessity of public interest" to "statute, judicial
> order, or regulation."  So if there is a concern generally with this
> mechanism, it also exists for MPL 2.0.  If there is a difference, it would
> be a matter of national security or necessity of public interest that is
> not embodied in any law.  I would expect that to be rare, but the
> clarification was important to our constituency.
>
> -----Original Message-----
> From: Josh Berkus [mailto:josh at postgresql.org]
> Sent: Thursday, September 03, 2015 2:58 PM
> To: Meeker, Heather J.; License submissions for OSI review
> Cc: Gregory Miller; John Sebes; christine at osetfoundation.org
> Subject: Re: [License-review] Submission of OSET Public License for
> Approval
>
> On 09/03/2015 02:49 PM, Meeker, Heather J. wrote:
> > 2. Ability to adjust terms downstream
> > This provision says you can "place additional conditions on the right
> granted" and that would not include additional grants of rights or waiver
> of conditions.  That distinction may sound like a legal technicality, but
> in open source licensing there is an important difference between license
> conditions -- which narrow a grant of rights -- and granting additional
> rights or removing conditions.  For example, in most copyleft licenses, you
> cannot place additional conditions on the exercise of the license at all,
> or remove any condition.   Our variation is actually very narrow -- only as
> required by law.  I take your point that states can pass crazy laws.  But
> if a law says a state can't use the software for elections except with
> restriction X, and the license (such as GPL) says you can't impose
> restriction X, then the state cannot use the software at all, and we are
> trying to avoid this result.
>
> Um ... no?
>
> I'm talking about clause 4, 4. Inability to Comply Due to Statue or
> Regulation.  This quite clearly allows recipients to waive some or all of
> the license provisions.
>
> --Josh Berkus
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
>
> _______________________________________________
> CAVO mailing list
> CAVO at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/cavo_lists.opensource.org/attachments/20150907/7494ee10/attachment.html>