<div dir="ltr"><div>Sorry for the delay responding to various concerns.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 10:55 PM Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">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"><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>People invest time and energy putting information into online platforms, only to find that their data gets held "hostage" against them.</div></div></div></blockquote><div><br></div><div>I agree that this is a social problem suffered by computer users. OSI has previously rejected licenses that attempted to use their terms to remedy social issues beyond sharing software freely. It's out of scope of OSI's mission, <i>and </i>OSI's stated mission for  Open Source software.</div></div></div></blockquote><div><br></div><div>The CAL is not of the same sort as the 996 license, or the JSON "Do no evil" license. While it does address a social issue, it does so in the exact same way the GPL addresses the social issue of software freedom.<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"><div>The previously proposed licenses with similar terms have in general been rejected because of the increase in legal load for the <i>passive user.</i> <br></div></div></div></blockquote><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 person who doesn't create derivative works or redistribute, but just runs the program. They shouldn't have to read the license just to run the program.</div></div></div></blockquote><div><br></div><div>This is an interesting point, but I don't think it is applicable in the general case. If the CAL were applied to a music player like VLC, or a graphics program like Gimp, the legal load would be precisely the same as for any other user. The only additional legal load is for an entity that wants to use CAL-licensed software to provide services over a network to others. This is exactly the same context in which the AGPL applies an additional legal load - and I would argue that if you are providing services to others, you have already taken upon you substantial legal liability.<br></div><div><br></div><br><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><br></div><div>Blockchain requires use of one-way functions, as does any algorithm that supports a verifiable public signature. The input to such functions is necessarily irretrievable and requires some sort of secret, usually in the form of a private key. Private keys (usually in the "wallet") must <i>remain </i>private, or the basis of trust in the system is destroyed. So, be sure your license doesn't require their disclosure. It seems to me that under the present terms it might do so.</div></div></div></blockquote><div><br></div><div>I understand this point now. However, the application to the CAL is only speculative ("under the present terms it might do so.") I would argue that the CAL is very careful in its definitions, such that the only required disclosures are of source code and data in which the user has a preexisting legal right. I cannot see a situation in which a first person, "Alice," could use the CAL to request disclosure of "Bob's" private key, where Alice does not have a preexisting right of control of Bob's key regardless of the CAL.  The CAL does not create any new rights in any unrelated Works.</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"><div>The terms do include use restrictions: by your own statement they restrict the user from denying their customers access to their data without a continued payment. You may consider this socially beneficial, but it's pretty clearly a use restriction. I don't see how this is different from the previously rejected licenses with other social goals implemented as use restrictions.</div></div></div></blockquote><div><br></div><div>The difference gets back to user freedom and the ability to "exit."
Operators of CAL-licensed software can refuse to continue hosting a user's data without further payment. But 

 licenses that  defend user freedom prevent an operator from denying the user the opportunity to exit a situation so as to run the program in another context. That is the same freedom protected by the CAL. <br></div><div><br></div><br><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 proposing that the data previously used for an arbitrary run of the program....</div></div></div></blockquote><div><br></div><div>This is incorrect. It is not an "arbitrary" run of the program; it is only an invocation of the program with the user's data, so that the user can run the program in another context with their same data and get the same result. <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"><br class="m_3874468970914368728gmail-m_3241337967131287173gmail-Apple-interchange-newline"><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"><br><div>Existing open source licenses, such as the GPLv3 family, recognize this and requires the provision of cryptographic keys that would prevent the execution of the code.</div></div></div></blockquote></div></div></blockquote><div><br></div><div>Yes, but a lack of specific market data doesn't actually prevent the execution of the code, as a key in a "trusted" boot system would.</div></div></div></blockquote><div><br></div><div>I am unsure where you are identifying "specific market data" in the CAL. But more fundamentally, in many systems, particularly those that deal with cryptographic primitives as a part of their operation, you would not get the same result (if it did indeed "boot").<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"><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">The CAL recognizes that user freedom also includes the provision of the user's data so that the program functions completely and fully in a context of the user's choice.<br></div></div></blockquote></div></div></blockquote><div><br></div><div>Thus, someone who wishes to have the freedom to sequester the data of their customer users <i>must be deprived of that freedom. </i>We restrict people from keeping derivative works private in some cases, because we're the Open Source Initiative. But now, we are going to restrict people from keeping data private too, because we're now the Open Source and People's Data Initiative?</div></div></div></blockquote></div><div><br></div><div>This overstatement continues to conflate "the People's Data" with a user's own data. Further, it strikes me as strange that the core argument is that you wish to preserve for operators "the freedom to sequester the data of their customer users." That freedom is definitely granted under some more permissive licenses, but preserving the rights of users is a core aspect of Free Software, which is the tradition addressed by the CAL.</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>