<div dir="ltr"><div dir="ltr">[I'll grant, for purposes of discussion of OSI's standards generally, 
Bruce's use of 'encumber', but I think I agree with Van that with 
respect to CAL specifically 'encumber' is incorrect.]</div><div dir="ltr"><br></div><div dir="ltr">On Fri, Jul 5, 2019 at 12:29 PM Bruce Perens via License-discuss <<a href="mailto:license-discuss@lists.opensource.org">license-discuss@lists.opensource.org</a>> wrote:<br></div><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"><div dir="ltr">Software system administrators are not always SaaS providers. And users are often administrators of their own software, that is a fundamental point of Free Software, that you _can_ do that. </div></blockquote><div><br></div><div>In trying to be brief, I was imprecise. Let me elaborate a bit.<br></div><div><br></div><div>In the late 1990s/early 2000s, the Venn diagram of users and system administrators was close to a circle: most software was self-administered. To say "we should empower software users" and "we should empower software administrators" was mostly redundant, because they were often the same people.The same provisions of GPL v2 (and of the Four Freedoms, though they weren't drafted until later) that empowered administrators basically always empowered users, or vice-versa.<br></div><div><br></div><div>There is of course still an area of overlap between administrators and users, so you're of course correct to say "system administrators are not always SaaS providers". But the union of "user" and "administrator" is shrinking over time; the area outside the union is growing. <br></div><div><br></div><div>(And of course, as Van pointed out a few minutes after I started this, where the user is their own administrator, CAL's data requirements are a null-op: that user-administrator is just as free as they are with any other modern copyleft. The SaaS-like case is the only interesting one in any competently drafted license that attempts to touch data.)<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 dir="ltr">I don't believe that FSF has ever made any statement in favor of encumbering the data processed by their programs. I don't believe they will. </div></blockquote><div><br></div><div><div>FSF has repeatedly made statements in favor of user control over 
their own data: in GPL v3 itself, in keynotes at Libre Planet, in 
policy interpretations (as advanced by interpretations of GPL v2 that 
demand user control over downloaded Javascript), and in writing/blog 
posts condemning SaaS systems that control user data in ways antithetical to the interests of their users. <br></div><div><br></div></div><div>You're correct to observe that, as far as I know, they've never taken the next step 'in favor of encumbering the data 
processed by administrators'. But it's a pretty strong set of policy 
presumptions in favor of user control over their own data, which does extend (via Javascript) to how SaaS providers need to deliver software that processes user data. <br></div><div><br></div><div>Perhaps when push comes to shove FSF believes SaaS providers' ability to modify their own software should trump the data-related rights of users. That'd be an interesting discussion to have! And it'd be an intelligible discussion, regardless of where FSF formally came down in the end, because FSF has a long track record of thinking about those issues in a fairly coherent way.<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"><div dir="ltr">And I don't believe that encumbering user data is in any way a step <i>forward </i>for the freedom of that user.</div></blockquote><div><br></div><div>Suffice to say, from extensive discussions with Europeans (and others) about GDPR, many, many people in and around the software industry strongly disagree with you. There may be a lot of justified quibbling about GDPR's implementation details[1], but there is a <i>very</i> strong presumption on the part of millions of people that encumbrances on software data usage enhance human freedom. Again, perhaps that is wrong! But it's a strong presumption, as a matter of law and policy, in the third-biggest economy on earth, and one that is gaining traction in California and elsewhere.<br></div><div><br></div><div>FSF's long track record around software freedom is completely, in my understanding of it, compatible with that view. (Stallman's personal perspective is that the <a href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwialMu-0J7jAhUzPn0KHR1iAq0QFjAAegQIAxAB&url=https%3A%2F%2Fwww.theguardian.com%2Fcommentisfree%2F2018%2Fapr%2F03%2Ffacebook-abusing-data-law-privacy-big-tech-surveillance&usg=AOvVaw1khPYPzNmgG9WHKZjxiZNA">GDPR doesn't go far enough</a>, and should ban all such collection altogether!) Perhaps, again, FSF might say 'licenses are a bad place to put these requirements', which would be fine. But at least there's a philosophy, and definition of software freedom, that gives FSF a way to wrestle with the question. <br></div><div><br></div><div>Luis</div><div><br></div><div>[1] Cookie popups are perhaps the most laughably bad attempt at protecting user freedom the world has ever seen... but they're an attempt to protect user freedom!<br></div><br> <br></div></div>