On August 13th, 2010, Oracle sued Google over copyright and patent infringement claims relating to the reimplementation of the Java runtime within its Android platform. The suit took over a decade to resolve, and had several major twists and turns, but ultimately the Supreme Court decided in Google’s favor on April 5th, 2021. Among the items at stake in this trial were the question of whether APIs were copyrightable, which is another way of saying the immediate future of the technology industry hung in the balance.
In its decision, the Supreme Court did not declare APIs immune from copyright, but rather held that Google’s use of the Java APIs constituted fair use. While it was not a total victory for those who would see APIs explicitly walled off from such concerns, it significantly raised the bar for legal challenges based on competitive usage of APIs. This was immediately relevant, as a loss would have almost certainly led to a widespread chilling effect across APIs industry-wide.
But Google vs Oracle is also critical to what may be the next front in the ongoing conflict between open source and commercial open source: APIs.
Those who have tracked popular open source projects such as PostgreSQL have likely heard a familiar observation amongst authors of the original project: that a database, for example, with Postgres API compatibility is not the same as a Postgres database. Databases that offer Postgres compatibility like AWS’ Aurora or Google’s AlloyDB, these fans argue, may not be fully compatible because of slight differences between the implementations, feature additions or omissions and more.
What cannot be argued is that the API for a large, successful and widely adopted software project is an enormously valuable asset. What might be argued is that it is possible, in certain cases, that the API is more valuable than the underlying code it represents. The underlying code for an API can and has been reimplemented in clean room settings, while the API must be a fixed point for developers.
With large projects that are maintained by multiple third parties such as Postgres, the potential friction from API reimplementations is minimal. By virtue of being a project worked on by many commercial vendors, there is no real exclusivity offered or claimed by the API.
The dynamics for single entity projects or open source projects developed primarily or solely by a single vendor, however, are quite another matter.
For many years now, open source projects and database projects specifically have developed a pattern or lifecycle from a licensing standpoint. Initial development is conducted under a typically permissive open source license, in which control is traded for usage and distribution growth. Once certain usage thresholds are met, and attract commensurate funding – venture or otherwise – permissive licenses are discarded in favor of licenses offering much stronger protections, up to and past the edge of what the definition of open source permits. These licensing “rug pulls” may have eased somewhat, in that commercial vendors appear to be pulling back from source available licenses and finding an equilibrium around the strongest copyleft license in the AGPL, but the justification is the same: exclusivity.
In short, whether it’s the AGPL or non-open source, source available alternatives, the end goal for relicensing is to try and capture the vast majority or entirety of the revenue associated with a given open source project rather than share it with other vendors, particularly large hyperscalers. Many source available licenses explicitly forbid other companies from monetizing the licensed code. The AGPL, meanwhile, does not forbid third parties from monetizing a given codebase, but it does require them to share any changes or fixes they make – a practice that many avoid as a rule. Thus a project can be technically open, but practically speaking only monetized by the original author of a given project.
But what about their APIs?
In January of 2019, AWS released a long suspected new database, DocumentDB. It was, as might be guessed, a document database, and one specifically that offered some MongoDB compatibility. MongoDB had, one quarter prior, relicensed its database from the AGPL to the much more expansive SSPL. This was ostensibly an effort to thwart competition from the likes of AWS, but the timing made it clear that AWS wanted no part of even the less protective AGPL and had instead done a clean room reimplementation of MongoDB’s API to offer a datastore theoretically compatible with Mongo, but built on their own stack not subject to the requirements of the AGPL – or the SSPL for that matter. .
This all having taken place almost two years before the landmark Google v Oracle decision, however, AWS was very careful to state that its API compatibility was only up to the version last licensed as the AGPL. No one at the time had any real legal certainty on whether APIs were copyrightable and thus proprietary.
In the years since, as discussed, the industry does not have certainty, precisely, but it has made assumptions in the wake of the trial, one of them being that APIs are for all intents and purposes non-proprietary.
Which brings us to this news from late May, in which MongoDB announced that they had asked FerretDB to “stop engaging in unfair business practices.” Their claims are based on assertions that Ferret:
- Misleads and deceives developers by falsely claiming that its product is a “replacement” for MongoDB “in every possible way and
- FerretDB has infringed upon MongoDB’s patents.
Two things stand out immediately. First, that Mongo’s claims ultimately reduce to trademark and patent infringement matters, and second that neither API nor copyright are mentioned once. Setting aside the relative merits or lackthereof of these claims, which are best left to those with legal backgrounds, courts or both, the important question is whether this case is a one off or the shape of things to come.
Commercial open source projects have struggled to maximize their revenue exclusivity for years, primarily through the aforementioned series of relicensing efforts. Those efforts, however, are based on copyright as it applies to source code. If copyright doesn’t apply to APIs, or if the bar for fair use is low enough to be easily achievable from a legal standpoint, that may suggest a future in which competitive third parties “island hop” the source code and go straight for the APIs. Given the size and usage base of some of the commercial open source projects, the economic incentives to do so are substantial indeed. APIs are ultimately a door for developers, and if that door can open to your products as easily as the original author’s, that will likely be of interest regardless of what the license on the original source code might be.
The upside to the Google v Oracle ruling was clear, in that an industry in which every last programming interface was considered proprietary would be a tectonic, systemic shock. The downside, though, is that we now have to hope that we don’t see a resurgence in interest in “embrace, extend, extinguish” efforts from large third parties trying to co-opt open source projects and user bases.
Either way, it seems likely that the next wave of conflict won’t be over licenses pertaining to code, but the APIs they implement.
Disclosure: AWS, Google, MongoDB and Oracle are RedMonk customers. FerretDB is not currently a RedMonk customer.
