My Oracle vs Google API Copyright Journey

Soon after beginning my journey as the API Evangelist in 2010 I began quickly realizing that there was more to this game than just technology. The mission of the blog was to get beyond the technology of APIs, and focus on the business of APIs. Which in 2010 was emerging as the biggest driver of why and how you do APIs, over the actual technical styles, practices, and approaches to delivering API infrastructure. I also quickly realized that it wasn’t just about business, and that there direct and indirect political layers that determine which direction APIs are pushing the tech sector. One critical conversation involving APIs that spans both the business and politics of APIs was the Oracle vs. Google copyright case. I had read about the case back in 2010 and 2011, but I really didn’t understand what it meant until the case got up and running in 2012. Kicking off an almost decade long journey for me as I studied and thought about API copyright, followed the case, then actually begin contributing to the case as part of the EFF’s push to help keep APIs free from copyright, ultimately coming to a conclusion this last week as the Supreme Court returned their decision that APIs were indeed copyrightable, but Google’s use of the Java APIs was indeed fair use.

The Oracle vs. Google API copyright case began as two parts, 1) for patent violations, and 2) for copyright infringement involving the Java API. The jury found Google in violation of copyright law for the 11,500 lines of code they reused from the Java API, but acknowledged that it fell under fair use, and then found no fault in the claim of patent violations. However, in the end Judge Alsup declared that fair use didn’t apply because you can’t actually copyright APIs—-which gets at the truth of all of this in my belief. The judge went the extra mile by actually learning Java so that he could understand the layers of an API, and how they actually work, something that if the Supreme Court had evaluated API copyright, they would have come to same conclusion. Anyways, of course Oracle filed an appeal, which ultimately overturned the the previous decision ad stated not only were APIs copyrightable, but Google’s usage of the Java API did not fall under fair use. Leaving APIs as something that is copyrightable, and some enterprise organizations feeling pretty emboldened about suing you for reuse or reimplementation. Thankfully Google elevated the conversation to the Supreme Court, bringing us to the decision last week that stepped us back from the edge a little bit with a pretty broad interpretation of what fair use means when it comes to APIs—something that I feel will give us the room we need to properly grow and innovate, but ultimately we need to help folks see that it is better for everyone if copyright doesn’t apply to APIs all.

A Decade of Learning and Thinking About API Copyright

I have spent almost a decade now thinking about API copyright, having written over twenty posts on the subject. Some of them are just simple blog posts, but some of them reflect hours of research, learning, and distillation of ideas. It is fascinating to evaluate how much I have learned about the subject, and how much more there is for me to understand about this fast growing dimension of our digital world.

I’d say this list represent my work as the API Evangelist well, in that some of it is very notebook ideas, with spelling and grammar mistakes, with others being deeper looks into how we start separate the layers of an API so that we can apply licensing, all the way to some pretty valuable contributions like the API Commons, and the usage of the restaurant analogy for APIs, which Google’s lawyers used as part of their defense after I provided. I have learned a lot throughout this journey, and just spent my weekend reprocessing it all, while also reading the Supreme Court ruling in it’s entirety--twice. I enjoy having my head wrapped around this concept, and feel like I have a firm grasp on the layers of what an API, and properly see it’s evolution and how it gets applied in the real world. It makes me feel like I have something unique and valuable to give back to the world—-which is ultimately why I do this work.

Accepting The Scope of Fair Use Defined by the Supreme Court

I am determined to convince the world that copyright should not be applied to APIs. However, I am optimistic regarding the scope of the definition of fair use that the Supreme Court has carved out. The Supreme Court operated under the assumption that copyright does apply to APIs, but considered four guiding factors set forth in the Copyright Act’s fair use provision: the purpose and character of the use; the nature of the copyrighted work; the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and the effect of the use upon the potential market value of the copyrighted work, before it ruled in favor of Google. In their ruling they made a distinction between declaring code and implementation code, meaning Google only copied declarative code, which are the parts of an API a developer references as part of their integration and then ultimately calls the implementation code, which API developers do not have any visibility into. This is an important distinction that can be used to further define fair use for copyright applied to web and event-driven APIs, as the declaring code is further separated from the implementation code by HTTP or TCP, as well as the migration of APIs to API gateways instead of programming language frameworks over the last decade. By design the declarative portion of a web API is the fair use portion of an API, in that it uses open source standards like HTTP and TCP as the declarative transport, which includes the usage of public DNS for the addressing. The declarative code for an API has been been baked into the public web, so I am not to overly concerned that we won’t be able to define fair use of APIs within this realm.

I will be pushing more API providers to publish a copyright license for their API as part of their OpenAPI or AsyncAPI, and expecting API service providers to offer some sort of API licensing capabilities anywhere an OpenAPI or AsyncAPI is put to work as part of the API lifecycle. It sucks that we have to do this, but it is the bar that Oracle set for the industry with it’s court case, so we have to work within this definition. I recommend publishing a Creative Commons CC0 or CC-BY license>a for each one of your OpenAPI or AsyncAPI definitions. I know some folks use an Apache, MIT, or other license here, but we aren’t talking about server-side or client-side code here, we are simply talking about the “structure, sequence, and organization” of your API, not your secret sauce behind. I am going to put some more work into API Commons to bring things up to date with how I see things after the Supreme Court ruling. I want clear licensing separate between the server side (implementation), the API definition (declarative), the client code, as well as the data, content, media, and algorithms that are the bits and bytes being passed back and forth. Ultimately I will be making an argument that the part of your API you describe with an OpenAPI or AsyncAPI is the fair use portion of your API, and that the declarative portion of an API as cited by the Supreme Court has further moved into the fair use realm as we move from language APIs to web APIs. Honestly, this dimension I speak of is really the actual API that Judge Allsop said copyright SHOULD NOT apply to, but since we have to operate in a world where copyright does apply, we’ll play by the fair use definition—until something shifts the line back to a place that will accommodate the future of API infrastructure.

The Purpose and Character of API Reuse

Another area in which the Supreme Court used as a guiding factor for ruling in favor of Google’s reuse of Java APIs was the purpose and character of the re-use. This was the hardest for me because you really can’t say that either Oracle or Google’s purpose and character is honorable. I mean, Oracle waited all but 7 months after buying Sun before they sued Google from patent and copyright infringement, and honestly Google’s reuse of Java API seems a little lazy, but I can see why they’d want their APIs to be familiar to Java developers. But, really, is that of an honorable purpose or character? IDK. I really don’t like this area when it comes to determining fair use, because there are many different intents behind the why and how an API will get re-used, spanning the technology, business, and politics of the API and the industry it operates within. Actually, maybe leaving it as part of the guiding factors, it means we’ll need to think more deeply about each re-implementation, forcing us to have a more meaningful conversation around how API provider and consumers strike a balance. I think in the end, if you are re-implementing someones API, 1) make sure you provide attribution, and 2) make sure you provide value to whoever you are copying. Then if you are someone who is allowing your APIs to be re-implemented, 1) make sure you have a license applied to your API, and 2) make sure you allow for value to be realized by your consumers and ensure that their is reciprocity when it comes to the relationship. Ultimately, the purpose and character of the API provider and API re-implementor, and you really have to consider all of this on a case by case basis, acknowledging there will be good and bad across the spectrum.

Learning and Building on What Came Before

I am pretty confident of the argument in the separation of the declarative portion of an API from the backend implementation in defense of fair use for the re-implementation of a language API. In light of the Supreme Court ruling. I am even more confident using this as an anchor for web APIs as described above. However, I know the importance of precedent and I wanted to further expand my understanding, while bolstering my argument by jumping down the rabbit hole of a few of the key citations from the Supreme Court ruling, helping understand the foundation of using fair use in defense of API re-implementation.

I am guessing I will learn a lot diving into each of these areas of the copyright argument. I particularly interested in the Nimmer on Copyright and the argument that it is easier to defend fair use in the realm of fiction or fantasy, because I mean, APIs are just digital make believe. ;-) Also I find the argument that you have to look at fair use closer when it comes to digital copyright, “in light of rapid technological change”—I am thinking I can carve out a pretty strong API-first style iteration argument here, and that fair use is essential part of the perpetual digital transformation we find ourselves in. Something that will never end as part of the ceaseless and unrelenting march forward of Internet fueled capitalism.

What an Amazing Journey

Looking back at this decade long journey I find myself pretty thankful for having a front-row seat for this. I have learned a lot. Along with my time working in Washington DC on other API policy, this rises pretty high on the list of things I’ve done that I consider having had a significant impact on the world. Ultimately, this is the type of work I want to be doing as the API Evangelist. Covering simply startup, or even enterprise APIs just hasn’t been nourishing enough for me, and I need much loftier challenges when it comes to doing what I do. I have really enjoyed learning about the law, and I learned so much from other actors along the way, like Sarah Jeong and Judge Alsup, who dedicated themselves to understand these very abstract concepts, while also still bringing heart and personality to the debate. I also have to call out Steve Willmott the former CEO of 3Scale, which was acquired by Red Hat and then IBM—-he bankrolled much of my earlier contributions to the discussion, and helped me carve out the time where I could sign on as part of the amicus briefs. While I am thankful the journey, and I feel like we’ve come to an important milestone in this journey, I do not think this is at all over. I don’t think there will be many enterprise organizations who try what Oracle did in the world of web and event-driven APIs, but I am confident there will be plenty of people who do not understand APIs, and look to lock things up and slow things down so they can generate more revenue.

I am going to do some more writing on the evolution in APIs from language APIs to web APIs, and how the declarative portion has moved even further into the fair use zone with web APIs. I am also really keen on investing the in strengthening the fair use argument based upon the rapid iteration and evolution of the API layer of the desktop, web, mobile, device, and network applications that define our world. APIs, and more specifically API-first, is all about rapid iteration, and this is precisely why you don’t want copyright applied in here gumming up the works. It is like someone in the early 1800s convincing everyone that you use glue in all of the gears of the factory instead of grease. The digital gears of the API economy are defined by the “structure, sequence and organization” of our digital resources and capabilities, the literal forward motion of these digital API gears are define by their ability to be iterated upon and evolved—this is the modern digital factory floor, and it is dependent on the velocity of it’s APIs. You do n’t make money off slowing down the API factory floor, you generate revenue off the exhaust of its operation at a sustainable velocity. Copyright has no business in the “structure, sequence and organization” of our digital resources and capabilities being defined by web and event-driven APIs, and the practice of generating revenue by licensing APIs is antiquated, and something that has no place in a fully digital enterprise. I am pretty thankful that in 2021 I can see this, but I predict I will evangelizing and converting people to this reality until the end of my career.