[License-discuss] For Public Comment: The Cryptographic Autonomy License

[VanL]

Hi Henrik,

Thanks for the commentary!

On Sat, Mar 16, 2019 at 2:47 PM Henrik Ingo <henrik.ingo at avoinelama.fi>
wrote:

>
> *About the main goal of this proposal, User Data:*
>
> It immediately stands out that this license also grants rights to third
> parties. This is also novel, isn't it? Potential OSD issues come to mind if
> this is seen as analogous to "you must also kill your cat" or "you must
> also pay a fee to the MPEG-LA".
>

There are two slightly separate issues here that should be distinguished.

- Granting rights to third parties
The CAL *does* grant rights to third parties, but only as intended third
party beneficiaries (similar to NASA-1.3) who have the right to request
copies of the Source Code and their own User Data. Other than this specific
right to enforce, third parties are not the subject of any grants.

- Protection of User Data
The protection of User Data portion is a limitation on the grant to the
licensee, not a grant of rights to a third party. It is similar in
structure although broader in intent than the GPLv3's anti-Tivoization
clause: You may not use the Work to deny these specific freedoms to your
Users.


> But after sleeping on it, I do agree that there will exist third parties
> who have such GDPR rights to their User Data, without being users nor
> Licensees of the licensed work.
>

It seems likely, though, that anyone for whom a licensee is holding User
Data will be a Recipient, and thus someone who should receive Access to
Source Code as well as their own User Data.

The GDPR angle is *similar*, but don't overread it. The GDPR is about
privacy first, and data only second. The CAL is about User Autonomy, which
is the four freedoms of free software plus user data.



> The Lawful Interest concept seems like an odd entry point. As an EU
> citizen the GDPR grants me rights wrt my User Data, but a US citizen
> doesn't have such rights (at least not for data that you have stored in a
> US based company). Does this license grant me more rights than a US
> citizen? Or was the intent to grant GDPR-like rights globally? I don't read
> the latter.
>

See the comment above about the GDPR. The intent is not to enforce
compliance with the GDPR or extend it globally. Rather, it is about
preventing the use of the work to deny freedoms to Recipients of the Work.
It just so happens that the GPDR also has some elements that talk about
that, so the CAL was drafted to talk about it consistently with those
specific provisions. But the CAL does nothing relative to the GPDR as a
whole.

As for the specific "lawful interest," the motivating use case for that was
something like ebooks. I may have a right to possess a particular copy of
an ebook, even if I don't "own" the ebook (as per current US law). We don't
want the phrase "the _____ is licensed, not sold" to be effective in
denying someone access to something that they have a legal right to possess.

The definition of "User Data" could easily be misunderstood too narrowly as
> data I have actively input into the system, such as via a form. I'm not so
> familiar with the GDPR that I could propose better wording, sorry. But for
> example, data Google collected about me, including from news sites, etc, is
> surely covered by the GDPR. Also, I expect that GDPR also includes data
> about me that the system has developed internally? (E.g. even if I had
> never input such a fact into Facebook, and Facebook never output it, some
> ML algorithm has probably inferred that I'm married to another FB user
> called Sanna Ingo. This is User Data in European law.)
>

Again, don't overread the comparison. All that you are talking about
GDPR-wise has to do with privacy, and not about User Data as contemplated
in the CAL. (If the law in the EU grants users ownership interests in their
tracking data, then it could be covered, but it would be because the law
made them an owner, not because it was *about* them.)



> Btw, it's probably an oversight that the Licensee is not themselves a
> beneficiary of the User Data rights. I would expect to see similar anti-DRM
> measures as in GPLv3 to ensure that I can access both software and data on
> a device I bought that has software with this license.
>

Those are present - see 2.3(d) and (e), which are directly analogous to
provisions in the GPLv3.


> *About Public Performance*
>
> First:
>
> First reaction is like "Convey" in GPLv3: Why can't you use existing
> industry terminology instead of inventing new stuff that has no established
> precedent? I would much prefer simple language like "if SaaS, you must ...".
>

I see your point, but I'm coming at it from a different angle: "public
performance" *is* existing industry terminology - just in the legal
industry. This is very closely tied to the specific copyright and patent
grants, not to types of businesses or types of uses. (Restricting based on
type of business or use would not be OSD compliant).



> If you hadn't introduced this as a network copyleft license, it would not
> at all be obvious from the language. More specifically, "interface" can
> mean a lot of things: 1) a GUI, 2) a REST APi, 3) a traditional API as in
> Oracle vs Google.
>

Interface in the CAL means any or all of those, to the extent that they are
protectable via IP law.


> 1) seems like something for which Public Performance can apply. I can see
> the GUI on my screen, much like a movie.
> 3) it's not at all obvious that you want or don't want this to be covered.
> Note especially that such an "interface" may be copyrighted even if it
> contains zero code from the licensed work. You'd probably have to spend a
> few more words to explain what is affected by this license and how.
>
> Second, about Public Performance:
>
> I don't think this approach will work. You want to create a license with
> conditions for SaaS usage. But Public Performance is much broader than
> that. [snip examples]
>

Public performance can be broader than SaaS, it is true.  (I think you are
slightly too focused on the GUI aspect, but we can go with it because that
could be an aspect of public performance.) The difference between the CAL
and your collecting societies is that the collecting societies have
licenses that say "pay us or it is copyright infringement." You have to
engage with them in order to avoid infringement.

In contrast, the CAL, like other reciprocal licenses, is actually kind of a
"pass forward" license: as long as you make the Source Code and applicable
User Data available to Recipients, no interaction with the licensor is
needed.

So, looking at your GUI examples, a link in the GUI that gave people Access
to the Source Code would prevent infringement in all the situations you
identify. In this way, it isn't too different from the AGPL.

*Smaller comments:*
>
> I basically fail to understand what you mean by "Compatible Open Source
> License". If it's "any OSI approved Open Source license", then why not say
> so? If you mean BSD and Apache style licenses, then compatibility is a
> property of those, and mentioning this seems redundant? In any case, saying
> "Open Source" without "OSI approved" feels undefined to me. A lot of people
> claim all kinds of licenses as open source.
>

Look at the definitions: "Open Source License" means a license approved by
both the OSI and FSF.


> You'd better spell out General Data Protection Regulation and also add "of
> the European Union".
>

Good idea, I'll add that.


>
> 2.4: Rather than an optional exception, I'd much prefer that you develop 2
> or more separate licenses with clearly different names like is the case
> with LGPL, GPĹ and AGPL. Now if I see that some software is licensed under
> CAL, such as in a github label or search, I won't be able to tell what I
> can do with that software.
>

I see your point, but in practice I think that they will be labeled
independently (such as GPL-with-classpath is labeled separately from GPL).



> Didn't read your entire blog post, but since this license clearly arises
> out of EU context, at least some EU countries (maybe all?) don't register
> copyrights as you can in the US.
>

That may be true.


>
> Good night :-)
>

Thanks!

Van
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190317/35c01136/attachment-0001.html>