<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 7:16 PM 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>Hello Bruce,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 6:27 PM Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> wrote:</div><div>No disrespect intended, and I am sorry for any that was communicated.<br></div></div></div></blockquote><div><br></div><div>Well said. Thank you. </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><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 dir="ltr">On Tue, Apr 23, 2019 at 3:18 PM VanL <<a href="mailto:van.lindberg@gmail.com" target="_blank">van.lindberg@gmail.com</a>> wrote:</div></div></blockquote><div>There is a particular way of locking down a program that is available in hashchain applications; that particular method is addressed in a single clause.</div></div></div></blockquote><div><br></div><div>Can you tell us more about this? I am not at all clear what your customer is worried about, and thus I am unclear about the motivation behind terms.</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>"Compliance with section 2" consists of:</div><div>   ...</div><div>   - Making a user's data available (2.3). </div></div></div></blockquote><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>...</div></div></div></blockquote><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>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><br></div><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> 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><br></div><div>The CAL breaks that. Passive users of software under the CAL would face real legal questions regarding data release in conjunction with the terms, which they could not handle adequately without counsel. This, IMO, is an unacceptable burden on the user.</div><div><br></div><div>It's really difficult for anyone not an attorney to parse the terms of this license and arrive at what their obligation is, figure out where ownership interests and possessive interests are involved, etc. There is nothing approaching plain language that states the obligation. And I suspect there is some uncertainty even regarding attorney's opinions.</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>Ummm... to the best of my knowledge, unreadable and irretrievable data has <i>nothing</i> to do with blockchains.</div></div></div></blockquote><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 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 license compels an action by the licensee - to make the source code and data available. This is exactly the same type of action required under every copyleft license.<br></div></div></div></blockquote><div><br></div><div>It's not the same action. Our other approved licenses require conveyance of the source code only. And in a meaningful way only from <i>developers </i>who create derivative works. Here you add data to the terms, which none of our other licenses require, and you require it of <i>users </i>of the program who are not developers. Vastly increasing the legal burden of users.</div><div><br></div><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><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>Just because I have ownership of the data doesn't mean that you have an existing legal responsibility to give it to me. This is exactly the problem addressed by the CAL.<br></div></div></div></blockquote><div><br></div><div>Yes. IMO, it's over-reaching. </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> The insight is that, increasingly, the data and the code are needed together to realize the program's function.</div></div></div></blockquote></div></div></blockquote><div><br></div><div>This is proposing that the data previously used for an arbitrary run of the program is essential to use the program at all. I can see this for data which defines fundamental characteristics of the world around us, for example a book of physical constants of the universe. But you are extending this to transactional data of a specific market, and denying that the program could be used in an alternate market. It's not logical.</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"><br class="gmail-Apple-interchange-newline"><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><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>It's over-reach. Sorry.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div></div>