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

[Ian Kelling]

VanL <van.lindberg at gmail.com> writes:

> Hello Ian,
>
> Thanks for chiming in. A couple responses:
>
> On Thu, Feb 13, 2020 at 8:50 AM Ian Kelling <ian at iankelling.org> wrote:
>
>>
>> What is providing a service?
>
>
> Providing a service is defined in terms of communicating the Work to
> another person - the essential human-to-human communication. It is
> encompassed in Section 4:
>
> "Exercis[ing] any permission granted by this License, such that the Work,
> or any part, aspect, or element of the Work, is distributed, communicated,
> made available, or made perceptible to a non-Affiliate third party (a
> “Recipient”), either via physical delivery or via a network connection to
> the Recipient."
>
> Speaking broadly as to Mailman, preferences and your specific messages
> would be considered User Data. But your worry about a bug preventing the
> use of Mailman is unfounded. The CAL doesn't specify the particular
> mechanism of compliance, so "bug-free" export code is not required.

Your argument seems to be that noncompliance is fine because the license
doesn't specify a compliance mechanism. But copyright law does, and it
doesn't make any sense to consider a license open source when
noncompliance is the natural result of free software development with
the best intentions.

Its not just about requiring bugs be fixed. As far as I can tell,
anytime you run a gratis service which stores user data (as defined by
CAL), its reasonable to expect that some people will input data then
request their user data (and CAL requires you give it to them), so to
reasonably expect that to be in compliance, it requires there to exist
software functionality to get that data, call it an export or
whatever. Almost all free software I know of that is used for gratis
services does not expose all user data it stores back to the user or
have that functionality, and thus would expect to be in noncompliance if
run under this license. I can list off 10 common ones easily, many are
in debian and developed with the best intentions around user data. Its
easy to say "software should do X", until you are the one writing it. It
just doesn't make sense to call a license open source if normal free
software can't comply because it lacks specific functionally.

Here's more concrete examples. For Mailman, you've said that CAL would
require users to be able to get their emails. Mailman stores email in a
raw form called mbox on the server. But mailman only exposes it to users
in html form which is derived from the raw form and missing some user
data, and can't work correctly with another instance of Mailman. Users
would need the mbox data. So if Mailman was under CAL, running it would
lead to noncompliance. And Mailman is a an extremely simple example. A
better one would be Mediawiki, or CiviCRM where admin users can define
and change fields at runtime, making things quite complicated, and
making the burden of tracking user data not just on the developer, but
also users. It could easily take months or years of full time
development to write functionality to export user data and track it. In
the rationale document by the OSI, it says compliance can already be
hard, so its fine that this is hard too. There has to be a limit
somewhere, and this should clearly be beyond it. For compliance with
existing licenses, you can follow a general principle of treating users
like fellow developers and there's essentially no burden, but this is
completely different.

To argue against this using the OSD: #3 says "allows modification", and
in the annotated version "For rapid evolution to happen, people need to
be able to experiment", it implies at least allowing any modification
that is typical in free software development, and implies allowing
running that software, and of course, being in compliance while doing
it. Well, the user data requirement does not allow that for software
meant to run as gratis internet services that stores user data. It would
be one thing if that was already a common practice in but its not at
all.


-- 
Ian Kelling
https://iankelling.org
Note, this my personal opinion, unrelated to my employer