[License-discuss] For Public Comment: The Cryptographic Autonomy License

[VanL]

 [Initially replied just to Henrik; resending to whole list. Thanks,
Henrik, for catching that!]

On Mon, Mar 18, 2019 at 12:47 PM Henrik Ingo <henrik.ingo at avoinelama.fi>
wrote:

>
> - Protection of User Data
>> The protection of User Data portion is a limitation on the grant to the
>> licensee, not a grant of rights to a third party. It is similar in
>> structure although broader in intent than the GPLv3's anti-Tivoization
>> clause: You may not use the Work to deny these specific freedoms to your
>> Users.
>>
>
> Ok, so is this actually an answer to a question I had later: You may not
> use this software to deny users and third parties freedoms that they
> already have as a matter of law? This is the only way I can understand this
> as a limitation. And like I said, this limited scope feels a bit redundant
> since I expect the sanctions in the GDPR to be effective in themselves.
>

Two points. First, and as I hope will become clearer after this email, the
CAL and GDPR have different scopes, so it is appropriate to have a
different instrument. Second, *you* may have some rights under GDPR, but
*I* don't.

That said, I think I better understand your point. You suggest that, due to
my phrasing and the consistent interpretation clause, I am suggesting that
User Data == Personal Data, leading to some of the ambiguities you identify
below. I have updated the language as follows:

*To the extent allowable under the Applicable Jurisdiction, provision of
User Data in compliance with the conditions in section 2.3(a) and 2.3(b)
 shall be interpreted consistently with the formatting and transmission
requirements of General Data Protection Regulation (EU) 2016/679 ("GDPR")
Arts. 15(3) and 20(1). The number of copies of User Data provided in
compliance with the conditions in section 2.3(b) shall be at least the same
number needed to comply with GDPR Art. 15(3).*

This provision makes clear that the consistency provision makes reference
to the number and format of User Data to be provided, and does not invite a
comparison between User Data and Personal Data.


> This is not at all the case. Say you received this software, and use it to
> keep a log of correspondence you've had with me. YOUR log is now MY
> personal data/user data, and under GDPR I have a right to receive a copy of
> it. Yet, I have never been anywhere close to the software, so I am not a
> recipient or user of it.
>

This is incorrect, because you are not a (cap-R) Recipient. Per the current
clause 2.3:

*You must give the same permissions received under this License to any
Recipient, and You must refrain from using the permissions given under this
License to interfere with Recipient’s quiet enjoyment of any Lawful
Interest in their own User Data. *

Snipping various GDPR things...


> Those merely prevent licensee from preventing me from circumventing DRM.
> GPLv3 says I'm entitled to have the keys. Big difference.
>

See 2.3(a) and 2.3(c). You have to provide the keys. The Recipient of the
ebook software has a Lawful Interest in the ebook as User Data. So you
can't lock it up.


>
> I could see how 2.3c was intended as an anti-Tivoization clause, and would
> be, except that currently CAL doesn't grant any permissions about ebook
> contents and also not about installing / upgrading the software itself. And
> again, even with those fixes, 2.3c is probably another example of being too
> terse and leaves us guessing what licensor intended.
>
>
>
>>
>>
>>> *About Public Performance*
>>>
>>> First:
>>>
>>> First reaction is like "Convey" in GPLv3: Why can't you use existing
>>> industry terminology instead of inventing new stuff that has no established
>>> precedent? I would much prefer simple language like "if SaaS, you must ...".
>>>
>>
>> I see your point, but I'm coming at it from a different angle: "public
>> performance" *is* existing industry terminology - just in the legal
>> industry. This is very closely tied to the specific copyright and patent
>> grants, not to types of businesses or types of uses.
>>
>
> Even in the legal field,
>
> 1. What precedent is there to talk about public performance *for
> software??? *I'm not denying that the law wouldn't cover this, just that
> we have no context to predict the outcomes of walking down this path, and
> that makes such a license the copyright version of Russian roulette!
>

You are correct. Public performance in software is not well defined. You
are also correct that for some people that may increase the perceived risk
of using the license (either as a licensor or licensee). I believe that the
definitions provided - and incorporated directly into the license as a
defined term (CAL 6(m)), significantly ameliorate that risk.



> 2. I didn't know also patents can be publicly performed. How does that
> work?
>

Patented inventions may be *used*, of which public performance is
necessarily a subset.


>
> Links are welcome, including to your blog, which I didn't read, because
> the intro didn't give me confidence it would answer these questions.
>

Well, I did say that the blog post was long and possibly boring. So I don't
blame you for not reading it. However, I have an entire section addressing
the question of public performance of software. (
https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#copyleftandthepublicperformanceofsoftware
)



> (Restricting based on type of business or use would not be OSD compliant).
>>
>>
> Right. So clearly this is the real motivation behind all this, and thank
> you for opening this door so that we can talk about the real issue. I
> disagree with the notion that delivering software as a service to a user is
> a type of business. Analogously offering software for download or
> distributing it on a CD-ROM are not types of business, and in any case open
> source licenses clearly can regulate those activities in order to ensure
> user freedoms. In the case of SaaS, both GUI and API forms of delivery are
> used by non-profits, governments, car manufacturers and all kinds of
> corporations and individuals, who clearly are not "in the SaaS business".
> And if anything, this should be much more obvious for SaaS than for the
> CD-ROM case.
>

You seem to be under the impression that this license is about SaaS use.
That is not so. While it is intentionally written to be useful for the SaaS
use case, the purpose of this license is to maximize user freedom in a
distributed system. Again, as I wrote in my blogpost:

*___*
*Aside: Who is Holo and what is Holochain?*

Holochain is a hashchain-based application framework for peer-to-peer
applications. Holo (the company) provides software that enables commerce on
top of Holochain, by acting as a bridge between Holochain apps and users
and facilitating business services.

*Holo's goal in developing a new license is to create a solid foundation
that respects user freedom. By applying this to the Holochain framework,
Holochain becomes a safe place for people and organizations to invest their
time, money, and data. Holo's goal of maximizing user autonomy was a
driving force in the development of the Cryptographic Autonomy License.*
___

No "trickery" (as you put it) here: The CAL is designed to give users a
liberty-maximizing framework within which they can enter into their own
varied and private economic arrangements. If Holochain created a system in
which users did not have the expectation of autonomy, they would be
strongly disincentivized from participating.

Snipping stuff about SaaS/MongoDB/etc...

You are missing my point. A link in the GUI, such as a Help > About box, or
> a link in the website footer, does not suffice. It will not be visible on
> the screen in the park, nor can the passers by grab a mouse and navigate to
> it. So they will have been recipients of a public performance, and it's now
> your responsibility to run around the park to hand each of them a paper
> slip with the download url, but also all the necessary attributions.
>

This is incorrect. A link, just as with the AGPL case, provides sufficient
compliance for this use case. Passers-by have no User Data, no legal
relationship, etc.


> Ok, so it is essentially the redundant case, but IMO it's actually
> positive that copyleft licenses explicitly mention that they're intended to
> be compatible with other open source licenses. That said, CAL doesn't
> actually make any licenses explicitly compatible, just says that an
> undefined set of licenses are compatible.
>

This is because the CAL is as compatible as possible. If the other license
allows it, the CAL is compatible.



>
>
>>
>>> 2.4: Rather than an optional exception, I'd much prefer that you develop
>>> 2 or more separate licenses with clearly different names like is the case
>>> with LGPL, GPĹ and AGPL. Now if I see that some software is licensed under
>>> CAL, such as in a github label or search, I won't be able to tell what I
>>> can do with that software.
>>>
>>
>> I see your point, but in practice I think that they will be labeled
>> independently (such as GPL-with-classpath is labeled separately from GPL).
>>
>>
> I now see that the preamble actually specifies 2 different long form
> names, the other one being "with exception". That is a good start. But it
> would still be cleaner if I could omit §2.4 completely, if I don't want to
> offer the exception.
>

I understand your preference, but I think it is more useful to keep as-is
and allow people to use it or not as they wish.

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