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

[Lukas Atkinson]

On Thu, 22 Aug 2019 at 22:14, Bruce Perens via License-review <
license-review at lists.opensource.org> wrote:

> The license attaches terms to the data processed through the program,
> rather than the software of the program itself. These terms compel a
> specific action regarding the data, that the licensee surrender a copy of
> that data to a specific third party.
>
> [This is an] attempt to expand the copyleft paradigm to include *the data
> processed by the program,* such that the licensee must disclose that data
> or perform other mandated actions upon it. While this particular submission
> places a very narrow limit on what data must be disclosed: giving it back
> to "it's owner", it's obvious that it could be followed by licenses
> regarding a more significant license term to be placed on the data
> processed, for example the one that Kyle Mitchell submitted last year,
> which required that data simply processed by the program be placed under an
> Open Source license, […]
>
> So, I am really most concerned with the precedent that this license would
> establish, which would lead to more severe terms being applied to the data
> processed. And thus I suggest that OSI not accept any such terms at all.
>

I don't buy the slippery slope argument. Importantly, the CAL does not
encumber the data. It does not require any license for the data. It does
not restrict how data may be processed. It merely compels a software
operator to perform certain actions regarding the data, and only if they
are able to do so.


> Regarding how to reject the license within the tems of the OSD: the terms
> proposed work out to be a restriction on use. One can not use the program
> to sequester the customer's data. Such sequestration is a strategy in the
> implementation of software-as-a-service companies - I'm not saying that
> it's nice, just that they do it. Thus, I believe this runs awry of OSD#6, *No
> Discrimination Against Fields of Endeavor. *#6 has generally been found
> by the OSI board to prohibit usage restrictions.
>

I agree that the CAL restricts use in a very small way, but think that this
restriction is appropriate, similar to how requiring source disclosure is
considered appropriate in copyleft licenses.

There is no discrimination against *fields* of endeavor here. SaaS as a
field does not require user data to be locked up. It is perfectly possible
to do SaaS and to comply with this term of the license – that's very close
to what any GDPR-compliant SaaS operator will already be doing.


> OSI has affirmed that it supports Software Freedom, of the specific form
> defined by the Free Software Foundation and OSI's member the Software
> Freedom Conservancy. Thus, the Four Freedoms of the Free Software
> Foundation apply, and Freedom 0 is more specific to usage restrictions: *The
> freedom to run the program as you wish, for any purpose**. *In this case,
> the proposed terms withhold the freedom to run the program while
> sequestering the information processed.
>

I interpret Freedom 0 to be very concerned about the end user of the
software, and think that this viewpoint is consistent with the history of
the software freedom movement. VanL has given a good rationale that true
end user freedom doesn't just require access to the source, but also access
to the data. As the end user's freedom so crucially depends on access to
their data, I think that on balance, a software operator's freedom must
take the backseat here.


> There are other problems with practical use of the license. Open Source
> software is intended for everyone to use, not just everyone who can afford
> an attorney and a programming staff. It thus should be the case that the
> "naive user", who simply runs Open Source software and does not modify it,
> should *not *need to read and understand the license, and certainly
> should not need a lawyer to tell them how to run the program in a compliant
> manner.
>

An end user is free to run the software for themselves or their affiliates
without restriction, and will certainly not have to consult a lawyer for
that. You are painting an overly dramatic picture here. In general, I also
find the CAL to be more comprehensible for lay persons than e.g. the GPLv3.

If anyone operates a service for other people to use, they already are
subject to so many legal obligations in their respective jurisdiction that
the CAL's provisions will really not matter that much. For example, CAL
compliance is trivial compared with GDPR compliance, and GDPR compliance is
not inherently difficult. I would assume that even in the US significant
legal issues around liability etc would exist for a service operator.

If compliance doesn't matter for some people, and isn't a noticeable burden
for the rest, and increases software freedom, is that provision really so
objectionable?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190822/4f46da92/attachment.html>