<div dir="ltr">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.<div><br></div><div>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 <b><u>will</u></b> 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.</div><div><br></div><div>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.</div><div><br></div><div>Whatever license and development process accomplishes this fundamental goal, that would be the way to go.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>All other issues regarding licenses and code development are, although relevant, substantially immaterial to this fundamental principal.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Thank you,<div><br></div><div>Tim Mayer</div></div></div></div>
<br><div class="gmail_quote">On Mon, Sep 7, 2015 at 11:39 AM, Lawrence Rosen <span dir="ltr"><<a href="mailto:lrosen@rosenlaw.com" target="_blank">lrosen@rosenlaw.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Heather Meeker wrote:<br>
> If there is a difference, it would be a matter of national security or<br>
> necessity of public interest that is not embodied in any law.<br>
> I would expect that to be rare, but the clarification was important<br>
> to our constituency.<br>
<br>
Now we get to policy issues that seriously concern me.<br>
<br>
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.<br>
<br>
That is why open source elections solutions are so critical to all of us. That is why FOSS licenses matter for this solution stack.<br>
<br>
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.<br>
<br>
When they DO put it into law, of course, we'll all obey it regardless of what our copyright licenses say.<br>
<br>
/Larry<br>
<span class=""><br>
<br>
-----Original Message-----<br>
From: Meeker, Heather J. [mailto:<a href="mailto:hmeeker@omm.com">hmeeker@omm.com</a>]<br>
</span>Sent: Monday, September 7, 2015 11:01 AM<br>
To: Josh Berkus <<a href="mailto:josh@postgresql.org">josh@postgresql.org</a>>; License submissions for OSI review <<a href="mailto:license-review@opensource.org">license-review@opensource.org</a>><br>
Subject: Re: [License-review] Submission of OSET Public License for Approval<br>
<br>
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.<br>
<br>
-----Original Message-----<br>
From: Josh Berkus [mailto:<a href="mailto:josh@postgresql.org">josh@postgresql.org</a>]<br>
Sent: Thursday, September 03, 2015 2:58 PM<br>
To: Meeker, Heather J.; License submissions for OSI review<br>
Cc: Gregory Miller; John Sebes; <a href="mailto:christine@osetfoundation.org">christine@osetfoundation.org</a><br>
Subject: Re: [License-review] Submission of OSET Public License for Approval<br>
<br>
On 09/03/2015 02:49 PM, Meeker, Heather J. wrote:<br>
> 2. Ability to adjust terms downstream<br>
> 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.<br>
<br>
Um ... no?<br>
<br>
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.<br>
<br>
--Josh Berkus<br>
<span class="im HOEnZb">_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
<a href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review" rel="noreferrer" target="_blank">https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
CAVO mailing list<br>
<a href="mailto:CAVO@opensource.org">CAVO@opensource.org</a><br>
<a href="https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo" rel="noreferrer" target="_blank">https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo</a><br>
</div></div></blockquote></div><br></div>