<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 14, 2019 at 5:35 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">On Wed, Aug 14, 2019 at 8:02 AM Henrik Ingo <<a href="mailto:henrik.ingo@avoinelama.fi" target="_blank">henrik.ingo@avoinelama.fi</a>> wrote:<br><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">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></div></blockquote><div><br></div><div>This is all fair counter arguments. As you've seen in other threads, I'm not the biggest fan of AGPLv3 either, where the license all but assumes a Graphical UI. (To be clear: I am a fan of copyleft and the AGPL, I just think there's room for alternatives.) Otoh through the discussions this year I've also learned to respect the value of crafting open source licenses that don't burden use of unmodified versions of the software.</div><div><br></div><div>I don't want to debate whether my suggestion is better than your current position. I expect that others will be more resistant to this idea as a whole anyway. I wanted to address the arguments about not burdening "mere use" with legal requirements and risk. Should that become the primary argument of your opposition, you can always reconsider whether you want to seek shelter at my proposal after all. <br></div><div><br></div><div>(I will silently consider to what extent I could approve of your current text if you submit it to license review. It's certainly improved from last time, but the idea remains problematic even to me.)<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 class="gmail_quote"><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"><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><div><br></div><div>I agree. I'm splitting hairs and clarifying the issue here and maybe in a FAQ example is sufficient. The real issue is the ambition to claim rights to competing API compatible implementations.<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 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></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></div></div></blockquote><div><br></div><div>Forgive me, but that is just a redundant statement that is legal weasel wording. You're essentially still saying that if an API could be protected by copyright, in some jurisdiction, then the CAL would still claim those rights. In my understanding, the previous review round was fairly strongly against this.<br></div><div><br></div><div> </div>henrik<br clear="all"></div>-- <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>