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

[Josh Berkus]

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

-- 
Josh Berkus