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

VanL van.lindberg at gmail.com
Thu Jun 27 22:03:29 UTC 2019 

Thank you for the work and concrete feedback. While I do not necessarily
agree with the objections raised, I appreciate that they are legitimate
concerns and were raised in good faith. Please expect a revision to the CAL
to be resubmitted.

One point of clarification: What does "elicit further discussion" mean,
exactly? The way this is phrased it sounds like it is my responsibility to
make sure that other people take the time to express their opinions.

Thank you,
Van


On Thu, Jun 27, 2019 at 8:03 AM Pamela Chestek <
pamela.chestek at opensource.org> 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 listLicense-review at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
> _______________________________________________
> 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/ae7fe83c/attachment-0001.html>

More information about the License-review mailing list