<div dir="ltr"><div dir="ltr"><div>Hi Henrik,</div><div><br></div><div>Thanks for the commentary!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2019 at 2:47 PM Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi">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"><br><div><b>About the main goal of this proposal, User Data:</b><br></div><div><br></div><div>It immediately stands out that this license also grants rights to third parties. This is also novel, isn't it? Potential OSD issues come to mind if this is seen as analogous to "you must also kill your cat" or "you must also pay a fee to the MPEG-LA". </div></div></blockquote><div><br></div><div>There are two slightly separate issues here that should be distinguished.</div><div><br></div><div>- Granting rights to third parties</div><div>The CAL *does* grant rights to third parties, but only as intended third party beneficiaries (similar to NASA-1.3) who have the right to request copies of the Source Code and their own User Data. Other than this specific right to enforce, third parties are not the subject of any grants.<br></div><div><br></div><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><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>But after sleeping on it, I do agree that there will exist third parties who have such GDPR rights to their User Data, without being users nor Licensees of the licensed work. <br></div></div></blockquote><div><br></div><div>It seems likely, though, that anyone for whom a licensee is holding User Data will be a Recipient, and thus someone who should receive Access to Source Code as well as their own User Data.</div><div><br></div><div>The GDPR angle is *similar*, but don't overread it. The GDPR is about privacy first, and data only second. The CAL is about User Autonomy, which is the four freedoms of free software plus user data.<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>The Lawful Interest concept seems like an odd entry point. As an EU citizen the GDPR grants me rights wrt my User Data, but a US citizen doesn't have such rights (at least not for data that you have stored in a US based company). Does this license grant me more rights than a US citizen? Or was the intent to grant GDPR-like rights globally? I don't read the latter.<br></div></div></blockquote><div><br></div><div>See the comment above about the GDPR. The intent is not to enforce compliance with the GDPR or extend it globally. Rather, it is about preventing the use of the work to deny freedoms to Recipients of the Work. It just so happens that the GPDR also has some elements that talk about that, so the CAL was drafted to talk about it consistently with those specific provisions. But the CAL does nothing relative to the GPDR as a whole.</div><div><br></div><div>As for the specific "lawful interest," the motivating use case for that was something like ebooks. I may have a right to possess a particular copy of an ebook, even if I don't "own" the ebook (as per current US law). We don't want the phrase "the _____ is licensed, not sold" to be effective in denying someone access to something that they have a legal right to possess.<br></div><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>The definition of "User Data" could easily be misunderstood too narrowly as data I have actively input into the system, such as via a form. I'm not so familiar with the GDPR that I could propose better wording, sorry. But for example, data Google collected about me, including from news sites, etc, is surely covered by the GDPR. Also, I expect that GDPR also includes data about me that the system has developed internally? (E.g. even if I had never input such a fact into Facebook, and Facebook never output it, some ML algorithm has probably inferred that I'm married to another FB user called Sanna Ingo. This is User Data in European law.)<br></div></div></blockquote><div><br></div><div>Again, don't overread the comparison. All that you are talking about GDPR-wise has to do with privacy, and not about User Data as contemplated in the CAL. (If the law in the EU grants users ownership interests in their tracking data, then it could be covered, but it would be because the law made them an owner, not because it was *about* them.)<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>Btw, it's probably an oversight that the Licensee is not themselves a beneficiary of the User Data rights. I would expect to see similar anti-DRM measures as in GPLv3 to ensure that I can access both software and data on a device I bought that has software with this license.<br></div></div></blockquote><div><br></div><div>Those are present - see 2.3(d) and (e), which are directly analogous to provisions in the GPLv3.<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><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. (Restricting based on type of business or use would not be OSD compliant).<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>If you hadn't introduced this as a network copyleft license, it would not at all be obvious from the language. More specifically, "interface" can mean a lot of things: 1) a GUI, 2) a REST APi, 3) a traditional API as in Oracle vs Google.</div></div></blockquote><div><br></div><div>Interface in the CAL means any or all of those, to the extent that they are protectable via IP law.<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>1) seems like something for which Public Performance can apply. I can see the GUI on my screen, much like a movie.</div><div>3) it's not at all obvious that you want or don't want this to be covered. Note especially that such an "interface" may be copyrighted even if it contains zero code from the licensed work. You'd probably have to spend a few more words to explain what is affected by this license and how.<br></div><div><br></div><div>Second, about Public Performance:</div><div><br></div><div>I don't think this approach will work. You want to create a license with conditions for SaaS usage. But Public Performance is much broader than that. [snip examples]<br></div></div></blockquote><div><br></div><div>Public performance can be broader than SaaS, it is true.  (I think you are slightly too focused on the GUI aspect, but we can go with it because that could be an aspect of public performance.) The difference between the CAL and your collecting societies is that the collecting societies have licenses that say "pay us or it is copyright infringement." You have to engage with them in order to avoid infringement.</div><div><br></div><div>In contrast, the CAL, like other reciprocal licenses, is actually kind of a "pass forward" license: as long as you make the Source Code and applicable User Data available to Recipients, no interaction with the licensor is needed.</div><div><br></div><div>So, looking at your GUI examples, a link in the GUI that gave people Access to the Source Code would prevent infringement in all the situations you identify. In this way, it isn't too different from the AGPL.</div><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><b>Smaller comments:</b></div><div><br></div><div>I basically fail to understand what you mean by "Compatible Open Source License". If it's "any OSI approved Open Source license", then why not say so? If you mean BSD and Apache style licenses, then compatibility is a property of those, and mentioning this seems redundant? In any case, saying "Open Source" without "OSI approved" feels undefined to me. A lot of people claim all kinds of licenses as open source.</div></div></blockquote><div><br></div><div>Look at the definitions: "Open Source License" means a license approved by both the OSI and FSF.<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>You'd better spell out General Data Protection Regulation and also add "of the European Union".</div></div></blockquote><div><br></div><div>Good idea, I'll add that.<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><br></div><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><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>Didn't read your entire blog post, but since this license clearly arises out of EU context, at least some EU countries (maybe all?) don't register copyrights as you can in the US.</div></div></blockquote><div><br></div><div>That may be true.<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><br></div><div>Good night :-)</div></div></blockquote><div><br></div><div>Thanks!</div><div><br></div><div>Van<br></div><div> </div></div></div></div>