<div dir="ltr"><div>Hi Henrik,</div><div><br></div><div>Thanks for your comments.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 14, 2019 at 8:02 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:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Data autonomy<br><div><br></div><div>Wrt the discussion of not encumbering mere use / private use with any obligations, I notice there's first of all a very explicit carve out for "your private purposes". Also the first paragraph of 4.2 is in the same spirit I think. But I think 4.2.1 still falls a bit short of drawing the right boundary. I think the reasonable boundary is: 1) If the software you received includes functionality for the user to download his data, you cannot remove or encumber this functionality. 2) When you add functionality that causes more data to be stored, it must be available through the same or similar functionality.</div></div></blockquote><div><br></div><div>[snip]</div><div><br></div><div>I see where you are going by this, but I don't think that works. <br></div><div><br></div><div>First, as you note, your proposed modification would have the result of making certain parts of the software un-modifiable, which I think is a no-go.</div><div><br></div><div>Second, it doesn't seem proper to me to dictate the structure of someone's program. I want to identify the policy that needs to be upheld, not the mechanism.[1] There are a million ways to be compliant with the CAL; I don't want to bake something in where it would not be appropriate. For example, even "I tar up the files and email them to you" may not be efficient, but it would be compliant.<br></div><div><br></div><div>Third, there are examples of later-added "user data download" functionality (e.g., Google Takeout) that would be hypothetically compliant with the CAL. So it doesn't seem unreasonable to say that functionality could be added to assist with compliance, if necessary. <br></div><div><br></div><div>Fourth, termination is not immediate; termination due to non-compliance only occurs if the licensee does not comply within 60 days of being notified of non-compliance. That gives adequate time for even inefficient measures, and prevents this from being a "submarine" issue.<br></div><div><br></div><div><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"><br><div>API copyleft</div><div><br></div><div>You no longer make any references to "public performance", so the issue of pioneering a new evil copyright power is avoided. Similarly there doesn't appear to be a direct claim on API copyright.<br></div><div><br></div><div><i>"4. If You exercise any permission granted by this License, such that the Work, or any part, aspect, or element of the Work, is distributed, communicated, made available, or made perceptible to a non-Affiliate third party (a “Recipient”), either via physical delivery or via a network connection to the Recipient, You must comply with the following conditions"</i></div><div><br></div><div>There is no question that a software license can claim rights in all of the above things. Also, since you are granting these rights, there's no OSD issue as such.</div><div><br></div><div>While this is narrower than the previous version, I think my practical questions still remain: If the work is "made perceptible" via a video screen in the park, do the photons emitted by the screen still fall within "physical delivery"?</div></div></blockquote><div><br></div><div>I thought very hard about your "public park" example, and that is why I chose those specific words. I don't think a walk-by would result in "physical delivery" of the software under any reasonable standard. If this ended up being the only issue, I would consider "tangible physical delivery," but I don't think it is necessary.<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><br></div><div>Rather than nit picking on that, let's go to the real issue: Since you didn't say anything about APIs or interfaces, it seems to me words like "aspect", "perceptible" and maybe "elaborate" remain in the license because the goal of your client clearly still remains to assert copyleft on an independent work implementing a compatible API. </div></div></blockquote><div><br></div><div>This depends. If the independent work contained protectable, licenseable portions of the CAL-licensed work, then it is not "independent," it is derivative.</div><div><br></div><div>If the independent work did not contain any protectable, licenseable portions of the CAL-licensed work, then I don't think the CAL could reach it under any standard.<br></div><div><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><br></div><div>I think 5.3 would benefit from following clarification: " In the event of termination due to litigation initiated by You,"</div></div></blockquote><div><br></div><div>Done. <br></div><div><br></div><div>Thanks,<br></div><div>Van<br></div><div><br></div><div><br></div><div><br></div><div>
[1] For the old-timers, yes, this is in deliberate contrast to X11. :) 

<br></div></div></div>