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

[Pamela Chestek]

Just a head's up that I don't think the Board can give a decision on
this license until after its face-to-face board meeting scheduled for
November 12-13.

Pam

Pamela Chestek
Chair, License Review Committee
Open Source Initiative

On 8/22/2019 5:12 PM, VanL wrote:
> 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
> <mailto: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
>
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190823/5c64053b/attachment-0001.html>