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

Sat Aug 24 14:59:01 UTC 2019

I have commented on earlier versions of the CAL and also discussed this
version on license discuss. So I will just briefly summarize my conclusions
here.

Overall this submission does a good job of addressing feedback from the
previous review. I've called out some specific improvements like the
anti-drm language. I also welcome the proposed patent litigation clause,
which to my knowledge gives stronger copyleft protection against patent
suits than any existing open source license.

Specific points:

1. Data Autonomy

This license justifies and scopes the "copyleft for user data" better than
the previous versions. It is now very clear that the goal is just to
protect user freedom.

Me and others have scrutinized this new idea a lot. In particular we have
discussed the principle that open source software shouldn't cause legal
burden or risk on a user that just wants to use the unmodified software.
Personally I'm not concerned about a SaaS vendor having this obligation
toward its customers and users. The burden is reasonable (required also by
law in EU, for example) and well justified with the goal of securing a new
aspect of software freedom to the user.

However, in the domain of consumer p2p software, like a file sharing
software or (original) Skype, it would be private consumers that carry this
burden, and it might be hard or impossible to fulfill their obligation. I
tried to poke at this on license discuss, but I agree with Van that I
failed to propose any improvement. As this is a fairly narrow corner case,
I don't think this issue should stand in the way of approving the CAL as an
open source license.

2. API copyright

This version no longer explicitly claims copyright on compatible APIs.
However some subtle words seem to have been left in the license to allow
for potentially still asserting such a claim in a jurisdiction where an API
could be so protected. When prompted, Van didn't deny this. This IMO puts
the OSI in a difficult position. If APIs become copyrightable, it is not
clear what the OSIs and open source community's reaction to that will be.
Approving this license now would essentially decide the issue without
discussion. The license would be OSI approved and Van's client or any other
CAL user could start asserting API copyright and claim that this license
"clearly" allows and intends such an assertion.

The remaining wording is so subtle that I don't feel qualified to push this
issue further. But I would hope that lawyers on the list do and that the
license approval committee pays attention to this point.

3. Coordinated Disclosure

I can think of arguments for and against this late addition, but in any
case it is clearly OSD compliant. The same mechanism is allowed by all OSI
approved permissive licenses.

It's also another great example of how new copyleft licenses can improve on
issues not addressed by existing licenses!

henrik

On Fri, Aug 23, 2019 at 12:11 AM VanL <van.lindberg at gmail.com> wrote:

> I am withdrawing Beta 2 and substituting Beta 3. The only difference
> between the two is the addition of new provision 4.1.3:
>
> #### 4.1.3. Coordinated Disclosure of Security Vulnerabilities
> You may delay providing the Source Code corresponding to a particular
> modification of the Work for up to ninety (90) days (the “Embargo Period”)
> if: a) the modification is intended to address a newly-identified
> vulnerability or a security flaw in the Work, b) disclosure of the
> vulnerability or security flaw before the end of the Embargo Period would
> put the data, identity, or autonomy of one or more Recipients of the Work
> at significant risk, c) You are participating in a coordinated disclosure
> of the vulnerability or security flaw with one or more additional
> Licensees, and d) the Source Code pertaining to the modification is
> provided to all Recipients at the end of the Embargo Period.
>
> All other discussion regarding CAL Beta 2 should apply. The following is
> copied from the Beta 2 submission:
>
> *Rationale:* The CAL is a new network copyleft license especially
> applicable for distributed systems. It is designed to be as protective as
> possible of downstream recipients of the software, providing them all that
> they need to create and use an independent copy of a licensed work without
> losing functionality or data.
>
> *Distinguish:* The CAL is most similar to the AGPL, and will have a
> similar scope of action in most cases. However, the CAL has provisions that
> require that operators provide recipients of the software with a copy of
> their user data, enhancing their ability to independently use the software.
> The CAL also allows the creation of mixed "Larger Works," provides for
> affiliate use, and does not specify a mechanism by which notice is given to
> recipients.
>
> *Legal Analysis*: The CAL was drafted by legal counsel. Previous
> discussions have outlined many aspects of the legal analysis.
>
> Following the rejection of CAL Beta 1, this version has been reworked to
> remove the reasons for rejection and to address the concerns that led into
> the “further discussion” items. In particular, I worked on laying out the
> scope of the private right of use, clarifying when the conditions apply,
> and avoiding constructions that may result in adverse policy inferences. I
> also simplified the language to enhance interpretability.
>
> The most controversial aspect of the CAL remains: it requires someone who
> is communicating the software (or a part of the software) to a "Recipient"
> (a non-affiliated third party), to also allow that Recipient access to the
> Recipient's own user data. To show how this fits into the broader concept
> of software freedom, the policy associated with this requirement is also
> laid out: to allow a Recipient to fully use an independent copy of the Work
> generated from the Source Code provided with the Recipient’s own User Data.
>
> *Previous Discussion*: For those only following this list, I also
> provided a changelog on license-discuss [1] which prompted some discussion.
> From that discussion, I'll note that Russell McOrmond is on record as
> believing that the CAL is part of a class of licenses - which includes the
> AGPL, and the GPL as applied) is not compliant with the OSD. Bruce Perens
> is on record as believing the any requirements that an operator provide
> user data is a violation of "no field of use" restriction in OSD 6. Bruce
> is also on record as believing that the identification of the private right
> of use is a field of use restriction.
>
>
> [1]
> http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-August/020937.html
>
> A copy of the license (now beta 3) in markdown-formatted plaintext is
> attached.
>
> Thanks,
> Van
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190824/ca2f806a/attachment.html>