<div dir="ltr">It seems to me that this new submission has repaired some of the more trivial reasons for rejection of the license, while preserving the main one.<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><pre class="m_3328895060422644984gmail-aLF-aPX-K0-aPE" style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px">#### 4.2.1. No Withholding User Data</pre></div><div><pre class="m_3328895060422644984gmail-aLF-aPX-K0-aPE" style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px">Throughout any period in which You exercise any of the permissions granted to </pre></div><div><pre class="m_3328895060422644984gmail-aLF-aPX-K0-aPE" style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px">You under this License, You must also provide to any Recipient to whom you </pre></div><div><pre class="m_3328895060422644984gmail-aLF-aPX-K0-aPE" style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px">provide services via the Work, a no-charge copy, provided in a commonly used </pre></div><div><pre class="m_3328895060422644984gmail-aLF-aPX-K0-aPE" style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px">electronic form, of the Recipient’s User Data in your possession, to the extent </pre></div><div><pre class="m_3328895060422644984gmail-aLF-aPX-K0-aPE" style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px">that such User Data is available to You for use in conjunction with the Work. </pre></div></blockquote><div><pre class="m_3328895060422644984gmail-aLF-aPX-K0-aPE" style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;color:rgb(0,0,0);font-size:14px"><br></pre>The license attaches terms to the data processed through the program, rather than the software of the program itself. These terms compel a specific action regarding the data, that the licensee surrender a copy of that data to a specific third party.</div><div><br></div><div>In this case the party may actually have right to that data, having created it themselves. This, however, is a distraction from the main point, which is the attempt to expand the copyleft paradigm to include <i>the data processed by the program,</i> such that the licensee must disclose that data or perform other mandated actions upon it. While this particular submission places a very narrow limit on what data must be disclosed: giving it back to "it's owner", it's obvious that it could be followed by licenses regarding a more significant license term to be placed on the data processed, for example the one that Kyle Mitchell submitted last year, which required that data simply processed by the program be placed under an Open Source license, or the old BitMover license which required that the running program communicate a public log of the program run to a specific BitMover log server.</div><div><br></div><div>So, I am really most concerned with the precedent that this license would establish, which would lead to more severe terms being applied to the data processed. And thus I suggest that OSI not accept any such terms at all.</div><div><br></div><div>Regarding how to reject the license within the tems of the OSD: the terms proposed work out to be a restriction on use. One can not use the program to sequester the customer's data. Such sequestration is a strategy in the implementation of software-as-a-service companies - I'm not saying that it's nice, just that they do it. Thus, I believe this runs awry of OSD#6, <i>No Discrimination Against Fields of Endeavor. </i>#6 has generally been found by the OSI board to prohibit usage restrictions.</div><div><br></div><div>OSI has affirmed that it supports Software Freedom, of the specific form defined by the Free Software Foundation and OSI's member the Software Freedom Conservancy. Thus, the Four Freedoms of the Free Software Foundation apply, and Freedom 0 is more specific to usage restrictions: <i>The freedom to run the program as you wish, for any purpose</i><span style="font-family:Roboto,arial,sans-serif;font-size:16px"><i>. </i></span>In this case, the proposed terms withhold the freedom to run the program while sequestering the information processed.</div><div><br></div><div>There are other problems with practical use of the license. Open Source software is intended for everyone to use, not just everyone who can afford an attorney and a programming staff. It thus should be the case that the "naive user", who simply runs Open Source software and does not modify it, should <i>not </i>need to read and understand the license, and certainly should not need a lawyer to tell them how to run the program in a compliant manner. The submitted license, however, applies terms to this naive user, who will potentially need a lawyer to explain to her what data to distribute and what can be kept, and a programmer to actually extract the data.</div><div><br></div><div>OSI, more than a decade ago, accepted a "badgeware" license, the Common Public Attribution License, which required attribution on a web site, potentially making the same demands that the user have a lawyer and at least a web designer in order to be in compliance. Debian rejected the same license as being incompatible with the DFSG, which has essentially the same text as the OSD. The CPAL was not successful, the submitter appears to be out of business, I can find no evidence of users of the license today, and searches for "badgeware" yield only decade-old pages. Yet, at the time, one commentator wrote, entertainingly in retrospect: <i>Badgeware is certainly not going away, and my fear is that if the OSI chooses to ignore it, or worse, refuses to approve the licenses, they will find themselves as irrelevant as the UN in short time. </i>(<a href="http://www.royrusso.com/blog/2007/01/11/badgeware-and-open-source/">http://www.royrusso.com/blog/2007/01/11/badgeware-and-open-source/</a>). Accepting badgeware was a contentious decision for OSI, received a lot of press coverage, and was ultimately a wrong decision as well as a useless and ineffective one. OSI should not repeat past mistakes.</div><div><br></div><div>The Open Source brand has, so far, stood for licenses which do not include terms applied to data simply processed by the licensed program. A significant part of that brand's value is the public perception that Open Source licenses <i>don't </i>do that. Thus, I suggest that the OSI board maintain the brand by rejecting this license and similar licenses that apply terms to the data simply processed by the program.</div><div><br></div><div> Thanks</div><div><br></div><div> Bruce</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 20, 2019 at 5:10 AM Pamela Chestek <<a href="mailto:pamela.chestek@opensource.org" target="_blank">pamela.chestek@opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
We don't think we can get anything ready in time to review the CAL
license, so unfortunately we shall carry on with email.<br>
<br>
Thanks,<br>
<br>
Pam<br>
<br>
<div class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921moz-signature">Pamela Chestek<br>
Chair, License Review Committee<br>
Open Source Initiative</div>
<div class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921moz-cite-prefix"><br>
On 8/19/2019 7:17 PM, Pamela Chestek wrote:<br>
</div>
<blockquote type="cite">
Hi all,<br>
<br>
I'd like to pause this discussion for a few days. As everyone
knows and I think agrees, email is poorly suited for this process.
The License Committee has been discussing trying out a different
tool, probably just a simple issue tracker. If y'all could give us
a few days to figure out if we want to try it out with this
discussion, that would be very greatly appreciated.<br>
<br>
Van, if you would prefer we NOT try a tool other than email,
please let me know.<br>
<br>
Thanks,<br>
Pam<br>
<br>
<div class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921moz-signature">Pamela Chestek<br>
Chair, License Review Committee<br>
Open Source Initiative</div>
<div class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921moz-cite-prefix"><br>
On 8/19/2019 5:09 PM, VanL wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>Hi Josh,</div>
<div><br>
</div>
<div>Looking again, I didn't really address your question
about the "offer an acceptance" language. So here goes:</div>
<div><br>
</div>
<div>License terms such as these are interpreted as
contracts. Contracts require 1) an offer, 2) an
acceptance, and 3) consideration.<br>
</div>
<div><br>
</div>
> ### 2.2. Offer and Acceptance<br>
> This License is automatically offered to every person
and organization. <br>
</div>
<div dir="ltr"><br>
</div>
<div>This establishes that the license is being offered as-is
to every possible licensee. This is the "offer" part of
contract law. <br>
</div>
<div><br>
</div>
<div>But because I don't want to individually sign an
agreement with every possible licensor, I need some way for
someone who wants to use software under this license to show
that they have accepted it. That's the next part:<br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">> You show that you accept this License and
agree to its conditions by taking any action with the Work
that, absent this License, would infringe any intellectual
property right held by Licensor. <br>
</div>
<div dir="ltr"><br>
</div>
<div>This means that if you do something that, absent the
license, you would not have the right to do, we will both
agree to interpret that as you "accepting" the license,
including all of its terms.</div>
<div><br>
</div>
<div>This also establishes the "consideration" - you get
software, I get your compliance with the terms.<br>
</div>
<div dir="ltr"><br>
>### 2.3. Compliance and Remedies<br>
> Any failure to act according to the terms and
conditions of this License places Your use of the Work
outside the scope of the License and infringes the
intellectual property rights of the Licensor. In the event
of infringement, the terms and conditions of this License
may be enforced by Licensor under the intellectual property
laws of any jurisdiction to which You are subject.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">
<div>This sentence ties the enforceability of the license
back to intellectual property law. IP law has stronger
remedies than contract law, so we want to be able to use
IP as a tool when enforcing the CAL. But note that only
the IP owner can sue under the IP laws. What about
everyone else? What about a Recipient - a user - who wants
a copy of the source and their data?<br>
</div>
<div dir="ltr"><br>
</div>
</div>
<div>> You also agree that either the Licensor or a
Recipient (as an intended third-party beneficiary) may
enforce the terms and conditions of this License against You
via specific performance.</div>
<div><br>
</div>
<div>This calls out to a doctrine in contract law that
recognizes that sometimes third parties, not named in a
contract, also may have a stake in the contract being
enforced. These are "third party beneficiaries." A third
party beneficiary doesn't have all the rights that the IP
holder does. But they can sue, using this clause, for
"specific performance" - a legal term that means "you must
comply with the license terms".<br>
</div>
<div><br>
</div>
<div>Thanks,<br>
</div>
<div>Van<br>
</div>
<br>
</div>
<br>
<fieldset class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921moz-quote-pre">_______________________________________________
License-review mailing list
<a class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a>
<a class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail-m_6083682025671467921moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_3328895060422644984gmail-m_-3589323269411557646gmail_signature"><div dir="ltr"><div><div dir="ltr">Bruce Perens - Partner, <a href="http://OSS.Capital" target="_blank">OSS.Capital</a>.</div></div></div></div>