[License-review] For Approval: The Cryptographic Autonomy License

[VanL]

Hi Bruce,

I'm going to respond to both your emails here.


On Thu, May 9, 2019, 8:39 PM Bruce Perens <bruce at perens.com> wrote:

>
> The intent for Holochain, as promoted by your customer, is to be
> distributed without middlemen. However, in such a network there would be
> little need for the data disclosure terms, thus they appear to be meant to
> fight a centralized operator.
>

[Snip further discussion of Holochain]

Thanks for including the information about Holo and Holochain. I think this
provides valuable context.

In the view of the creators of Holochain, centralized power tends to reduce
the freedom of all those who interact with it. Thus decentralization is a
positive hood, in that it tends to maximize self-determination.  The CAL is
designed to  reduce the incentives for participants in the ecosystem to
take a decentralized system (like Holochain) and re-centralize it to get
power over the other participants.

This is why the CAL is really in the Free Software tradition: RMS saw
copyright as a tool for immoral domination of others, so he created
copyleft to reverse the typical incentives toward IP centralization,
promoting Freedom.

The creators of Holochain see centralized control over data as an
equivalent tool for immoral domination of others, and commissioned the CAL
to reverse the typical incentives toward data centralization ("hoarding"),
promoting Freedom.

This brings us to Freedom Zero. You wrote in your other email:

> OSI is not simply bound to interpret the OSD, but to protect user's
software freedom. Thus, we can apply this rule:
>
> The freedom to run the program as you wish, for any purpose (freedom 0).
>
> Your proposed text does not grant that freedom. The data release terms
prevent some purposes, even regarding entirely unmodified software as
distributed by your customer.

The CAL and the GPL preserve freedom in exactly the same way. You are not
being precise enough in your reading. The CAL does not prevent anyone from
running the program as they wish. There are no use restrictions in the CAL,
except those that, in the words of the GPL:

"To protect your rights, we need to prevent others from denying you these
rights or asking you to surrender the rights. Therefore, you have certain
responsibilities if you distribute copies of the software, or if you modify
it: responsibilities to respect the freedom of others."

This statement applies perfectly to the CAL. If I were to update the GPL
preamble for the CAL, I would only say:

"The CAL is designed to make sure that you have the freedom to use and
distribute copies of free software (and charge others for services you
provide or source code if you wish), that you receive your data and the
source code from those who provide the software to you, or can get those
things if you want them, that you can change the software or use pieces of
it in new free programs, that you can run the software to process your data
in the context of your choice, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these
rights or asking you to surrender the rights. Therefore, you have certain
responsibilities if you provide the software to others, or if you modify
it: responsibilities to respect the freedom and the autonomy of others."

The CAL doesn't restrict freedom zero. It just curtails the economic
incentive for others to act in ways that restrict other's freedoms by also
requiring them to also turn over those things that grant them exclusivity
and thus, power.


The problem I am having here is a more global problem with the license....
>

The CAL is an unabashedly legal instrument, and fir anyone who really wants
to understand it, legal counsel is required. But it really is no more
complex than the GPL.

For the ordinary developer, though, I can summarize its effects in one
sentence:

If you make CAL-licensed software available in any way to a person, then
you must also provide that person 1) a copy of the license, 2) access to
the software source code, and 3) a copy of any of the data used with
software that the person has given to you, should that data still be
available.


Thanks,

Van

__________________________
Van Lindberg
van.lindberg at gmail.com
m: 214.364.7985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190509/5de2ec8f/attachment-0001.html>