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

[VanL]

Hello Bruce,

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

>
> Please do me the courtesy of assuming that my arguments are not always
> misapprehensions, but may be valid objections to your license.
>

No disrespect intended, and I am sorry for any that was communicated.



> On Tue, Apr 23, 2019 at 3:18 PM VanL <van.lindberg at gmail.com> wrote:
>
>> I don't really understand what you are going for here: Every license was
>> designed to fulfill a specific purpose. The GPL was designed to preserve
>> software freedom; the ISC license was written to be as short as possible;
>> the MPL was written to allow a the joint compilation of separate works into
>> a single binary.
>>
>
> Yes. But none of GPL, ISC, and MPL are specific to an application. The
> only one that really mentions specific technology at all is GPL3...
>

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



>
> In this case, my client identified that it was in their business interest
>> to have a strong network copyleft license that was maximally respecting of
>> user freedom.
>>
>
> I am not yet convinced that a compulsion to reveal the data processed by
> the program is maximally respecting of user freedom. I do note that other
> well-known licenses promoted as freedom-respecting have very clearly stated
> that you can run the software for any purpose....
>

Ability to run the program is clearly granted. Quoting the CAL:
1.1. Conditioned on compliance with section 2, and subject to the
reservations of section 1.2,* you have world-wide, royalty-free,
non-exclusive permission to:*
    a) *Take any action with the Work or a Modified Work that would
infringe the copyright or database protection laws of an Applicable
Jurisdiction* applying to the Work, including Publicly Performing any
interface derived from the Work; and
    b) *Take any action with the Work or a Modified Work that would
infringe any patent claims Licensable by Licensor,* to the extent that
those claims are embodied in the Work as distributed by Licensor.

"Compliance with section 2" consists of:
   - Attribution (2.1)
   - Making source code available (2.2)
   - Making a user's data available (2.3).

That's the meat of it.


It also appears that the license is clothed in the language and law of
> protecting people from the effects of others holding their personal data.
> This, however, seems a false impression, because the terms require a
> potentially very broad compulsion to disclosure that does not respect
> individual privacy - anyone with a possessory interest or a chain of
> derivation regarding their data potentially has a right to *your *data.
>

You assert this, but you can't end up with rights data that you did not
already have. No rights or obligations are created in any other work.

And then we compel disclosure of data even in contexts that do not protect
> people. Rather than personal data, the application of the program is
> blockchain data used to implement a market. This sort of data is still
> encumbered with disclosure compulsion regardless of whether it is actually
> personal or not.
>



> The User Data is not encumbered. *This is a fundamental point*. There are
>> no additional restrictions placed on any User Data that were not there in
>> the first place. Users own or have the right to possess their own User Data.
>>
>
> But this seems self-contradictory. If users have the right to compel
> disclosure of their user data separately from the license, why does the
> license need to have language to compel disclosure of that data at all?
>

On the contrary, this happens all the time. People invest time and energy
putting information into online platforms, only to find that their data
gets held "hostage" against them. Want to continue to have access to your
data? Keep paying.

The CAL recognizes that modern computing is about both the program *and*
the data. I may *own* my data. I may be able to get a copy of the source
code. But unless I can run the program (no Tivoization, no "effectively
controlling access to a copyrighted work," no control of the cryptographic
keys used to process the data) I don't have freedom. And unless I can use
the software to process my own data, I also don't have effective freedom.



>
>
>> The CAL just denies a licensee the right to lock up a User's Data and
>> make it irretrievable or unreadable.
>>
>
> So, you're saying that it is in violation of the license for me to, for
> example, encode passwords with a one-way hash. And that doesn't seem a use
> restriction? For example, by making it impossible to properly implement
> access control software under the license.
>

This is a good point. I could argue that there are ways of negotiating
access control that don't require the transmission of passwords or similar
information (e.g., public keys). But to avoid this issue, note the changed
2.3(b):

b) Throughout any period in which You exercise any of the permissions
granted to You under this License, You must also provide to any third party
with which you have an enforceable legal agreement, a no-charge copy,
provided in a commonly used electronic form, of the User Data in your
possession in which that third party has a Lawful Interest,* to the extent
that such User Data is available to You for use in conjunction with the
Work*;

If I store passwords in plaintext (boo!) then I need to give you back your
password. If I only have a hash, I may need to give you back that hash if
doing so is necessary for me to use the Work.


And what *other *purpose than access validation does unreadable or
> irretrievable data have, that we must prevent a software user from ever
> doing that? I guess that's implementing a blockchain. Doesn't that bring us
> back to use restrictions?
>

Ummm... to the best of my knowledge, unreadable and irretrievable data has
*nothing* to do with blockchains. In fact, the entire point of a blockchain
is that the data is retrievable and publicly verifiable (which implies
readable). You are imagining motives and technology which have no basis in
fact.



>
> Let's say the CAL was applied to something like a photo storage site where
>> you store your photos. *The CAL does not apply any licensing
>> requirements on your photos*. *It does not encumber them at all*. It
>> only states that the photo storage site using the software cannot encrypt *your
>> *photos and prevent *you* from retrieving them.
>>
>
> That's not a use restriction?
>

No, but I recognize that I was unclear. You can encrypt the photos. You can
use the software in whatever what you would like. You just cannot refuse to
decrypt them for me if you have the ability to do so. See 2.3(b) above.



>
> If allowing a person to retrieve their own data is an encumbrance, then
>> the AGPL provides a similar encumbrance, in that it ensures that a site
>> operator also offer users a copy of the source code to which they are
>> entitled.
>>
>
> Not so. The AGPL only applies to the program and its language is very
> careful not to reach beyond the program. It requires that a person who
> modifies the program must offer to distribute a copy of the program,
> potentially a modified version, if they perform activities similar to
> public performance. In contrast, the CAL *reaches **beyond the program*
> to apply terms to data which is simply processed by the program. This is *not
> *an encumberance like the AGPL!
>

You have asserted this multiple times. Please quote, specifically, any
terms are applied to any data beyond the program. It is not there. No
person gains or loses any rights in any data that they did not previously
possess. No license terms are applied to anything other than the Work
(including derivative works). 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.

We don't need any such theory. Ownership of intellectual property is
>> mediated by the laws of a jurisdiction. For example,a photographer has an
>> ownership interest in photos that she takes because of the operation of
>> copyright law. I have an "mp3 locker" where I store copies of songs that I
>> legally possess - I have non-ownership possessory interest.
>>
>
> So as the operator of a music or photo site, I either have an existing
> legal responsibility to give you your data upon request, in which case the
> license does not need to compel me to do that, or I don't, and the license
> needs to compel me to do that. Which one are you stating is true?
>

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.

This invents a hypothetical contrary to the terms of the license under
>> discussion. The license doesn't grant the "very broad right" you are afraid
>> of, and so the accompanying parade of horribles doesn't apply. If I don't
>> have an ownership or possessory interest - both again, normal legal terms -
>> then I can't ask for the data.
>>
>
> I am still hearing that you have an interest in law, and that the license
> must still go beyond what your interest in law *is,* to compel the site
> operator to distribute files to you that are *not *the program under the
> license, and that she would not otherwise have to distribute to you.
>

I don't fully understand this comment. Trying to respond, though: The CAL
requires the operator to make available to a user the files corresponding
to the program as it is used by that user. The insight is that,
increasingly, the data and the code are needed together to realize the
program's function. 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. 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.

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