<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 17, 2019 at 10:36 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>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" 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"><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></div></div></blockquote><div><br></div><div>And to be clear, as a goal this is laudable, I just wanted to call it out as different.<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>- 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><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>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></div></div></blockquote><div><br></div><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. More on this in the next paragrpah...<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>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></div></blockquote><div><br></div><div>Ok, let me draw a straight line here to underscore how your use of User Data and GDPR is confusing. This is kind of "proof by contradiction":</div><div><br></div><div>1. In the GDPR, what is commonly called "user data", is actually the term "personal data". It is defined <a href="https://gdpr-info.eu/art-4-gdpr/">in Article 4</a> §1, and a more prosaic <a href="https://gdpr-info.eu/issues/personal-data/">description is on the GDPR website</a>.</div><div><br></div><div>2. <a href="https://gdpr-info.eu/art-20-gdpr/">Art 20</a> is the right to data portability and <a href="https://gdpr-info.eu/art-15-gdpr/">Art 15</a> right to access data and how it is used (for purpose of auditability). The scope of both of these obviously is "personal data" as in Art 4.</div><div><br></div><div>3. CAL 7.1.1 explicitly says it should be interpreted as in the GDPR: "To the extent allowable under the Applicable Jurisdiction, section 2.3(a) shall be interpreted consistently with GDPR Art. 20 and section 2.3(b) should be interpreted consistently with GDPRArt. 15(3)."</div><div><br></div><div>4. CAL2.3a and 2.3b are about User Data</div><div><br></div><div>5. The definition of User Data is substantially different from "personal data" in GDPR Art 4.</div><div><br></div><div>=> It's impossible to know what data CAL 2.3a and 2.3b even attempts to cover, given two contradictory clauses in the license itself.<br></div><div><br></div><div>To use your specific example, the contents of an ebook are not GDPR personal data, so would be excluded from protection due to 7.1.1.<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> </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></div></div></div></blockquote><div><br></div><div>To achieve this, I believe you need to address that separately, as the GDPR will not sufficiently help you. The current text clearly ties all of the User Data related rights to the GDPR, including then exclusion of anything not covered by the GDPR.<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"><br><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></div></blockquote><div><br></div><div>But you specifically say it <b>shall</b> be interpreted consistently with the GDPR. How can that be overread?</div><div><br></div><div>The GDPR gives me a lawful interest in my "personal data" precisely because it is about me, not because I am an owner, which in most cases I'm not.<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>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></div></div></div></div></blockquote><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><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>2. I didn't know also patents can be publicly performed. How does that work?<br></div><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 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><br></div><div>Similarly the anti-tivoization clauses in the GPL are not discriminating against tivo, or mobile phone vendors for that matter, nor is the requirement to share all build files discriminating against compiler vendors. They are all there guaranteeing valid freedoms for the user / recipient of the license, that the distributor/publisher must fulfill.<br></div><div><br></div><div>Trying to talk about SaaS indirectly, via inventing completely untested legal concepts, seems unproductive. SaaS is a form or delivering software (or its functionality) to users, and users' freedoms are best protected when a license can clearly and explicitly do so in clear language. And SaaS often implies also a certain system architecture, such as REST, which could also be addressed by a license without discriminating against a type of business. (AGPL being one obvious example that doesn't violate the OSD.)<br></div><div><br></div><div>I assume this is not controversial, but I'll mention that copyright law itself does not necessitate this kind of trickery. Software licenses effectively limit software from being executed on more than 2 CPUs, in Iran, for commercial use and many other things. Of course, those specific examples are against the OSD, but copyright law itself definitively already provides sufficient power to effectively protect user freedoms also in OSD compliant ways.<br></div><div><br></div><div>(As disclosure, but also pre-emptively: I'm employed by MongoDB. I don't work in legal or PR so am not authorized to speak about SSPL or MongoDB in public. If replies to this thread bring in the SSPL or MongoDB, I will ignore them, and may have to withdraw from this thread completely.)<br></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> </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></div></div></div></blockquote><div><br></div><div>If the meaning of interface was defined in the license, that would maybe address my concern here.<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"><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">Second, about Public Performance:<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></div></div></div></blockquote><div><br></div><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><br></div><div>This is just meant as one example of what will happen when you try to extend legal words into unprecedented uses.<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"><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></div></blockquote><div><br></div><div>Ah, I missed that even if I tried to look. I may need to sing the alphabet song as a refresher!</div><div><br></div><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><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.<br></div><div> </div></div>henrik<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>