OSI Board Statement on CAL


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.


Pamela Chestek
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.

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.

Open questions

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
    software freedom:

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.

1 Like

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.