[License-review] For Approval: The Cryptographic Autonomy License
pamela.chestek at opensource.org
Thu Jun 27 13:02:28 UTC 2019
Below is the License Review Committee's recommendation to the OSI Board
on the Cryptographic Autonomy License.
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.
Chair, License Review Committee
Open Source Initiative
License: Cryptographic Autonomy License (as captured 8 May 2019, Exhibit A)
Submitted: April 22, 2019:
Decision due no later than the first Board meeting after June 21, 2019
License Review Committee Recommendation:
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.
_Reasons for withholding approval:_
1. 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.
2. 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,
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
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.
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:
1. _Scope of copyleft_.
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.
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.
2. _At what point the licensor can oblige licensee behavior_.
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.
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
3. _A license that requires data portability_.
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
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.
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.
On 4/22/2019 2:43 PM, VanL wrote:
> 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.
> We now present the CAL 1.0-Beta for approval at the next board meeting:
> Google Docs link:
> PDF Link: https://www.processmechanics.com/static/CAL-1.0-Beta.pdf
> The CAL is still open for revision until it is approved by the Board,
> and the links above will be updated as appropriate.
> I also refer everyone here again to the blog post describing the legal
> foundations of the license
> as well as the discussion on license-discuss, summarized by Lukas
> Atkinson here:
> License-review mailing list
> License-review at lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-review