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

[Christopher Lemmer Webber]

VanL writes:

> Hi Chris,
>
> +On Wed, Feb 12, 2020 at 2:19 PM Christopher Lemmer Webber <
> cwebber at dustycloud.org> wrote:
>
>>
>> Could you specify what those problems are?
>>
>
> At least one key design concern was the gradual re-centralization of
> originally decentralized systems. A system can be designed to be
> decentralized, but aggregating too much power to one party - through
> non-nefarious means - can lead to harmful re-centralization and a loss of
> autonomy.

Definitely agreed with that.

> As an example, think of XMPP: originally decentralized, broadly
> adopted in part due to support in Gmail, but then re-centralized and
> re-proprietarized.

Yes, this is a real concern, and one I warn the ActivityPub community
about regularly.

> That sort of situation would be significantly less likely to occur in
> a CAL-licensed ecosystem.

>From a high level, I can see how the CAL tries to solve that.  Let me
give a contrasting approach, which I am now attempting to bring to the
federated social web:

  https://gitlab.com/spritely/golem/blob/master/README.org
  https://datashards.net/

Here we are trying to use datashards in an encrypted content-addressed
storage system so that the following things can happen:

 - Posts can be hosted across many servers.  A post no longer "lives" in
   a specific place, as posts tend to on the fediverse today.  In fact,
   servers can host data/posts without knowing what it is they are
   hosting (unless they were explicitly given authorization).

 - User profiles can be kept at updateable datashards URIs, which like
   the post URIs that can "live anywhere", do not live at any specific
   server.  But a user profile will say "here's where you should deliver
   my messages currently".  If the user would like to change which
   server they get messages delivered to, they can push out an update to
   the network without the consent of the original server.  This means
   users can survive nodes going down or just plain not wanting to be
   on the same hosting provider anymore... they can just move.

This is solving a similar problem to what you are trying to do in
legalcode, but on the cryptography/protocol layer.

>> The language of the section talks about use rather than execution, which
>> is broader.  Starting up and running a program is different than being
>> able to understand how to use its features.
>
>
> As I said, nothing in the CAL requires the generation of new documentation,
> and the context of this requirement is the provision of source code, which
> limits it. However, even if this were interpreted broadly, I don't think
> that asking for existing associated documentation is a bad thing. It is
> closely tied to the work, and, as you point out, the idea is to empower
> users.
>
> The AGPL makes no distinction between client and server...
>
>
> [snip a bunch about the AGPL]
>
> Although the AGPL may give rise to similar duties in many circumstances,
> the legal methods of operation are completely different. None of the
> analysis that you discuss here applies to the CAL.

Maybe this is the case for the network distribution requirement... I
assume this is the relevant section:

  If You exercise any permission granted by this License, such that the
  Work, or any part, aspect, or element of the Work, is distributed,
  communicated, made available, or made perceptible to a non-Affiliate
  third party (a “Recipient”), either via physical delivery or via a
  network connection to the Recipient, You must comply with the
  following conditions:

I have a bit of trouble telling whether or not this is saying that a
network interaction with a remote version of an application requires
distribution of source code or not.  A simple test would be, does
performing an HTTP POST or HTTP GET against a CAL-licensed server
implementation constitute a requirement that the server is required to
deliver the implementation's source code?

If the answer is "no", then I will agree with you: this is "weaker" than
the AGPL in such a way that my concerns do not manifest.  If the answer
is "yes", then I think my concerns are still there.  (Note that these
are separate concerns from the recipient data delivery concerns.)

> Moving to ocap systems:
>
>> That's true, though in an actor ocap style system the granularity of
>> such interactions is very small.  Does a recipient or user require a
>> human behind the wheel, or does it apply to every object in the system?
>>
>
> [snip ocap system, Alice and Bob, etc]
>
> You are thinking about this at entirely the wrong layer. You are trying to
> place a legal interpretation on technical abstractions. That is always
> dicey, and in this case it just doesn't fit. The best I can say is that it
> applies to the human motivating an action through one or more software
> interfaces. Trying to parse that out to "every object in the system" is
> like trying to ask whether each individual H20 molecule in the ocean is
> individually salty. It doesn't make sense. I completely understand your
> technical explanations. I am just not sure there is a way to meaningfully
> respond using the frame you propose.

You're right that I am looking at things in terms of a highly technical
perspective; it could be that I am wrong, because I am taking the
perspective in which I operate day-to-day.  It is true that in court,
neither a judge nor jury is likely to look at things in terms of a
system architecture.  Since you said you understood ocap actor model
architectture, I tried to explain things that way; maybe it was a
mistake.

So let's put it another way, in terms of a very high-level approach that
most people here will be familiar with: let's say that Alice runs a
distributed social network server (let's say Mastodon was under the CAL,
for simplicity, and Alice is running that), and Bob signs up as a user.
Bob makes a significant number of posts.

1. Is Alice required to be able to provide Bob with a "dump" of all of
   Bob's content so that Bob can leave at any time?  Presumably, yes.

2. This then means that Mastodon must be written in such a way where
   Alice can easily do this (or even better, that it can even be done
   without Alice's intervention).  If Mastodon does an incomplete job at
   this data dump, and some data is missing, is Alice in violation of
   the software license?

3. Presume an existing implementation of Mastodon today.  Right now we
   re pre-Datashards implementation... all links are https:// based, so
   you can't really migrate posts between servers.  Is this a
   "substantially identical use of the work in an equivalent context"
   even though now everything is broken?  (I genuinely don't know, but
   it could be interesting to see that tested in court.)

4. If Alice in violation of the license if:
   - She deletes old posts from 5+ years ago, because she was running
     out of server space?
   - She decides that Bob was violating community guidelines, and
     decides to delete some of Bob's posts?
   - The server experiences a crash, and some or all content is lost?

Maybe (3) is really not a concern, and an export of data is sufficient,
even if a "fully" equivalent context is not possible.  I genuinely don't
know.

As for (4), maybe there is a solution:

  4.2.1. No Withholding User Data

  Throughout any period in which You exercise any of the permissions
  granted to You under this License, You must also provide to any
  Recipient to whom you provide services via the Work, a no-charge copy,
  provided in a commonly used electronic form, of the Recipient’s User
  Data in your possession, to the extent that such User Data is
  available to You for use in conjunction with the Work.

You could say, well, such user data is no longer available to me for use
in conjunction with the work.  But then I wonder how useful this section
of the license is, since you could always just delete data to get around
the "no witholding" requirement.

At any rate, I think (1) and (2) are bigger concerns.  This seems like
an enormous implementation burden where the irony is that if
implementations get it wrong, operators of the service may be the ones
left holding the bag.

I still have some other concerns that I expressed in the prior email,
but I'm not sure how to get into them without getting back into the
technical muck (at least with my level of brain activity at this time of
the night)... at any rate, I've run out of time to argue them.  I also
still feel that the legal layer is the wrong layer at which to solve
this.  Still, I want to make clear that my concerns are not with the
sincerity of the *goals* of the CAL... I don't doubt Van's sincerity in
trying to solve problems which we both agree on.  I'm just nervous about
this as a solution.  But I have probably said as much as I have time to
say.