[License-review] For Approval: The Cryptographic Autonomy License

Thu May 2 12:31:15 UTC 2019

On 5/1/2019 9:05 PM, VanL wrote:
>
>
> On Wed, May 1, 2019 at 5:18 PM Pamela Chestek <pamela at chesteklegal.com
> <mailto:pamela at chesteklegal.com>> wrote:

> Isn't it as simple as "cannot impose any additional restrictions"?
>
> Not quite. The GPLv3 has a list of allowable restrictions (trademark,
> etc), and you can't add additional restrictions above those
> enumerated. For the CAL, however, I hoped to avoid adding a laundry list.
>
> Removed that portion from 2.3, and focused on 7.2: "This License is
> not sublicensable. Each time You provide the Work or a Modified Work
> to a Recipient, the Recipient automatically receives a license under
> the terms described in this License. *You may not impose any further
> reservations, conditions, or other provisions on any Recipients’
> exercise of the permissions granted herein."*
>
Yes, that's better, thanks.

<snip>
>
>>      
>>     GPLv3, Section 3: You disclaim any intention to limit operation
>>     or modification of the work as a means of enforcing, against the
>>     work's users, your or third parties' legal rights to forbid
>>     circumvention of technological measures.
>>
>>     CAL: 2.3(e): You waive any claim that the capabilities of the
>>     work were limited or modified as a means of enforcing the legal
>>     rights of third parties against Recipients
>
>
Okay, I get it, thanks.
>>  
>>
>>     You have defined "Public Performance" as using the Software to
>>     take any
>>     action that implicates the right of performance or public display
>>     under
>>     copyright law, and include as one use case of making an interface
>>     available. The license grant is for this full scope. However, your
>>     definition of "Modified Work" and "Recipient" refer only to
>>     "Public[ly]
>>     Perform[ance/ing] an interface." This creates ambiguity about the
>>     scope
>>     of the right for Modified Work and that Recipients have.
>>
>>
>> If you look at the header to 2.3, it encompasses all ways in which a
>> Licensee can communicate the Work to a Recipient.
> Not following at all.
>
> I am not quite understanding your question, then. The header to
> section 2 states:
> "Any distribution, Public Performance, sale, or offer for sale of the
> Work to a Recipient is subject to the following conditions...
> "These words are used to imply distribution (under copyright), public
> performance (under copyright, or alternative, as defined), and
> distribution to a third party, including SaaS/network interaction
> (which is considered to be encompassed under sale/offer under patent
> law). These specific terms were used because these were the ones that
> I saw as implicating some kind of transfer, in some respect, of the
> work covered by the License.
In 2.2 you say that Public Performance, defined as "using the Software
to take any action that implicates the rights of public performance or
public display of a work under copyright law, specifically including
making aspects of the Software, including any interfaces used for access
to or manipulation of User Data, directly or indirectly available to the
public," is subject to subject to some conditions. In 2.2.2 you say one
of the conditions is providing source code for Modified Works, which is
defined as "any work containing, directly combining with, derivative of,
or Publicly Performing*/an interface/* included in or derived from the
Work." So if my Modified Work implicates the right of Public Performance
in some way other than making an interface available (say reading it
aloud at my author talk at the New York Public Library), must I make my
modified version available? I say no, I only have to when the Modified
Work implicates using the interface.

You've defined Public Performance more broadly, then added a specific
limitation in the context of Modified Work, i.e., only those works that
consist of publicly performing an interface. It's s simple fix, you just
need to change the definition of Modified Work so it doesn't further
limit the scope of Modified Work: "'Modified Work' means any work
containing, directly combining with, derivative of, or Publicly
Performing [strike "an interface"] included in or derived from the Work."

>>  
>>
>>     Section 7.1.1: I don't understand why a reference to GDPR is
>>     required;
>>     it strikes me as a "you must comply with all applicable law"
>>     requirement. And why the GDPR and not any other or future laws? If a
>>     statement is needed that the requirements the law impose will
>>     override
>>     the license requirements, you can say that more generally.
>>
>>
>> This clause is not about complying with the GDPR. Rather, it is the
>> reverse: It is a limitation saying that if you comply with those
>> specific subsets of the GDPR, that is also good enough to count as
>> compliance with CAL 2.3(b). It is intended to streamline CAL
>> compliance by hooking into an already-existing enforcement regime.
> I do not misunderstand this section but I am apparently not explaining
> my concern clearly enough. It is facially non-compliant with OSD 6.
> You have given special permission to someone who has to comply with
> the GDPR that relieves them of duties under CAL. Others who may have
> similar conflicts do not get this special permission. Imagine that
> Australia passes exactly the same law as the GDPR except it's called
> the ADPR. Those who have to comply with the ADPR do not have the
> special forgiveness for compliance that those who are complying with
> the GDPR have. The Australians therefore may not be able to use the
> CAL software because they cannot comply with it and the ADPR at the
> same time, but those who must comply with the GDPR have an additional
> permission so they can comply with both. The solution is to make this
> section non-specific to a particular legal regime.
>
> Hmm. Maybe I will just delete 7.1.1. This was meant to be an
> interpretive guide only, and to reduce the possible scope of what a
> court might think is necessary to comply. But it doesn't affect the
> rights/responsibilities at all. All that said, it seems to be causing
> more confusion than it helps.
> Specifically with regard to your hypothetical, though, anyone who
> provided the same data in the way described would be complying with
> the CAL. They may also be complying with another law (GDPR,  ADPR, or
> $XDPR). But this license doesn't condition anything on compliance with
> those other laws. It only says that the performances required under
> the CAL and those specific subsections of the GPDR should be
> interpreted consistently.
>
I assumed there was something about data delivery schemes in the GDPR
that might conflict with the CAL, so you were saying compliance with the
GDPR scheme would be compliance with CAL. That is an additional
permission available for GDPR and no one else. If it's always going to
be possible to comply with the CAL and a privacy law no matter what the
legal requirements  of the privacy law, then I would suggest taking it
out. If it could be that a data privacy law prevents full compliance
with sections 2.3(a) and (b), then it probably makes sense to make the
implications clear, either the CAL is waived to the extent necessary or
there is liberty or death. What if the privacy law said "Data Processor
may not provide a copy of data about the Subject if the data was not
provided to the Data Processor by the Subject"?

Pam

Pamela S. Chestek
Chestek Legal
PO Box 2492
Raleigh, NC 27602
919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190502/12cba0a4/attachment.html>