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

[VanL]

Response below.

On Wed, May 1, 2019 at 5:24 PM Pamela Chestek <pamela at chesteklegal.com>
wrote:

>
> On 4/27/2019 10:30 AM, Pamela Chestek wrote:
>
>
> On 4/23/19 10:15 PM, VanL wrote:
>
> There is a particular way of locking down a program that is available in
> hashchain applications; that particular method is addressed in a single
> clause. That is exactly like anti-Tivoization (which is also addressed in a
> single clause inspired by the GPLv3, and the anti-circumvention, which is
> addressed in a third clause - again parallel to the GPLv3).
>
>
> On 4/23/19 11:55 PM, Bruce Perens via License-review wrote:
>
> Here you add data to the terms, which none of our other licenses require,
> and you require it of *users *of the program who are not developers.
>
>
> Bruce does identify what strikes me as a distinction between your section
> 2.3 and the anti-Tivozation clause. The anti-Tivozation clause says that
> where object code is conveyed on certain devices where the device is
> transferred in a way equivalent to ownership, then you must give me what is
> needed to install and execute a modified version of the code on the device.
> That all relates to my right to modify code in a meaningful way. Your
> provision simply says that someone can get a copy of their data, as Bruce
> points out a burden that falls on someone who is only running the software.
> So I don't consider them analogous.
>
> Van,
>
> Do you have a comment on this? I share Bruce's concern that Section 2.3 is
> outside the scope of open source licenses. I'm not buying your argument
> that it's the same as anti-Tivoization, for the reason I described above.
>
>
There are two separate issues. The clause in 2.3(c) referring to
cryptographic seeds, etc. is a special anti-Tivoization clause for the
context of a cryptographically authenticated distributed system. In those
systems, the keys (and the ability to generate or revoke the key, which is
effectively identical) are "data" but are also intrinsic to the functioning
of the system. It is possible to give someone software and prohibit them
from running it or having control over it. This is software Tivoization,
and 2.3(c) addresses this attack.

The larger concern seems to be with 2.3(b), which is the User Data clause.
The analysis here is that Freedom 0 - the right to run the program as you
wish, for any purpose - necessarily implies a right of data portability
with regard to your own data. I am unable to run the program as I wish if,
after having run it with some SaaS provider, all of my previous data
entered into the program and used for my personal processing is now
rendered inaccessible to me. As with the GPL licenses, the only rights
denied are the rights that would reduce the freedom of a third party
recipient, and so the specific right to deny data portability is denied if
you are offering the program's functionality to a Recipient.

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