<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 1:50 PM Lukas Atkinson <<a href="mailto:opensource@lukasatkinson.de">opensource@lukasatkinson.de</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 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" target="_blank">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>Importantly, the CAL does not encumber the data.</div></div></blockquote></div></div></blockquote><div><br></div><div>This is a semantic argument about the meaning of legal terms. It doesn't "encumber" the data, but it asserts a requirement for specific action regarding the data upon the licensee with as large and odious an effect as something called "encumberance" might have.</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 class="gmail_quote"><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> 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></blockquote></div></div></blockquote><div><br></div><div>It doesn't say "only if you are able to do so". It says "to the extent that such User Data is available to You for use in conjunction with the Work."</div><div>It can very easily be the fact that the data is available for you to use in conjunction with the work, but not for you to extract from the program without soliciting the work of a more technically-skilled person.</div><div><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 class="gmail_quote"><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></div></blockquote><div><br></div><div>OK, so a restriction of use is OK if it achieves a <i>similar </i>purpose to requirements that you distribute source code, even though it's data, not source code. So, what happens when the next license comes along, and requires that you distribute your <i>own private </i>data to the software author, with appropriate rights? How is that fundamentally different from the requirement here? We then get to stating a whole rule-set for data freedom that maintains your privacy too, which isn't currently in the OSD and doesn't belong there.</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 class="gmail_quote"><div>SaaS as a field does not require user data to be locked up.<br></div></div></div></blockquote><div><br></div><div>I reject the proposition that #6 protects <i>classes </i>of endeavor and does not at the same time protect any of the million implementation details of that endeavor. I could then come out with an anti-vegetable-oil license that requires the use of lard, and that would, under your analysis, protect the field of endeavor of baking. A field of endeavor is the whole of the large set of decisions that make it up, not some Platonic Ideal version of the same endeavor.</div><div><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 class="gmail_quote"><div></div><div>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><div><br></div><div>Actually, OSI hasn't gotten into the business of protecting one party at the other's expense except in the case of anything so fundamental as responsibility to distribute source code. This shows the problem OSI would be entering here - the need to weigh each party's rights and decide <i>which is more worthy than the other. </i>Certainly not everyone agrees that the user is more worthy than the business. This is a sort of micromanaging social engineering that we have wisely stayed away from.</div><div><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 class="gmail_quote"><div>An end user is free to run the software for themselves or their affiliates without restriction</div></div></div></blockquote><div><br></div><div>That's actually not a factual statement. There is a restriction in legal terms, backed by the potential of prosecution for copyright infringement.</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 class="gmail_quote"><div>, and will certainly not have to consult a lawyer for that. You are painting an overly dramatic picture here.</div></div></div></blockquote><div> </div><div>What happens when someone asks for their data? Whether or not to give it, and how to give it without violating anyone else's privacy, are not trivial decisions.</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 class="gmail_quote"><div>In general, I also find the CAL to be more comprehensible for lay persons than e.g. the GPLv3.</div></div></div></blockquote><div><br></div><div>I don't actually. But this is irrelevant, because the naive user does not have to read the GPL. It doesn't place any restrictions upon them. </div><div><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 class="gmail_quote"><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?</div></div></div></blockquote><div><br></div><div>We must keep in our minds that Open Source involves lots of licenses, not just the one under consideration. The aggregate of license obligations can become intolerable for practical use while a single license might be tolerable for some arbitrarily selected person. </div><div><br></div><div>At the risk of being criticized for the slippery-slope fallacy, where do you stop? How do we define what is not so much trouble, and who do we define that for, and what about everyone else?</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div></div>