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

[Josh Berkus]

On 8/22/19 1:13 PM, Bruce Perens via License-review 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.
> 
> In this case the party may actually have right to that data, having
> created it themselves. This, however, is a distraction from the main
> point, which is the 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, or the old BitMover
> license which required that the running program communicate a public log
> of the program run to a specific BitMover log server.

This is a "slippery slope" argument, and as such a fallacy.

One of the key purposes of open source software -- particularly copyleft
-- is to preserve user and downstream developer freedom.  In many kinds
of software, being able to effectively use that software independent of
the original vendor requires not just access to the source code bits,
but access to the data stored by the software as well.  As such, this
kind of requirement to distribute the data on the same terms as the
software is a natural, and probably inevitable, extension of copyleft
principles.

As an example, imagine that I have a geodata processing program, which I
support by running a hosted version, and all user data is PK-encrypted
using a key only I control.  If the software is under the GPL (because
it depends on, say, PostGIS), the user still doesn't have the freedom to
run the software themselves unless they are willing to recreate all of
their data.  The CAL would protect user freedom in this case.

> 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.

Calling this an OSD6 violation is a huge stretch.  By that argument, all
copyleft licenses -- in fact, every license except BSD and MIT -- would
violate OSD#6 because it restricts proprietary software companies.
Heck, even the BSD license could be said to restrict plaintiff's
attorneys, if you want to make enough of a case of it.

While it is not the OSI's job to challenge Amazon's business model, it
is not our job to protect it either.

> 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. The submitted license, however, applies terms to
> this naive user, who will potentially need a lawyer to explain to her
> what data to distribute and what can be kept, and a programmer to
> actually extract the data.

So if the CAL only applied to *modified* versions of the original
software, you would have no objections under these terms?

-- 
Josh Berkus