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

Wed May 1 22:17:36 UTC 2019

Responses inline.

On 4/30/2019 9:00 PM, VanL wrote:
> Hi Pam,
>
> Sorry for the delay replying.
>
> On Sat, Apr 27, 2019 at 9:30 AM Pamela Chestek
> <pamela at chesteklegal.com <mailto:pamela at chesteklegal.com>> wrote:
>
>     Hi Van,
>
>     Below are some comments on the text itself.
>     > Section 2.2.1 and 2.4 are circular references so that it's not clear
>     what the duty is.
>
>
> The intention is that it can function either like MPL's per-file
> licensing, or like the LGPL. But reading this, I understand the
> confusion. I have updated the draft to try to address this issue. Does
> this make it clearer?
>
>
>     2.4. Combined Work Exception
>
> As an exception to the conditions in sections 2.2.1 and 2.2.2, any
> Source Code files marked by the Licensor as having the “Combined Work
> Exception,” or any Object Code exclusively resulting from Source Code
> files so marked, may be combined with other Software into a “Larger
> Work.” So long as you comply with the conditions in 2.1, 2.2, and 2.3
> relative to the Source Code provided to you by Licensor, any other
> Software in the Larger Work as well as the Larger Work as a whole may
> be licensed under the terms of your choice.
>
> I hope that this also clears up the use of the term "relative." It is
> here essentially a synonym for "regarding" or "with respect to."
>
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?
>  
>
<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"?
>
>  
>
>
>     Section 2.3(e): missing capitalization of "Work"? I also don't
>     understand what it's trying to say or stop.
>
>
> 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.

IMO, your generalization of the language from the GPLv3 makes it
unintelligible here (and frankly I don't understand it in the GPLv3 either).
>  
>
>
>     Section 4.1: I would insert the word "automatically" before
>     "compliance"
>     within 60 days to distinguish it from compliance after that, which
>     requires the express restoration by the Licensor.
>
>
> Is this what you mean? "As a special exception to termination for
> non-compliance, Your permissions for the Work under this License will
> _automatically_ be reinstated if You come into compliance with all the
> conditions in section 2 within sixty days of being notified by
> Licensor or an intended third party beneficiary of Your noncompliance."
Yes.
>
>  
>
>     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.
>  
>
>     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.

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/20190501/093c228b/attachment.html>