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

[VanL]

Note that before final approval I may change the acceptable delay to 30,
45, or 60 days based upon broader feedback, but would not expect to make
any other change. (BTW, I would welcome feedback on that aspect on the
license-discuss list.)

Thanks,
Van

On Thu, Aug 22, 2019 at 4:10 PM VanL <van.lindberg at gmail.com> wrote:

> I am withdrawing Beta 2 and substituting Beta 3. The only difference
> between the two is the addition of new provision 4.1.3:
>
> #### 4.1.3. Coordinated Disclosure of Security Vulnerabilities
> You may delay providing the Source Code corresponding to a particular
> modification of the Work for up to ninety (90) days (the “Embargo Period”)
> if: a) the modification is intended to address a newly-identified
> vulnerability or a security flaw in the Work, b) disclosure of the
> vulnerability or security flaw before the end of the Embargo Period would
> put the data, identity, or autonomy of one or more Recipients of the Work
> at significant risk, c) You are participating in a coordinated disclosure
> of the vulnerability or security flaw with one or more additional
> Licensees, and d) the Source Code pertaining to the modification is
> provided to all Recipients at the end of the Embargo Period.
>
> All other discussion regarding CAL Beta 2 should apply. The following is
> copied from the Beta 2 submission:
>
> *Rationale:* The CAL is a new network copyleft license especially
> applicable for distributed systems. It is designed to be as protective as
> possible of downstream recipients of the software, providing them all that
> they need to create and use an independent copy of a licensed work without
> losing functionality or data.
>
> *Distinguish:* The CAL is most similar to the AGPL, and will have a
> similar scope of action in most cases. However, the CAL has provisions that
> require that operators provide recipients of the software with a copy of
> their user data, enhancing their ability to independently use the software.
> The CAL also allows the creation of mixed "Larger Works," provides for
> affiliate use, and does not specify a mechanism by which notice is given to
> recipients.
>
> *Legal Analysis*: The CAL was drafted by legal counsel. Previous
> discussions have outlined many aspects of the legal analysis.
>
> Following the rejection of CAL Beta 1, this version has been reworked to
> remove the reasons for rejection and to address the concerns that led into
> the “further discussion” items. In particular, I worked on laying out the
> scope of the private right of use, clarifying when the conditions apply,
> and avoiding constructions that may result in adverse policy inferences. I
> also simplified the language to enhance interpretability.
>
> The most controversial aspect of the CAL remains: it requires someone who
> is communicating the software (or a part of the software) to a "Recipient"
> (a non-affiliated third party), to also allow that Recipient access to the
> Recipient's own user data. To show how this fits into the broader concept
> of software freedom, the policy associated with this requirement is also
> laid out: to allow a Recipient to fully use an independent copy of the Work
> generated from the Source Code provided with the Recipient’s own User Data.
>
> *Previous Discussion*: For those only following this list, I also
> provided a changelog on license-discuss [1] which prompted some discussion.
> From that discussion, I'll note that Russell McOrmond is on record as
> believing that the CAL is part of a class of licenses - which includes the
> AGPL, and the GPL as applied) is not compliant with the OSD. Bruce Perens
> is on record as believing the any requirements that an operator provide
> user data is a violation of "no field of use" restriction in OSD 6. Bruce
> is also on record as believing that the identification of the private right
> of use is a field of use restriction.
>
>
> [1]
> http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-August/020937.html
>
> A copy of the license (now beta 3) in markdown-formatted plaintext is
> attached.
>
> Thanks,
> Van
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190822/81d9387b/attachment.html>