<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. 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. 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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 5, 2019 at 12:07 PM Luis Villa <<a href="mailto:luis@lu.is">luis@lu.is</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"><div dir="ltr"><div dir="ltr">On Sat, Jun 29, 2019 at 6:40 AM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com" target="_blank">pamela@chesteklegal.com</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 bgcolor="#FFFFFF">
<br>
<div class="gmail-m_1614233802710781004gmail-m_5703124612383989672moz-cite-prefix">On 6/28/19 11:40 PM, Bruce Perens via
License-discuss wrote:<br>
</div>
<blockquote type="cite"><span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-im" style="color:rgb(80,0,80)">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><br>
3. <u>A <span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span> that
requires data portability</u>. <br>
Section 2.3(b) obliges the user of a software to “provide to
any third party with which you have an enforceable legal
agreement, a no-charge copy … of the User Data in your
possession in which that third party has a Lawful Interest
….” The <span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span> submitter
confirmed in this sequence of emails that the intent of this
provision is to expand the scope of software freedom: <br>
<a class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span>-review_lists.opensource.org/2019-May/004123.html</a><br>
<a class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004124.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span>-review_lists.opensource.org/2019-May/004124.html</a><br>
<a class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004126.html" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span>-review_lists.opensource.org/2019-May/004126.html</a> <br>
The members of the <span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">License</span> Review
Committee do not agree whether this is appropriate for an
open source <span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span>. It
therefore requires extensive additional public discussion
before the OSI will be able to reach a conclusion on this
point.<br>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>It's my opinion that this is out of scope for an Open Source <span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span>. My argument is on the record
above and I'm glad to elaborate. I think Arthur (Van's customer)
could explain what he wants to do with this and why he thinks
it's important. But even if I end up approving of the sentiment,
so far I think it would remain out of scope for an OSI approved
Open Source <span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span>. Of course,
you don't need OSI's approval to use any <span class="gmail-m_1614233802710781004gmail-m_5703124612383989672gmail-il">license</span> you
wish.</div></blockquote></div></blockquote><div><br></div><div>Access to data is a big part of why I keep asking what OSI means by software freedom. If the ultimate rubric for OSI is 'freedom' then I don't think you can answer 'how should licenses interact with data' without a theory of what 'freedom' means, including whose 'freedom' the standard is.</div><div><br></div><div>If 'software freedom' means 'freedom for software system administrators (known commonly known as SaaS providers)', then the answer to this is probably fairly straightforward: data/privacy rules are an unacceptable impingement on their freedom; they should be able to run the software as they see fit for their users, with complete flexibility (within legal and commercial constraints) to choose how to use/interact with/dispose of data. So, in that case, data is not appropriate for an open source license; easy call.<br></div><div><br></div><div>If 'software freedom' means 'freedom for software end users (sometimes known as human beings)', then the answer to this is also straightforward: data is increasingly central to any reasonable assessment of human autonomy as mediated by software. This has been obvious for over a decade (<a href="https://wiki.gnome.org/Attic/FreeOpenServicesDefinition/DataControl" target="_blank">I first wrote about it publicly in 2008</a>). Perhaps one might then oppose this on the grounds that <i>licenses</i> are <i>pragmatically ineffective</i> ways to expand this freedom, but it's certainly obvious that <i>philosophically </i>human control over data is a part of software freedom and within scope of any comprehensive theory of software freedom. So perhaps CAL is still out of bounds, but on pragmatic grounds, not philosophical.<br></div><div><br></div><div>I'm pretty sure I know how FSF thinks about this philosophically; their definition of software freedom has consistently extended to <i>user</i>-control: user modification of Javascript, activism against DRM, etc. It's possible they might oppose CAL on pragmatic grounds, since there's a (strong!) case to be made that licensing is an ineffective tool for this, and perhaps even (as with some tough cases around DRM) they might decide that freedom zero trumps all other rights, even when that definitively reduces user freedom. I hope they weigh in on CAL at some point to help further clarify their thinking as to how that might translate into practice (both inside and outside of licensing). <br></div><div><br></div><div>I genuinely don't know what OSI institutionally thinks software freedom means in this context, and would look forward to clarification.<br></div><div><br></div><div>Luis [I'm mostly off the grid starting tomorrow; sorry about the bad timing but look forward to seeing how this develops]<br></div></div></div>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Bruce Perens - Partner, <a href="http://OSS.Capital" target="_blank">OSS.Capital</a>.</div></div></div></div>