[License-review] For approval: The Cryptographic Autonomy License (Beta 4)
van.lindberg at gmail.com
Tue Feb 11 13:57:57 UTC 2020
I look forward to responding to your other concerns. But to respond above:
There are only two substantive locations where cryptographic keys are
required. In the definition of source code, section 4.1:
The “Source Code” of the Work means the form of the Work preferred for
making modifications, including any comments, configuration information,
documentation, help materials, installation instructions, cryptographic
seeds or keys, and any information reasonably necessary for the Recipient
to independently compile and use the Source Code and to have full access to
the functionality contained in the Work.
This is essentially equivalent to the "complete corresponding source" of
the GPL3. Quoting specifically from the GPL3: "'Installation Information'
for a User Product means any methods, procedures,* authorization keys,* or
other information required to install and execute modified versions of a
covered work in that User Product from a modified version of its
So this first element is tied to the ability to "independently compile and
use the Source Code and have full access to the functionality contained in
the Work" -- i.e., no Tivoization.
The second substantive place where cryptographic keys are mentioned is in
the user autonomy provisions, specifically 4.2.2:
You may not, by the use of cryptographic methods applied to anything
provided to the Recipient, by possession or control of cryptographic keys,
seeds, or hashes, by other technological protection measures, or by any
other method, limit a Recipient's ability to access any functionality
present in the Recipient's independent copy of the Work, or deny a
Recipient full control of the Recipient's User Data.
This is where the distinction arises. An operator must not use any
technical measure, including the use of cryptographic protocols, to "limit
a Recipient's ability to access any functionality" or to "deny a Recipient
full control of the Recipient's User Data." However, securely transmitting
information to the Recipient (e.g. using TLS) does nothing to "limit a
Recipient's ability to access any functionality" or "deny a Recipient full
control of the Recipient's User Data."
Thus, the information that needs to be provided, including cryptographic
keys, is limited to that information that would prevent compilation or
access to functionality, or would deny the Recipient full control over the
Recipient's own user data. The normal system uses of cryptography are not
implicated. Nor are the uses of cryptography in a distributed systems for
addressing or authentication, excepting the use of a user's keys to
validate an agent's actions (which belong to the user anyway).
On Tue, Feb 11, 2020 at 6:54 AM Christopher Lemmer Webber <
cwebber at dustycloud.org> wrote:
> Where in the license is this distinction made?
> At any rate, I'm not convinced such a distinction exists. I
> increasingly work with peer to peer systems where the distinction
> between "user" and "system" and even "client" and "server" no longer
> exist. I don't believe it is possible to make a sound distinction, and
> at any rate I don't see one in the license. But perhaps I am missing
> Regardless, these are not my only concerns. I will write them up today.
> VanL writes:
> > I definitely want to hear any concerns... but I will also note that the
> > crypto portions of the license were reviewed by a number of people who
> > expert in that space and they approved.
> > My best guess is that you are concerned that this requires the disclosure
> > of user-specific keys, and so you think that means that traditional
> > which relies on a private key or private cert would need to be disclosed.
> > This is incorrect.
> > They difference is between user keys and system keys. User keys form the
> > basis of a user's identity and control over computation or data. Under
> > license, they must be controlled by the user alone.
> > System keys, however, used for things like TLS and SSH, are not User Data
> > within the scope of that term. They may be kept confidential and secure.
> > Thanks,
> > Van
> > __________________________
> > Van Lindberg
> > van.lindberg at gmail.com
> > m: 214.364.7985
> > On Mon, Feb 10, 2020, 7:17 PM Christopher Lemmer Webber <
> > cwebber at dustycloud.org> wrote:
> >> Josh Berkus writes:
> >> > On 1/7/20 11:00 AM, Pamela Chestek wrote:
> >> >> The discussion is still active so it will not be considered at the
> >> >> Board meeting, which is this Friday. The soonest would be the
> >> >> Board meeting.
> >> >
> >> > So, it's been a month since there's been any discussion about the CAL.
> >> > Pamela, can we take a poll of how people feel about the license?
> >> > Pass/Reject/MoreDiscussionNeeded?
> >> I'm not very sure if I'm in the right place to state this, but I'd say
> >> "Reject" or at least "MoreDiscussionNeeded". I believe there are very
> >> serious problems in the license that will (ironically, due to its name)
> >> prevent the ability to have safely private networks on cryptographically
> >> secure peer to peer networks. I believe I can demonstrate the privacy
> >> risks, and spend most of tomorrow doing a detailed and longer writeup
> >> about my concerns. Note that I don't think it's any malicious intention
> >> of the author to introduce these problems; I think Van is acting in good
> >> faith and interest there, but nonetheless I think the concerns exist and
> >> are very grave, if I understand correctly.
> >> If I am going to air them before the board meeting, am I doing it in the
> >> right place here? If so, I will follow up on the thread here tomorrow.
> >> - Chris
> >> PS: I'm sorry I haven't aired my very serious concerns earlier. Van
> >> asked me personally to review at last year's CopyleftConf and I never
> >> got around to writing up my thoughts. I regret that, and wish I had
> >> done so sooner... maybe I could have prevented a lot of trouble.
> >> Nonetheless I think it's important that I write them up now; I'm
> >> guessing we're in the "speak now or forever hold your peace" moment
> >> though, so I'm trying to articulate my concerns before it's too late.
> >> _______________________________________________
> >> License-review mailing list
> >> License-review at lists.opensource.org
> > _______________________________________________
> > License-review mailing list
> > License-review at lists.opensource.org
> License-review mailing list
> License-review at lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-review