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

[VanL]

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. As an example, think of XMPP: originally decentralized, broadly
adopted in part due to support in Gmail, but then re-centralized and
re-proprietarized. That sort of situation would be significantly less
likely to occur in a CAL-licensed ecosystem.


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

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.

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