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

[VanL]

Sorry for the delay responding to various concerns.

On Tue, Apr 23, 2019 at 10:55 PM Bruce Perens <bruce at perens.com> wrote:

>
> 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 CAL is not of the same sort as the 996 license, or the JSON "Do no
evil" license. While it does address a social issue, it does so in the
exact same way the GPL addresses the social issue of software freedom.


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

This is an interesting point, but I don't think it is applicable in the
general case. If the CAL were applied to a music player like VLC, or a
graphics program like Gimp, the legal load would be precisely the same as
for any other user. The only additional legal load is for an entity that
wants to use CAL-licensed software to provide services over a network to
others. This is exactly the same context in which the AGPL applies an
additional legal load - and I would argue that if you are providing
services to others, you have already taken upon you substantial legal
liability.



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

I understand this point now. However, the application to the CAL is only
speculative ("under the present terms it might do so.") I would argue that
the CAL is very careful in its definitions, such that the only required
disclosures are of source code and data in which the user has a preexisting
legal right. I cannot see a situation in which a first person, "Alice,"
could use the CAL to request disclosure of "Bob's" private key, where Alice
does not have a preexisting right of control of Bob's key regardless of the
CAL.  The CAL does not create any new rights in any unrelated Works.



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

The difference gets back to user freedom and the ability to "exit."
Operators of CAL-licensed software can refuse to continue hosting a user's
data without further payment. But licenses that  defend user freedom
prevent an operator from denying the user the opportunity to exit a
situation so as to run the program in another context. That is the same
freedom protected by the CAL.


This is proposing that the data previously used for an arbitrary run of the
> program....
>

This is incorrect. It is not an "arbitrary" run of the program; it is only
an invocation of the program with the user's data, so that the user can run
the program in another context with their same data and get the same
result.



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

I am unsure where you are identifying "specific market data" in the CAL.
But more fundamentally, in many systems, particularly those that deal with
cryptographic primitives as a part of their operation, you would not get
the same result (if it did indeed "boot").



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

This overstatement continues to conflate "the People's Data" with a user's
own data. Further, it strikes me as strange that the core argument is that
you wish to preserve for operators "the freedom to sequester the data of
their customer users." That freedom is definitely granted under some more
permissive licenses, but preserving the rights of users is a core aspect of
Free Software, which is the tradition addressed by the CAL.

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