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

Christopher Lemmer Webber cwebber at dustycloud.org
Wed Feb 12 00:07:46 UTC 2020

Hi Van,

First of all, I have asked for review from a community I collaborate
with which actually works on cryptographic autonomy here:


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

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

 - 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

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

More information about the License-review mailing list