Should API-restricting licenses qualify as open source?

A look at how a closely-watched legal case about copyright and APIs might affect open source licensing
135 readers like this.
Two government buildings

In its 2014 Oracle v. Google decision, the United States Court of Appeals for the Federal Circuit held that the method declarations and "structure, sequence, and organization" (SSO) of the Java SE API were protected by copyright. This much-criticized result contradicted a decades-old industry and professional consensus assumption that APIs were in the public domain, reflected in an ongoing common practice of successive reimplementation of APIs, and persisting even after the general copyrightability of software was settled by statute. Unsurprisingly, that consensus shaped the view of APIs from within open source. Open source licenses, in particular, do not address APIs, and their conditions have not customarily been understood to apply to APIs.

If the copyrightability ruling survives its current review by the United States Supreme Court, there is reason to worry that Oracle v. Google will eventually have some detrimental impact on open source licensing. License authors might draft new licenses that would explicitly extend familiar kinds of open source license conditions to activities merely involving APIs. There could also be comparable efforts to advance Oracle v. Google-influenced reinterpretations of existing open source licenses.

We've already seen an example of a new open source-like license that restricts APIs. Last year, Holochain, through its lawyer Van Lindberg, submitted the Cryptographic Autonomy License (CAL) for approval by the Open Source Initiative (OSI). The 1.0-Beta draft included source availability and licensing requirements placed on works merely containing or derivative of interfaces included in or derived from the licensed work. (CAL 1.0-Beta was rejected by the OSI for reasons other than the interface copyleft feature. Subsequent revisions of CAL removed explicit references to interfaces, and the OSI approved CAL 1.0 earlier this year.) Licenses like CAL 1.0-Beta would extend copyleft to reimplementations of APIs having no code in common with the original. Though less likely, new permissive licenses might similarly extend notice preservation requirements to mere copies of APIs.

In my view, API-restricting licenses, though otherwise FOSS-like, would not qualify for the open source label. To simplify what is actually a complicated and contentious issue, let's accept the view that the license approval decisions of the OSI, interpreting the Open Source Definition (OSD), are the authoritative basis for determining whether a license is open source. The OSD makes no mention of software interfaces. Some advocates of a relaxation of standards for approving open source licenses have argued that if a type of restriction is not explicitly prohibited by the OSD, it should be considered acceptable in an open source license. To guard against this tactic, which amounts to "gaming" the OSD, the OSI clarified in 2019 that the purpose of the approval process is to ensure that approved licenses not only conform to the OSD but also provide software freedom.

Though Luis Villa has raised concerns that it gives rise to a "no true Scotsman" problem, I believe the emphasis on software freedom as a grounding principle will enable the OSI to deal effectively and in a well-reasoned, predictable way with cases where license submissions expose unforeseen gaps or vagueness in the OSD, which is politically difficult for the OSI to revise. (Disclosure: I was on the OSI board when this change to the license review process was made.) It is also an honest acknowledgment that the OSD, like the Free Software Definition maintained by the Free Software Foundation, is an unavoidably imperfect and incomplete attempt to distill the underlying community norms and expectations surrounding what FOSS is.

Software freedom is the outgrowth of a long-lived culture. Judging whether a license that extends FOSS-normative conditions to APIs provides software freedom should begin with an examination of tradition. This leads to a straightforward conclusion. As noted above, from nearly the earliest days of programming and continuing without interruption through the rise of the modern open source commons, software developers have shared and acted on a belief in an unconditional right to reimplement software interfaces. From a historical perspective, it is difficult to think of anything as core to software freedom as this right to reimplement.

The inquiry cannot be entirely backward-looking, however, since the understanding of software freedom necessarily changes in response to new societal or technological developments. It is worth asking whether a departure from the traditional expectation of unrestricted APIs would advance the broader goals of open source licensing. At first glance, this might seem to be true for copyleft licensing, since, in theory, compliant adoption of API copyleft licenses could expand the open source software commons. But expanding the scope of copyleft to API reimplementations—software traditionally seen as unrelated to the original work—would violate another open source norm, the limited reach of open source licenses, which is partially captured in OSD 9.

Another observation is that software freedom is endangered by licensing arrangements that are excessively complex and unpredictable and that make compliance too difficult. This would likely be true of API-restricting FOSS-like licenses, especially on the copyleft side. For example, copyleft licenses typically place conditions on the grant of permission to prepare derivative works. Trying to figure out what is a derivative work of a Java method declaration, or the SSO of a set of APIs, could become a compliance nightmare. Would it include reimplementations of APIs? Code merely invoking APIs? The fundamental vagueness of Oracle v. Google-style API copyright bears some resemblance to certain kinds of software patent claims. It is not difficult to imagine acquirers of copyrights covered by API-restrictive licenses adopting the litigation strategies of patent trolls. In addition to this risk, accepting API-restrictive licenses as open source would further legitimize API copyrightability in jurisdictions like the United States, where the legal issue is currently unsettled.

Oracle v. Google-influenced interpretations of existing open source licenses would similarly extend familiar open source license conditions to activities merely involving APIs. Such reinterpretations would transform these licenses into ones that fail to provide software freedom and advance the goals of open source, for the same reasons that apply to the new license case. In addition, they would upend the intentions and expectations of the authors of those licenses, as well as nearly all of their licensors and licensees.

It might be argued that because open source licenses are principally (though not exclusively) copyright licenses, it is necessary, if not beneficial, for their conditions to closely track the expansion of copyright to APIs. This is not so for new open source licenses, which can be drafted explicitly to nullify the impact of Oracle v. Google. As for reinterpretations of existing open source licenses, while the issue of API copyrightability remains unsettled, it would not be appropriate to abandon traditional interpretations in favor of anticipating what an Oracle v. Google-influenced court, unfamiliar with open source culture, would decide. Litigation over open source licenses continues to be uncommon, and influential open source license interpretations have emerged in the technical community with little regard to how courts might act. In any event, courts engaged in interpreting commonly-used open source licenses may well be persuaded to treat APIs as unconstrained.

Some have suggested that interpretation of the GPL should take full advantage of the scope of underlying copyright rights. This is related to a view of copyleft as a "hack on copyright" or a "judo move" that "return[s] the violent force of the oppressor against the oppressor itself." It can be detected in the copyleft tutorial sponsored by the Software Freedom Conservancy and the FSF, which says: "The strongest copylefts strive to [use] the exclusive rights that copyright grants to authors as extensively as possible to maximize software freedom." It might seem logical for someone with this perspective to specifically promote an API copyright interpretation of the GPL. But I know of no advocate of strong copyleft who has done so, and the text and interpretive history of the GPL do not support such a reading.

A somewhat different view of API copyright and GPL interpretation, occasionally voiced, is that Oracle v. Google may put the doctrine of strong copyleft on a surer legal foundation. Similarly, it has sometimes been asserted that strong copyleft rested on some notion of API copyrightability all along, which suggests that Oracle v. Google provides some retroactive legal legitimacy. The latter view is not held by the FSF, which in an earlier era had opposed the expansion of copyright to user interfaces. This stance made its way into GPLv2, which has a largely overlooked provision authorizing the original licensor to exclude countries that would restrict "distribution and/or use … either by patents or by copyrighted interfaces." The FSF also severely criticized Oracle's claim of copyright ownership of Java APIs. And the FSF has never questioned the right to reimplement APIs of GPL-licensed software under non-GPL licenses (as has happened, for example, with the FSF-copyrighted GNU Readline and the BSD-licensed libedit). If there were shown to be some legal deficiency in strong copyleft theory that API copyrightability could somehow fix, I believe it would be better either to live with a weaker understanding of GPL copyleft or to pursue revisions to the GPL that would reformulate strong copyleft without relying on API copyright.

If API copyrightability survives Supreme Court review, it would then be appropriate for license stewards, licensors of existing open source licenses, and drafters of new open source licenses to take constructive steps to minimize the impact on open source. Stewards of widely used open source licenses, where they exist, could publish interpretive guidance clarifying that APIs are not restricted by the license. Updates to existing open source licenses and entirely new licenses could make unrestricted APIs an explicit policy. Licensors of existing open source licenses could make clear, in standardized license notices or through external commitments, that they will not treat open source license conditions as imposing any restriction on activities merely involving APIs.

What to read next
Richard Fontana
Richard is Senior Commercial Counsel on the Products and Technologies team in Red Hat's legal department. Most of his work focuses on open source-related legal issues.


Richard, I believe your article should be corrected. You have misrepresented the CAL license. It is not a "new open source-like license that restricts APIs." The CAL license has exactly the same copyleft scope as a number of licenses currently in use, some predating AGPLv3, that define the scope of the copyleft as as the scope of copyright. CAL was not groundbreaking in this regard, and had the OSI rejected it for that reason then OSI would have been challenged for having a license review process that was subjective rather than objective. As you noted, the original draft was written specifically to capture APIs, but this was an aspect that the OSI questioned when it rejected the first version and, as you note, this aspect does not appear in the second version, indicating that the OSI would have rejected a license that extended copyleft beyond the scope of copyright.

Referring to it now as "open source-like" is also disingenuous. You fail to mention in your article that you voted to approve the CAL license as an OSI-approved license. You said on February 6, 2020 "Having reviewed the latest draft, 'Pass' from me. I have lingering concerns over this license, and the potential for abuse by Holochain or other unknown licensors, based partly on the earlier drafting history, some of Van's earlier comments on those drafts, and general suspicion of new copyleft licenses advanced specifically by narrow commercial interests. However I don't think those concerns are sufficiently grounded in the current license text such that I would recommend rejection or more protracted discussion. If this license is approved, I would not recommend that anyone use it. But on its face, the license, including the core interesting User Data requirement feature, seem to me consistent with the spirit of the OSD and software freedom."

Hi Pam, The "open source-like license" I am referring to in that paragraph is not CAL 1.0 (the license approved by the OSI earlier this year), but rather CAL 1.0-Beta, the earlier draft originally submitted by Van Lindberg in early 2019. You are right that I supported OSI approval of the *later* version of CAL, which did not have the interface copyleft feature. I also raised concerns about OSD-conformance of the *earlier* version of CAL, CAL 1.0-Beta, because of the interface copyleft feature. I've read the paragraph a number of times since receiving your comment and discussed it with some of my colleagues at Red Hat, and I feel it is sufficiently clear that no edit to the article is necessary, but I hope this reply to your comment helps clarify things for readers.

In reply to by pchestek

As a laymen, I was able to understand that it was the CAL 1.0-Beta license that was open source-like, not th CAL 1.0 license that passed the OSD.

As an aside, I think this discussion is fascinating. I must that my first reaction was that Copyleft to APIs seemed fine, but you have thoroughly convinced me that we need to advocate for the innate right to re-implement APIs regardless of software license. I now think this is a the best option, stack ranked. To your point, I think the second best would be, should the Oracle vs. Google case make APIs copyright-able, then for Open Source licenses to explicitly expand to include this right. This would, at least, protect open source code, which is becoming a bigger and bigger portion of code in the world, so it would naturally expand.

In reply to by fontana

The main difference (very simply put) with APIs compared to software source code alone is that the APIs need the data and/or other resources to work. You can transport and copy the source code, but unless you have the data, or devices, lighting, buildings or whatever resources the API exposes the source code licensing model alone will not guarantee the usability of the API. Or that the API will provide the same resources and work in a same way if the code is installed elsewhere. So in that sense, licensing an API is not (always) the same as licensing software. In case someone is interested, we've spent considerable time in the Finnish open source, open data and API community this year figuring this out. Some of our findings are in this long post In general, we see that open source licensing covers and can cover a lot of the API licensing, but not all.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.