<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Aug 2019 at 22:14, 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"><div>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>[This is an] 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, […]</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></blockquote><div><br></div><div>I don't buy the slippery slope argument. Importantly, the CAL does not encumber the data. It does not require any license for the data. It does not restrict how data may be processed. It merely compels a software operator to perform certain actions regarding the data, and only if they are able to do so.<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>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></blockquote><div><br></div><div>I agree that the CAL restricts use in a very small way, but think that this restriction is appropriate, similar to how requiring source disclosure is considered appropriate in copyleft licenses.</div><div><br></div><div>There is no discrimination against <i>fields</i> of endeavor here. SaaS as a field does not require user data to be locked up. It is perfectly possible to do SaaS and to comply with this term of the license – that's very close to what any GDPR-compliant SaaS operator will already be doing.<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>I interpret Freedom 0 to be very concerned about the end user of the software, and think that this viewpoint is consistent with the history of the software freedom movement. VanL has given a good rationale that true end user freedom doesn't just require access to the source, but also access to the data. As the end user's freedom so crucially depends on access to their data, I think that on balance, a software operator's freedom must take the backseat here.<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.<br></div></div></blockquote><div><br></div><div>An end user is free to run the software for themselves or their affiliates without restriction, and will certainly not have to consult a lawyer for that. You are painting an overly dramatic picture here. In general, I also find the CAL to be more comprehensible for lay persons than e.g. the GPLv3.</div><div><br></div><div>If anyone operates a service for other people to use, they already are subject to so many legal obligations in their respective jurisdiction that the CAL's provisions will really not matter that much. For example, CAL compliance is trivial compared with GDPR compliance, and GDPR compliance is not inherently difficult. I would assume that even in the US significant legal issues around liability etc would exist for a service operator.</div><div><br></div><div>If compliance doesn't matter for some people, and isn't a noticeable burden for the rest, and increases software freedom, is that provision really so objectionable?<br></div></div></div>