[License-review] For approval: The Cryptographic Autonomy License (Beta 4)

[Eric Schultz]

Before I begin, I am politely asking folks to not include me on any replies
to this email (I'll be unsubscribing from the list after I send this). I
have no issue with anyone discussing what I said on the list but I don't
really want to see it in my inbox. If I want to continue participating,
I'll go to the list archives.

--
Elana Hashman asked me to give my feedback on the CAL on this list. So here
goes!

First, I appreciate the work that Van has done in working with the OSI in
developing the CAL. I also appreciate that this has seemed like a
legitimate attempt to create a license that meets the OSD requirements. Far
too many license creators, primarily in the startup space, seem to be
trying to change the OSD to fit their license instead.

As for the license itself, I don't see any obvious pitfalls in it. It seems
straight forward enough based on my hobbyist understanding of licenses.
I'll let actual lawyers decide whether there are holes in it or not. The
real question then is, if the license does what we think it does, is it an
OSD compatible license?

My initial conclusion is "I don't know". To come closer to a more certain
conclusion, I can try to use a different lens which I believe also
encompasses the OSD: "does it uphold user freedom?" My conclusion is still
"I don't know" but I'd lean slightly towards "yes". To be fair, I could be
convinced that it does not as well. It's just a close call in my book. Feel
free to use that opinion in any way you'd like in this process.

That said, no one here is really even talking about the CAL because the CAL
approval process is a proxy for the larger issue: can a license require
users to provide network users with their data? I don't know that it can
but I also don't know that it can't. This is a fundamental question of what
the OSD means. The CAL license review process isn't for deciding what the
OSD means, or at least, it shouldn't be. I have a great respect for Van and
I don't have any real criticisms of him in this process. That said, I don't
like that the entire catalyst for evaluating the boundaries of the OSD is
some sort of a cryptocurrency/blockchain startup with a vague business
model who happened to have the funding to go through the drafting and
approval process. Serving the interests of venture capital is not what the
OSD means to me and ultimately that's what the CAL submission and approval
process is doing.

The OSD is supposed to belong to humanity. If we're going to evaluate user
data exportability in the OSD, it needs to include more viewpoints and
considerations. A few that should be considered that I don't believe have
been:

* The experience of people in non-Western countries
* Minimally technical users. As an example, is there a way that requiring
user data exportability would put an unreasonable legal burden upon small
businesses, nonprofits or individuals using the software?
* Marginalized people. One area of potential worry I have is whether this
requirement would open up marginalized groups to further legal trouble.
What's the risk to LGBTQ people in Russia or the Uyghur in China?
* The interaction of data exportability with the privacy of other users.
There certainly exist situations where multiple users may have access to
the same private data. An obvious example is messaging software whether
both sides of the conversation would be able to export the conversation.
Are there nuanced sides of this that aren't being considered?
* How does it work when the software doesn't have an obvious service
provider, in the case of privately run P2P applications? What should we
expect the OSD to require as it applies to user data exportability when the
users have a temporary fleeting interaction with each other, possibly on
the order of milliseconds?

We already have enough viewpoints related to the scenario of the dominant
rich service provider with a mildly less privileged user. I'd even say
that's been the driving scenario of almost all the "innovations" around
licenses, both from companies and well-meaning individuals, over the past
few years.

Let's do better.

Eric



--
Eric Schultz, Developer and FOSS Advocate
wwahammy.com
eric at wwahammy.com
@wwahammy
Pronouns: He/his/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200105/552ceeda/attachment-0001.html>