<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
It was phrased that way because we didn't know whether you would be
interested in resubmitting and OSI wouldn't be starting theoretical
conversations just for the heck of it. So the thought was that if
you are interested in resubmitting you could get the ball rolling on
the conversation, since you have the greatest interest in ensuring
OSI has enough information to reach a conclusion. But anyone else
could too. Honestly, I was expecting people to already be expressing
opinions on these issues, I think they're really interesting and
thought-provoking. But what do I know!<br>
<br>
Personally, what I wanted to see was more people who might agree
with you and make a persuasive case that these choices are
consistent with open source principles - you didn't have a lot of
allies, and maybe because there aren't any, but I couldn't tell. I
also wanted to see reasoned explanations from both sides why the
choices do or don't enhance the availability of software. For
example, there seems to be a belief that a very strong copyleft is
counterproductive and therefore harms software freedom. If that's
true, and a basis for therefore saying a license isn't "open
source," how do we know where the line is?<br>
<br>
Saying again for clarity, all my personal opinion! Not speaking for
OSI.<br>
<br>
Pam<br>
<br>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
PO Box 2492<br>
Raleigh, NC 27602<br>
919-800-8033<br>
<a class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
</div>
<div class="moz-cite-prefix"><br>
On 6/27/2019 6:03 PM, VanL wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFQvZENsayVB8ZPRBOvwUJvUyfEyvHof8Z_02Ln1V+N-5Smz=g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Thank you for the work and concrete feedback. While I do
not necessarily agree with the objections raised, I appreciate
that they are legitimate concerns and were raised in good
faith. Please expect a revision to the CAL to be resubmitted.</div>
<div><br>
</div>
<div>One point of clarification: What does "elicit further
discussion" mean, exactly? The way this is phrased it sounds
like it is my responsibility to make sure that other people
take the time to express their opinions.</div>
<div><br>
</div>
<div>Thank you,</div>
<div>Van</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2019 at 8:03
AM Pamela Chestek <<a
href="mailto:pamela.chestek@opensource.org"
moz-do-not-send="true">pamela.chestek@opensource.org</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 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="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004028.html"
target="_blank" 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="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004156.html"
target="_blank" 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="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html"
target="_blank" 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="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html"
target="_blank" 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="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html"
target="_blank" 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="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004113.html"
target="_blank" 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="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html"
target="_blank" moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html</a><br>
<a class="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html"
target="_blank" moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html</a><br>
<a class="gmail-m_-8836674767220522735moz-txt-link-freetext"
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004126.html"
target="_blank" 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="gmail-m_-8836674767220522735moz-signature"><br>
</div>
<div class="gmail-m_-8836674767220522735moz-cite-prefix">On
4/22/2019 2:43 PM, VanL wrote:<br>
</div>
<blockquote type="cite">
<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#"
target="_blank" 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"
target="_blank" 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/"
target="_blank" 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"
target="_blank" 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="gmail-m_-8836674767220522735mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-8836674767220522735moz-quote-pre">_______________________________________________
License-review mailing list
<a class="gmail-m_-8836674767220522735moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org" target="_blank" moz-do-not-send="true">License-review@lists.opensource.org</a>
<a class="gmail-m_-8836674767220522735moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" target="_blank" moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org"
target="_blank" moz-do-not-send="true">License-review@lists.opensource.org</a><br>
<a
href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</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>