<div dir="auto">Hi Pam,<div dir="auto"><br></div><div dir="auto">Chris can weigh in, but given his last response, I think the concern is similar to ones that were previously raised, specifically:</div><div dir="auto"><br></div><div dir="auto">What if the software architecture makes it difficult to identify or access the user data?</div><div dir="auto"><br></div><div dir="auto">and</div><div dir="auto"><br></div><div dir="auto">What if there is not a built-in way to identify and export user data?</div><div dir="auto"><br></div><div dir="auto">I think that the meta response is the same: the CAL does not and should not define a particular method of compliance. That may mean that the CAL is not appropriate for some uses, but that is in the control of the licensor.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Van<br><br><div data-smartmail="gmail_signature" dir="auto">__________________________<br>Van Lindberg<br><a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a><br>m: 214.364.7985</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 12, 2020, 8:13 PM Pamela Chestek <<a href="mailto:pamela.chestek@opensource.org">pamela.chestek@opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<br>
<br>
I'm still in the dark. Can you explain what OSD is not met and where you<br>
find that in the license? If it's a meta-OSD problem, like forced<br>
disclosure of data that is not yours to have, can you explain it in<br>
layperson's terms? If you believe that the license is not appropriate<br>
for certain types of uses or certain types of software architecture, can<br>
you explain how that violates the OSD?<br>
<br>
Thanks,<br>
Pam<br>
<br>
Pamela Chestek<br>
Chair, License Review committee<br>
Open Source Initiative<br>
<br>
On 2/12/2020 5:48 PM, Christopher Lemmer Webber wrote:<br>
> Hi Simon,<br>
><br>
> Thank you for your question. I have done my best to give a more high<br>
> level series of questions in the last email I just sent in response to<br>
> Van:<br>
><br>
> <a href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004675.html" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004675.html</a><br>
><br>
> I hope I have done a better job of detailing a set of concerns that<br>
> don't require going into the CS weeds.<br>
><br>
><br>
> Simon Phipps writes:<br>
><br>
>> Chris,<br>
>><br>
>> Thanks for the engagement. For those of us who are not specialists in the<br>
>> computer science topics you're discussing, please can you summarise why you<br>
>> believe CAL does not satisfy the OSD, specifically citing the clauses<br>
>> involved?<br>
>><br>
>> Thanks<br>
>><br>
>> Simon<br>
>> (in-role)<br>
>><br>
>> On Wed, Feb 12, 2020 at 12:08 AM Christopher Lemmer Webber <<br>
>> <a href="mailto:cwebber@dustycloud.org" target="_blank" rel="noreferrer">cwebber@dustycloud.org</a>> wrote:<br>
>><br>
>>> Hi Van,<br>
>>><br>
>>> First of all, I have asked for review from a community I collaborate<br>
>>> with which actually works on cryptographic autonomy here:<br>
>>><br>
>>> <a href="https://groups.google.com/forum/#!topic/cap-talk/VE6nNhfwp_w" rel="noreferrer noreferrer" target="_blank">https://groups.google.com/forum/#!topic/cap-talk/VE6nNhfwp_w</a><br>
>>><br>
>>> The above thread outlines my concerns in detail. It may be desirable<br>
>>> for me to bullet-point them in a follow-up email, but I'd encourage<br>
>>> reading that email.<br>
>>><br>
>>> I will respond to some parts below.<br>
>>><br>
>>> VanL writes:<br>
>>><br>
>>>> I look forward to responding to your other concerns. But to respond<br>
>>> above:<br>
>>>> There are only two substantive locations where cryptographic keys are<br>
>>>> required. In the definition of source code, section 4.1:<br>
>>>><br>
>>>> The “Source Code” of the Work means the form of the Work preferred for<br>
>>>> making modifications, including any comments, configuration information,<br>
>>>> documentation, help materials, installation instructions, cryptographic<br>
>>>> seeds or keys, and any information reasonably necessary for the Recipient<br>
>>>> to independently compile and use the Source Code and to have full access<br>
>>> to<br>
>>>> the functionality contained in the Work.<br>
>>>><br>
>>>> This is essentially equivalent to the "complete corresponding source" of<br>
>>>> the GPL3. Quoting specifically from the GPL3: "'Installation Information'<br>
>>>> for a User Product means any methods, procedures,* authorization keys,*<br>
>>> or<br>
>>>> other information required to install and execute modified versions of a<br>
>>>> covered work in that User Product from a modified version of its<br>
>>>> Corresponding Source."<br>
>>>><br>
>>>> So this first element is tied to the ability to "independently compile<br>
>>> and<br>
>>>> use the Source Code and have full access to the functionality contained<br>
>>> in<br>
>>>> the Work" -- i.e., no Tivoization.<br>
>>> I agree that it is similar to GPLv3 in this particular section, however<br>
>>> there are some key differences. The GPLv3 appears to specify the<br>
>>> requirement to "install and execute". This is not the same as the<br>
>>> requirement to provide a broader requirement for documentation for<br>
>>> "use". Usage is significantly broader than mere execution... how much<br>
>>> documentation need there be? Is it a violation to add a feature then<br>
>>> not document how to use it? There is also a broader number of<br>
>>> requirements here, including the requirements for configuration<br>
>>> information.<br>
>>><br>
>>> This isn't the primary part I am concerned about, but it does concern<br>
>>> me. As I expressed in the email above to cap-talk (and in my Copyleft<br>
>>> Conference talk last year), I am *already* concerned about the<br>
>>> requirements that network copyleft introduces in the AGPL for a<br>
>>> circumstance where there is little distinction between code and data,<br>
>>> and thus private configuration information might be considered part of<br>
>>> the complete and corresponding work. In my talk last year I was making<br>
>>> an argument that we could see emacs lisp as being both configuration<br>
>>> information and code (but the lack of network requirement permitted<br>
>>> private modification). Here that argument need not even be made since<br>
>>> the CAL *explicitly* requires configuration information.<br>
>>><br>
>>> I'm definitely worried then about:<br>
>>> - The introduction of a requirement for documentation for *use*<br>
>>> - The introduction of a requirement for configuration information,<br>
>>> *especially in the context of network distribution requirements*.<br>
>>><br>
>>> These concerns compound with the following section.<br>
>>><br>
>>>> The second substantive place where cryptographic keys are mentioned is in<br>
>>>> the user autonomy provisions, specifically 4.2.2:<br>
>>>><br>
>>>> You may not, by the use of cryptographic methods applied to anything<br>
>>>> provided to the Recipient, by possession or control of cryptographic<br>
>>> keys,<br>
>>>> seeds, or hashes, by other technological protection measures, or by any<br>
>>>> other method, limit a Recipient's ability to access any functionality<br>
>>>> present in the Recipient's independent copy of the Work, or deny a<br>
>>>> Recipient full control of the Recipient's User Data.<br>
>>>><br>
>>>> This is where the distinction arises. An operator must not use any<br>
>>>> technical measure, including the use of cryptographic protocols, to<br>
>>> "limit<br>
>>>> a Recipient's ability to access any functionality" or to "deny a<br>
>>> Recipient<br>
>>>> full control of the Recipient's User Data." However, securely<br>
>>> transmitting<br>
>>>> information to the Recipient (e.g. using TLS) does nothing to "limit a<br>
>>>> Recipient's ability to access any functionality" or "deny a Recipient<br>
>>> full<br>
>>>> control of the Recipient's User Data."<br>
>>> Here is where I am very concerned. Recipient is very broad.<br>
>>><br>
>>> The use of the word "operator" tells me that the intended use of this<br>
>>> license has been seen within the scope of a client-server style<br>
>>> architecture, or has been flavored by the experience of seeing that<br>
>>> rolled out as the primary way we've seen networked applications in the<br>
>>> last couple of decades. I explain in the above email to cap-talk why I<br>
>>> think this is going to be big trouble: I believe it *actually* prevents<br>
>>> applications and protocols that are persuing cryptographic autonomy. In<br>
>>> particular:<br>
>>><br>
>>> - It does not seem to anticipate that *every user* should be running<br>
>>> their own application... not client-to-server, but peer-to-peer, so<br>
>>> these are not "server operator requirements", they are requirements<br>
>>> for every user, including potentially ones just running some software<br>
>>> on their phone or laptop. If Bob holds some small amount of data on<br>
>>> Alice's machine, is Bob able to persue an enforcement request from<br>
>>> Alice's usage of her phone? I do not see a good way to present this<br>
>>> requirement to ordinary users, and it may even result in accidental<br>
>>> privacy leaks.<br>
>>><br>
>>> - Assume that object access is managed by capability security. This is<br>
>>> to say, if you have a reference to an object, you can access its<br>
>>> resources, but otherwise you cannot. In order to uphold the<br>
>>> Principle of Least Authority, varied and attenuated access is given<br>
>>> out to many different objects in the system. Which of them are<br>
>>> "users", and what rights for what data do they have to extract which<br>
>>> information? This is not theoretical, this is the direction that<br>
>>> sophisticated peer-to-peer, cryptographically secure distributed<br>
>>> programs are going (eg the programming language E, the work that the<br>
>>> Agoric company is doing, and my own work on Spritely Goblins). While<br>
>>> I (and many other security researchers) believe this is the<br>
>>> healthiest direction for network security to go, I do not see a good<br>
>>> way to be able to uphold this with the requirements for recipient<br>
>>> data distribution and key distribution.<br>
>>><br>
>>> Perhaps this sounds too technically abstract. Let me put it more<br>
>>> simply: I believe I could use this license to coerce someone into giving<br>
>>> up private data or encryption keys in a peer to peer network.<br>
>>><br>
>>>> Thus, the information that needs to be provided, including cryptographic<br>
>>>> keys, is limited to that information that would prevent compilation or<br>
>>>> access to functionality, or would deny the Recipient full control over<br>
>>> the<br>
>>>> Recipient's own user data. The normal system uses of cryptography are not<br>
>>>> implicated. Nor are the uses of cryptography in a distributed systems for<br>
>>>> addressing or authentication, excepting the use of a user's keys to<br>
>>>> validate an agent's actions (which belong to the user anyway).<br>
>>> You seem more confident than I am in terms of what these categories are,<br>
>>> so I think it would be useful for you to give us some scenarios, then we<br>
>>> can work through them:<br>
>>><br>
>>> - A requirement for distributing "recipient data".<br>
>>> - A situation where two peers communicate, but a requirement for<br>
>>> recipient data distribution does not become invoked.<br>
>>> - A scenario by which cryptographic key material, in relationship to<br>
>>> user data, must be provided.<br>
>>> - A scenario where the remote program has cryptographic key material<br>
>>> that is not required to be distributed. This one is very important<br>
>>> in that the question must be asked: "what part of the license makes<br>
>>> this categorically excluded from its requirement"?<br>
>>><br>
>>> With those in place I think we can have a better analysis.<br>
>>><br>
>>> Finally, I am going to repeat part of what I said in the cap-talk<br>
>>> thread: the choice of the license name is ironic, because though the<br>
>>> goals are good (ensure autonomy of users), it may actually create<br>
>>> difficulties in complying in the kinds of systems that actually are<br>
>>> doing so through cryptography and protocols (ocap actor model systems,<br>
>>> encrypted data vaults). The problem is one that must be addressed for<br>
>>> the sake of user freedom, but I believe it is being addressed on the<br>
>>> incorrect layer. Here we see an attempt to address it on the license<br>
>>> layer, but IMO this is wrong: there are active systems that exist and<br>
>>> are addressing this in such a way that the cryptographic tooling and<br>
>>> protocols themselves are the ones that help ensure greater user<br>
>>> autonomy.<br>
>>><br>
>>> Thank you,<br>
>>> - Chris<br>
>>><br>
>>>> Thanks,<br>
>>>> Van<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Feb 11, 2020 at 6:54 AM Christopher Lemmer Webber <<br>
>>>> <a href="mailto:cwebber@dustycloud.org" target="_blank" rel="noreferrer">cwebber@dustycloud.org</a>> wrote:<br>
>>>><br>
>>>>> 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<br>
>>> the<br>
>>>>>> crypto portions of the license were reviewed by a number of people who<br>
>>>>> are<br>
>>>>>> expert in that space and they approved.<br>
>>>>>><br>
>>>>>> My best guess is that you are concerned that this requires the<br>
>>> disclosure<br>
>>>>>> of user-specific keys, and so you think that means that traditional<br>
>>>>> crypto<br>
>>>>>> which relies on a private key or private cert would need to be<br>
>>> disclosed.<br>
>>>>>> This is incorrect.<br>
>>>>>><br>
>>>>>> They difference is between user keys and system keys. User keys form<br>
>>> the<br>
>>>>>> basis of a user's identity and control over computation or data. Under<br>
>>>>> 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<br>
>>> Data<br>
>>>>>> within the scope of that term. They may be kept confidential and<br>
>>> secure.<br>
>>>>>> Thanks,<br>
>>>>>> Van<br>
>>>>>><br>
>>>>>> __________________________<br>
>>>>>> Van Lindberg<br>
>>>>>> <a href="mailto:van.lindberg@gmail.com" target="_blank" rel="noreferrer">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" rel="noreferrer">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<br>
>>>>> next<br>
>>>>>>>>> Board meeting, which is this Friday. The soonest would be the<br>
>>>>> February<br>
>>>>>>>>> Board meeting.<br>
>>>>>>>> So, it's been a month since there's been any discussion about the<br>
>>> CAL.<br>
>>>>>>>> Pamela, can we take a poll of how people feel about the license?<br>
>>>>>>>> Pass/Reject/MoreDiscussionNeeded?<br>
>>>>>>> I'm not very sure if I'm in the right place to state this, but I'd<br>
>>> say<br>
>>>>>>> "Reject" or at least "MoreDiscussionNeeded". I believe there are<br>
>>> very<br>
>>>>>>> serious problems in the license that will (ironically, due to its<br>
>>> name)<br>
>>>>>>> prevent the ability to have safely private networks on<br>
>>> cryptographically<br>
>>>>>>> secure peer to peer networks. I believe I can demonstrate the<br>
>>> 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<br>
>>> intention<br>
>>>>>>> of the author to introduce these problems; I think Van is acting in<br>
>>> good<br>
>>>>>>> faith and interest there, but nonetheless I think the concerns exist<br>
>>> 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<br>
>>> the<br>
>>>>>>> right place here? If so, I will follow up on the thread here<br>
>>> tomorrow.<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" rel="noreferrer">License-review@lists.opensource.org</a><br>
>>>>>>><br>
>>>>>>><br>
>>> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
>>>>>> _______________________________________________<br>
>>>>>> License-review mailing list<br>
>>>>>> <a href="mailto:License-review@lists.opensource.org" target="_blank" rel="noreferrer">License-review@lists.opensource.org</a><br>
>>>>>><br>
>>> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
>>>>> _______________________________________________<br>
>>>>> License-review mailing list<br>
>>>>> <a href="mailto:License-review@lists.opensource.org" target="_blank" rel="noreferrer">License-review@lists.opensource.org</a><br>
>>>>><br>
>>>>><br>
>>> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
>>>> _______________________________________________<br>
>>>> License-review mailing list<br>
>>>> <a href="mailto:License-review@lists.opensource.org" target="_blank" rel="noreferrer">License-review@lists.opensource.org</a><br>
>>>><br>
>>> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer 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" rel="noreferrer">License-review@lists.opensource.org</a><br>
>>><br>
>>> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer 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" rel="noreferrer">License-review@lists.opensource.org</a><br>
> <a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
<br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank" rel="noreferrer">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>