An End To API Gaslighting?

The Supreme Court decision in Oracle vs Google ends a decade-long nightmare for open source developers.

Sunlight or gaslight?*

The decision of the US Supreme Court (SCOTUS) to reverse the erroneous conclusion of the US Federal Circuit appeals court (CAFC) that Google’s use of the Java SE API in Android was a copyright infringement comes as a great relief to open source programmers everywhere. Software developers have always assumed that merely including a function prototype in their code does not require copyright permission as it’s just a fact about the implementation.

Re-implementing a whole set of functions using only the original prototype so that a compatible program can be created is thus normal; the first wave of open source completely relied on doing so. The whole global open source community has been working for decades on the assumption that a re-implemented API does not risk a lawsuit. So the Pandora’s box Oracle tried to open was felt as an existential threat.

The decision issued on April 5th is a great outcome, albeit falling short of what might have been achieved had SCOTUS dived fully into the boundaries of copyrightability as Google asked in their petition. It aligns the US with the norm in Europe as well as affirms that the law in the US matches the common-sense expectations of programmers.

The Java Journey

How did we even get here? Sun Microsystems created the Java platform, a combination of a programming language and a comprehensive suite of helper functions split into three “editions” all of which are colloquially referred to just as “Java”. The promise of Java was famously “write once, run anywhere” – an abstraction achieved by using a software-implemented chip that’s ported to every hardware platform, hiding platform differences and delivering a uniform programming environment that’s agnostic to the hardware it runs on.

The core language and libraries, Java SE (“Standard Edition”), were widely adopted due in no small part to Sun’s vigorous application of licensing controls so that implementations were the same everywhere. Java ME — the edition aimed at mobile phones (not “smart phones” – this was before such things existed), was also widely adopted by phone manufacturers. But instead of the uniformity achieved by Java SE, Sun tolerated divergent implementations in return for significant licensing revenue. The result was that Java ME allowed manufacturers to “differentiate” and software in the after-market needed testing and maybe rewriting for every new phone. Write once, test everywhere.

Google saw a market opportunity here, not least after realising Apple were “going big” with the new “Smart Phone” product category with their Apple-only iPhone, and invested heavily to create the Android platform. What distinguishes smart phones from their ancestors is a uniform application layer served by a global app store so all models of phone can run the same apps. By hiding all the hardware differences under a uniform platform, Android allowed the software market on phones to transcend networks and hardware vendors. It created exactly the market Java ME should have created were it not for Sun’s tolerance of phone manufacturer “differentiation”.

Because so many programmers already knew how to use it, Google decided that the right programming language for Android was Java, but that the hot mess of Java ME should be avoided along with Sun. They created a whole new universe of helper functions with different names and architectures while ignoring those created by Sun for Java ME. But in order to use the Java programming language, they had to implement the core language functions of Java, and it just so happens almost all of those are also implemented as libraries of helper functions too. So Google took the function prototypes of those core language capabilities from Java SE and wrote (or otherwise obtained) completely unrelated code to implement them.

To a programmer, doing so seems obvious and unremarkable. Google didn’t copy implementing code from Java SE; they wrote a fresh implementation of the programming language, just as generations of software tool companies had done for every programming language. To Sun, while it was regrettable in revenue terms that Google had decided not to follow the path to Java ME, at least they were using Java as the programming language for Android while driving its adoption and market growth in a whole new, completely different market. Far from litigating, Sun welcomed Android and promised to support it in their open source NetBeans IDE.

Lighting Up

Just three years later, Oracle acquired Sun in early 2010 and took over stewardship of Java. Oracle then immediately sued Google for patent and copyright infringement over their use of Java. Despite seeming promising, the patent infringement case was quickly dismissed, leaving only the weak copyright complaints. That was when the gaslighting started.

The heart of the lawsuit’s copyright strategy was an attempt to persuade courts that the reality software developers understand is not real. In this case, Oracle’s legal team aimed to persuade the court that the term “API” didn’t refer just to an application programming interface in the sense of a set of function prototypes, but to the whole body of code implementing it as well. They then used an artificial distinction for elements within that presumed body of code, “declaring code” and “implementation code”, so that function prototypes sounded like they were part of the whole work and weren’t just placeholders. When practitioners spoke from their experience without defining “API”, this framing meant their factual statements sounded like they supported Oracle’s case.

By seeding these and many other complexities to reframe reality, the court was led down a path of treating function prototypes as if they were part of the implementation code itself. With this sleight of hand, it was then easy to characterise use of function prototypes as if it was appropriation of the code. This created cognitive dissonance in anyone already familiar with programming, resulting in many attempts to clarify with analogies. That seemed to include the district court judge, William Alsup, who I remember asking me at the end of my witness testimony in the court how I understood an API.

While Alsup saw through it, by building on this constructed complexity Oracle managed to persuade the CAFC (essentially a patent appeals court) to overturn the thoughtful judgements of Alsup’s district court. Like the dissenting option to SCOTUS from Justice Thomas and the outrage of IP maximalists after the case, CAFC’s finding was simplistic in its handling of the reality understood by developers and heavy on bad assumptions about software, based partly on being patent specialists and partly on not understanding about function prototypes.

Every conversation about the case with Oracle’s staff and legal team had the feeling of cognitive dissonance that’s characteristic of being gaslighted. They sought to make every practitioner challenging their position feel they were inexperienced, naive and lacked understanding of the technology. This went on for years. The feeling of despondency that accompanied the final CAFC holding, once again overturning the district court’s reality-based judgement, was overwhelming.

Extinguished by SCOTUS

So the decision of the Supreme Court on April 5th was like finally being released and affirmed. Wisely, the court avoided the byzantine complexities that had enabled the gaslighting in the first place. SCOTUS asserted that since a reversal on the fair use matter would render any outcome of the copyrightability issue moot, they would only expend effort on the fair use matter. They then held that — regardless of the extent to which an API is copyrightable — if a party “reimplemented a user interface taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, [the party’s] copying of the … API was a fair use of that material as a matter of law.” 

Justice Breyer, who had been a leading copyright scholar prior to his judicial career, has written for the court a wise, strong, precedent-setting outcome that reflects the reality programmers expect, which is that the use of an external function declaration alone doesn’t give others a control point. That expectation has been almost universal for the whole history of programming and SCOTUS has correctly upheld the consensus of the public in the face of self-serving gaslighting. As if to confirm the practical effect of the finding, Justice Thomas has voiced the outrage of the copyright maximalist community using the conceptual framework of the gaslighters in his dissent. It seems even the dissenters agree the court’s decision is strong.

While there is obviously a risk of future cases exploring the limits of what constitutes a user interface in API terms (and of course nothing in this article should be understood as legal advice}, it seems that in the majority of cases concerning open source developers, the reality they expect will also be the reality in law.

Many thanks to the friends who checked this over for me, especially Richard Fontana and Rich Sands. All the errors remain mine.

*(It’s sunlight)

A Rights Ratchet Score Card

A draft scorecard for determining if a software project is open as bait for a business pivot or genuinely keeping your freedoms protected.

Open or closed? You decide.

The seven signs a project is following the rights-ratchet route to riches and the framework for going beyond licensing can be augmented by some straightforward indicators of an issue. None of these alone is necessarily a cause for concern, but the more clicks, the more risks. Here’s a rough-and-ready first draft of a scorecard to check whether your software supplier considers you a community peer and will respect and protect your essential freedoms, or visualises you more like one of those pods in The Matrix. Just count the clicks; the more clicks, the higher the risk this is a rights-ratchet that will end up closed.

Continue reading

What Did Sun’s OSPO Do?

Started in 1999 and established as an official corporate function in 2005, Sun’s Open Source Program Office (OSPO) was among the first in the industry and maybe the first to use the name.

As I’ve discussed in earlier posts, corporations are the vehicle for the collective expression of many individuals. However, to the outside world they are a monolith, and are expected to be consistent as well as predictable in their actions.  With the many varied, implicit expectations and explicit obligations that different open source projects have, transforming a company’s reputation into that of a good actor in open source is a complex task.  It’s also a necessary one if you expect other actors to invest their time and work in your project, or to give you influence in steering a project together.

Continue reading

Accommodating Open Source In Standards Processes

Holders of zero-tolerance positions on both sides of the divide need to realise that accommodating open source productively inside standards bodies is both viable and happening now.

A fine balance

You’ll recall that open source and open standards are orthogonal concepts where even the words they share (like “open”) are defined differently. That doesn’t mean they are mutually exclusive, nor that they are bad together – they can be cultivated well in the same garden. There is great value from accommodating the two orthogonal concepts so that neither is invalidated by non-mandatory elements of the other. When they combine, great value is unleashed.

Continue reading

Growing Blueberries

Why accommodating open source at a standards body is like growing blueberries.

Fresh-from-the-bush blueberries are one of the good things of life. When I set up my home office about a decade ago, I had to install an underground conduit to supply essential services — power, water, network — and dug a deep trench all along the path that leads there. When I refilled the trench I decided to plant a blueberry hedge so looked into how to grow good blueberries.

Continue reading

The FAQ as Vital OSPO Tool

Using a community FAQ as a way to get internal disagreement addressed and external communities on board – the OpenJDK experience!

In this talk from FOSS Backstage 2021, Rich Sands and I discuss the way we used a (very large) FAQ to both align the disparate corporate functions inside Sun Microsystems and address the lack of trust in Sun by both the Free Java community and the wider open source community. What we did back then is still a highly appropriate tool for any OSPO that needs to stand in the divide between a controversial corporate position and an aggravated community.

Software Freedom For Business Value

Software freedom is important to as an idea, but it also creates all the value of open source for business and should be jealously guarded by OSPOs.

In talking about open source, I and others routinely use the expression “software freedom” to refer to the set of rights upon which the open source phenomenon is based. It arises as a synonym for “free software”, an unfortunately ambiguous term that leads people hearing it for the first time to conclude all the primary attributes of open source software relate to money — price, cost-of-ownership, license fee and so on.

“Software freedom” puts the focus in the right place — on the essential liberties required to benefit from the software. One problem with this alternative term is we are becoming accustomed to hearing discussions of “freedom” be limited to activist or political contexts, and consequently regard the term “software freedom” with caution. But a focus on software freedom isn’t just for the revolutionaries.

Continue reading

Permission Beyond Licensing

Is that single-company-controlled project actually open source in the sense of delivering software freedoms to you or just about delivering prospective customers to its host company? Here are 7 tests.

I frequently sum up the nature of open source licensing as granting permission in advance to developers or users to use, improve and share the software for any purpose. But the “Permission In Advance” lens has uses beyond just the rights to copyrights and patents granted in an OSI-approved license. 

In my consulting engagements, I use a “thinking tool” to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy — both to join it and to host it — should begin with the question: “How confident are community members that they have permission in advance to do whatever they need to succeed?” The more reasons for confidence, the larger the community.

Here are some of the questions community members will be asking, perhaps silently, about single-company open source projects and their own agency as a member of the community:

Continue reading

OSPOs As Community Advocates

Is your Open Source Program Office just part of your corporate defences, or is it the community’s advocate inside your company as well?


As we considered before, corporations are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, showing the outworking of the processes and systems they devise to embody their vision. So the work of an Open Source Program Office (OSPO) needs to address social change within the company and address community needs outside as well as compliance or other corporate self-protection.

Continue reading

Corporate Maturity As Stochastic Outcome

Corporate open source maturity may be better evaluated by considering the actions of individuals and small groups statistically rather than evaluating the stated corporate strategy

It’s easy to forget that corporations (and indeed large non-profits) are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, as well as the outworking of the processes and systems they devise to embody their vision. Things happen not because a faceless corporation somehow chooses to act in a certain way from a point in time, but because of the persuasive decisions of actual people, acting within their belief systems and directing the work of others.

Collective Behaviour

Every good – and bad – decision ultimately goes back to an individual somewhere, and corporate effects are in many ways emergent. So fitting a maturity model to a corporation may not be the best way to predict its future outcomes. That is a trailing indicator driven by the behaviours of the individuals within the company.

Continue reading