[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,
https://wiki.opensource.org/bin/Working+Groups+%26+Incubator+Projects/Archived+Discussions+on+Not+Approved+Licenses/,
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.
Pam
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