<div dir="ltr"><div>Thank you Henrik.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2019 at 5:01 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">
To summarize my concerns (that still remain):<br>
<br>
1. The use of public performance in a software license is novel and<br>
untested. It's hard to predict it's effect, but from the definition of<br>
Public Performance it seems possible and even likely that both<br>
developers and users can get sued inadvertently.<br></blockquote><div><br></div><div>I see this point, but disagree about the likelihood of inadvertent suit. This is probably an irreconcilable difference, as I see the public performance aspect as being key to the CAL.<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">
2. From a policy point of view, it is not in OSI interest to expand<br>
the use of copyright legislation to restrict software.<br></blockquote><div><br></div><div>I see this also. But in the context of copyright law as it is currently written and interpreted, I don't think it is an extension to use legal terminology and case law which already presumptively applies to software.<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">
3. It is not necessary for you to use Public Performance to achieve<br>
your goals of the license. Both from a copyright law, and an Open<br>
Source Definition point of view, you can use legal methods that are<br>
more boring, but better tested and safer, to achieve your goals.<br></blockquote><div><br></div><div>See above.<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"> In particular I wanted to<br>
state that obviously restrictions on DRM in general are not a<br>
violation of OSD. Quite the contrary, they are  a great example of<br>
protecting user rights against new technical means of restricting<br>
users.<br></blockquote><div><br></div><div>I also agree with this point.<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>
Another remaining point from my previous review: CAL 2.3 c-e cover the<br>
use of DRM within the software licensed by CAL. It doesn't cover the<br>
use of DRM in the hardware or OS to restrict installation and use of<br>
the CAL licensed software. This seems like an unfortunate loophole<br>
that can be fixed by borrowing a few sentences from GPLv3.<br></blockquote><div><br></div><div>If you take a look at the exact text, the text is very close to the GPLv3. There was quite a bit of "borrowing" in exactly the way you suggest.<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">
For 2.4, I still wonder whether you are willing to consider some more<br>
explicit option to flag that I didn't choose to use the option. For<br>
example, when I apply CAL to my software, can I remove §2.4 from the<br>
license text?<br></blockquote><div><br></div><div>I see this point, but I think that you are covered: 2.4 is an opt-in provision that applies only if it is explicitly called out by the license author. If you don't see the particular text specifically invoking it, it does not apply.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,</div><div class="gmail_quote">Van<br></div></div>