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

[VanL]

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

> Yes, that's fine. There still is a problem with 2.2.2 and the wording
> "with the exception in 2.4." Why aren't 2.2.1 and 2.2.2 parallel language?
>

Now I see your point here, I just missed that. They now use parallel
language, "Subject to the exception in section 2.4...."

>
>
> <snip>
>
>
>> Section 2.3: It says "You must give the same permission received under
>> this License to any Recipient...." However, Section 7.2 says the license
>> is not sublicensable, so the Licensee doesn't have authority to grant
>> permissions at all. The clause doesn't seem to have an effect and
>> therefore only creates confusion.
>>
>
> This is intended to reflect a similar concept to the GPL's "no further
> restrictions" clause. I am open to ways to improve this to make it clearer.
>
> 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."*


> Thanks, capitalization fixed. With regard to the meaning, this is an
> anti-DMCA clause. See my email to Henrik on this list identifying the
> parallel GPLv3 clause.
>
> "See email" isn't particularly helpful when the thread is so long and I am
> looking for an email from you, of which there are many. A link to the
> pipermail link would be more helpful.
>

Sorry, just trying to be succint.

GPLv3, Section 3: No covered work shall be deemed part of an effective
technological measure under any applicable law...

CAL 2.3(a): You may not, by means of cryptographic controls, technological
protection measures, or any other method, limit a third party from
independently Processing User Data in which they have a Lawful Interest

GPLv3, Section 3: When you convey a covered work, you waive any legal power
to forbid circumvention of technological measures to the extent such
circumvention is effected by exercising rights under this License with
respect to the covered work

CAL, 2.3(d): You waive any legal power to forbid circumvention of technical
protection measures that include use of the Work

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



> 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.



> 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.

Thanks,
Van
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190501/3ddb3b69/attachment.html>