[License-review] For approval: The Cryptographic Autonomy License (Beta 4)

Pamela Chestek pamela.chestek at opensource.org
Thu Feb 13 02:12:33 UTC 2020

Hi Chris,

I'm still in the dark. Can you explain what OSD is not met and where you
find that in the license? If it's a meta-OSD problem, like forced
disclosure of data that is not yours to have, can you explain it in
layperson's terms? If you believe that the license is not appropriate
for certain types of uses or certain types of software architecture, can
you explain how that violates the OSD?


Pamela Chestek
Chair, License Review committee
Open Source Initiative

On 2/12/2020 5:48 PM, Christopher Lemmer Webber wrote:
> Hi Simon,
> Thank you for your question.  I have done my best to give a more high
> level series of questions in the last email I just sent in response to
> Van:
>   http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004675.html
> I hope I have done a better job of detailing a set of concerns that
> don't require going into the CS weeds.
> Simon Phipps writes:
>> Chris,
>> Thanks for the engagement. For those of us who are not specialists in the
>> computer science topics you're discussing, please can you summarise why you
>> believe CAL does not satisfy the OSD, specifically citing the clauses
>> involved?
>> Thanks
>> Simon
>> (in-role)
>> On Wed, Feb 12, 2020 at 12:08 AM Christopher Lemmer Webber <
>> cwebber at dustycloud.org> wrote:
>>> Hi Van,
>>> First of all, I have asked for review from a community I collaborate
>>> with which actually works on cryptographic autonomy here:
>>>   https://groups.google.com/forum/#!topic/cap-talk/VE6nNhfwp_w
>>> The above thread outlines my concerns in detail.  It may be desirable
>>> for me to bullet-point them in a follow-up email, but I'd encourage
>>> reading that email.
>>> I will respond to some parts below.
>>> VanL writes:
>>>> I look forward to responding to your other concerns. But to respond
>>> above:
>>>> There are only two substantive locations where cryptographic keys are
>>>> required. In the definition of source code, section 4.1:
>>>> 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.
>>>> 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,* authorization keys,*
>>> 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."
>>>> 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.
>>> I agree that it is similar to GPLv3 in this particular section, however
>>> there are some key differences.  The GPLv3 appears to specify the
>>> requirement to "install and execute".  This is not the same as the
>>> requirement to provide a broader requirement for documentation for
>>> "use".  Usage is significantly broader than mere execution... how much
>>> documentation need there be?  Is it a violation to add a feature then
>>> not document how to use it?  There is also a broader number of
>>> requirements here, including the requirements for configuration
>>> information.
>>> This isn't the primary part I am concerned about, but it does concern
>>> me.  As I expressed in the email above to cap-talk (and in my Copyleft
>>> Conference talk last year), I am *already* concerned about the
>>> requirements that network copyleft introduces in the AGPL for a
>>> circumstance where there is little distinction between code and data,
>>> and thus private configuration information might be considered part of
>>> the complete and corresponding work.  In my talk last year I was making
>>> an argument that we could see emacs lisp as being both configuration
>>> information and code (but the lack of network requirement permitted
>>> private modification).  Here that argument need not even be made since
>>> the CAL *explicitly* requires configuration information.
>>> I'm definitely worried then about:
>>>  - The introduction of a requirement for documentation for *use*
>>>  - The introduction of a requirement for configuration information,
>>>    *especially in the context of network distribution requirements*.
>>> These concerns compound with the following section.
>>>> The second substantive place where cryptographic keys are mentioned is in
>>>> the user autonomy provisions, specifically 4.2.2:
>>>> 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.
>>>> 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."
>>> Here is where I am very concerned.  Recipient is very broad.
>>> The use of the word "operator" tells me that the intended use of this
>>> license has been seen within the scope of a client-server style
>>> architecture, or has been flavored by the experience of seeing that
>>> rolled out as the primary way we've seen networked applications in the
>>> last couple of decades.  I explain in the above email to cap-talk why I
>>> think this is going to be big trouble: I believe it *actually* prevents
>>> applications and protocols that are persuing cryptographic autonomy.  In
>>> particular:
>>>  - It does not seem to anticipate that *every user* should be running
>>>    their own application... not client-to-server, but peer-to-peer, so
>>>    these are not "server operator requirements", they are requirements
>>>    for every user, including potentially ones just running some software
>>>    on their phone or laptop.  If Bob holds some small amount of data on
>>>    Alice's machine, is Bob able to persue an enforcement request from
>>>    Alice's usage of her phone?  I do not see a good way to present this
>>>    requirement to ordinary users, and it may even result in accidental
>>>    privacy leaks.
>>>  - Assume that object access is managed by capability security.  This is
>>>    to say, if you have a reference to an object, you can access its
>>>    resources, but otherwise you cannot.  In order to uphold the
>>>    Principle of Least Authority, varied and attenuated access is given
>>>    out to many different objects in the system.  Which of them are
>>>    "users", and what rights for what data do they have to extract which
>>>    information?  This is not theoretical, this is the direction that
>>>    sophisticated peer-to-peer, cryptographically secure distributed
>>>    programs are going (eg the programming language E, the work that the
>>>    Agoric company is doing, and my own work on Spritely Goblins).  While
>>>    I (and many other security researchers) believe this is the
>>>    healthiest direction for network security to go, I do not see a good
>>>    way to be able to uphold this with the requirements for recipient
>>>    data distribution and key distribution.
>>> Perhaps this sounds too technically abstract.  Let me put it more
>>> simply: I believe I could use this license to coerce someone into giving
>>> up private data or encryption keys in a peer to peer network.
>>>> 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).
>>> You seem more confident than I am in terms of what these categories are,
>>> so I think it would be useful for you to give us some scenarios, then we
>>> can work through them:
>>>  - A requirement for distributing "recipient data".
>>>  - A situation where two peers communicate, but a requirement for
>>>    recipient data distribution does not become invoked.
>>>  - A scenario by which cryptographic key material, in relationship to
>>>    user data, must be provided.
>>>  - A scenario where the remote program has cryptographic key material
>>>    that is not required to be distributed.  This one is very important
>>>    in that the question must be asked: "what part of the license makes
>>>    this categorically excluded from its requirement"?
>>> With those in place I think we can have a better analysis.
>>> Finally, I am going to repeat part of what I said in the cap-talk
>>> thread: the choice of the license name is ironic, because though the
>>> goals are good (ensure autonomy of users), it may actually create
>>> difficulties in complying in the kinds of systems that actually are
>>> doing so through cryptography and protocols (ocap actor model systems,
>>> encrypted data vaults).  The problem is one that must be addressed for
>>> the sake of user freedom, but I believe it is being addressed on the
>>> incorrect layer.  Here we see an attempt to address it on the license
>>> layer, but IMO this is wrong: there are active systems that exist and
>>> are addressing this in such a way that the cryptographic tooling and
>>> protocols themselves are the ones that help ensure greater user
>>> autonomy.
>>> Thank you,
>>>  - Chris
>>>> Thanks,
>>>> Van
>>>> On Tue, Feb 11, 2020 at 6:54 AM Christopher Lemmer Webber <
>>>> cwebber at dustycloud.org> wrote:
>>>>> Where in the license is this distinction made?
>>>>> At any rate, I'm not convinced such a distinction exists.  I
>>>>> increasingly work with peer to peer systems where the distinction
>>>>> between "user" and "system" and even "client" and "server" no longer
>>>>> exist.  I don't believe it is possible to make a sound distinction, and
>>>>> at any rate I don't see one in the license.  But perhaps I am missing
>>>>> something?
>>>>> Regardless, these are not my only concerns.  I will write them up today.
>>>>> VanL writes:
>>>>>> I definitely want to hear any concerns... but I will also note that
>>> the
>>>>>> crypto portions of the license were reviewed by a number of people who
>>>>> are
>>>>>> expert in that space and they approved.
>>>>>> My best guess is that you are concerned that this requires the
>>> disclosure
>>>>>> of user-specific keys, and so you think that means that traditional
>>>>> crypto
>>>>>> which relies on a private key or private cert would need to be
>>> disclosed.
>>>>>> This is incorrect.
>>>>>> They difference is between user keys and system keys. User keys form
>>> the
>>>>>> basis of a user's identity and control over computation or data. Under
>>>>> the
>>>>>> license, they must be controlled by the user alone.
>>>>>> System keys, however, used for things like TLS and SSH, are not User
>>> Data
>>>>>> within the scope of that term. They may be kept confidential and
>>> secure.
>>>>>> Thanks,
>>>>>> Van
>>>>>> __________________________
>>>>>> Van Lindberg
>>>>>> van.lindberg at gmail.com
>>>>>> m: 214.364.7985
>>>>>> On Mon, Feb 10, 2020, 7:17 PM Christopher Lemmer Webber <
>>>>>> cwebber at dustycloud.org> wrote:
>>>>>>> Josh Berkus writes:
>>>>>>>> On 1/7/20 11:00 AM, Pamela Chestek wrote:
>>>>>>>>> The discussion is still active so it will not be considered at the
>>>>> next
>>>>>>>>> Board meeting, which is this Friday. The soonest would be the
>>>>> February
>>>>>>>>> Board meeting.
>>>>>>>> So, it's been a month since there's been any discussion about the
>>> CAL.
>>>>>>>> Pamela, can we take a poll of how people feel about the license?
>>>>>>>> Pass/Reject/MoreDiscussionNeeded?
>>>>>>> I'm not very sure if I'm in the right place to state this, but I'd
>>> say
>>>>>>> "Reject" or at least "MoreDiscussionNeeded".  I believe there are
>>> very
>>>>>>> serious problems in the license that will (ironically, due to its
>>> name)
>>>>>>> prevent the ability to have safely private networks on
>>> cryptographically
>>>>>>> secure peer to peer networks.  I believe I can demonstrate the
>>> privacy
>>>>>>> risks, and spend most of tomorrow doing a detailed and longer writeup
>>>>>>> about my concerns.  Note that I don't think it's any malicious
>>> intention
>>>>>>> of the author to introduce these problems; I think Van is acting in
>>> good
>>>>>>> faith and interest there, but nonetheless I think the concerns exist
>>> and
>>>>>>> are very grave, if I understand correctly.
>>>>>>> If I am going to air them before the board meeting, am I doing it in
>>> the
>>>>>>> right place here?  If so, I will follow up on the thread here
>>> tomorrow.
>>>>>>>  - Chris
>>>>>>> PS: I'm sorry I haven't aired my very serious concerns earlier.  Van
>>>>>>> asked me personally to review at last year's CopyleftConf and I never
>>>>>>> got around to writing up my thoughts.  I regret that, and wish I had
>>>>>>> done so sooner... maybe I could have prevented a lot of trouble.
>>>>>>> Nonetheless I think it's important that I write them up now; I'm
>>>>>>> guessing we're in the "speak now or forever hold your peace" moment
>>>>>>> though, so I'm trying to articulate my concerns before it's too late.
>>>>>>> _______________________________________________
>>>>>>> License-review mailing list
>>>>>>> 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
>>>>> _______________________________________________
>>>>> License-review mailing list
>>>>> 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
>>> _______________________________________________
>>> License-review mailing list
>>> 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

More information about the License-review mailing list