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

[Richard Fontana]

On Mon, Apr 29, 2019 at 10:20 AM VanL <van.lindberg at gmail.com> wrote:
>
>
>
> On Sun, Apr 28, 2019 at 2:35 PM Pamela Chestek <pamela at chesteklegal.com> wrote:
>>
>> Hi Van,
>>
>> Thanks, and I appreciate your indulgence while I struggle with how the license is architected. So the design of the license (and perhaps the goal) is that (1) any software written to offer the same APIs has to be under a Compatible Open Source License and (2) the user's data is portable. Is that correct?
>
>
> Yes, that is correct.

I'm still trying to find time to review CAL in detail but I want to
note this as one major concern I have.

This seems to be the first submitted-to-OSI license I can think of
that is intentionally written to extend copyleft to API copyright --
the first concerted attempt to create an "Oracle v. Google copyleft",
if you will. If I understand correctly, this means

(a) if independent reimplementations of APIs bearing no literal
similarity to the CAL-licensed implementation are distributed in
binary form, the distributor must also provide the source code of the
modifications under CAL or presumably a permissive or weak copyleft
license,

(b) the source code of independent reimplementations of APIs bearing
no literal similarity to the CAL-licensed implementation must be
distributed, under CAL or presumably a permissive or weak copyleft
license, if the licensee "Publicly Performs" an interface (as a
separate matter I think the concept of performing an *interface* is
unclear)

It's true that to the extent APIs are copyrightable, there could be
implications for interpretation of existing licenses like the GPL and
AGPL. However, the FSF, as GPL family license steward, has I believe
taken a strong public stance against API copyrightability as a matter
of policy and I believe would not endorse a newly-maximalist reading
of the GPL to take advantage of API copyrightability. I also believe
that there is a deep-rooted policy against accommodation of any sort
of restrictive application of interface copyright in free
software/open source, dating from the 1990s, that ought to be read
into the OSD and our understanding of software freedom, and is
supported by the widespread hostility in the free software and open
source community to the result in Oracle v. Google. I think it would
be legitimate for a post-Oracle v. Google open source license to
recognize the potential copyrightability of APIs by treating them as
subject to some highly permissive license requirement, but it's
another thing entirely to use it as the basis for a copyleft
requirement.

Have you given thought to the different legal situation in the EU
under SAS Institute Inc. v. World Programming Ltd.
(https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Programming_Ltd)?
I would be curious to hear from lawyers in Europe about this.

Richard