<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">henrik.ingo@avoinelama.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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" target="_blank" rel="noreferrer">josh@berkus.org</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">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:1px solid 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:1px solid 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:1px solid 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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">henrik.ingo@avoinelama.fi</a><br>+358-40-5697354        skype: henrik.ingo            irc: hingo<br><a href="http://www.openlife.cc" target="_blank" rel="noreferrer">www.openlife.cc</a><br><br>My LinkedIn profile: <a href="http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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>