<div dir="ltr">Continuing to characterize these users as "clueless" shows a deep contempt for the less technical portion of the OSS community. I'm not inclined to be the word police but I believe that this is inappropriate for this list and makes it unnecessarily toxic. <div><br></div><div>I think even non-native English speakers can understand that the phrase "clueless" is intentionally derogatory.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 12, 2019 at 3:18 AM 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Bruce</div><div><br></div><div>As you point out, most operators - however clueless they may be - already must carry the burden of handling users' data carefully. In the EU - and this includes sites outside the EU that serve the EU market - they already have the burden to return to users a data set mandated by the GDPR, which is even broader than the data set defined by CAL. So the net additional burden imposed by CAL is actually zero.</div><div><br></div><div>Just to give another example of the kinds of things a clueless operator must legally understand to handle correctly: Should the operator ever transfer copies of user data from the EU to the US - such as over MySQL replication - then at minimum they need to apply encryption at rest on the other end, and possibly more, like minimize or anonymize the personally identifiable data. If the operator doesn't know what encryption at rest means, then yes, they will spend €€€€€€€ to have someone else implement that.<br></div><div><br></div><div>henrik<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 12, 2019 at 1:23 AM Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">Henrik, I think your example misses the point. Most operators, of course, have more than one customer, and in returning data to one customer, must be very careful to segregate it from anyone else's data. The penalties in Europe for failing to do that are potentially very significant, and we can expect them to get that way everywhere.<div dir="auto"><br></div><div dir="auto">So they either are compelled to write an export facility, or do some sort of ad hoc export. But they must be very careful about what data is released, and due diligence probably requires that they inspect the outgoing data manually.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2019, 13:12 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Josh,</div><div><br></div><div>I agree that this is an interesting question to discuss, and raised it myself some months ago. But...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2019 at 10:09 PM Josh Berkus <<a href="mailto:josh@berkus.org" rel="noreferrer" target="_blank">josh@berkus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">3) I am now compelled, under the terms of the license, to *write* a user<br>
data export feature that didn't exist in the software that I copied from<br>
you under the CAL.<br>
<br></blockquote><div><br></div><div>Sorry but this is not true. The whole point of Van's position is that the CAL doesn't compel you to write or create any particular technical solution.</div><div><br></div><div>As a trivial counter example: Assume that you use the CAL licensed software to provide services to a single user other than yourself. You can now fulfill your obligations easily by just creating a zip file of your data directory.</div><div><br></div><div>Of course, if you expect lots of users and therefore maybe lots of requests for user data, you probably should write an easy export feature since that is the most practical solution to you. But the CAL doesn't compel you to do that. Quite the contrary, it allows you to choose whatever method is preferable for you.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
4) As a corollary, this means that if I am not a programmer (and don't<br>
have $$$$), I cannot use the software you created in (1).<br>
<br>
While the above may be OK with you, it would be an unprecedented step in<br>
the history of OSS licenses, and as such is likely to create significant<br>
barriers to approval.<br>
<br></blockquote><div><br></div><div>Note that this same criticism can be pointed toward the GPL itself too - for source code.</div><div><br></div><div>Assume I give to you 1 CD with a binary executable, and another CD with the corresponding source. I have not published the source code online, you are the only recipient of it.</div><div><br></div><div>You now want to distribute the unmodified binary to 2 other recipients. How will you comply with the GPL requirement to distribute source? You either have to burn 2 new CDs with the source, or upload the source to an online location. If you don't know how to do that, you must spend $$$$ to get it done.</div><div><br></div><div>The fact that this is not a common problem with the GPL, suggests that the analogous problem might not be common for CAL either. Even if the hypothetical scenario is definitely worth discussing.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Nigel is suggesting language to make the data export requirement<br>
symmetrical; that is, that downstream users are required to preserve or<br>
expand any data export features present in the software they copied.<br></blockquote><div><br></div><div>Note that such a requirement may itself not be OSD compliant. At least care would have to be taken to draft the language more precisely than what you did above, so that it doesn't create the situation where some code or feature can never be removed from the software.</div><div><br></div><div>henrik<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
-- <br>
Josh Berkus<br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" rel="noreferrer" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><a href="mailto:henrik.ingo@avoinelama.fi" rel="noreferrer" target="_blank">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354 skype: henrik.ingo irc: hingo<br><a href="http://www.openlife.cc" rel="noreferrer" target="_blank">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" rel="noreferrer" target="_blank">http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7</a></div></div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" rel="noreferrer" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><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>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>