<div dir="ltr"><div class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I look forward to responding to your other concerns. But to respond above:</div><div><br></div><div>There are only two substantive locations where cryptographic keys are required. In the definition of source code, section 4.1:</div><blockquote>The “Source Code” of the Work means the form of the Work preferred for making modifications, including any comments, configuration information, documentation, help materials, installation instructions, cryptographic seeds or keys, and any information reasonably necessary for the Recipient to independently compile and use the Source Code and to have full access to the functionality contained in the Work.</blockquote><div>This is essentially equivalent to the "complete corresponding source" of the GPL3. Quoting specifically from the GPL3: "'Installation Information' for a User Product means any methods,
procedures,<b> authorization keys,</b> or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source." <br></div><div><br></div><div>So this first element is tied to the ability to "independently compile and use the Source Code and have full access to the functionality contained in the Work" -- i.e., no Tivoization.</div><div><br></div><div>The second substantive place where cryptographic keys are mentioned is in the user autonomy provisions, specifically 4.2.2:</div><blockquote>You may not, by the use of cryptographic methods applied to anything provided to the Recipient, by possession or control of cryptographic keys, seeds, or hashes, by other technological protection measures, or by any other method, limit a Recipient's ability to access any functionality present in the Recipient's independent copy of the Work, or deny a Recipient full control of the Recipient's User Data.</blockquote><div>This is where the distinction arises. An operator must not use any technical measure, including the use of cryptographic protocols, to "limit a Recipient's ability to access any functionality" or to "deny a Recipient full control of the Recipient's User Data." However, securely transmitting information to the Recipient (e.g. using TLS) does nothing to "limit a Recipient's ability to access any functionality" or "deny a Recipient full control of the Recipient's User Data."</div><div><br></div><div>Thus, the information that needs to be provided, including cryptographic keys, is limited to that information that would prevent compilation or access to functionality, or would deny the Recipient full control over the Recipient's own user data. The normal system uses of cryptography are not implicated. Nor are the uses of cryptography in a distributed systems for addressing or authentication, excepting the use of a user's keys to validate an agent's actions (which belong to the user anyway).</div><div><br></div><div>Thanks,<br>Van</div><div><br></div><div><br><span style="font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap" id="gmail-docs-internal-guid-f3b5c567-7fff-69a7-4a39-fa1d5fc98b45"></span>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 11, 2020 at 6:54 AM Christopher Lemmer Webber <<a href="mailto:cwebber@dustycloud.org">cwebber@dustycloud.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Where in the license is this distinction made?<br>
<br>
At any rate, I'm not convinced such a distinction exists. I<br>
increasingly work with peer to peer systems where the distinction<br>
between "user" and "system" and even "client" and "server" no longer<br>
exist. I don't believe it is possible to make a sound distinction, and<br>
at any rate I don't see one in the license. But perhaps I am missing<br>
something?<br>
<br>
Regardless, these are not my only concerns. I will write them up today.<br>
<br>
<br>
VanL writes:<br>
<br>
> I definitely want to hear any concerns... but I will also note that the<br>
> crypto portions of the license were reviewed by a number of people who are<br>
> expert in that space and they approved.<br>
><br>
> My best guess is that you are concerned that this requires the disclosure<br>
> of user-specific keys, and so you think that means that traditional crypto<br>
> which relies on a private key or private cert would need to be disclosed.<br>
> This is incorrect.<br>
><br>
> They difference is between user keys and system keys. User keys form the<br>
> basis of a user's identity and control over computation or data. Under the<br>
> license, they must be controlled by the user alone.<br>
><br>
> System keys, however, used for things like TLS and SSH, are not User Data<br>
> within the scope of that term. They may be kept confidential and secure.<br>
><br>
> Thanks,<br>
> Van<br>
><br>
> __________________________<br>
> Van Lindberg<br>
> <a href="mailto:van.lindberg@gmail.com" target="_blank">van.lindberg@gmail.com</a><br>
> m: 214.364.7985<br>
><br>
> On Mon, Feb 10, 2020, 7:17 PM Christopher Lemmer Webber <<br>
> <a href="mailto:cwebber@dustycloud.org" target="_blank">cwebber@dustycloud.org</a>> wrote:<br>
><br>
>> Josh Berkus writes:<br>
>><br>
>> > On 1/7/20 11:00 AM, Pamela Chestek wrote:<br>
>> >> The discussion is still active so it will not be considered at the next<br>
>> >> Board meeting, which is this Friday. The soonest would be the February<br>
>> >> Board meeting.<br>
>> ><br>
>> > So, it's been a month since there's been any discussion about the CAL.<br>
>> > Pamela, can we take a poll of how people feel about the license?<br>
>> > Pass/Reject/MoreDiscussionNeeded?<br>
>><br>
>> I'm not very sure if I'm in the right place to state this, but I'd say<br>
>> "Reject" or at least "MoreDiscussionNeeded". I believe there are very<br>
>> serious problems in the license that will (ironically, due to its name)<br>
>> prevent the ability to have safely private networks on cryptographically<br>
>> secure peer to peer networks. I believe I can demonstrate the privacy<br>
>> risks, and spend most of tomorrow doing a detailed and longer writeup<br>
>> about my concerns. Note that I don't think it's any malicious intention<br>
>> of the author to introduce these problems; I think Van is acting in good<br>
>> faith and interest there, but nonetheless I think the concerns exist and<br>
>> are very grave, if I understand correctly.<br>
>><br>
>> If I am going to air them before the board meeting, am I doing it in the<br>
>> right place here? If so, I will follow up on the thread here tomorrow.<br>
>><br>
>> - Chris<br>
>><br>
>> PS: I'm sorry I haven't aired my very serious concerns earlier. Van<br>
>> asked me personally to review at last year's CopyleftConf and I never<br>
>> got around to writing up my thoughts. I regret that, and wish I had<br>
>> done so sooner... maybe I could have prevented a lot of trouble.<br>
>> Nonetheless I think it's important that I write them up now; I'm<br>
>> guessing we're in the "speak now or forever hold your peace" moment<br>
>> though, so I'm trying to articulate my concerns before it's too late.<br>
>><br>
>> _______________________________________________<br>
>> License-review mailing list<br>
>> <a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
>><br>
>> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
>><br>
> _______________________________________________<br>
> License-review mailing list<br>
> <a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>