<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
At its meeting today, the Board passed the following motion: "The
Board of the Open Source Initiative withholds its approval of the
Cryptographic Autonomy License Version 1.0 as an Open Source
Initiative Certified license."<br>
<br>
Vote: 7 Yes; 0 No; 0 Abstain.<br>
<br>
The license has been listed on the "Archived Discussions on Not
Approved Licenses" wiki page,
<a class="moz-txt-link-freetext" href="https://wiki.opensource.org/bin/Working+Groups+%26+Incubator+Projects/Archived+Discussions+on+Not+Approved+Licenses/">https://wiki.opensource.org/bin/Working+Groups+%26+Incubator+Projects/Archived+Discussions+on+Not+Approved+Licenses/</a>,
which has a link to the rational document (also below).<br>
<br>
I also moved the wiki page listing the Not Approved Licenses so that
it is linked from the home page of the wiki, which should make it a
bit easier to find.<br>
<br>
Pam<br>
<br>
<div class="moz-signature">Pamela Chestek<br>
Chair, License Review Committee<br>
Open Source Initiative<br>
<br>
</div>
<div class="moz-cite-prefix">On 6/27/2019 9:02 AM, Pamela Chestek
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:75f7060a-47e6-39aa-ad2b-6f8f2d8e7a80@opensource.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>