[License-review] For Approval: The Cryptographic Autonomy License
van.lindberg at gmail.com
Tue May 14 16:03:37 UTC 2019
Hi Pam - and cc'ing Richard to this reply -
Thanks to both of you for the feedback.
On Tue, May 14, 2019 at 7:45 AM Pamela Chestek <pamela at chesteklegal.com>
> I would also comment that I think you have underplayed the significance of
> the scope of copyleft question by characterizing it as a "legal mechanism"
> question. You have not mentioned below that this license requires that any
> newly-written software that implements the same APIs must also be under and
> open source license.
> That is a new concept; no copyleft license requirement has been applied to
> code written from scratch. I don't read the thread, particularly Richard
> and Henrik's emails, as suggesting that public performance is per se the
> problem, but rather the concept altogether is, no matter how it is
This is a good point, although I think it is logically separate from the
public performance question. The public performance question is largely
around the network effect of the copyleft and is basically an
alternative-but-similar mechanism to AGPL's "network interaction" language.
The API question is separate and keys on OvG, not on public performance. It
has to do with the proper interpretation of "What is a derivative work"
under copyright law, which is applicable both in the network and
non-network context. There are two subpoints here:
- The applicability and scope of API copyright in light of OvG:
Argument: OvG is limited on its terms, and is avoidable.
Response: We are already seeing preferential filing of copyright cases
with patents to reach the Federal Circuit, and I have seen application of
the OvG concept in new licenses. This precedent is unavoidable unless the
Fed. Cir's decision is completely gutted by the SCt (which is possible, but
I think unlikely). This may not be the ideal world, but it is the one we
- Is the application of copyright to APIs good policy:
Argument: This is bad policy, or at best premature; we should not be a
Response: While API copyright can be misused, it is structured here to
increase software freedom (yes-this point is debatable). More broadly, if
copyright is recognized in APIs, that is an issue for courts to interpret.
It is better to deal with it explicitly-either claiming it and using it,
like the CAL, or disclaiming it, as Richard advocates-rather than just
letting it hang out as an unknown.
I would also generally bring up the patent issue again; patent law is a
completely separate chain of legal reasoning that also supports all the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-review