<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 8:09 PM Kevin P. Fleming <<a href="mailto:kevin%2Bosi@km6g.us">kevin+osi@km6g.us</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">On Thu, Aug 22, 2019 at 4:52 PM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com" target="_blank">pamela@chesteklegal.com</a>> wrote:<br>
><br>
>  It's not the ease of compliance, it's the fact that there is a compliance requirement at all when no other license has one in the same circumstance.<br>
<br>
The AGPL also imposes a compliance requirement in your hypothetical<br>
situation. If you install an AGPL-licensed plugin in your website (in<br>
any manner, even choosing it from a plugin repository offered by the<br>
website software project's operators), and the users of your website<br>
interact with that plugin over the network, then you are obligated to<br>
provide the source code to your users if the copy you are operating<br>
*has been modified*. <br></blockquote><div><br></div><div>Relevant to this discussion: I know some software authors who consider construe this requirement strictly: If the source as downloaded is not exactly the same as the source as deployed, it is "modified." This means that under the AGPL, even the minor changes needed for customization result in the software being "modified" and result in compliance requirements.</div><div><br></div><div>While this is an aggressive interpretation, it is not clearly wrong, nor is it unsupported by the AGPL text. Thus, the compliance burden between the CAL and the AGPL would be identical for Pam's case.</div><div><br></div><div>Thanks,<br></div><div>Van<br></div></div></div>