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