[License-discuss] For Discussion: Cryptographic Autonomy License (CAL) Beta 2

[VanL]

Subject: Cryptographic Autonomy License Beta 2

Thanks again to the license-review committee for the response to Beta 1. I
have reworked the CAL to remove the reasons for rejection and to address
some of the concerns that led into the “further discussion” items. I have
also privately discussed these with various people and received positive
feedback, and so am posting CAL beta 2 for discussion.

The link to CAL Beta 2 is here:
https://docs.google.com/document/d/1PFX7PtPoSbSe7cC7BEoh44OjbWN91-IQOyGzO5Zr-1Q/edit?usp=sharing

I debated providing a redline, but this is a significant reworking of the
license – dealing not just with the exact issues raised, but also working
to simplify the language as much as possible. The result was such that a
redline would be so noisy as to be uninformative. However, for those who
are interested, the remainder of this message is a changelog describing the
changes made in response to the discussions previously held.

Thanks,

Van

====

Changelog:

Overall:

1. Use of Legal language

CAL Beta 1 was criticized for its use of legal terms, idioms, and
constructions. These criticisms both focused on interpretability for
developers as well as the lack of a few explicit positive grants, which
were present in CAL Beta 1 through negative implication. The entire license
has been reworked with an eye toward reducing complexity.

2. Private right of use

One criticism of CAL Beta 1 was that it did not include an explicit
positive grant of a private right of use. (It was present, but not
explicit.) CAL Beta 2 has been updated to include a positive grant for
private use, as well as to describe its scope. As long as the use is truly
"private", there is an unlimited right to use CAL-licensed software. See
Section 1:

> 1. Purpose

> This License gives You unlimited permission to use and modify the

> software to which it applies (the “Work”), either as-is or in

> modified form, for Your private purposes, while protecting the

> owners and contributors to the software from liability. If any

> non-affiliated third party receives any part, aspect, or element

> of the Work from You, this License also requires that You provide

>that third party all the permissions and materials needed to

> independently use and modify the Work without a loss of data or

> capability.

As with other licenses, obligations are incurred only when a third party
becomes involved.

3.    Specific provision for GDPR

Comment: This provision was always an interpretive aid, not a fundamental
part of the license. I have removed it.

4.    The mechanism of “public performance”

Comment: While I still believe that the use of the term "public
performance" was fine, this mechanism has been reworked significantly to
remove this concern. Specifically:

- There was some question as to whether any sort of "public performance" -
regardless of the use of the specific term of art - could be a trigger for
applying copyleft obligations. Bruce Perens advocated that some sort of
"public performance" is acceptable [1] and noted that it has been an
accepted part of other licenses. To address the concern, the mechanism was
reworked to focus on the transfer of "any part, aspect, or element of the
Work" to a third party. See CAL Section 4:

> 4. Conditions

> If You exercise any permission granted by this License, such that the
Work,

> or any part, aspect, or element of the Work, is distributed, communicated,

> displayed, made available, or made perceptible to a non-Affiliate third
party

>  (a “Recipient”), either directly or via a network connection to the
Recipient,

> You must comply with the following conditions: [...]

This parallels existing licenses where the transfer of the *whole* work is
used as the trigger for copyleft obligations. The concept was proposed
on-list and did not attract debate. [2]

[1]
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-June/004261.html

[2]
http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-July/020715.html

5. Scope of copyleft.

- Beta 2 has been reworked to focus on the transfer of "licenseable" parts
of the Work. This limits the application to what can be properly reached by
a license, regardless of what the scope of copyleft turns out to be. See
Section 2.1 of CAL Beta 2:

> 2.1 Application

> The terms of this License apply to the Work as you receive it from
Licensor,

> as well as to any modifications, elaborations, or implementations created
by

> You that contain any licenseable portion of the Work (a “Modified Work”).

> Unless specified, any reference to the Work also applies to a Modified
Work.


6. At what point the licensor can oblige licensee behavior.

In CAL Beta 2 (quoted above relative to the “public performance”
objection), I have tried to recast this as the “communication” of some
part, aspect, or element of the Work. This aligns the trigger
philosophically with previous work, while still retaining the network
aspect that we want.

7. A license that requires data portability.

As described in various email threads, the point of the data provision is
to enable Recipients to make use of the software with their own data. This
was not evident to some participants in the discussion, who incorrectly
referred to "licensing" of data.

I refocused the discussion and language in the CAL to focus on the ability
of Recipients to use the software without any loss of functionality or
data. See Section 4.3:

> 4.3 Maintain User Autonomy

> In addition to providing each Recipient the opportunity to have

> Access to the Source Code, You cannot use the permissions given

> under this License to interfere with a Recipient’s ability to

> fully use an independent copy of the Work generated from the

> Source Code You provide with the Recipient’s own User Data.

This should be clearer in its application and intent, by noting that the
freedom being preserved is specific to a Recipient's ability to
independently run the Work as received from the Licensee.

8. Definitions

While the use of a “Definitions” section is typical in a license or other
legal document, its use in the CAL was criticized. Instead, some necessary
definitions have been placed in-line and the standalone section was removed.

9. “Affiliates”

While CAL Beta 1 already included the concept of “Affiliates,” CAL Beta 2
slightly expands the notion so as to deal with a common occurrence:
independent contractors dedicated to a single employer. These dedicated
contractors are also affiliates under Beta 2. See Section 7.1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190808/dfa5cc2d/attachment-0001.html>