<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" 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="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004028.html">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="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004156.html">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="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html">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="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html">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="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html">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="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004113.html">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="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html</a><br>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html</a><br>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004126.html">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="moz-signature"><br>
</div>
<div class="moz-cite-prefix">On 4/22/2019 2:43 PM, VanL wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFQvZENr0qBdz40xR2aCTD+vvQyw+WmNL-tDtuXMPqHR345zMQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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#"
moz-do-not-send="true">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"
moz-do-not-send="true">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/"
moz-do-not-send="true">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"
moz-do-not-send="true">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="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>