Changelog: CAL Beta 2



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

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:
  1. 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]


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:

7.1 Affiliates
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.

1 Like

Does MPLv2? How about EPLv2? GPLv2?

Does OSD require the right to withhold private changes? Where is the boundary between private changes and changes that OSL and AGPL require be shared?

Why not just come out and say that the scope is whatever copyright reaches?

@VanL I’m doing an event in Berlin on Aug 29th. Are you “around Europe”? It would be great if you could present on CAL.

1 Like

GPLv2 does. I haven’t closely examined the others.

CAL Beta 1 did allow a private right of use, but people were confused about it because it was present through negative implication:

  1. You are granted [all these rights, which include rights for private use]…
  2. If you take [these specific actions], you must also comply with the following conditions…

As a lawyer, it is easy to see that if the grant in 1 is bigger than the scope of the specific actions in 2, then that space defines the private right of use. But most people are not used to logic like that.

As for “anything in copyright,” I actually don’t want it to be that broad. I really want to focus on types of distribution.

1 Like

@boris: I’m in the United States, with no current plans to go to Europe during that time.

1 Like

Where’s the explicit positive grant in GPLv2? I only see that permission by implication, in that other conditions are triggered at least partially be distribution.

Compare GPLv3, section 2, paragraph 2, sentence 1:

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

OK, thanks for letting me know! I’ll be looking to run this style of event in Canada/US, but for this first version I don’t have enough of a budget for transcontinental flights. Am following CAL with interest :slight_smile:

1 Like

Section 0: “The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).”

Nothing explicit about changes.