<div dir="ltr"><div>Hi Chris,</div><div><br></div>+On Wed, Feb 12, 2020 at 2:19 PM Christopher Lemmer Webber <<a href="mailto:cwebber@dustycloud.org">cwebber@dustycloud.org</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"><br>
Could you specify what those problems are?<br></blockquote><div><br></div><div>At least one key design concern was the gradual re-centralization of originally decentralized systems. A system can be designed to be decentralized, but aggregating too much power to one party - through non-nefarious means - can lead to harmful re-centralization and a loss of autonomy. As an example, think of XMPP: originally decentralized, broadly adopted in part due to support in Gmail, but then re-centralized and re-proprietarized. That sort of situation would be significantly less likely to occur in a CAL-licensed ecosystem.<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">
The language of the section talks about use rather than execution, which<br>
is broader.  Starting up and running a program is different than being<br>
able to understand how to use its features.  </blockquote><div><br></div><div>As I said, nothing in the CAL requires the generation of new documentation, and the context of this requirement is the provision of source code, which limits it. However, even if this were interpreted broadly, I don't think that asking for existing associated documentation is a bad thing. It is closely tied to the work, and, as you point out, the idea is to empower users.<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">
The AGPL makes no distinction between client and server...</blockquote><div><br></div><div>[snip a bunch about the AGPL]</div><div><br></div><div>Although the AGPL may give rise to similar duties in many circumstances, the legal methods of operation are completely different. None of the analysis that you discuss here applies to the CAL.<br></div><div> </div><div>Moving to ocap systems:<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">That's true, though in an actor ocap style system the granularity of<br>
such interactions is very small.  Does a recipient or user require a<br>
human behind the wheel, or does it apply to every object in the system?<br></blockquote><div><br></div><div>[snip ocap system, Alice and Bob, etc] <br></div><div><br></div><div>You are thinking about this at entirely the wrong layer. You are trying to place a legal interpretation on technical abstractions. That is always dicey, and in this case it just doesn't fit. The best I can say is that it applies to the human motivating an action through one or more software interfaces. Trying to parse that out to "every object in the system" is like trying to ask whether each individual H20 molecule in the ocean is individually salty. It doesn't make sense. I completely understand your technical explanations. I am just not sure there is a way to meaningfully respond using the frame you propose.</div><div><br></div><div>Thanks,<br>Van<br></div><div><br></div><div> </div></div></div>