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

[VanL]

These are good concerns. For completeness, I'll respond:

On Thu, Feb 13, 2020 at 11:06 AM Christopher Lemmer Webber <
cwebber at dustycloud.org> 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?
>

No. The CAL only requires turning over data to which a person has an
existing legal right. By definition, this is not "forced disclosure" - the
legal basis already exists.



>   - I think that requirements for documentation and configuration
>    information for "use" is a bit too broad; I think "execute" is a
>    better term.  This one is an easy fix.
>

I don't think there ends up being a meaningful difference between "use" and
"execute," especially given the context of providing only the
"information *reasonably
necessary* for the Recipient to independently compile and use the Source
Code and to have full access to the functionality contained in the Work."


>
>   - Is the requirement to be able to give user/recipient data an onerous
>    one?


The difficulty or non-difficulty of providing data has been discussed on
this list in the context of the CAL. In certain circumstances, providing
source code is also onerous, but that does not make copyleft licenses any
less OSD-compliant.


>    What are the implications for data retention?  What about
>    accidental data loss?


The CAL does not penalize accidental data loss, nor does it require a
particular data retention policy. It just says that someone providing
services must provide the "Recipient’s User Data *in your possession*, *to
the extent that such User Data is available to You* for use in conjunction
with the Work."


> If software does not make extracting such
>    information easy, is the liability on the software developers, or on
>    the operator of a service?
>

The liability is on the person providing the service, not the developers -
just as with other copyleft licenses.




> > 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 ... [the issue 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).


The fact that an author may choose an architecture that makes compliance
more difficult is not discrimination against a field of endeavor nor a
requirement that particular technologies be used (or not used). Even if
compliance may be "difficult," that is not discrimination. For example, a
person can also engage in development practices that make full disclosure
of the source code difficult; that does not mean that those practices are
outlawed by the license.


But I would like to most strongly disagree with the following:

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

The CAL does not do this. It *only* requires the disclosure of the User's
own data, to which they have an existing legal claim. Giving someone *their
own data* is never a violation of that person's privacy!

Thanks,
Van
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200213/24118322/attachment.html>