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.
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
