<div dir="ltr"><div>Response below.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 1, 2019 at 5:24 PM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.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 bgcolor="#FFFFFF">
    <br>
    <div class="gmail-m_498425161774712415moz-cite-prefix">On 4/27/2019 10:30 AM, Pamela Chestek
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <br>
      <div class="gmail-m_498425161774712415moz-cite-prefix">On 4/23/19 10:15 PM, VanL wrote:<br>
      </div>
      <blockquote type="cite">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).</blockquote>
      <br>
      <div class="gmail-m_498425161774712415moz-cite-prefix">On 4/23/19 11:55 PM, Bruce Perens via
        License-review wrote:<br>
      </div>
      <blockquote type="cite">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. </blockquote>
      <br>
      Bruce does identify what strikes me as a distinction between your
      section 2.3 and the anti-Tivozation clause. The anti-Tivozation
      clause says that where object code is conveyed on certain devices
      where the device is transferred in a way equivalent to ownership,
      then you must give me what is needed to install and execute a
      modified version of the code on the device. That all relates to my
      right to modify code in a meaningful way. Your provision simply
      says that someone can get a copy of their data, as Bruce points
      out a burden that falls on someone who is only running the
      software. So I don't consider them analogous.<br>
    </blockquote>
    Van,<br>
    <br>
    Do you have a comment on this? I share Bruce's concern that Section
    2.3 is outside the scope of open source licenses. I'm not buying
    your argument that it's the same as anti-Tivoization, for the reason
    I described above. <br>
    <br></div></blockquote><div><br></div><div>There are two separate issues. The clause in 2.3(c) referring to cryptographic seeds, etc. is a special anti-Tivoization clause for the context of a cryptographically authenticated distributed system. In those systems, the keys (and the ability to generate or revoke the key, which is effectively identical) are "data" but are also intrinsic to the functioning of the system. It is possible to give someone software and prohibit them from running it or having control over it. This is software Tivoization, and 2.3(c) addresses this attack.</div><div><br></div><div>The larger concern seems to be with 2.3(b), which is the User Data clause. The analysis here is that Freedom 0 - the right to run the program as you wish, for any purpose - necessarily implies a right of data portability with regard to your own data. I am unable to run the program as I wish if, after having run it with some SaaS provider, all of my previous data entered into the program and used for my personal processing is now rendered inaccessible to me. As with the GPL licenses, the only rights denied are the rights that would reduce the freedom of a third party recipient, and so the specific right to deny data portability is denied if you are offering the program's functionality to a Recipient.</div><div><br></div><div>Thanks,</div><div>Van<br></div><div><br></div><div> </div></div></div>