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

[Henrik Ingo]

On Sat, Feb 15, 2020 at 8:04 PM Brian Behlendorf <brian at behlendorf.com> wrote:
> On Thu, 13 Feb 2020, Pamela Chestek wrote:
> > Yes, that was one of the very first issues raised with the CAL license
> > v1 on license-discuss before it was submitted to license-review almost a
> > year ago, in April 2019. This is Van's explanation about why they are
> > about two different things:
> > http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020324.html.
>
> I realize this is moot with the OSI board recommending approval (or did
> they approve?),

At this point it's approved.

> but I'm not persuaded by what was written at that link
> (starting with "GDPR is about privacy, not data" - the "D" is literally
> "Data" and the P is not "Privacy"). I'm not a GDPR expert by any stretch,
> but found in other discussions that making self-sovereign identity systems
> GDPR-compatible to involve several layers of non-trivial issues. Issues
> such as the fact that any particular bit of data is rarely about just one
> person, and more often than not about two people; hashed/encrypted data
> can also be PII; and that there are reasonable exceptions where data can't
> be shared or deleted upon request that are not machine-parseable
> situations (such as "valid business reason"). GDPR's impact is also still
> evolving as enforcement actions establish a track record for how it will
> be enforced and accepted by judges on broad or narrow interpretive bases.
> It's a ton of complexity - but all of which I find myself arguing on the
> side of being an unavoidable part of the ethics of dealing with data about
> other people.
>
> I would have more trust in an analysis of these issues by someone not
> vested in whether OSI approves the license. Elizabeth Renieris
> (@hackylawyer on Twitter) for instance.
>

I'm not a lawyer but also not vested in any interests. I'm also
European so I have some everyday knowledge about GDPR. (Such as what
the letters stand for. Yes, this is a common question!)

The key here is that the data that GDPR applies to is a different set
than what the CAL considers User Data. Says the CAL:

> “User Data” means any data that is an input to or an output from the Work, where the presence of the data is necessary for substantially identical use of the Work in an equivalent context chosen by the Recipient, and where the Recipient has an existing ownership interest, an existing right to possess, or where the data has been generated by, for, or has been assigned to the Recipient.

>From the above it is clear that the CAL addresses data that I already
have in my possession, or have had when it was stored in the system by
me, or in any case data that I'm clearly entitled to have. So in terms
of privacy or confidentiality the data I can get thanks to CAL should
typically not be new information to me. The point of the CAL is merely
to guarantee my right to move data that belongs to me. ("data
autonomy")

The GDPR otoh is concerned with transparency: site operators must
disclose to me what data they have collected and enriched about me.
Usually behind my back such that I was never aware of that data. Of
course, data that I have entered into a site (my cat photos) is also
covered by GDPR, but it's not the main point.

Separately the EU also has a MyData initiative, which is concerned
with my right to extract and move my data from one service provider to
another. This is similar in spirit to the CAL. This initiative is more
about growing an ecosystem of tools and practices, and the legal basis
does come from the GDPR. (And before GDPR came from other pre-existing
EU legislation.)


> All of this is not to argue for or against CAL as an OSD-compliant
> license, though it feels like the first (I could be wrong) to bring the
> data created or managed by the application into the license itself.

It sure is the first. This was a major discussion item in the review process.

> That
> seems to veer very much on limitations on use, but more importantly - data
> is a complex subject, and at times will defy the kind of predictability
> and automated-conformance-checking that open source licenses have long
> offered their users. Perhaps it's not OSI's role to argue that an approved
> license should not be used, but this license will add to the compliance
> burden for end users, no matter how much this license authors believe
> their obligations are a strict subset.

It certainly does introduce a new aspect licensees must take into
account. Even if in some jurisdictions it may have little practical
consequence, if the same obligation existed by law anyway, it's still
something lawyers need to analyze and keep in mind.

henrik
-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7