<div dir="ltr"><div>Hi Bruce,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 13, 2019 at 2:09 PM Bruce Perens <<a href="mailto:bruce@perens.com">bruce@perens.com</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"><br><div class="gmail_quote"><div>In a discussion like this, you can expect people to disagree, and to <i>continue </i>to disagree. It seems to me that if we are all going get along, the appropriate response to such disagreement is <i>not </i>to take a strident tone and recount how many times you have attempted to correct me, as if you were a harried school teacher facing a recalcitrant pupil.</div></div></div></blockquote><div><br></div><div>This is a completely fair point, and I apologize for the tone.<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 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 class="gmail_quote"><div>The CAL does not encumber any data. It does not change the licensing on any data. Please respond with the specific text that "encumber[s] data processed by the program."</div></div></div></blockquote><div><br></div><div>The terms very obviously require the licensee to perform a specific action with the data. If this is not "encumberance", what is it?</div></div></div></blockquote><div><br></div><div>I understand the term "encumber" to place a continuing obligation on the data, such that each subsequent holder of the data would also be bound by the obligation. This is the way in which this term is used in legal/licensing parlance.</div><div><br></div><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><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"><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>"Withholding user data" isn't a field of endeavor, just like "withholding source code" isn't a field of endeavor. </div></div></div></blockquote><div><br></div><div>Of course development of proprietary software, sequestration of its source code, and making use of copyright and trade-secret protection is a <i>very popular</i> business method in the industry and can indeed be considered to be a field of endeavor. We have already discussed on this list, and license-review, why OSD #6 does not prohibit reciprocal licensing even though this is so. I doubt that you really mean to open that discussion again.</div></div></div></blockquote><div><br></div><div>I am not reopening that discussion, but merely referring to it as being analogous.</div><div><br></div><div>But with reference to the "field of endeavor," I go again to OSD #6: "6. No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."</div><br></div><div class="gmail_quote">I understand the irony of quoting this to you. 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. If "field of endeavor" is defined as a tactic, and not a purpose, then we fall afoul of Fontana's<i> reducto ad absurdum </i>where 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 class="gmail_quote"><br></div><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 class="gmail_quote"><br></div><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?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote">Van<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div><br></div><div><br></div><div><br></div><div> </div></div></div>