<div dir="ltr"><div dir="ltr">I suspect that it might not really be time to submit the license yet, and that it needs further work.<div><br></div><div>The purpose of the license is to implement a sort of market and to protect the operation <i>of the market,</i> rather than simply <i>the rights regarding the program.</i> This necessarily requires that the terms of the license go substantially beyond  terms regarding the software itself. Thus, we have the terms regarding user data, which apply to <i>any data whatsoever</i> which the program has touched in some way:</div><div><i style="background-color:transparent;font-size:12pt;white-space:pre-wrap;color:rgb(0,0,0);font-family:Calibri,sans-serif"><br></i></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><i>b) Throughout any period in which You exercise any of the permissions granted to You under this License, You must also provide to any third party with which you have an enforceable legal agreement, a no-charge copy, provided in a commonly used electronic form, of the User Data in your possession in which that third party has a Lawful Interest;</i><i><br></i><i><br></i></blockquote>And then we define user data this way:<br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><i><br>l) “User Data” means any data that is either a) an input to, or b) an output from, the Work or a Modified Work, in which a third party other than the Licensee has a Lawful Interest in the data.</i></blockquote><div><br></div><div>But we never define<i> lawful interest. </i>We refer to GDPR and, I guess, vaguely wave at the body of law entire.</div><div><br></div><div>So, consider that each user processes data about the <i>entire market, </i>as is common in blockchain systems<i>.</i> Each user may thus have an obligation to disclose data to very many other users who have a legal interest in that data. The user may also have an obligation to guard data from being disclosed to the wrong people, because this would endanger the user's privacy rights or those of other users, or break the market. So, this can be a very large legal obligation to properly verify requests and distribute data.</div><div><br></div><div>Now, I can guess that Van intended these terms to apply only to a large operator of a financial network of the sort theorized. But as written they apply to every user.</div><div><br><div>The user is very poorly informed regarding user data. When does another user actually have a <i>legal interest</i> in it? And where, since this is European law? Why are we using a term from real estate law: "quiet enjoyment", which we can not expect the user to understand regarding software? Since GDPR is referenced, the user needs to understand that too, even if it doesn't apply where they live.</div><div><br></div><div>If the user data is stored using a one-way hash, and we also have terms regarding cryptographic hashes, must the specifics of the one-way hash be revealed, even when they would put the security of other users at risk?</div><div><br></div></div><div>So, it strikes me that overall, this is a license that requires a lawyer simply to <i>use </i>the software, and that a user without legal counsel would not practically be able to exercise their responsibility regarding the license terms.</div><div><br></div><div>I am not recommending approval until the actual complexity of the license as faced by a non-developer user is much better bounded than it is by the current terms.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2019 at 11:44 AM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.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"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I'd like to thank everyone who provided feedback on earlier drafts of the Cryptographic Autonomy License (CAL). Since we presented the draft license in February, we have received hundreds of comments and suggestions, all of which have helped us fine-tune the license.</div><div><br></div><div>We now present the CAL 1.0-Beta for approval at the next board meeting:</div><div>  Google Docs link: <a href="https://docs.google.com/document/d/1sWUREQN02YJ-q91gXOCflRB57Q1YcU1G7UMS_a8WOTI/edit#" target="_blank">https://docs.google.com/document/d/1sWUREQN02YJ-q91gXOCflRB57Q1YcU1G7UMS_a8WOTI/edit#</a></div><div>  PDF Link: <a href="https://www.processmechanics.com/static/CAL-1.0-Beta.pdf" target="_blank">https://www.processmechanics.com/static/CAL-1.0-Beta.pdf</a> <br></div><div><br></div><div>The CAL is still open for revision until it is approved by the Board, and the links above will be updated as appropriate. <br></div><div><br></div><div>I also refer everyone here again to the blog post describing the legal foundations of the license (<a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/" target="_blank">https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/</a>) as well as the discussion on license-discuss, summarized by Lukas Atkinson here: <a href="http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-April/020394.html" target="_blank">http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-April/020394.html</a><br></div><div><br></div><div>Thanks,<br></div><div>Van<br></div><div> <br></div></div></div></div></div></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div></div>