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:
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
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  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:
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. 
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:
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.
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.
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:
An “Affiliate” means any other entity that, directly or indirectly
through one or more intermediaries, controls, is controlled by,
or is under common control with, the Licensee. Employees of a
Licensee are also Affiliates, as are contractors who are exclusively
providing services to Licensee.