[License-review] For Approval: The Cryptographic Autonomy License
Pamela Chestek
pamela at chesteklegal.com
Fri Jun 28 00:33:37 UTC 2019
It was phrased that way because we didn't know whether you would be
interested in resubmitting and OSI wouldn't be starting theoretical
conversations just for the heck of it. So the thought was that if you
are interested in resubmitting you could get the ball rolling on the
conversation, since you have the greatest interest in ensuring OSI has
enough information to reach a conclusion. But anyone else could too.
Honestly, I was expecting people to already be expressing opinions on
these issues, I think they're really interesting and thought-provoking.
But what do I know!
Personally, what I wanted to see was more people who might agree with
you and make a persuasive case that these choices are consistent with
open source principles - you didn't have a lot of allies, and maybe
because there aren't any, but I couldn't tell. I also wanted to see
reasoned explanations from both sides why the choices do or don't
enhance the availability of software. For example, there seems to be a
belief that a very strong copyleft is counterproductive and therefore
harms software freedom. If that's true, and a basis for therefore saying
a license isn't "open source," how do we know where the line is?
Saying again for clarity, all my personal opinion! Not speaking for OSI.
Pam
Pamela S. Chestek
Chestek Legal
PO Box 2492
Raleigh, NC 27602
919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com
On 6/27/2019 6:03 PM, VanL wrote:
> 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 <mailto: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 list
>> License-review at lists.opensource.org <mailto:License-review at lists.opensource.org>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> <mailto:License-review at lists.opensource.org>
> http://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/048ea68c/attachment-0001.html>
More information about the License-review
mailing list