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

[Richard Fontana]

On Tue, Apr 30, 2019 at 7:47 PM Pamela Chestek <pamela at chesteklegal.com> wrote:
>
> Assume that there is a right of public performance in an API.[^1] What section of the OSD, or well-settled rationale for not approving a license, does this particular provision of the CAL fail?[^2] It exercises no rights outside of copyright law. It serves to make more software available under open source licenses. Why is this not considered "open source"?

As far as I currently understand, it forces source code distribution,
and licensing under a limited set of licenses (probably excluding the
GPL family), under some circumstances, upon someone who creates an
independent implementation of the CAL-licensed API.

Recently I made a sort of joke on Twitter to the effect that any
criticism of a submitted-to-OSI license can be couched as a violation
of OSD 5/6. Well, maybe it's not a joke. In the context of some
recently-submitted licenses (L0-R, SSPL) I and some others have argued
that it is wrong to read the OSD with excessive literalism, or
legalism or pedanticism. But if one insists on a literal reading of
the OSD, CAL seems to violate OSD 5 and 6. It discriminates against
the class of persons that wish to create re-implementations of APIs,
that wish not to be forced to distribute the source code for such
implementations, and that (if they do distribute the source code) that
wish not to be restricted in terms of the licenses they can use. Now
of course practically all licenses can be accused of discriminating in
some way. The GPL sure does. So perhaps the OSD 5/6 inquiry goes to
figuring out whether the nature of the discrimination is worse than
that done by the widely-used/popular licenses, particularly the GPL (I
can go into that further but assume that makes sense). The GPL
historically was never read by its license steward or by the majority
of the GPL-using community as extending in any meaningful way to API
copyright as such (I don't think the public performance right vs.
distribution distinction matters here). I believe that reading would
have been met with widespread condemnation, even by the strongest
supporters of the FSF's interpretation of GPL copyleft. I think the
overwhelmingly negative reaction to the copyrightability result in
Oracle v. Google in the open source community supports this. From a
software freedom perspective, extending a copyleft requirement to an
interface is unjust. It has the character of a requirement that I
believe historically would have been considered going too far, for a
supposed free software license.

I also think it may violate the spirit of OSD 9, somewhat like the
case of SSPL.

Also, the OSI has clarified recently that the purpose of the license
approval process is to "Ensure approved licenses conform to the Open
Source Definition and provide software freedom". So the license
submitter need not merely show that the license meets the OSD, but
also that it provides software freedom. And I will say as someone who
was on the board at the time that one of the reasons that language was
used was because of growing concern about "gaming" of the license
review process through literalist or legalistic readings of the OSD.
In reality they shouldn't be seen as two requirements -- rather the
OSD is an imperfect, mostly-1990s-drafted guide to the more
fundamental inquiry which is whether the license provides software
freedom. In my view, and as you can see I like to look to history and
cultural intuition to reach my understanding, the unreasonable burden
it places on the re-implementor of an API is a violation of software
freedom. At least that's my current view, based on my current reading
of the last CAL draft I looked at.

I also want to take issue with a couple of things you said there:

> It exercises no rights outside of copyright law

The fact that a license limits itself to exercising rights within
copyright law isn't a guarantee that it provides software freedom.

> It serves to make more software available under open source licenses.

Not necessarily (beyond the mere fact of approval, if CAL were
approved as an open source license). If you mean the effect of the
copyleft requirement, whether this results in more software available
under open source licenses depends on how the CAL licensor uses the
license, how widely adopted it is, and also the reaction of potential
users. I think a number of people in the course of the SSPL (and maybe
L0-R) discussion expressed the view that it is improper to consider
the way a particular licensor would be likely to use the license in
connection with an open source license-centered business model. I am
pretty sure I disagree with that. In this case, we have a situation I
see as similar to SSPL: it seems really unlikely that this license --
which is relatively complex, seemingly special-purpose and proposed by
a business entity -- would see any adoption by any other licensors
(perhaps not itself a reason for nonapproval but I think worth
thinking about). Also I am fairly sure I heard Van say at CopyleftConf
that his client was contemplating using this license as the basis of a
proprietary/copyleft dual-licensing scheme (Van if I misheard that
please correct me). If that's so, then the only likely user of this
license will be using it not in the hope that it will result in more
open source software but rather that it will result in *less* open
source software, and may even strategize to make that the more likely
outcome. See Chris Webber's recent license-discuss posting, where he
points out that "proprietary relicensors" want noncompliance, not
compliance.

> [^1]: There is an escape hatch in the definition. It says "'Public Performance; (or 'Publicly Performing') means any action that implicates the rights of public performance or public display of a work under copyright law." I can argue, or perhaps it can be clarified, that the definition says if there isn't such a thing under copyright law, then this provision isn't operational. However, I don't believe that Google v. Oracle will have the result of closing the door on the right of public performance for APIs, since Google v. Oracle is about the right of reproduction, not the right of public performance. Personally I believe it is a non-frivolous theory.

I don't think it's frivolous in a litigant argument sense. However, I
question what it could possibly mean to publicly perform an *API*. I
can sort of see how the visual interface in a graphical executable
program or web application could be likened to public performance.
That's maybe public performance of *software* in general.  But for a
SaaS application, say, what aspect of the user's experience
constitutes the perception of the performance specifically of the API?
Typically, the API is perceptually hidden from the user.

Richard