<div dir="ltr"><div dir="ltr">
<div class="gmail_quote"><span class="gmail-im"><div class="gmail_attr">[Initially replied just to Henrik; resending to whole list. Thanks, Henrik, for catching that!]<br></div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Mon, Mar 18, 2019 at 12:47 PM Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>- Protection of User Data</div><div>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.</div></div></div></div></blockquote><div><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><div><br></div><div>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:</div><div><br></div><div>
<i><span style="font-size:12pt;font-family:Calibri;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap" id="gmail-m_-2700915308366314524gmail-docs-internal-guid-665f55a7-7fff-58b7-a28c-1ee7df5f31ce">To the extent allowable under the Applicable Jurisdiction,<b> provision of User Data in compliance with the conditions in section 2.3(a) and 2.3(b) </b> shall be interpreted consistently <b>with the formatting and transmission requirements</b> of General Data Protection Regulation (EU) 2016/679 ("GDPR") Arts. 15(3) and 20(1). The <b>number of copies of User Data provided in compliance with the conditions in section 2.3(b)</b> shall be at least the same number needed to comply with GDPR Art. 15(3).</span></i>

</div><div><br></div><div>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.<br></div><span class="gmail-im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div></span><div>This is incorrect, because you are not a (cap-R) Recipient. Per the current clause 2.3:</div><div><br></div><div>
<i><span style="font-size:12pt;font-family:Calibri;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap" id="gmail-m_-2700915308366314524gmail-docs-internal-guid-fb96625c-7fff-e1de-f65a-b797ee06a5d2">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 <b>Recipient’s</b> quiet enjoyment of any Lawful Interest in their own User Data. </span></i>

</div><div><br></div></div><div class="gmail_quote">Snipping various GDPR things...<br></div><div class="gmail_quote"><span class="gmail-im"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Those
 merely prevent licensee from preventing me from circumventing DRM. 
GPLv3 says I'm entitled to have the keys. Big difference.</div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><span class="gmail-im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><b>About Public Performance</b><br></div><div><br></div><div>First:<br></div><div><br></div><div>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 
...".<br></div></div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Even in the legal field,<div><br></div><div>1. What precedent is there to talk about public performance <b>for software??? </b>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!<br></div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><span class="gmail-im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>2. I didn't know also patents can be publicly performed. How does that work?<br></div></div></div></div></blockquote><div><br></div></span><div>Patented inventions may be *used*, of which public performance is necessarily a subset.<br></div><span class="gmail-im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>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. (<a href="https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#copyleftandthepublicperformanceofsoftware" target="_blank">https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/#copyleftandthepublicperformanceofsoftware</a>)<br></div><span class="gmail-im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> (Restricting based on type of business or use would not be OSD compliant).<br></div><div><br></div></div></div></div></blockquote><div><br></div><div>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.<br></div></div></div></div></div></blockquote><div><br></div></span><div>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:<br><br><b>___</b></div><div><b>Aside: Who is Holo and what is Holochain?</b><br><br>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.<br><br><b>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.</b><br>___<br></div><div><br></div><div>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. 

</div><div><br></div><div>Snipping stuff about SaaS/MongoDB/etc...<br></div><span class="gmail-im"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>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.<br></div><span class="gmail-im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div></span><div>This is because the CAL is as compatible as possible. If the other license allows it, the CAL is compatible.<br></div><span class="gmail-im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>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.<br></div></div></blockquote><div><br></div><div>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).<br></div><div><br></div></div></div></div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>Thanks,<br></div><div>Van<div class="gmail-adL"><br></div></div></div>

</div><br></div>