There has been a lot of noise on this list recently. Bumping this thread to give anyone who wishes a chance to comment.
Thanks, Van On Thu, Aug 8, 2019 at 4:18 PM VanL <van.lindb...@gmail.com> wrote: > 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
