[License-review] For Approval: The Cryptographic Autonomy License

Pamela Chestek pamela.chestek at opensource.org
Fri Aug 16 20:46:28 UTC 2019

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."

Vote: 7 Yes; 0 No; 0 Abstain.

The license has been listed on the "Archived Discussions on Not Approved
Licenses" wiki page,
which has a link to the rational document (also below).

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.


Pamela Chestek
Chair, License Review Committee
Open Source Initiative

On 6/27/2019 9:02 AM, Pamela Chestek wrote:
> 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.
> Pam
> Pamela Chestek
> Chair, License Review Committee
> Open Source Initiative
> License: Cryptographic Autonomy License (as captured 8 May 2019,
> Exhibit A)
> Submitted: April 22, 2019: 
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004028.html
> 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.
>     http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004156.html
>  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,
>     http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html;
>     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,
>     http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004153.html.
>     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.
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html.
> 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.
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004113.html
> 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.
> 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:
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004126.html
> 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:
>> https://docs.google.com/document/d/1sWUREQN02YJ-q91gXOCflRB57Q1YcU1G7UMS_a8WOTI/edit#
>>   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
>> (https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/)
>> as well as the discussion on license-discuss, summarized by Lukas
>> Atkinson here:
>> http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-April/020394.html
>> Thanks,
>> Van
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190816/97e00d23/attachment.html>

More information about the License-review mailing list