<div dir="ltr"><div>These are good concerns. For completeness, I'll respond:<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020 at 11:06 AM Christopher Lemmer Webber <<a href="mailto:cwebber@dustycloud.org">cwebber@dustycloud.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"><br>
- Is there a possibility of forced disclosure of private data, in terms<br>
of user data or keys, in terms of a wider source distribution<br>
requirement or via the introduction of the user/recipient data (and<br>
cryptographic material) disclosure for equivalent use?<br></blockquote><div><br></div><div>No. The CAL only requires turning over data to which a person has an existing legal right. By definition, this is not "forced disclosure" - the legal basis already exists.<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">
- I think that requirements for documentation and configuration<br>
information for "use" is a bit too broad; I think "execute" is a<br>
better term. This one is an easy fix.<br></blockquote><br>I don't think there ends up being a meaningful difference between "use" and "execute," especially given the context of providing only the "information <b>reasonably necessary</b> for the Recipient to independently compile and use the Source Code and to have full access to the functionality contained in the Work."</div><div class="gmail_quote"><br></div><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">
- Is the requirement to be able to give user/recipient data an onerous<br>
one? </blockquote><div><br></div><div>The difficulty or non-difficulty of providing data has been discussed on this list in the context of the CAL. In certain circumstances, providing source code is also onerous, but that does not make copyleft licenses any less OSD-compliant.<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">
What are the implications for data retention? What about<br>
accidental data loss?
</blockquote><br>The CAL does not penalize accidental data loss, nor does it require a particular data retention policy. It just says that someone providing services must provide the "Recipient’s User Data <b>in your possession</b>, <b>to the extent that such User Data is available to You</b> for use in conjunction with the Work."<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If software does not make extracting such<br>
information easy, is the liability on the software developers, or on<br>
the operator of a service?<br></blockquote><div><br></div><div>The liability is on the person providing the service, not the developers - just as with other copyleft licenses.<br></div><div><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">
> If you believe that the license is not appropriate for certain types<br>
> of uses or certain types of software architecture, can you explain how<br>
> that violates the OSD?<br>
<br>
Yes, in addition to the above three bulleted concerns, I have indicated<br>
that I think a peer-to-peer actor model environment would be especially<br>
difficult to comply with this license for ...
[the issue is] arguably raised in </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OSD sections 6 and 10 ("no discrimination against fields of endeavor" <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(though this would arise implicitly) or "License Must Be Technology-Neutral" <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(as in, is this something that is easier to deal with in client-server architectures but<br>
not as possible in ocap actor model architectures).</blockquote><div> </div><div>The fact that an author may choose an architecture that makes compliance more difficult is not discrimination against a field of endeavor nor a requirement that particular technologies be used (or not used). Even if compliance may be "difficult," that is not discrimination. For example, a person can also engage in development practices that make full disclosure of the source code difficult; that does not mean that those practices are outlawed by the license.<br></div><div><br></div><div> </div><div>But I would like to most strongly disagree with the following:<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">
if we can
determine that a license is written in such a way that it can be used to<br>
coerce via legal means a violation of a person's privacy...<br></blockquote><div><br></div><div>The CAL does not do this. It <b>only</b> requires the disclosure of the User's own data, to which they have an existing legal claim. Giving someone <b>their own data</b> is never a violation of that person's privacy!</div><div><br></div><div>Thanks,</div><div>Van<br></div></div></div>