[License-review] For approval: The Cryptographic Autonomy License (Beta 4)

Thu Feb 13 02:26:50 UTC 2020

Hi Pam,

Chris can weigh in, but given his last response, I think the concern is
similar to ones that were previously raised, specifically:

What if the software architecture makes it difficult to identify or access
the user data?

and

What if there is not a built-in way to identify and export user data?

I think that the meta response is the same: the CAL does not and should not
define a particular method of compliance. That may mean that the CAL is not
appropriate for some uses, but that is in the control of the licensor.

Thanks,
Van

__________________________
Van Lindberg
van.lindberg at gmail.com
m: 214.364.7985

On Wed, Feb 12, 2020, 8:13 PM Pamela Chestek <pamela.chestek at opensource.org>
wrote:

> Hi Chris,
>
> I'm still in the dark. Can you explain what OSD is not met and where you
> find that in the license? If it's a meta-OSD problem, like forced
> disclosure of data that is not yours to have, can you explain it in
> layperson's terms? If you believe that the license is not appropriate
> for certain types of uses or certain types of software architecture, can
> you explain how that violates the OSD?
>
> Thanks,
> Pam
>
> Pamela Chestek
> Chair, License Review committee
> Open Source Initiative
>
> On 2/12/2020 5:48 PM, Christopher Lemmer Webber wrote:
> > Hi Simon,
> >
> > Thank you for your question.  I have done my best to give a more high
> > level series of questions in the last email I just sent in response to
> > Van:
> >
> >
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004675.html
> >
> > I hope I have done a better job of detailing a set of concerns that
> > don't require going into the CS weeds.
> >
> >
> > Simon Phipps writes:
> >
> >> Chris,
> >>
> >> Thanks for the engagement. For those of us who are not specialists in
> the
> >> computer science topics you're discussing, please can you summarise why
> you
> >> believe CAL does not satisfy the OSD, specifically citing the clauses
> >> involved?
> >>
> >> Thanks
> >>
> >> Simon
> >> (in-role)
> >>
> >> On Wed, Feb 12, 2020 at 12:08 AM Christopher Lemmer Webber <
> >> cwebber at dustycloud.org> wrote:
> >>
> >>> Hi Van,
> >>>
> >>> First of all, I have asked for review from a community I collaborate
> >>> with which actually works on cryptographic autonomy here:
> >>>
> >>>   https://groups.google.com/forum/#!topic/cap-talk/VE6nNhfwp_w
> >>>
> >>> The above thread outlines my concerns in detail.  It may be desirable
> >>> for me to bullet-point them in a follow-up email, but I'd encourage
> >>> reading that email.
> >>>
> >>> I will respond to some parts below.
> >>>
> >>> VanL writes:
> >>>
> >>>> 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
> >>>> Corresponding Source."
> >>>>
> >>>> 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.
> >>> I agree that it is similar to GPLv3 in this particular section, however
> >>> there are some key differences.  The GPLv3 appears to specify the
> >>> requirement to "install and execute".  This is not the same as the
> >>> requirement to provide a broader requirement for documentation for
> >>> "use".  Usage is significantly broader than mere execution... how much
> >>> documentation need there be?  Is it a violation to add a feature then
> >>> not document how to use it?  There is also a broader number of
> >>> requirements here, including the requirements for configuration
> >>> information.
> >>>
> >>> This isn't the primary part I am concerned about, but it does concern
> >>> me.  As I expressed in the email above to cap-talk (and in my Copyleft
> >>> Conference talk last year), I am *already* concerned about the
> >>> requirements that network copyleft introduces in the AGPL for a
> >>> circumstance where there is little distinction between code and data,
> >>> and thus private configuration information might be considered part of
> >>> the complete and corresponding work.  In my talk last year I was making
> >>> an argument that we could see emacs lisp as being both configuration
> >>> information and code (but the lack of network requirement permitted
> >>> private modification).  Here that argument need not even be made since
> >>> the CAL *explicitly* requires configuration information.
> >>>
> >>> I'm definitely worried then about:
> >>>  - The introduction of a requirement for documentation for *use*
> >>>  - The introduction of a requirement for configuration information,
> >>>    *especially in the context of network distribution requirements*.
> >>>
> >>> These concerns compound with the following section.
> >>>
> >>>> 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."
> >>> Here is where I am very concerned.  Recipient is very broad.
> >>>
> >>> The use of the word "operator" tells me that the intended use of this
> >>> license has been seen within the scope of a client-server style
> >>> architecture, or has been flavored by the experience of seeing that
> >>> rolled out as the primary way we've seen networked applications in the
> >>> last couple of decades.  I explain in the above email to cap-talk why I
> >>> think this is going to be big trouble: I believe it *actually* prevents
> >>> applications and protocols that are persuing cryptographic autonomy.
> In
> >>> particular:
> >>>
> >>>  - It does not seem to anticipate that *every user* should be running
> >>>    their own application... not client-to-server, but peer-to-peer, so
> >>>    these are not "server operator requirements", they are requirements
> >>>    for every user, including potentially ones just running some
> software
> >>>    on their phone or laptop.  If Bob holds some small amount of data on
> >>>    Alice's machine, is Bob able to persue an enforcement request from
> >>>    Alice's usage of her phone?  I do not see a good way to present this
> >>>    requirement to ordinary users, and it may even result in accidental
> >>>    privacy leaks.
> >>>
> >>>  - Assume that object access is managed by capability security.  This
> is
> >>>    to say, if you have a reference to an object, you can access its
> >>>    resources, but otherwise you cannot.  In order to uphold the
> >>>    Principle of Least Authority, varied and attenuated access is given
> >>>    out to many different objects in the system.  Which of them are
> >>>    "users", and what rights for what data do they have to extract which
> >>>    information?  This is not theoretical, this is the direction that
> >>>    sophisticated peer-to-peer, cryptographically secure distributed
> >>>    programs are going (eg the programming language E, the work that the
> >>>    Agoric company is doing, and my own work on Spritely Goblins).
> While
> >>>    I (and many other security researchers) believe this is the
> >>>    healthiest direction for network security to go, I do not see a good
> >>>    way to be able to uphold this with the requirements for recipient
> >>>    data distribution and key distribution.
> >>>
> >>> Perhaps this sounds too technically abstract.  Let me put it more
> >>> simply: I believe I could use this license to coerce someone into
> giving
> >>> up private data or encryption keys in a peer to peer network.
> >>>
> >>>> 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).
> >>> You seem more confident than I am in terms of what these categories
> are,
> >>> so I think it would be useful for you to give us some scenarios, then
> we
> >>> can work through them:
> >>>
> >>>  - A requirement for distributing "recipient data".
> >>>  - A situation where two peers communicate, but a requirement for
> >>>    recipient data distribution does not become invoked.
> >>>  - A scenario by which cryptographic key material, in relationship to
> >>>    user data, must be provided.
> >>>  - A scenario where the remote program has cryptographic key material
> >>>    that is not required to be distributed.  This one is very important
> >>>    in that the question must be asked: "what part of the license makes
> >>>    this categorically excluded from its requirement"?
> >>>
> >>> With those in place I think we can have a better analysis.
> >>>
> >>> Finally, I am going to repeat part of what I said in the cap-talk
> >>> thread: the choice of the license name is ironic, because though the
> >>> goals are good (ensure autonomy of users), it may actually create
> >>> difficulties in complying in the kinds of systems that actually are
> >>> doing so through cryptography and protocols (ocap actor model systems,
> >>> encrypted data vaults).  The problem is one that must be addressed for
> >>> the sake of user freedom, but I believe it is being addressed on the
> >>> incorrect layer.  Here we see an attempt to address it on the license
> >>> layer, but IMO this is wrong: there are active systems that exist and
> >>> are addressing this in such a way that the cryptographic tooling and
> >>> protocols themselves are the ones that help ensure greater user
> >>> autonomy.
> >>>
> >>> Thank you,
> >>>  - Chris
> >>>
> >>>> Thanks,
> >>>> Van
> >>>>
> >>>>
> >>>>
> >>>> 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
> >>>>> something?
> >>>>>
> >>>>> 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
> >>>>> are
> >>>>>> 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
> >>>>> crypto
> >>>>>> 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
> >>>>> the
> >>>>>> 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
> >>>>> next
> >>>>>>>>> Board meeting, which is this Friday. The soonest would be the
> >>>>> February
> >>>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> >>>>>> _______________________________________________
> >>>>>> License-review mailing list
> >>>>>> License-review at lists.opensource.org
> >>>>>>
> >>>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> >>>>> _______________________________________________
> >>>>> License-review mailing list
> >>>>> License-review at lists.opensource.org
> >>>>>
> >>>>>
> >>>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> >>>> _______________________________________________
> >>>> License-review mailing list
> >>>> License-review at lists.opensource.org
> >>>>
> >>>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> >>>
> >>> _______________________________________________
> >>> License-review mailing list
> >>> License-review at lists.opensource.org
> >>>
> >>>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> >>>
> > _______________________________________________
> > License-review mailing list
> > License-review at lists.opensource.org
> >
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200212/b8f4aa80/attachment-0001.html>