<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Just a head's up that I don't think the Board can give a decision on
    this license until after its face-to-face board meeting scheduled
    for November 12-13. <br>
    <br>
    Pam<br>
    <br>
    <div class="moz-signature">Pamela Chestek<br>
      Chair, License Review Committee<br>
      Open Source Initiative</div>
    <div class="moz-cite-prefix"><br>
      On 8/22/2019 5:12 PM, VanL wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAFQvZENQk2O7iuPVHMTfqVT1y_gJ+7rNc=Mw5aKdhO2AkNkK6g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Note that before final approval I may change the acceptable
          delay to 30, 45, or 60 days based upon broader feedback, but
          would not expect to make any other change. (BTW, I would
          welcome feedback on that aspect on the license-discuss list.)<br>
        </div>
        <div><br>
        </div>
        <div>Thanks,<br>
        </div>
        <div>Van<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 4:10
          PM VanL <<a href="mailto:van.lindberg@gmail.com"
            moz-do-not-send="true">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>I am withdrawing Beta 2 and substituting Beta 3. The
              only difference between the two is the addition of new
              provision 4.1.3:</div>
            <div><br>
            </div>
            #### 4.1.3. Coordinated Disclosure of Security
            Vulnerabilities<br>
            <div>You may delay providing the Source Code corresponding
              to a particular modification of the Work for up to ninety
              (90) days (the “Embargo Period”) if: a) the modification
              is intended to address a newly-identified vulnerability or
              a security flaw in the Work, b) disclosure of the
              vulnerability or security flaw before the end of the
              Embargo Period would put the data, identity, or autonomy
              of one or more Recipients of the Work at significant risk,
              c) You are participating in a coordinated disclosure of
              the vulnerability or security flaw with one or more
              additional Licensees, and d) the Source Code pertaining to
              the modification is provided to all Recipients at the end
              of the Embargo Period.</div>
            <div><br>
            </div>
            <div>All other discussion regarding CAL Beta 2 should apply.
              The following is copied from the Beta 2 submission:<br>
            </div>
            <div><br>
            </div>
            <div><em>Rationale:</em> The CAL is a new network copyleft
              license especially applicable for distributed systems. It
              is designed to be as protective as possible of downstream
              recipients of the software, providing them all that they
              need to create and use an independent copy of a licensed
              work without losing functionality or data.<em><br>
              </em></div>
            <div><em><br>
              </em></div>
            <div><em>Distinguish:</em> The CAL is most similar to the
              AGPL, and will have a similar scope of action in most
              cases. However, the CAL has provisions that require that
              operators provide recipients of the software with a copy
              of their user data, enhancing their ability to
              independently use the software. The CAL also allows the
              creation of mixed "Larger Works," provides for affiliate
              use, and does not specify a mechanism by which notice is
              given to recipients.<br>
            </div>
            <div><br>
            </div>
            <div><i>Legal Analysis</i>: The CAL was drafted by legal
              counsel. Previous discussions have outlined many aspects
              of the legal analysis.</div>
            <div><br>
            </div>
            <div>Following the rejection of CAL Beta 1, this version has
              been reworked to remove the reasons for rejection and to
              address the concerns that led into the “further
              discussion” items. In particular, I worked on laying out
              the scope of the private right of use, clarifying when the
              conditions apply, and avoiding constructions that may
              result in adverse policy inferences. I also simplified the
              language to enhance interpretability.<br>
            </div>
            <div>
              <div><br>
              </div>
              <div>The most controversial aspect of the CAL remains: it
                requires someone who is communicating the software (or a
                part of the software) to a "Recipient" (a non-affiliated
                third party), to also allow that Recipient access to the
                Recipient's own user data. To show how this fits into
                the broader concept of software freedom, the policy
                associated with this requirement is also laid out: to
                allow a Recipient to fully use an independent copy of
                the Work generated from the Source Code provided with
                the Recipient’s own User Data.</div>
              <div><i><br>
                </i></div>
              <div><i>Previous Discussion</i>: For those only following
                this list, I also provided a changelog on
                license-discuss [1] which prompted some discussion. From
                that discussion, I'll note that Russell McOrmond is on
                record as believing that the CAL is part of a class of
                licenses - which includes the AGPL, and the GPL as
                applied) is not compliant with the OSD. Bruce Perens is
                on record as believing the any requirements that an
                operator provide user data is a violation of "no field
                of use" restriction in OSD 6. Bruce is also on record as
                believing that the identification of the private right
                of use is a field of use restriction.<br>
                <div><br>
                </div>
                <div>
                  <div><br>
                  </div>
                  <div>[1] <a
href="http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-August/020937.html"
                      target="_blank" moz-do-not-send="true">http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-August/020937.html</a>
                    <div
                      class="gmail-m_8661181084855566984gmail-m_8598923853321266476gmail-adL"><br>
                    </div>
                  </div>
                </div>
                <div>A copy of the license (now beta 3) in
                  markdown-formatted plaintext is attached.</div>
                <div><br>
                </div>
                <div>Thanks,<br>
                </div>
                <div>Van</div>
              </div>
            </div>
          </div>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
License-review mailing list
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>