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

[VanL]

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.lindberg at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190813/801ce8f8/attachment-0001.html>