<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 13, 2019 at 12:50 PM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a>> wrote:</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>This is a completely fair point, and I apologize for the tone.<br></div></div></div></blockquote><div><br></div><div>Well spoken, and accepted of course!</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>The CAL does require that a licensee make available the user's data to the user, but it does not impose restrictions on how the data is used, nor do any obligations persist after any transfer of the data. Thus, the CAL has a condition on the license, but not an encumbrance on the data.<br></div></div></div></blockquote><div><br></div><div>Please excuse me for repeating previous discussion, it's obviously necessary to discuss this new version.</div><div><br></div><div>You are attempting to extend the reciprocal licensing paradigm, to require that the licensee distribute the data to a specific party (the user). It's my contention that neither Free Software nor Open Source contain or allow this specific requirement.</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">But looking at what was written, use "in a business" or "for genetic research" clearly refer to overriding purposes of the use, and not to any particular tactics.</div></div></blockquote><div><br></div><div>Those are examples. They don't restrict "field of endeavor" to exclude all of the very many decisions necessary to carry out your business. It's really obvious that SaaS providers have lock-in strategies as a major part of their business, otherwise it would not be a an explicit goal of the CAL, and apparently this version's sole remaining significant difference from accepted Open Source licenses, to <i>defeat</i> lock-in terms. The businesses that use such terms are fields of endeavor, and would be different fields of endeavor if they operated differently.</div><div><br></div><div>I sympathize with the goal of CAL, while still not believing that the implementation of that goal is well-placed as a software license term. It belongs in law regarding online business. This seems to me to be the same as all of the discussions of license additions to achieve an ethical purpose - which we've just iterated again. They attempt to extend the Open Source paradigm to address some other issue.</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">any restriction can be cast as a violation of OSD #6 because it could potentially interfere with a hypothetical licensee's permission to do the opposite.</div></div></blockquote><div><br></div><div>I have to differ with Richard's theorizing, which I think Pam has also commented that she shares. We have the restrictions that achieve the purpose of Open Source, as stated by the definition, and we have <i>all other restrictions.</i> The OSD specifically says that distribution of source code must be allowed. The OSD implicitly provides you with a way to separate restrictions into two categories, one that achieves the purpose of Open Source as defined, and one that does not. Having made that separation, there is no <i>reducto ad absurdum. </i>There are simply permitted restrictions, and those not permitted.</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">The CAL does not prohibit (or even mention) any purposes for which the software can be used; it is completely agnostic in that fashion.</div></div></blockquote><div><br></div><div>It just tells me I can't make the user data trade secret, or simply sequester it and thwart the user's desire to see it returned. And my business may succeed or fail over that one thing. I'm not saying that it's nice.</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">So I would challenge you: What is an articulable, non-gerrymandered rule that says "you may use this for any field of endeavor" that allows current licenses, but disallows the CAL?</div></div></blockquote><div> </div><div>I would simply say "You may use the software for any purpose" is a sufficient filter. I would say that OSD #6 states this same rule, in different language.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_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></div>