When do API developer platform policies disobey antitrust laws?
Our Chief Enterprise Strategist recently asked me about Facebook’s troubles with its APIs, data privacy policies, and antitrust lawsuits. It is an issue, which is very close to my heart, and increasingly attracting attention from enterprises, API practitioners, legal experts, and CxOs concerned with API and data governance across their enterprises.
The reasons to shut down a developer consumer’s API usage could be genuine. Perhaps they violated ToU, policies, or laws of the land, which could have jeopardized the API provider’s reputation. But could there be hidden agendas too? For example, an application could smartly utilize APIs from a particular vendor and pose a certain business risk to that vendor. In this situation, we can expect an API vendor to take action to protect its business interests. But who gets to decide if those actions are fair and not designed to scuttle competition, which may invoke antitrust laws?
The real question I want to investigate here is: are companies building APIs as “Products” for creating technical innovations? Or, could they actually be devised to lay down traps that can eventually be used to scuttle future competitions? In other words: could companies use their own APIs as digital weapons?
Facebook’s Evolving Developer Platform Policy
VentureBeat reporter Chris O’Brien recently made an important observation in his article related to Facebook’s antitrust lawsuit: “Facebook began changing the rules to specifically punish or reward developers.”
Chris’ article spiked my interest, but where is the evidence that Facebook is potentially using its APIs as weapons to scuttle competition? I am not a lawyer to scrutinize the legalities of Facebook’s antitrust lawsuit, but being a computer scientist, I could do some data analysis. I started looking into Facebook’s Platform Policy (FPP) that governs their APIs’ usage by their developer community. Facebook began to open up their APIs (read started selling their data) more aggressively around 2016–2017 (after completing their ten years of foundation). Recall the Cambridge Analytica case.
Suppose Facebook is indeed systematically changing its ToU. In that case, it must be reflected in their FPP, which developers must comply with while using Facebook APIs to build applications and functionalities. I started digging deeper. Needless to say, tracking and analyzing the FPP from the last 15 years or so was a challenge. Thanks to my team’s innovative ways, they have built a tool that can quickly track and analyze legal agreements (e.g., API ToU and policies). Using this tool, I simply looked for changes in FPP from 2016 to 2020. See the screenshot of the tool, as shown in Figure 1. I noticed something trivial yet an interesting change in FPP. This change was about omissions and inclusions of two specific policies:
- Don’t build an app whose primary purpose is to redirect people off of Facebook.
- Don’t replicate core functionality that Facebook already provides.
Both of these policies should make sense to any developers who are building their applications using Facebook APIs/data. In particular, the second policy is more interesting, which discourages developers from infringing upon Facebook’s Intellectual Property (IP). As of 2019, Facebook has 1317 patents. Now that covers a lot of IP ground potentially to build many interesting applications and functionalities using massive sets of data that are generated by the Facebook platform(s), including Instagram and Whatsapp.
Facebook clearly has policies (well stated in their Platform Policy available online) that do not allow developers to replicate Facebook’s core functionalities or build applications that are purposely designed to redirect Facebook users off of Facebook platform(s) mentioned above. That makes complete sense. So, what is the problem here?
The intriguing part here is that until 27th October 2017, Facebook clearly retained its policy of “Don’t replicate core functionality that Facebook already provides.” But, Facebook dropped that specific policy since 7th May 2018 (or perhaps even earlier as I analyzed only a subset of their evolving documents publicly available online).
Even more interesting is that Facebook retained their other policy of “Don’t build an app whose primary purpose is to redirect people off of Facebook” at least until 24th January 2020. Both of the above policies are not part of the latest FPP version (which was last updated on 26th June 2020).
Reasons Behind Platform Policy Changes
Why would Facebook want others to replicate their core functionalities? Or did they remove these policies, especially around “replication of functionalities,” simply because they are unenforceable due to so many innovations created using Facebook data sets? Perhaps, it is also hard for Facebook to define “what their core” functionality is given their scope from “voting” to “fashion” to online “shopping,” etc.
Why would Facebook keep these policies in earlier times and drop them now? Do they really want others to use their data to build features and functions that could infringe on their IP? It is not very hard to conceive that with 1000+ patents, it’s not very difficult for them to cite violations of their IP rights. They could very much protect those rights while denying developers access to their APIs and data. That too, after the fact that some applications may already be relying upon their APIs and data heavily.
Now the question is, when does Facebook strike? Do they wait until specific applications prove a viable or profitable business model? Or do they strike early on? For example, Facebook routinely scrutinizes companies that are using their APIs while denying access to many. It would be wise not to make any assumptions, but it is clear that companies (and not just Facebook) can exercise these options to their advantage.
Does API Non-Compete ToU Break Antitrust Law?
Federal Trade Commission (FTC) made some important observations in their lawsuit: “In order to communicate with Facebook (i.e., send data to Facebook Blue or retrieve data from Facebook Blue) third-party apps must use Facebook APIs.” (Facebook Blue is an internal term used by Facebook to distinguish the “main” Facebook platform from Instagram and Whatsapp). Clearly, APIs are at the core of this lawsuit.
Chris noted that: “As the main platform exploded over time, Facebook began changing the rules to specifically punish or reward developers. This was particularly the case if Facebook felt those app developers posed a competitive threat.” Chris also gave several examples of companies that Facebook scuttled, including Color and Path. According to the FTC lawsuit, Facebook shut down its API usage, which contributed to the closure of these companies. Although Facebook accused these companies of violating its “Spam” policy, it is not hard to imagine the real reasons behind these shutdowns. Since then. Facebook has moved on to build short video-based features (that Color specialized in) and other small community based social networking features (that Path specialized in).
According to FTC’s December 9, 2020 press release: “Facebook has engaged in a systematic strategy—including its 2012 acquisition of up-and-coming rival Instagram, its 2014 acquisition of the mobile messaging app WhatsApp, and the imposition of anti-competitive conditions on software developers—to eliminate threats to its monopoly.” That is where it spiked my interest to collect some evidence from Facebook’s ToU. We may never know what Facebook’s actual underlying API strategies are, but significant FPP changes indicate the potential weaponization of APIs. Or at least, data-driven companies may have that power as an option if they choose to wield it. The example I gave is Facebook, which is already being investigated for a breach of antitrust laws. Yet, it does not mean that Facebook is the only company that is using its APIs underhandedly.
I want to emphasize that APIs (and other similar technologies) are here to stay. Their benefits far outweigh the business and legal risks that I highlighted above. Nonetheless, we must track agreements and policies that govern the usage of APIs and data as they could evolve, and any ambiguity around their compliant usage could be detrimental to businesses. That’s true not only when enterprises are consuming APIs, but also when they are producing APIs with ambiguous policies. These API policies could indeed act as weapons, but like a double-edged sword, which could swing both ways. So let’s do the right thing and enable APIs to build the next generation of digital innovations in a responsible manner.
Source: Nordic APIs