<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">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">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>