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

[VanL]

On Fri, Aug 23, 2019 at 1:43 PM Pamela Chestek <pamela at chesteklegal.com>
wrote:

>
> On 8/23/2019 2:31 PM, VanL wrote:
> > Bruce's - and your - arguments are frequently addressed to what I
> > might term "data in the large." Bruce made this point explicitly, by
> > invoking the slippery slope argument. However, should we be looking
> > more specifically at the CAL's requirements? They were written to be
> > narrow and closely tied to the actual capability to use the software.
> Can you walk me through how that's the case? That is the piece I'm missing.
>

Sure. The key concept is that a Recipient must have the full ability to
self-host or to switch hosts without having to give anything up in
exercising that right. This is expressed in the "Purpose" in Section 1:

> This License also strives to protect the freedom and autonomy of third
> parties who receive the Work from you. If any non-affiliated third party
> receives any part, aspect, or element of the Work from You, this License
> requires that You provide that third party all the permissions and
materials
> needed to independently use and modify the Work without that third party
> having a loss of data or capability due to your actions.

This frames the rest of the discussion, because the focus is on the
Recipient-User's ability to fully utilize the work. This focus is made
operable through the autonomy condition and the definition of User Data
itself:

> In addition to providing each Recipient the opportunity to have Access to
the
> Source Code, You cannot use the permissions given under this License to
> interfere with a Recipient’s ability to fully use an independent copy of
the
> Work generated from the Source Code You provide with the Recipient’s own
User
> Data.
>
> “_User Data_” means any data that is either an input to or an output from
the
> Work, or any data necessary for the functioning of the Work, in which the
> Recipient has an existing ownership interest, or that the Recipient has an
> existing right to possess, or that has been generated for or has been
> assigned to the Recipient.

I wrote this to be as careful as possible about preserving the Recipient's
ability to fork, or to self-host, or to choose another host, while not
reaching anything that the Recipient didn't have a right to. As such, it is
closely tied to the actual, practical experience of running an independent
copy of the software.

It is also important that the CAL doesn't require an operator to delete
copies and it does not encumber the data (in the legal sense). There is
nothing that provides an end-user Recipient control over the use of the
data by an operator-user Recipient. Just as with the source code, the
parties can each go their merry way and never interact again. This is again
a key distinction that makes the CAL not about "all data," but instead
about preserving an end-user's ability to run the software,

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