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

Wed May 1 03:35:06 UTC 2019

On 4/30/19 9:57 PM, Richard Fontana wrote:
> 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.
That is also the way I understand it.
>
> 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. 
Darn, I thought I thought of that. Well, I just thought it was OSD6.
> 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 don't see this as even slightly different from the GPL in reach, at
least if the S. Ct. concludes that APIs are copyrightable to some
extent. Dalvik was largely written from scratch but, to the extent it
implements the Java APIs, it is an infringement, the corollary being
that if lawfully made it would be a derivative work of Java. Have I
erred in my reasoning somewhere? I'm just trying to find some rationale
for why this is any different from A/GPL and I haven't seen it yet.

As Scott pointed out, scope is what it is (or what the S. Ct. says it
is), and the right of public performance may not actually change
anything. What troubles me more about the right of public performance
here, though, is how it will be interpreted outside of the US.
> 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.
So, an originalist. ;-)
>
> I also think it may violate the spirit of OSD 9, somewhat like the
> case of SSPL.
I think the difference is that the SSPL didn't have any colorable theory
that its reach was only as far as copyright law, but there is a theory here.
>
> 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.
I'm just trying to figure out where you and others believe the boundary
is. I thought it was the scope of copyright (and related rights that
interfere with the exercise of of the grant), but it now appears that
copyright isn't where the boundary is either.
>
>> 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.y d
This is a rehash of the philosophical divide exposed during the
discussion of the SSPL, but I think a bit of a straw argument. By its
express terms CAL forces more software into an open source license, in
the same way that AGPL and GPL do. If that effect means that less people
choose it, and so in actual fact less software is free, that's no
different than how the the AGPL or GPL operate -- by their words more
software should be free, but in reality less software is free because of
the perceived negative effect of copyleft, which we know exists because
of their use in dual licensing schemes. If you believe that not all
copyleft licenses have a negative effect on the amount of software
released under open source licenses, then where is the tipping point and
why?
>  
>
>> [^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.
We could enjoy long conversations musing on the hypothetical, but as
much as I would enjoy it I'll avoid wasting the list's time. At any
rate, it's unlikely we would have a definitive answer anytime soon.

Pam

Pamela S. Chestek
Chestek Legal
PO Box 2492
Raleigh, NC 27602
+1 919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com