<div dir="ltr"><div>Hi Bruce,</div><div><br></div><div>I appreciate your succinct statement of what you find problematic about the CAL. I don't believe that our views are compatible. Thus, I am presenting my comments to similarlly succinctly respond for the benefit of the others on the list, who may have tired of our back-and-forth, This is not an effort to reopen particular elements of the debate.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 3:14 PM Bruce Perens via License-review <<a href="mailto:license-review@lists.opensource.org">license-review@lists.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 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:0px 0px 0px 40px;border:medium none;padding:0px"><div><pre class="gmail-m_7833317177669039209m_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></blockquote></div></blockquote><div><br></div><div>[snip]</div><div><br></div><div>This is correct. The autonomy provisions, including the user data provisions, are central to the CAL.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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....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></blockquote><div><br></div><div>
As you note, the CAL provisions are narrowly targeted. While I can appreciate the existence of slippery slopes, the OSI has proved very resilient to approving licenses based upon the existence of prior "analogous" license provisions.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></div></div></blockquote><div><br></div><div>Thank you for confirming your view in this respect. I would challenge this thinking, however, based upon the observation that there exist SaaS companies that provide user data for other reasons (such as Google Takeout, Facebook's data download, etc). Thus I submit that this is not incompatible with providing a SaaS service, and thus not a field of use restriction.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>Again, thanks for your statement of the case. I submit that the private use provisions within the CAL are consistent with Freedom 0.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></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. </div></div></blockquote><div><br></div><div>Partially in response to this point, the CAL has been written to be much simpler for a non-lawyer to understand. More specifically, however, the provisions of the CAL would not apply unless the user decided to become an operator, serving other people and providing them with aspects of the software. <br></div><div><br></div>Thanks,<br></div><div class="gmail_quote">Van</div><div class="gmail_quote"><br></div></div>