<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">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"><div dir="ltr"><br></div><div dir="ltr">Please do me the courtesy of assuming that my arguments are not always misapprehensions, but may be valid objections to your license.</div></div></blockquote><div><br></div><div>No disrespect intended, and I am sorry for any that was communicated.<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 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:<br></div><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 dir="ltr"><div class="gmail_quote"><div>I don't really understand what you are going for here: Every license was designed to fulfill a specific purpose. The GPL was designed to preserve software freedom; the ISC license was written to be as short as possible; the MPL was written to allow a the joint compilation of separate works into a single binary.</div></div></div></div></blockquote><div><br></div><div>Yes. But none of GPL, ISC, and MPL are specific to an application. The only one that really mentions specific technology at all is GPL3...</div></div></div></blockquote><div><br></div><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. That is exactly like anti-Tivoization (which is also addressed in a single clause inspired by the GPLv3, and the anti-circumvention, which is addressed in a third clause - again parallel to the GPLv3).<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 dir="ltr"><div class="gmail_quote"><div> In this case, my client identified that it was in their business interest to have a strong network copyleft license that was maximally respecting of user freedom.</div></div></div></div></blockquote><div><br></div><div>I am not yet convinced that a compulsion to reveal the data processed by the program is maximally respecting of user freedom. I do note that other well-known licenses promoted as freedom-respecting have very clearly stated that you can run the software for any purpose....</div></div></div></blockquote><div><br></div><div>Ability to run the program is clearly granted. Quoting the CAL:<br>1.1. Conditioned on compliance with section 2, and subject to the reservations of section 1.2,<b> you have world-wide, royalty-free, non-exclusive permission to:</b><br>    a) <b>Take any action with the Work or a Modified Work that would infringe the copyright or database protection laws of an Applicable Jurisdiction</b> applying to the Work, including Publicly Performing any interface derived from the Work; and<br></div><div>    b) <b>Take any action with the Work or a Modified Work that would infringe any patent claims Licensable by Licensor,</b> to the extent that those claims are embodied in the Work as distributed by Licensor. <br></div><div><br></div><div>"Compliance with section 2" consists of:</div><div>   - Attribution (2.1)<br></div><div>   - Making source code available (2.2)</div><div>   - Making a user's data available (2.3).</div><div><br></div><div>That's the meat of it.<br></div><div><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"><div>It also appears that the license is clothed in the language and law of protecting people from the effects of others holding their personal data. This, however, seems a false impression, because the terms require a potentially very broad compulsion to disclosure that does not respect individual privacy - anyone with a possessory interest or a chain of derivation regarding their data potentially has a right to <i>your </i>data.</div></div></div></blockquote><div><br></div><div>You assert this, but you can't end up with rights data that you did not already have. No rights or obligations are created in any other work.<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"><div>And then we compel disclosure of data even in contexts that do not protect people. Rather than personal data, the application of the program is blockchain data used to implement a market. This sort of data is still encumbered with disclosure compulsion regardless of whether it is actually personal or not.</div></div></div></blockquote><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 dir="ltr"><div class="gmail_quote"><div>The User Data is not encumbered. <b>This is a fundamental point</b>. There are no additional restrictions placed on any User Data that were not there in the first place. Users own or have the right to possess their own User Data.</div></div></div></div></blockquote><div><br></div><div>But this seems self-contradictory. If users have the right to compel disclosure of their user data separately from the license, why does the license need to have language to compel disclosure of that data at all?<br></div></div></div></blockquote><div><br></div><div>On the contrary, this happens all the time. People invest time and energy putting information into online platforms, only to find that their data gets held "hostage" against them. Want to continue to have access to your data? Keep paying.</div><div><br></div><div>The CAL recognizes that modern computing is about both the program <i>and</i> the data. I may <i>own</i> my data. I may be able to get a copy of the source code. But unless I can run the program (no Tivoization, no "effectively controlling access to a copyrighted work," no control of the cryptographic keys used to process the data) I don't have freedom. And unless I can use the software to process my own data, I also don't have effective freedom.<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></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"><div class="gmail_quote"><div>The CAL just denies a licensee the right to lock up a User's Data and make it irretrievable or unreadable.</div></div></div></div></blockquote><div><br></div><div>So, you're saying that it is in violation of the license for me to, for example, encode passwords with a one-way hash. And that doesn't seem a use restriction? For example, by making it impossible to properly implement access control software under the license.</div></div></div></blockquote><div><br></div><div>This is a good point. I could argue that there are ways of negotiating access control that don't require the transmission of passwords or similar information (e.g., public keys). But to avoid this issue, note the changed 2.3(b):</div><br>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,<b> to the extent that such User Data is available to You for use in conjunction with the Work</b>;<br><br></div><div class="gmail_quote">If I store passwords in plaintext (boo!) then I need to give you back your password. If I only have a hash, I may need to give you back that hash if doing so is necessary for me to use the Work.<br></div><div class="gmail_quote"> </div><div class="gmail_quote"><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></div><div>And what <i>other </i>purpose than access validation does unreadable or irretrievable data have, that we must prevent a software user from ever doing that? I guess that's implementing a blockchain. Doesn't that bring us back to use restrictions?</div></div></div></blockquote><div><br></div><div>Ummm... to the best of my knowledge, unreadable and irretrievable data has <i>nothing</i> to do with blockchains. In fact, the entire point of a blockchain is that the data is retrievable and publicly verifiable (which implies readable). You are imagining motives and technology which have no basis in fact.<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 dir="ltr"><div class="gmail_quote"><div>Let's say the CAL was applied to something like a photo storage site where you store your photos. <b>The CAL does not apply any licensing requirements on your photos</b>. <b>It does not encumber them at all</b>. It only states that the photo storage site using the software cannot encrypt <b>your </b>photos and prevent <b>you</b> from retrieving them.<br></div></div></div></div></blockquote><div><br></div><div>That's not a use restriction? </div></div></div></blockquote><div><br></div><div>No, but I recognize that I was unclear. You can encrypt the photos. You can use the software in whatever what you would like. You just cannot refuse to decrypt them for me if you have the ability to do so. See 2.3(b) above.<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 dir="ltr"><div class="gmail_quote"><div>If allowing a person to retrieve their own data is an encumbrance, then the AGPL provides a similar encumbrance, in that it ensures that a site operator also offer users a copy of the source code to which they are entitled.</div></div></div></div></blockquote><div><br></div><div>Not so. The AGPL only applies to the program and its language is very careful not to reach beyond the program. It requires that a person who modifies the program must offer to distribute a copy of the program, potentially a modified version, if they perform activities similar to public performance. In contrast, the CAL <b>reaches </b><i>beyond the program</i> to apply terms to data which is simply processed by the program. This is <i>not </i>an encumberance like the AGPL!</div></div></div></blockquote><div><br></div><div>You have asserted this multiple times. Please quote, specifically, any terms are applied to any data beyond the program. It is not there. No person gains or loses any rights in any data that they did not previously possess. No license terms are applied to anything other than the Work (including derivative works). 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><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 dir="ltr"><div class="gmail_quote"><div>We don't need any such theory. Ownership of intellectual property is mediated by the laws of a jurisdiction. For example,a photographer has an ownership interest in photos that she takes because of the operation of copyright law. I have an "mp3 locker" where I store copies of songs that I legally possess - I have non-ownership possessory interest.<br></div></div></div></div></blockquote><div><br></div><div>So as the operator of a music or photo site, I either have an existing legal responsibility to give you your data upon request, in which case the license does not need to compel me to do that, or I don't, and the license needs to compel me to do that. Which one are you stating is true?</div></div></div></blockquote><div><br></div><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><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 dir="ltr"><div class="gmail_quote"><div>This invents a hypothetical contrary to the terms of the license under discussion. The license doesn't grant the "very broad right" you are afraid of, and so the accompanying parade of horribles doesn't apply. If I don't have an ownership or possessory interest - both again, normal legal terms - then I can't ask for the data.</div></div></div></div></blockquote><div><br></div><div>I am still hearing that you have an interest in law, and that the license must still go beyond what your interest in law <i>is,</i> to compel the site operator to distribute files to you that are <i>not </i>the program under the license, and that she would not otherwise have to distribute to you.</div></div></div></blockquote><div><br></div><div>I don't fully understand this comment. Trying to respond, though: The CAL requires the operator to make available to a user the files corresponding to the program as it is used by that user. The insight is that, increasingly, the data and the code are needed together to realize the program's function. 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. 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.</div><div><br></div><div>Thanks,<br></div><div>Van<br></div><div><br></div><div><br></div><div> </div></div></div>