[License-discuss] Data portability as an obligation under an open source license

[Luis Villa]

On Sat, Jun 29, 2019 at 6:40 AM Pamela Chestek <pamela at chesteklegal.com>
wrote:

>
> On 6/28/19 11:40 PM, Bruce Perens via License-discuss wrote:
>
>
>> 3.    *A license that requires data portability*.
>> 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 license submitter confirmed in this sequence of
>> emails that the intent of this provision is to expand the scope of software
>> freedom:
>> http://lists.opensource.org/pipermail/license
>> -review_lists.opensource.org/2019-May/004123.html
>> http://lists.opensource.org/pipermail/license
>> -review_lists.opensource.org/2019-May/004124.html
>> http://lists.opensource.org/pipermail/license
>> -review_lists.opensource.org/2019-May/004126.html
>> The members of the License Review Committee do not agree whether this is
>> appropriate for an open source license. It therefore requires extensive
>> additional public discussion before the OSI will be able to reach a
>> conclusion on this point.
>>
>
> It's my opinion that this is out of scope for an Open Source license. 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
> license. Of course, you don't need OSI's approval to use any license you
> wish.
>
>
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.

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.

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 (I first
wrote about it publicly in 2008
<https://wiki.gnome.org/Attic/FreeOpenServicesDefinition/DataControl>).
Perhaps one might then oppose this on the grounds that *licenses* are
*pragmatically
ineffective* ways to expand this freedom, but it's certainly obvious
that *philosophically
*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.

I'm pretty sure I know how FSF thinks about this philosophically; their
definition of software freedom has consistently extended to *user*-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).

I genuinely don't know what OSI institutionally thinks software freedom
means in this context, and would look forward to clarification.

Luis [I'm mostly off the grid starting tomorrow; sorry about the bad timing
but look forward to seeing how this develops]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190705/39674b92/attachment.html>