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

Wed Aug 14 13:01:41 UTC 2019

I was just reading the new version wondering whether you won with "defeat
by exhaustion". But seems like you were able to get some attention today.
Below are my own thoughts, not a response to anyone else but you.

Overall this is definitively an improvement. For example, the anti-DRM
provision is not only simpler, but as a result can probably apply more
broadly to the use cases I felt were excluded by previous version.

Data autonomy

Wrt the discussion of not encumbering mere use / private use with any
obligations, I notice there's first of all a very explicit carve out for
"your private purposes". Also the first paragraph of 4.2 is in the same
spirit I think. But I think 4.2.1 still falls a bit short of drawing the
right boundary. I think the reasonable boundary is: 1) If the software you
received includes functionality for the user to download his data, you
cannot remove or encumber this functionality. 2) When you add functionality
that causes more data to be stored, it must be available through the same
or similar functionality.

What I think is unreasonable but still allowed by this language is to trap
operator users with the following submarine: I develop SOFTWARE and release
it under CAL. SOFTWARE is designed to store user input, but doesn't allow
to download it as required by 4.2.1. You download SOFTWARE and provide
access to 3rd parties. When you inevitably fail to provide some recipient
with data, I can sue you for copyright infringement.

Assuming that you are open to make such modification, we would arrive at a
license that could be considered to be OSD compliant. The remaining
question of course is whether the idea of "copyleft for data" can be OSD
compliant in the first place? The way I have suggested to implement the
license requirement above, it no longer burdens the operator user with any
unreasonable obligation, since the functionality to get your data is
automatic in the software itself. Otoh it *does* restrict the operator user
from modifying or removing some code - seemingly incompatible with the very
idea of open source.

Then again, the OSI has approved the badgeware CPAL-1.0 license and I think
the restriction to provide a user his own data is 100 times more justified.
(This is also analogous with the GPL requirements that you cannot omit
build scripts or DRM keys, even if you otherwise can remove anything freely
from the software.) As a result, I'm starting to come down on the side that
- assuming a good formulation is found - the idea of copyleft for data can
be compliant with OSD and software freedom.

API copyleft

You no longer make any references to "public performance", so the issue of
pioneering a new evil copyright power is avoided. Similarly there doesn't
appear to be a direct claim on API copyright.

*"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, made available, or made perceptible to a non-Affiliate third
party (a “Recipient”), either via physical delivery or via a network
connection to the Recipient, You must comply with the following conditions"*

There is no question that a software license can claim rights in all of the
above things. Also, since you are granting these rights, there's no OSD
issue as such.

While this is narrower than the previous version, I think my practical
questions still remain: If the work is "made perceptible" via a video
screen in the park, do the photons emitted by the screen still fall within
"physical delivery"?

Rather than nit picking on that, let's go to the real issue: Since you
didn't say anything about APIs or interfaces, it seems to me words like
"aspect", "perceptible" and maybe "elaborate" remain in the license because
the goal of your client clearly still remains to assert copyleft on an
independent work implementing a compatible API. Clearly such an idea is
directly against OSD#9. (Probably also EU law?)

Making the license even less vague on this issue doesn't help. This is
clearly an example of a case where a license must either be very clear or
at least the license steward must be trusted in the community not to
interpret any imperfections or complexities against the open source
community's interests. Speaking as a former employee of the MySQL sales
team, I hope my words carry some weight. To make progress with CAL, I think
you will need to clearly reject the idea of API copyright both in the
license text and your eventual submission.

Minor

I think 5.3 would benefit from following clarification: " In the event of
termination due to litigation initiated by You,"

henrik

On Tue, Aug 13, 2019 at 7:41 PM VanL <van.lindberg at gmail.com> wrote:

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

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190814/ffe9476e/attachment-0001.html>