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:
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.
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:
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.
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
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.
I’m of two very different minds about this.
On the one hand, this is more than I’ve seen in response to a license submission in recent times. It’s a message from the board to the review list with statements on matters of substance.That’s a giant leap for OSI, and something I begged for on my own submission, for months, to no avail. Getting this kind of thing compiled and posted requires work and persistence. It reflects very well of the new board.
But there’s not so much as a small step in substance to match the procedural milestone. Confining myself just to the “reasons for withholding approval”:
Facial analysis and the nondiscrimination criteria don’t mix. Literally any license condition commits that definition of discrimination. Every copyleft license fails that test. Copyleft discriminates against closed, proprietary development (field of endeavor?) and developers (persons or groups?). I’m tired of quoting RMS saying the GPL was written to discriminate against closed, as closed used prior license terms to discriminate against free.
Looking at the history of edits to OSD after the establishment of OSI, there is only one period of rapid, successive change. It came right after the founding, and the changes were directed toward outside comments from readers who read OSD, on its face, to exclude GPL.
If OSD 5 and 6 demand permissive licensing, or admit copyleft licensing only if blessed by particular foundations, OSI should say that. As it stands, invocation of the discrimination criteria actually indicate that the case against a license is weak. They’re last-ditch weapons. If you want to ding a license and you go digging in OSD for a reason, OSD 5 and 6 are what you’ll find.
An EU court may very well speak French or German or some other language. Translation steps of multiple kinds will inevitably be required.
Moreover, CAL is hardly the first proposed license to borrow specific language from US copyright law. Apache 2.0 borrows nearly all the specific US statutory language in its copyright and patent grants.
When a license doesn’t need or want to distinguish different exclusive rights, The Blue Oak Model License does it right. Just say “otherwise infringe [patent|copyleft]” and be done with it.
When a license needs or wants to call out a specific exclusive right, as does CAL, it has to use some word or phrase to evoke it. “Derivative work” is not a direct translation of non-US copyright laws, and it doesn’t appear in the Berne Convention either.
That’s already the case for every OSI-approved copyleft license that makes the reach of copyleft coterminous with “derivative work”. For example, OSL. Especially in light of evolving case law on API copyright.