<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 19, 2019 at 5:35 PM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</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"><span class="gmail-m_-5761631934117998759gmail-im"><div class="gmail_attr">[Initially replied just to Henrik; resending to whole list. Thanks, Henrik, for catching that!]<br></div></span>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><br></div></div></div></div></blockquote><div><br></div><div>Sure. And it is only this most recent reply that has helped me understand what your intended scope was in the first place.<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><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_-5761631934117998759gmail-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-m_-5761631934117998759gmail-im"><div></div></span></div></div></div></blockquote><div><br></div><div>It's clearer. Thanks.</div><div><br></div><div>It's IMO regrettable that the goal of the CAL isn't to protect the entire scope of GDPR personal data (in addition to copyrighted ebook data), because that would have been really cool, but since I am not your client in this project, I will have to settle with the victory that the above is at least clearer now.</div><div><br></div><div>Btw, it will probably continue to be a source of confusion that people commonly say - and think of "user data" - when they mean GDPR personal data. No matter how clear you make the license itself, calling out this difference seems like a good FAQ entry. (Even I started out googling with "user data", and google was smart enough to point me in the right direction anyway.)<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"><span class="gmail-m_-5761631934117998759gmail-im"></span><br><span class="gmail-m_-5761631934117998759gmail-im"></span><div class="gmail_quote"><span class="gmail-m_-5761631934117998759gmail-im"><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-m_-5761631934117998759gmail-im"><div></div></span></div></div></div></blockquote><div><br></div><div>This is clearer now. I think the remaining weakness is what has been pointed out by Bruce, that DRM measures, especially restricting installation of software itself, is often not a property of the software, rather controlled by OS or other outside mechanism.</div><div><br></div><div>To my layman understanding it seems this would be improved if you flipped the order and causality to: "You may not use crypographic [things] to control the Software..." Or possibly the license needs both the current sentence and also this.<br></div><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 dir="ltr"><div class="gmail_quote"><span class="gmail-m_-5761631934117998759gmail-im"><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"><div dir="ltr"><div class="gmail_quote"><div> <br></div></div></div></div></blockquote></div><br><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-m_-5761631934117998759gmail-im"><div><br></div></span></div></div></div></blockquote><div><br></div><div>Well, it's of course true that people can choose to use this license or not. The relevance of discussing this now is that if you intended to submit this license later for OSI approval, issues like "nobody can predict what this license will mean in practice" and "developers and users are likely to get sued" tend to become obstacles. And it's an entirely avoidable obstacle since the issue is merely with language rather than the goals of the license.<br></div><div><br></div><div>If we again compare to the GPL, merely to draw from existing history and practice, it always explicitly didn't restrict "unlimited
permission to run the unmodified Program". In my understanding this is motivated by making it absolutely certain that a user can never get sued for anything. This approach of course also self-imposes some limits to the GPLs powers, and I'm not saying other licenses should do the same, but the principle of protecting users and non-lawyered developers should be given similar priority as the FSF has done.<br></div><div><br></div><div></div><div>6m seems to be written broadly, so that it <b>does</b> include all possible interpretations of "public performance". Even if you tried to limit the scope of public performance in CAL, I don't see that you can simply redefine public performance to mean something else than it already means for music and other types of work, rather you would have to explicitly exempt some types of public performance by saying that they are not limited but permitted. And since the scope of public performance is a bit unknown, and music industry (among others) is actively working to broaden it, the CAL would probably need to explicitly say what type of public performance is governed by the license, and then say that "any other" public performance is allowed without any limitations or obligations.</div><div><br></div><div>Famously, <a href="https://en.wikipedia.org/wiki/Freedom_of_panorama">the Eiffel tower is still considered a public performance in France</a>. This issue has been bitterly fought for 5 years (and beyond) and aligning yourself on the copyright maximalist side of that discussion seems like an odd approach for a new open source license.<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"><span class="gmail-m_-5761631934117998759gmail-im"><div></div></span><span class="gmail-m_-5761631934117998759gmail-im"><div></div></span><span class="gmail-m_-5761631934117998759gmail-im"><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-m_-5761631934117998759gmail-im"><div><br></div></span></div></div></div></blockquote><div><br></div><div>Thanks! Your blog did quickly become very US centric, and since my primary interest in this was my being a EU "data subject", I had stopped reading at that point. But that was a concise and well referenced explanation well worth reading.</div><div><br></div><div>In addition to concerns I already raised above and in previous email, reading this reminds me of an <a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020261.html">email Bruce sent in January</a>. I realize now it may have been motivated by the CAL all along? Key point: "In addition, I think there's a principle here. Extension of copyright is bad for Open Source, even if it helps us enforce our licenses more effectively."</div><div><br></div><div>I'm myself always open to discuss ways of making copyleft stronger, but Bruce has a valid point. In the case of CAL my argument is that you can achieve the same goals by using legal tools already existing in the software industry, so pioneering the use of public performance has only downsides (for users of CAL, but also all of us) but little benefits.<br></div><div><br></div><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 dir="ltr"><div class="gmail_quote"><span class="gmail-m_-5761631934117998759gmail-im"><div></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></div></div></div></blockquote></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></div></div></div></div></blockquote><div><br></div><div>I use SaaS broadly as you have marketed this as "network copyleft". We can use "Remote Network Interaction" (from AGPL) or any other term if you prefer.</div><div><br></div><div>That said, the fact that Holochain is more peer-to-peer than a typical SaaS application is indeed architecturally interesting. For now I will resist the temptation to analyze CAL from that perspective, but hopefully that will also be discussed at some point!<br></div><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 dir="ltr"><div class="gmail_quote"><span class="gmail-m_-5761631934117998759gmail-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-m_-5761631934117998759gmail-im"><div></div></span></div></div></div></blockquote><div><br></div><div>Passers by have been recipients of a public performance. These examples are straight out of existing case law and money exchanges hands every month based on this being legally established. Licensees have fought these cases in court and lost and now they're paying.<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"><span class="gmail-m_-5761631934117998759gmail-im"><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>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></span><span class="gmail-m_-5761631934117998759gmail-im"><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></div></div></blockquote><div><br></div><div>My thinking here is that once software is published without exception, it is never again possible for later contributors or forks to choose that exception (for that software). So the text is unnecessary when not applied. But the existence of that text in the license file can lead people to think it's an option for them to choose. Experience with copyleft licenses educates us that people are strongly biased to believe they can do whatever they desire to do, and the copyleft requirements really only applies to someone else.</div><div><br></div><div>henrik<br></div><br clear="all"></div><br>-- <br><div dir="ltr" class="gmail_signature"><a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354 skype: henrik.ingo irc: hingo<br><a href="http://www.openlife.cc" target="_blank">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div></div></div>