<div dir="ltr"><div>I have commented on earlier versions of the CAL and also discussed this version on license discuss. So I will just briefly summarize my conclusions here.</div><div><br></div><div>Overall this submission does a good job of addressing feedback from the previous review. I've called out some specific improvements like the anti-drm language. I also welcome the proposed patent litigation clause, which to my knowledge gives stronger copyleft protection against patent suits than any existing open source license.</div><div><br></div><div>Specific points:</div><div><br></div><div>1. Data Autonomy<br></div><div><br></div><div>This license justifies and scopes the "copyleft for user data" better than the previous versions. It is now very clear that the goal is just to protect user freedom.</div><div><br></div><div>Me and others have scrutinized this new idea a lot. In particular we have discussed the principle that open source software shouldn't cause legal burden or risk on a user that just wants to use the unmodified software. Personally I'm not concerned about a SaaS vendor having this obligation toward its customers and users. The burden is reasonable (required also by law in EU, for example) and well justified with the goal of securing a new aspect of software freedom to the user. <br></div><div><br></div><div>However, in the domain of consumer p2p software, like a file sharing software or (original) Skype, it would be private consumers that carry this burden, and it might be hard or impossible to fulfill their obligation. I tried to poke at this on license discuss, but I agree with Van that I failed to propose any improvement. As this is a fairly narrow corner case, I don't think this issue should stand in the way of approving the CAL as an open source license.</div><div><br></div><div>2. API copyright</div><div><br></div><div>This version no longer explicitly claims copyright on compatible APIs. However some subtle words seem to have been left in the license to allow for potentially still asserting such a claim in a jurisdiction where an API could be so protected. When prompted, Van didn't deny this. This IMO puts the OSI in a difficult position. If APIs become copyrightable, it is not clear what the OSIs and open source community's reaction to that will be. Approving this license now would essentially decide the issue without discussion. The license would be OSI approved and Van's client or any other CAL user could start asserting API copyright and claim that this license "clearly" allows and intends such an assertion.</div><div><br></div><div>The remaining wording is so subtle that I don't feel qualified to push this issue further. But I would hope that lawyers on the list do and that the license approval committee pays attention to this point.</div><div><br></div><div>3. Coordinated Disclosure <br></div><div><br></div><div>I can think of arguments for and against this late addition, but in any case it is clearly OSD compliant. The same mechanism is allowed by all OSI approved permissive licenses.</div><div><br></div><div>It's also another great example of how new copyleft licenses can improve on issues not addressed by existing licenses!</div><div><br></div><div>henrik<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 23, 2019 at 12:11 AM 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><i>Rationale:</i> 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.<i><br></i></div><div><i><br></i></div><div><i>Distinguish:</i>
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_2297450306475990100gmail-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>
_______________________________________________<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"><br>-- <br><div dir="ltr" class="gmail_signature"><a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354 skype: henrik.ingo irc: hingo<br><a href="http://www.openlife.cc" target="_blank">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div></div>