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

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

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/20190627/5bd4fb89/attachment.html>


More information about the License-review mailing list