Oracle v. Google highlights the urgent need for open court APIs
Our quest to build better, fairer courts is missing a critical ingredient: open API standards for court management systems, along with procurement requirements that mandate interoperability and prevent courts from being locked in to a specific software vendor.
A looming Supreme Court ruling in Oracle v. Google could make risks of vendor lock-in even worse, and underscores the urgent need for courts to collaborate on open, interoperable APIs.
A quick background: what is an API?
Oracle v. Google is a case about the copyrightability of software APIs. In simple terms, an API is a way to access a set of functions in software or code. When competitors use common or open APIs for the software they build, it makes it easier for users to switch between them, or to mix and match software from different vendors.
Let’s take a real-world example. S3 is Amazon’s widely-used service for storing files on the cloud. You might know it from the occasional news article where a company uploads sensitive data to S3 and accidentally leaks it to the public internet.
If I’m writing software that uses S3 to store data, I have to use S3’s API: the specific instructions that Amazon has written to access the S3 service. S3’s API and function names uses concepts like Buckets and Objects to describe places to hold collections of data, or data itself. These are entirely metaphorical: no physical buckets are being filled with objects. But, in order for my software to work properly with the S3 service, I’ll need to use those same concepts and function names in my code.
Due to its ubiquity, S3’s API is widely (and openly) copied, and has become a de facto standard. Competitor cloud services, including Oracle, replicate S3’s API structure and function names, right down to the bucket. This means that my software that I wrote for Amazon’s cloud will also work with Oracle’s cloud, or Google’s cloud, or anyone else who has copied the S3 API. This is great for customers — if I want to move my application from Amazon’s cloud to a competitor’s, I don’t have to rewrite my software’s code. This makes for a healthier, more competitive software ecosystem, and prevents users from being locked in to Amazon’s services.
Courts, APIs, and walled gardens
So what does this have to do with courts? Modern courts run on software, mostly produced by a small group of vendors. A court management system is often not a single piece of software, but several of them — docket management, e-filing, reminders, and so on — that interact with one another. This interaction relies on APIs. Open APIs can make court software more interoperable, and ensure that different software tools can communicate with one another, even if they aren’t built by the same vendor. But unlike S3, most court software APIs are closed or nonexistent.
One last example. Let’s say a court wanted to procure a reminder system, to text, call, or email defendants and self-represented litigants about upcoming court appointments and deadlines, or to provide an up-to-date case status. A really good reminder system would be able to use APIs to communicate with the court’s case management system, so it could get accurate, up-to-date information about each case, and deliver that information to defendants and litigants. In order to do this efficiently, a reminder system would need access to the case management system’s API. If court management systems used common, open APIs, a court could feel confident that any court reminder software would probably work with their system. If each brand of case management system has a different API, with different concepts and function names, or a closed API, the court has fewer options, and may be “locked in”: forced to buy whatever reminder product their existing software partner offers.
Interoperability helps courts develop a technology strategy more closely tailored to their functional needs. With open, interoperable APIs, courts could competitively procure software tools from different vendors, and could more easily ensure that they all work together. If you squint hard, you might be able to envision a court management system as a foundational platform for accessing data and services from a court. That future may still be a ways off, but without open, non-proprietary API standards, it will be even farther out of reach.
This may be science-fiction for courts, but the modern software ecosystem has been built on the assumption that APIs were not copyrightable. Oracle v. Google has thrown this assumption out the window. Here, the details of the case (Google copying parts of the Java API to make it easier for developers to work with Android) are less relevant than its consequences: that replicating APIs may run afoul of copyright law, and may not be fair use either.
Oracle v. Google could embolden court vendors to further stymie interoperability for court software. A vendor could prevent researchers, competitors, and even client courts from writing tools that interact with their court management software, that support a move to a competitor product, or that simply replicates part of their API. This could reduce competition in an already anemic market for court management software, as the cost of switching becomes prohibitively high. It could make it more difficult for courts to procure software tailored to their needs, and to work with researchers and policy-makers to analyze data about what happens in courts.
What to do about it
It’s not too late to fix this, no matter how the law around APIs are settled. Courts must adopt open data and API standards, and mandate openness and interoperability as part of their procurement requirements.
Already, good work is being done here. As part of their goal to help standardize court data, the National Center for State Courts and Measures for Justice are developing open data standards for courts. This is an effort worth supporting, but is only one piece of the puzzle.
In addition to open data standards, courts need open API standards: a common language for creating, accessing, and manipulating court data. Beyond just making it easier for people to query data from the courts, open API standards can help support a vibrant, competitive ecosystem of software for courts to improve their own operations. Once these standards are built, agencies like NIST can help maintain and steward them, as they’ve done for data standards for election and voting systems.
Vendor promises to never enforce copyright claims against their API simply aren’t enough to ensure an interoperable software ecosystem for courts. Procurement contracts should require APIs to follow (or be compatible with) open standards where possible, and be openly licensed and documented in all cases.
(Somewhere, there is the right funder and team who can build the moonshot solution: an open, interoperable suite of court management tools, owned by and stewarded for a collaboration of local and state courts. But that’s a dream for another day.)
Policymakers, judges, and researchers are struggling to learn about and improve how courts function — about their caseloads and backlogs, about their fines and fee collection, about their operations and outcomes, about how or whether limited representation and apps can help clients. Modernizing court management can help us answer these questions. We must not let software’s walled gardens hold us back from building fairer, more well-run courts.
