<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>Larry,</div><div><br></div><div>What I see happening here is a "lawyer perspective" on how software gets written and delivered compared to an actual developers perspective and how the software is really being packaged.</div><div><br></div><div class="MsoPlainText">> A main justification for having this alteration of MPL 2.0 seems to be </div><div class="MsoPlainText">> that the GPL license family would be inappropriate because it would </div><div class="MsoPlainText">> cause problems, possibly even contractually insurmountable ones, in </div><div class="MsoPlainText">> procurement. So my point is that this seems to assume that the </div><div class="MsoPlainText">> products being offered for procurement contain no GPL-licensed code, </div><div class="MsoPlainText">> and perhaps only contain OSET-PL plus code under noncopyleft licenses.</div><div></div><div><br></div><div>Typically the software developer is NOT tampering with the layers of source code around at all - in fact they are striving to use those AS IS - and NOT embedding any of the source code in their solution. Quite the reverse - they are only interested in using compiled libraries and API calls to avoid making their life more complex. If there are bugs or changes/enhancements desired - these will be referred back to the managing project for resolution. Similarly standalone services - such as Apache server - will be used out-the-box and configured using the control files, user management accounts, profiles and parameters that are available for that purpose.</div><div><br></div><div>When it comes to delivery there are then three choices:</div><div><br></div><div>a) Providing detailed install instructions to manually locate each component from the original project site, download, install, and configure.</div><div><br></div><div>b) Provide a package that performs a) for the user with assistive menus and hand-holding - selecting the specific components and installing them<br></div><div><br></div><div>c) Pre-built package and installer - developer obtains all the necessary downloads - creates an install package - fully automates b) for the user.</div><div><br></div><div>What this means is in terms of license compatibility is that the great majority of the solution stack as simply used as is - and therefore the individual license terms apply - and no conflicts can occur.</div><div><br></div><div>Where a developer is actually using software components IN THEIR OWN CODE then they need to ensure that those parts are licensed appropriately. However - I do not see that this provides ANY CONFLICTS for election officials or parties. They are essentially using each component part according to the individual licensing terms - and not attempting to modify the underlying code in any way.<br></div><div><br></div><div>David</div><div><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [CAVO] [License-review] Submission of OSET Public License<br>
for Approval<br>
From: "Lawrence Rosen" <<a href="mailto:lrosen@rosenlaw.com">lrosen@rosenlaw.com</a>><br>
Date: Tue, September 08, 2015 12:28 pm<br>
To: "'CAVO'" <<a href="mailto:cavo@opensource.org">cavo@opensource.org</a>><br>
Cc: Lawrence Rosen <<a href="mailto:lrosen@rosenlaw.com">lrosen@rosenlaw.com</a>><br>
<br>
<style>
#wmQuoteWrapper /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}
#wmQuoteWrapper @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}
#wmQuoteWrapper /* Style Definitions */ p.MsoNormal, #wmQuoteWrapper li.MsoNormal, #wmQuoteWrapper div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;}
#wmQuoteWrapper a:link, #wmQuoteWrapper span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;}
#wmQuoteWrapper a:visited, #wmQuoteWrapper span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;}
#wmQuoteWrapper p.MsoPlainText, #wmQuoteWrapper li.MsoPlainText, #wmQuoteWrapper div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif; color:black;}
#wmQuoteWrapper span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:"Calibri",sans-serif; color:black;}
#wmQuoteWrapper span.EmailStyle19 {mso-style-type:personal-compose;}
#wmQuoteWrapper .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;}
#wmQuoteWrapper @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}
#wmQuoteWrapper div.WordSection1 {page:WordSection1;}
</style><div class="WordSection1"><div class="MsoPlainText">Heather Meeker wrote:<o:p></o:p></div><div class="MsoPlainText">> I do think this is a license compatibility point, in a way. <o:p></o:p></div><div class="MsoPlainText">> Permissive licenses for third-party components would allow <o:p></o:p></div><div class="MsoPlainText">> the code as a whole to be licensed under the terms of OSET. <o:p></o:p></div><div class="MsoPlainText">> But a copyleft license would not. <o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">We are not just speaking of "components" but of a "solution stack" for elections. It <u>will</u> include GPL and MPL components. Inevitably. <o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">All existing FOSS licenses (permissive and copyleft) are already compatible for aggregates such as comprehensive election systems. (See OSD #1.) The government agencies that acquire such systems are already faced with all those FOSS licenses. Good for FOSS!<o:p></o:p></div><div class="MsoPlainText"> <o:p></o:p></div><div class="MsoPlainText">This does not affect whether the OSET-PL should be approved by OSI. Lots of licenses already are. We are mostly focusing on the justification(s) you are asserting for it.<o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">/Larry<o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">-----Original Message-----<br>From: Meeker, Heather J. [<a href="mailto:hmeeker@omm.com">mailto:hmeeker@omm.com</a>] <br>Sent: Tuesday, September 8, 2015 8:51 AM<br>To: 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<o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">Thanks. I do think this is a license compatibility point, in a way. Permissive licenses for third-party components would allow the code as a whole to be licensed under the terms of OSET. But a copyleft license would not. However, incompatibility with other copyleft licenses is not a problem we can solve own our own. We have tried to do as much as we can to solve it on the outbound side with our license compatibility terms. But on the inbound side, it's up to the third-party copyright owner.<o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">Assuming that such incompatibility does create an issue, then this question dovetails back to the question of whether we can be successful with the license. In other words, if I can rephrase your question a bit, is it possible to build a complete enough voting system without using code under incompatible licenses? It's a good point you raise. But as I have commented before, our likelihood of success is not the criterion for license approval.<o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">Sent from my tablet --Heather Meeker<o:p></o:p></div><div class="MsoPlainText"><o:p> </o:p></div><div class="MsoPlainText">> On Sep 8, 2015, at 8:34 AM, Richard Fontana <<a target="_blank" href="mailto:fontana@sharpeleven.org"><span style="color:black;text-decoration:none">fontana@sharpeleven.org</span></a>> wrote:<o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">> My comment wasn't about license compatibility. Rather:<o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">> Clearly OSET favored some kind of copyleft license, and you've made a <o:p></o:p></div><div class="MsoPlainText">> few comments about the GPL that seem to imply (possibly reinforced by <o:p></o:p></div><div class="MsoPlainText">> the comments of the CAVO folks, unless this was in response to those<o:p></o:p></div><div class="MsoPlainText">> comments) that in this open source voting systems space there is a <o:p></o:p></div><div class="MsoPlainText">> background community preference for the GPL, maybe even specifically <o:p></o:p></div><div class="MsoPlainText">> GPLv3.<o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">> A main justification for having this alteration of MPL 2.0 seems to be <o:p></o:p></div><div class="MsoPlainText">> that the GPL license family would be inappropriate because it would <o:p></o:p></div><div class="MsoPlainText">> cause problems, possibly even contractually insurmountable ones, in <o:p></o:p></div><div class="MsoPlainText">> procurement. So my point is that this seems to assume that the <o:p></o:p></div><div class="MsoPlainText">> products being offered for procurement contain no GPL-licensed code, <o:p></o:p></div><div class="MsoPlainText">> and perhaps only contain OSET-PL plus code under noncopyleft licenses.<o:p></o:p></div><div class="MsoPlainText">> If they do contain GPL-licensed code -- for example, let's say a <o:p></o:p></div><div class="MsoPlainText">> software stack that includes the Linux kernel -- you've eliminated any <o:p></o:p></div><div class="MsoPlainText">> benefit you otherwise might have gotten from the novel features of <o:p></o:p></div><div class="MsoPlainText">> this license. (Similarly, if your stack includes any MPL 2.0 code, you <o:p></o:p></div><div class="MsoPlainText">> are stuck with the limitations of MPL 2.0 relative to the changed <o:p></o:p></div><div class="MsoPlainText">> features in OSET-PL.) One or more of the people from CAVO seemed to be <o:p></o:p></div><div class="MsoPlainText">> making a similar point.<o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">> Thanks for the clarification about why MPL 2.0's 'Executable Forms'<o:p></o:p></div><div class="MsoPlainText">> provision is not sufficient for OSET's needs.<o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">> Richard<o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">> <o:p></o:p></div><div class="MsoPlainText">>> On Mon, Sep 07, 2015 at 05:34:06PM +0000, Meeker, Heather J. wrote:<o:p></o:p></div><div class="MsoPlainText">>> Re: Aren't you assuming that such an open source technology system <o:p></o:p></div><div class="MsoPlainText">>> will not contain any GPL-licensed software....<o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>> No, we are not at the point of making such assumptions. We don't expect to limit this license to only one software package, so there are many possible configurations of software and attendant licenses. If this is a licensing compatibility concern, the OSET license is no less compatible with other licenses that most copyleft licenses already approved, and more so than some approved licenses. If this is a question of whether election procurement managers are likely to accept our license, then that is a different question. (Please see my prior post on this point.) <o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>> Re: One other question: MPL 2.0 allows using different terms for <o:p></o:p></div><div class="MsoPlainText">>> 'Executable .....<o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>> So does OSET (we use the same provision as MPL2 2.0), but we are assuming that provisioning election systems will include delivery of source code -- or at least, that we need to allow for that possibility. <o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>> -----Original Message-----<o:p></o:p></div><div class="MsoPlainText">>> From: License-review [<a target="_blank" href="mailto:license-review-bounces@opensource.org"><span style="color:black;text-decoration:none">mailto:license-review-bounces@opensource.org</span></a>] <o:p></o:p></div><div class="MsoPlainText">>> On Behalf Of Richard Fontana<o:p></o:p></div><div class="MsoPlainText">>> Sent: Sunday, September 06, 2015 11:03 AM<o:p></o:p></div><div class="MsoPlainText">>> To: License submissions for OSI review<o:p></o:p></div><div class="MsoPlainText">>> Subject: Re: [License-review] Submission of OSET Public License for <o:p></o:p></div><div class="MsoPlainText">>> Approval<o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>>> On Tue, Sep 01, 2015 at 10:18:59PM +0000, Meeker, Heather J. wrote:<o:p></o:p></div><div class="MsoPlainText">>>> Our stakeholder community—elections administrators and officials—are <o:p></o:p></div><div class="MsoPlainText">>>> very receptive to acquiring open source software-based election and <o:p></o:p></div><div class="MsoPlainText">>>> voting systems provided the software (and related support and <o:p></o:p></div><div class="MsoPlainText">>>> services) can be legally acquired through their procurement process. <o:p></o:p></div><div class="MsoPlainText">>>> A primary ingredient of their procurement process is terms and <o:p></o:p></div><div class="MsoPlainText">>>> conditions of software licensing that meet their regulatory requirements.<o:p></o:p></div><div class="MsoPlainText">>>> <o:p></o:p></div><div class="MsoPlainText">>>> While governments already often acquire open source technology on an <o:p></o:p></div><div class="MsoPlainText">>>> ad hoc basis under existing licenses, they face more, and different, <o:p></o:p></div><div class="MsoPlainText">>>> hurdles acquiring open source election systems. Open source <o:p></o:p></div><div class="MsoPlainText">>>> software that is merely part of a larger IT system is usually <o:p></o:p></div><div class="MsoPlainText">>>> covered by two documents—the open source license, and an overarching <o:p></o:p></div><div class="MsoPlainText">>>> (and often superseding) procurement agreement that fits with the <o:p></o:p></div><div class="MsoPlainText">>>> applicable regulations. Where an agency is acquiring an entire open <o:p></o:p></div><div class="MsoPlainText">>>> source technology system—especially technology to be used in public <o:p></o:p></div><div class="MsoPlainText">>>> elections and subject to competitive bidding—procurement regulations need to be handled properly within the four corners of the open source license.<o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>> I'm trying to understand this particular point. Aren't you assuming <o:p></o:p></div><div class="MsoPlainText">>> that such an open source technology system will not contain any <o:p></o:p></div><div class="MsoPlainText">>> GPL-licensed software, perhaps not any copyleft software (perhaps not <o:p></o:p></div><div class="MsoPlainText">>> any software under any other open source license -- in other words <o:p></o:p></div><div class="MsoPlainText">>> are you assuming that the 'technology system' will consist solely of <o:p></o:p></div><div class="MsoPlainText">>> software under the OSET-PL)? Because otherwise you have a <o:p></o:p></div><div class="MsoPlainText">>> mixed-license product where only some portion of the product is <o:p></o:p></div><div class="MsoPlainText">>> licensed in such a way as to meet your goals.<o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>> One other question: MPL 2.0 allows using different terms for <o:p></o:p></div><div class="MsoPlainText">>> 'Executable Forms', so presumably you could meet your objectives here <o:p></o:p></div><div class="MsoPlainText">>> by way of an appopriate non-open-source license for the Excecutable <o:p></o:p></div><div class="MsoPlainText">>> Form. Why is MPL 2.0 not suitable - is it because you expect to be <o:p></o:p></div><div class="MsoPlainText">>> distributing 'Source Code' (as defined in OSET-PL/MPL 2.0) in a <o:p></o:p></div><div class="MsoPlainText">>> procurement context, or is it because of some desire to be able to <o:p></o:p></div><div class="MsoPlainText">>> claim that the license used in the procurement context is open source?<o:p></o:p></div><div class="MsoPlainText">>> <o:p></o:p></div><div class="MsoPlainText">>> Richard<o:p></o:p></div><div class="MsoPlainText">>> _______________________________________________<o:p></o:p></div><div class="MsoPlainText">>> License-review mailing list<o:p></o:p></div><div class="MsoPlainText">>> <a target="_blank" href="mailto:License-review@opensource.org"><span style="color:black;text-decoration:none">License-review@opensource.org</span></a><o:p></o:p></div><div class="MsoPlainText">>> <a target="_blank" href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review"><span style="color:black;text-decoration:none">https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review</span></a><o:p></o:p></div><div class="MsoPlainText">>> _______________________________________________<o:p></o:p></div><div class="MsoPlainText">>> License-review mailing list<o:p></o:p></div><div class="MsoPlainText">>> <a target="_blank" href="mailto:License-review@opensource.org"><span style="color:black;text-decoration:none">License-review@opensource.org</span></a><o:p></o:p></div><div class="MsoPlainText">>> <a target="_blank" href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review"><span style="color:black;text-decoration:none">https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review</span></a><o:p></o:p></div><div class="MsoPlainText">> _______________________________________________<o:p></o:p></div><div class="MsoPlainText">> License-review mailing list<o:p></o:p></div><div class="MsoPlainText">> <a target="_blank" href="mailto:License-review@opensource.org"><span style="color:black;text-decoration:none">License-review@opensource.org</span></a><o:p></o:p></div><div class="MsoPlainText">> <a target="_blank" href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review"><span style="color:black;text-decoration:none">https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review</span></a><o:p></o:p></div><div class="MsoPlainText">_______________________________________________<o:p></o:p></div><div class="MsoPlainText">License-review mailing list<o:p></o:p></div><div class="MsoPlainText"><a target="_blank" href="mailto:License-review@opensource.org"><span style="color:black;text-decoration:none">License-review@opensource.org</span></a><o:p></o:p></div><div class="MsoPlainText"><a target="_blank" href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review"><span style="color:black;text-decoration:none">https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review</span></a><o:p></o:p></div></div><hr>_______________________________________________<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">https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo</a><br>
</div>
</blockquote></span></body></html>