<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 23, 2019 at 1:43 PM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.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"><br>
On 8/23/2019 2:31 PM, VanL wrote:<br>
> Bruce's - and your - arguments are frequently addressed to what I<br>
> might term "data in the large." Bruce made this point explicitly, by<br>
> invoking the slippery slope argument. However, should we be looking<br>
> more specifically at the CAL's requirements? They were written to be<br>
> narrow and closely tied to the actual capability to use the software.<br>
Can you walk me through how that's the case? That is the piece I'm missing.<br></blockquote><div><br></div><div>
<div dir="ltr"><div><div>Sure. The key concept is 
that a Recipient must have the full ability to self-host or to switch 
hosts without having to give anything up in exercising that right. This 
is expressed in the "Purpose" in Section 1:</div><br>> This License also strives to protect the freedom and autonomy of third<br>
> 

parties who receive the Work from you. If any non-affiliated third party<br>
> 

receives any part, aspect, or element of the Work from You, this License<br>
> 

requires that You provide that third party all the permissions and materials<br>
> 

needed to independently use and modify the Work without that third party<br><div>
> 

having a loss of data or capability due to your actions.</div><div><br></div><div>This
 frames the rest of the discussion, because the focus is on the 
Recipient-User's ability to fully utilize the work. This focus is made 
operable through the autonomy condition and the definition of User Data 
itself:<br></div><div><br></div>> In addition to providing each Recipient the opportunity to have Access to the<br>> Source Code, You cannot use the permissions given under this License to<br>
> 

interfere with a Recipient’s ability to fully use an independent copy of the<br>
> 

Work generated from the Source Code You provide with the Recipient’s own User<br>
> 

Data.<br>
> 

<br>
> 

“_User Data_” means any data that is either an input to or an output from the<br>
> 

Work, or any data necessary for the functioning of the Work, in which the<br>
> 

Recipient has an existing ownership interest, or that the Recipient has an<br>
> 

existing right to possess, or that has been generated for or has been<br>
> 

assigned to the Recipient.</div><div><br></div><div>I wrote this to be 
as careful as possible about preserving the Recipient's ability to fork,
 or to self-host, or to choose another host, while not reaching anything
 that the Recipient didn't have a right to. As such, it is closely tied 
to the actual, practical experience of running an independent copy of 
the software.</div><div><br></div><div>It is also important that the CAL
 doesn't require an operator to delete copies and it does not encumber 
the data (in the legal sense). There is nothing that provides an 
end-user Recipient control over the use of the data by an operator-user 
Recipient. Just as with the source code, the parties can each go their 
merry way and never interact again. This is again a key distinction that
 makes the CAL not about "all data," but instead about preserving an 
end-user's ability to run the software,<br></div></div><div dir="ltr"><br></div><div>Thanks,<br></div><div>Van<br></div><div dir="ltr"><div> <br></div></div> 

<br></div></div></div>