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

[VanL]

Hi Chris,

Thanks for sharing your concerns.

Let me start with your last point first:

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.
>

You may be interested to know that I did not choose this name. It was
specified by my client, whose founders have spent their professional life
working on Cryptographic Autonomy - and this license was specifically
designed in part to deal with issues that the technical layer can't handle
well. The legal layer isn't sufficient, but neither is the technical layer.
Code has bugs; protocols can be subverted. The license is a backstop and
tool to stop an entirely different set of adversaries that are not well
addressed by using code alone.

Now, addressing your more-specific concerns, my response in brief is that
you are incorrect as to the scope of what is required by the CAL.

First, with regard to the source code requirement: The easy response is
that there is nothing in the CAL that would require someone to generate new
documentation. More generally, you are confusing configuration information
generally with configuration information needed to install and use, which
is the context of this provision.

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*.
>

I... confess I don't follow your argument here. I am aware of the LISPy
"code is data is configuration"-type context - but I am having trouble
imagining a network-aware Emacs creating any burden at all. Even if you
look at typical network interactions that have been built into Emacs (news
reader, email, etc), you would have to evaluate whether your interaction
via Emacs turned the other party into a Recipient by transmitting a
licensable element to the other party. In all the cases I am aware of,
Emacs would be a client (in the typical client-server sense). In the case
where one party is acting as a client, the terms of the interaction are
generally set by the party acting as the server in a particular network
transaction. I am not sure how requesting information from a third party,
on terms set by the third party, would involve the sharing of *your*
copyrightable/licensable material. Accordingly, the third party is not a
"Recipient" according to the terms of the CAL and your Emacs configuration
is safe - and private to you.

If you modified Emacs to be a server, and serve up information, then that
would be something else - but in that case it is no different than any
other server.

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.
>

You are mistaken. The CAL was written specifically for a peer-to-peer
application, but was designed to be compatible with client-server
interactions, as they are the most common. Nevertheless, even in a
peer-to-peer interaction, you can still talk about a "Recipient" because
each peer acts sometimes as a client and sometimes as a server, and those
different roles give rise to different types of sharing (and thus different
requirements).

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 .[...]



>   - Assume that object access is managed by capability security.  [...]


I am familiar with actor-model ocap systems, and this does not cause them
any issue. The CAL is very careful to limit disclosure to the Recipient's
user data; it does not require disclosure of the operator's private data.

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 comment shows a key misunderstanding: A user is a *person*, not an
object that has been granted authority. This is one of the benefits of
acting at the legal layer; we can apply legal reasoning to the
people-actors, not the object-actors that live in the system.

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.
>

I don't really think this is the place to dive deep into software
architecture, so I'll just say that this reflects a misunderstanding of the
requirements of the CAL. Least authority system or not, the analysis is:
  1) Is there a Recipient - a human being that has received licensable
material?
  2) Do I have the Recipient's User Data? Meaning, do I have data that a
User has a legal right to in my possession?
  3) Is that User Data available to me? (For example, not encrypted beyond
my ability to identify it?)

If all three of these questions are true, then you need to provide the
Recipient's User Data back to the Recipient.

I will return again to the main point: I have a pretty good knowledge of,
and deep respect for, the leading edge of capability-based systems. We
definitely need further technical work in this area in order to provide
better guarantees to users. But that doesn't mean that the legal layer is
unnecessary! The legal layer is orthogonal to the technical layer, and each
reinforces the other. It is a fundamental mistake to only look at one or
the other.

Thanks,
Van
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200211/e97f3a0f/attachment-0001.html>