<div dir="ltr"><div dir="ltr"><br><div>Hi Chris,</div><div><br></div><div>Thanks for sharing your concerns.<br></div><div><br></div><div>Let me start with your last point first:</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"><div>Finally, I am going to repeat part of what I said in the cap-talk<br>
thread: the choice of the license name is ironic, because though the<br>
goals are good (ensure autonomy of users), it may actually create<br>
difficulties in complying in the kinds of systems that actually are<br>
doing so through cryptography and protocols (ocap actor model systems,<br>
encrypted data vaults).  The problem is one that must be addressed for<br>
the sake of user freedom, but I believe it is being addressed on the<br>
incorrect layer.  Here we see an attempt to address it on the license<br>
layer, but IMO this is wrong: there are active systems that exist and<br>
are addressing this in such a way that the cryptographic tooling and<br>
protocols themselves are the ones that help ensure greater user<br>
autonomy.</div></blockquote>

</div><div dir="ltr"><br></div><div>You may be interested to know that I did not choose this name. It was specified by my client, whose founders have spent their professional life working on Cryptographic Autonomy - and this license was specifically designed in part to deal with issues that the technical layer can't handle well. The legal layer isn't sufficient, but neither is the technical layer. Code has bugs; protocols can be subverted. The license is a backstop and tool to stop an entirely different set of adversaries that are not well addressed by using code alone. <br></div><div><br></div><div>Now, addressing your more-specific concerns, my response in brief is that you are incorrect as to the scope of what is required by the CAL.</div><div><br></div><div>First, with regard to the source code requirement: The easy response is that there is nothing in the CAL that would require someone to generate new documentation. More generally, you are confusing configuration information generally with configuration information needed to install and use, which is the context of this provision.</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"><div> In my talk last year I was making<br>
an argument that we could see emacs lisp as being both configuration<br>
information and code (but the lack of network requirement permitted<br>
private modification).  Here that argument need not even be made since<br>
the CAL *explicitly* requires configuration information.<br>
<br>
I'm definitely worried then about:<br>
 - The introduction of a requirement for documentation for *use*<br>
 - The introduction of a requirement for configuration information,<br>
   *especially in the context of network distribution requirements*.</div></blockquote><div><br></div><div>I... confess I don't follow your argument here. I am aware of the LISPy "code is data is configuration"-type context - but I am having trouble imagining a network-aware Emacs creating any burden at all. Even if you look at typical network interactions that have been built into Emacs (news reader, email, etc), you would have to evaluate whether your interaction via Emacs turned the other party into a Recipient by transmitting a licensable element to the other party. In all the cases I am aware of, Emacs would be a client (in the typical client-server sense). In the case where one party is acting as a client, the terms of the interaction are generally set by the party acting as the server in a particular network transaction. I am not sure how requesting information from a third party, on terms set by the third party, would involve the sharing of *your* copyrightable/licensable material. Accordingly, the third party is not a "Recipient" according to the terms of the CAL and your Emacs configuration is safe - and private to you.</div><div><br></div><div>If you modified Emacs to be a server, and serve up information, then that would be something else - but in that case it is no different than any other server.<br></div><div><div dir="ltr"><br></div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The use of the word "operator" tells me that the intended use of this<br>
license has been seen within the scope of a client-server style<br>
architecture, or has been flavored by the experience of seeing that<br>
rolled out as the primary way we've seen networked applications in the<br>
last couple of decades. <br></blockquote><div><br></div><div>You are mistaken. The CAL was written specifically for a peer-to-peer application, but was designed to be compatible with client-server interactions, as they are the most common. Nevertheless, even in a peer-to-peer interaction, you can still talk about a "Recipient" because each peer acts sometimes as a client and sometimes as a server, and those different roles give rise to different types of sharing (and thus different requirements).<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">In particular:<br>
<br>
 - It does not seem to anticipate that *every user* should be running<br>
   their own application... not client-to-server, but peer-to-peer .[...]</blockquote><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"> 
- Assume that object access is managed by capability security.  [...]</blockquote><div><br></div><div><div> I am familiar with actor-model ocap systems, and this does not cause them any issue. The CAL is very careful to limit disclosure to the Recipient's user data; it does not require disclosure of the operator's private data.<br></div></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"> In order to uphold the Principle of Least Authority, varied and attenuated access is given out to many different objects in the system.  Which of them are "users", and what rights for what data do they have to extract which information?  </blockquote><div><br></div><div>This comment shows a key misunderstanding: A user is a *person*, not an object that has been granted authority. This is one of the benefits of acting at the legal layer; we can apply legal reasoning to the people-actors, not the object-actors that live in the system.<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">This is not theoretical, this is the direction that sophisticated peer-to-peer, cryptographically secure distributed programs are going (eg the programming language E, the work that the<br>
   Agoric company is doing, and my own work on Spritely Goblins).  While I (and many other security researchers) believe this is the healthiest direction for network security to go, I do not see a good<br>
   way to be able to uphold this with the requirements for recipient data distribution and key distribution.<br>
</blockquote><div><br></div><div>
I don't really think this is the place to dive deep into software architecture, so I'll just say that this reflects a misunderstanding of the requirements of the CAL. Least authority system or not, the analysis is: <br></div><div>  1) Is there a Recipient - a human being that has received licensable material?<br></div><div>  2) Do I have the Recipient's User Data? Meaning, do I have data that a User has a legal right to in my possession?<br></div><div>  3) Is that User Data available to me? (For example, not encrypted beyond my ability to identify it?)</div><div><br></div><div>If all three of these questions are true, then you need to provide the Recipient's User Data back to the Recipient. <br></div><div><br></div><div>I will return again to the main point: I have a pretty good knowledge of, and deep respect for, the leading edge of capability-based systems. We definitely need further technical work in this area in order to provide better guarantees to users. But that doesn't mean that the legal layer is unnecessary! The legal layer is orthogonal to the technical layer, and each reinforces the other. It is a fundamental mistake to only look at one or the other.</div><div><br></div><div>Thanks,</div><div>Van<br></div><br></div></div></div>