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

[Bruce Perens]

On Tue, Apr 23, 2019 at 7:16 PM VanL <van.lindberg at gmail.com> wrote:

> Hello Bruce,
>
> On Tue, Apr 23, 2019 at 6:27 PM Bruce Perens <bruce at perens.com> wrote:
> No disrespect intended, and I am sorry for any that was communicated.
>

Well said. Thank you.

>
>
>
>> On Tue, Apr 23, 2019 at 3:18 PM VanL <van.lindberg at gmail.com> 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.
>

Can you tell us more about this? I am not at all clear what your customer
is worried about, and thus I am unclear about the motivation behind terms.


> "Compliance with section 2" consists of:
>    ...
>    - Making a user's data available (2.3).
>


> ...
>


> People invest time and energy putting information into online platforms,
> only to find that their data gets held "hostage" against them.
>

I agree that this is a social problem suffered by computer users. OSI has
previously rejected licenses that attempted to use their terms to remedy
social issues beyond sharing software freely. It's out of scope of OSI's
mission, *and *OSI's stated mission for  Open Source software.

The previously proposed licenses with similar terms have in general been
rejected because of the increase in legal load for the *passive user.* The
person who doesn't create derivative works or redistribute, but just runs
the program. They shouldn't have to read the license just to run the
program.

The CAL breaks that. Passive users of software under the CAL would face
real legal questions regarding data release in conjunction with the terms,
which they could not handle adequately without counsel. This, IMO, is an
unacceptable burden on the user.

It's really difficult for anyone not an attorney to parse the terms of this
license and arrive at what their obligation is, figure out where ownership
interests and possessive interests are involved, etc. There is nothing
approaching plain language that states the obligation. And I suspect there
is some uncertainty even regarding attorney's opinions.

Ummm... to the best of my knowledge, unreadable and irretrievable data has
> *nothing* to do with blockchains.
>

Blockchain requires use of one-way functions, as does any algorithm that
supports a verifiable public signature. The input to such functions is
necessarily irretrievable and requires some sort of secret, usually in the
form of a private key. Private keys (usually in the "wallet") must
*remain *private,
or the basis of trust in the system is destroyed. So, be sure your license
doesn't require their disclosure. It seems to me that under the present
terms it might do so.


> The license compels an action by the licensee - to make the source code
> and data available. This is exactly the same type of action required under
> every copyleft license.
>

It's not the same action. Our other approved licenses require conveyance of
the source code only. And in a meaningful way only from *developers *who
create derivative works. 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. Vastly increasing the legal burden of users.

The terms do include use restrictions: by your own statement they restrict
the user from denying their customers access to their data without a
continued payment. You may consider this socially beneficial, but it's
pretty clearly a use restriction. I don't see how this is different from
the previously rejected licenses with other social goals implemented as use
restrictions.

Just because I have ownership of the data doesn't mean that you have an
> existing legal responsibility to give it to me. This is exactly the problem
> addressed by the CAL.
>

Yes. IMO, it's over-reaching.

 The insight is that, increasingly, the data and the code are needed
>> together to realize the program's function.
>>
>
This is proposing that the data previously used for an arbitrary run of the
program is essential to use the program at all. I can see this for data
which defines fundamental characteristics of the world around us, for
example a book of physical constants of the universe. But you are extending
this to transactional data of a specific market, and denying that the
program could be used in an alternate market. It's not logical.


>> Existing open source licenses, such as the GPLv3 family, recognize this
>> and requires the provision of cryptographic keys that would prevent the
>> execution of the code.
>>
>
Yes, but a lack of specific market data doesn't actually prevent the
execution of the code, as a key in a "trusted" boot system would.

The CAL recognizes that user freedom also includes the provision of the
>> user's data so that the program functions completely and fully in a context
>> of the user's choice.
>>
>
Thus, someone who wishes to have the freedom to sequester the data of their
customer users *must be deprived of that freedom. *We restrict people from
keeping derivative works private in some cases, because we're the Open
Source Initiative. But now, we are going to restrict people from keeping
data private too, because we're now the Open Source and People's Data
Initiative?
It's over-reach. Sorry.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190423/dba7f9b1/attachment.html>