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

Josh Berkus josh at berkus.org
Fri Feb 14 22:47:00 UTC 2020

On 2/13/20 9:05 AM, Christopher Lemmer Webber wrote:

>  - Is there a possibility of forced disclosure of private data, in terms
>    of user data or keys, in terms of a wider source distribution
>    requirement or via the introduction of the user/recipient data (and
>    cryptographic material) disclosure for equivalent use?

Since the data is disclosed only to its original owner, no.  Could an
authoritarian government force a user to request data so they can
intercept it? Sure.  But that's not something we can prevent with a license.

>  - Is the requirement to be able to give user/recipient data an onerous
>    one?  What are the implications for data retention?  What about
>    accidental data loss?  If software does not make extracting such
>    information easy, is the liability on the software developers, or on
>    the operator of a service?

All of these questions were already discussed extensively on this list,
and some of them resulted in revisions that went into v4.

>> If you believe that the license is not appropriate for certain types
>> of uses or certain types of software architecture, can you explain how
>> that violates the OSD?
> Yes, in addition to the above three bulleted concerns, I have indicated
> that I think a peer-to-peer actor model environment would be especially
> difficult to comply with this license for, and may result in accidental
> weakening of its security.  (Again, I do not think this is Van's intent,
> I think it is a bug, but I'm not sure if it's fixable.)  The phrasing
> you used "not appropriate for certain types of uses or certain types of
> software architecture", is arguably raised in OSD sections 6 and 10 ("no
> discrimination against fields of endeavor" (though this would arise
> implicitly) or "License Must Be Technology-Neutral" (as in, is this
> something that is easier to deal with in client-server architectures but
> not as possible in ocap actor model architectures).

That is not what either OSD6 or 10 mean.  The fact that a license is
useless in certain contexts does not make it an invalid license.  I
challenge you to find any of our approved licenses that is useful to
everyone everywhere under every circumstance.

> *However*, I think we are hitting something that goes beyond mere OSD
> compliance.
> OSI publishes a list of licenses.  These licenses appear as
> recommendations from the OSI.  The OSD is a useful document, though a
> question is: is the OSI's job merely to be a technical filter that
> issues a pass/fail for OSD compliance?  There are many things that the
> OSD does not discuss, such as implications of privacy (though I have
> discussed others, such as onerousness of capbility to comply with terms
> of the license).

But we do discuss those.  And we did discuss them for this license.

>  For example (and leaving aside whether or not this is
> what happens in the CAL, I am discussing in the more general), if we can
> determine that a license is written in such a way that it can be used to
> coerce via legal means a violation of a person's privacy, but it
> technically checked all the boxes on the OSD, should the OSI still
> publish that license on its list?

This feels like a strawman argument.  Are you contending that the CALv4
could be used in this way, despite efforts to prevent it via revisions?
If so, please explain.

> I would be extremely disturbed if the answer to that question is "yes".
> I think that the OSD is a good metric, but as others have indicated, it
> might be incomplete in assessing how user freedom is impacted by a
> license.  Shouldn't our first priority be to find serious user freedom
> violations in the construction of a license and then see how that
> matches up with the OSD?  After all, OSI refers to its license list as
> "approved" not as "compliant".

The entire point of the OSD is to provide us with a working definition
of what "user freedom" consists of. While it is certainly incomplete,
it's the best we currently have. What metric of "user freedom" would we
consult *first* before the the OSD?

Overall, it sounds like you don't have specific objections to the actual
text of this license, but do have discussion you want to take to

Josh Berkus

More information about the License-review mailing list