<div dir="ltr">Pam,<div><br></div><div>It is reassuring that the committee put in this degree of effort.</div><div><br></div><div>One of the main reasons given by the committee is that there was <i>insufficient discussion</i> on license-review. In your message <<a href="mailto:8d5fb3a8-86f5-89fa-4f3e-1ac5978af3b1@opensource.org">8d5fb3a8-86f5-89fa-4f3e-1ac5978af3b1@opensource.org</a>>, of Fri, May 10, 5:51 PM you wrote "Thank you very much, your opinions have been noted", which I took as the chair's  direction for me to terminate discussion of the license. This is ironic given the response of the committee.</div><div><br></div><div>Of course, we would also have more discussion if additional well-informed people with a diversity of opinions actually joined the list. Which I believe was the intent of the restructuring of the license committee. But I don't see them yet. Until we find a way to persuade them to show up, a temporary fix might be for the OSI board to become more active participants on this list.</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 Thu, Jun 27, 2019 at 6:03 AM Pamela Chestek <<a href="mailto:pamela.chestek@opensource.org" target="_blank">pamela.chestek@opensource.org</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">
    Below is the License Review Committee's recommendation to the OSI
    Board on the Cryptographic Autonomy License.<br>
    <br>
    You will see that there is a section titled "Open Questions." If
    list members would like to discuss these topics, please have the
    conversation on the License-Discuss list.<br>
    <br>
    Pam<br>
    <br>
    Pamela Chestek<br>
    Chair, License Review Committee<br>
    Open Source Initiative<br>
    <br>
    License: Cryptographic Autonomy License (as captured 8 May 2019,
    Exhibit A)<br>
    Submitted: April 22, 2019: 
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004028.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004028.html</a><br>
    Decision due no later than the first Board meeting after June 21,
    2019<br>
    <br>
    License Review Committee Recommendation: <br>
    <br>
    Resolved that it is the opinion of the OSI that the Cryptographic
    Autonomy License does not conform to the OSD and assure software
    freedom and the license is therefore not approved. The license
    submitter is invited to submit a new draft for consideration by the
    OSI after revision. See [link] for rationale document.<br>
    <br>
    <u>Rationale Document</u><br>
    <br>
    <u>Reasons for withholding approval:</u><br>
    <br>
    <ol>
      <li>Specific provision for GDPR: The license makes special
        accommodations for those who must comply with General Data
        Protection Regulation (EU) 2016/679 ("GDPR") Arts. 15(3) and
        20(1) but does not make those same accommodations for those who
        may be obliged to comply with similar requirements found in
        other data privacy laws. An additional permission or restriction
        granted specifically for a particular class or group is, on its
        face, non-compliance with OSD5/6. However, the license submitter
        said that this provision will be removed if it is the remaining
        issue.
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004156.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004156.html</a>
      </li>
      <li>The mechanism of “public performance”: The health of an open
        source software project relies on a predictable and consistent
        understanding of what the license permits and what it requires
        for compliance. However, this license uses a term specific to US
        law, which is “public performance.” The use of of a term found
        only in one jurisdiction’s body of law leads to the possibility
        of highly disparate outcomes under other legal systems. The
        license submitter suggests that public performance “appears
        analogous” to the EU concept of communication to the public,
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html</a>;
        however, there is no reason to believe an EU court would find
        that the words “public performance” mean the same thing as
        “communication to the public” or that an EU court would view
        “communication to the public” as applying to APIs in the same
        way that the license submitter posits “public performance” does
        under US law. (A number of commenters on license-review also
        disagreed with the license submitter’s belief that under US law
        the right of public performance will extend to the use of APIs.)
        The submitter argues that the term is defined in the license and
        therefore does not rely on local interpretation,
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html</a>.
        However, the definition does rely on copyright law for scope
        (“‘Public Performance’ (or ‘Publicly Performing’) means using
        the Software to take any action that implicates the rights of
        public performance or public display of a work under copyright
        law, ...”). The high likelihood that the license would be
        interpreted in significantly different ways in different legal
        jurisdictions militates against its approval. Although the CAL
        is not, by any means, a “crayon” license, it has the potential
        for the same negative consequence, which is unpredictable
        interpretation.</li>
    </ol>
    <u>Open questions</u><br>
    <br>
    The above are the reasons that the license has not been approved and
    the submitter is encouraged to revise and resubmit the license.
    However, there are also additional issues raised during the
    discussion of the license that merit further community input and
    discussion before the license would be approved. These issues are:<br>
    <br>
    1.    <u>Scope of copyleft</u>.<br>
    Until now, the principle of copyleft has only been applied to
    literal code, not APIs. The license submitter’s proposal is for a
    copyleft effect that would apply to new implementations of the API
    even when the underlying has been written from scratch.
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html</a>.
    The license also makes this extension even if the legal system would
    not extend copyright (and therefore copyleft) so far. During the
    license-review process some commentators objected to this extension
    of the copyleft principle this far. However, the license review
    committee does not believe that there was sufficient discussion
    representing all points of view on the license-review list and so
    does not reject the license for this reason. The license submitter
    should also be aware that the OSI was a signatory on a brief
    submitted to the U.S. Supreme Court advocating against the
    copyrightability of APIs. APIs are also known to be outside the
    scope of copyright under European law. We are consequently
    uncomfortable endorsing an application of copyright law to APIs in
    any form without further discussion.<br>
    <br>
    2.    <u>At what point the licensor can oblige licensee behavior</u>.
    <br>
    The trigger for meeting license obligations can differ across
    licenses. The most common, almost universal trigger, is distribution
    of software. The AGPL license triggers upon allowing network
    interaction with modified software. The CAL license implements a new
    trigger, which is the obligation to make unmodified software
    available to anyone interacting with an interface for the software.
    In other words, someone might install a program that allows for
    interaction with the website (perhaps providing a webform to sign up
    for a newsletter) and would now be obliged to make the source code
    available to any person who filled out the webform.
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004113.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004113.html</a>
    The License Review Committee does not believe that there has been
    adequate airing of this issue from a variety of viewpoints on the
    license-review discussion about this aspect of the license, so has
    not reached a conclusion about at what point imposing license
    obligations is appropriate. <br>
    <br>
    3.    <u>A license that requires data portability</u>. <br>
    Section 2.3(b) obliges the user of a software to “provide to any
    third party with which you have an enforceable legal agreement, a
    no-charge copy … of the User Data in your possession in which that
    third party has a Lawful Interest ….” The license submitter
    confirmed in this sequence of emails that the intent of this
    provision is to expand the scope of software freedom: <br>
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html</a><br>
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html</a><br>
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004126.html" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004126.html</a>
    <br>
    The members of the License Review Committee do not agree whether
    this is appropriate for an open source license. It therefore
    requires extensive additional public discussion before the OSI will
    be able to reach a conclusion on this point.<br>
    <br>
    If the license submitter is interested in resubmitting this license
    for review, the license review committee recommends eliciting
    additional, more diverse discussion on these points on the
    license-discuss list prior to its resubmission.<br>
    <br>
    <br>
    <div class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-signature"><br>
    </div>
    <div class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-cite-prefix">On 4/22/2019 2:43 PM, VanL wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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>
      <fieldset class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944mimeAttachmentHeader"></fieldset>
      <pre class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-quote-pre">_______________________________________________
License-review mailing list
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a>
<a class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail-m_-5951671555406410944moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
    </blockquote>
    <br>
  </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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-1377214042525883419gmail-m_3237944614474669553gmail_signature"><div dir="ltr"><div><div dir="ltr">Bruce Perens - Partner, <a href="http://OSS.Capital" target="_blank">OSS.Capital</a>.</div></div></div></div>