Oracle v Google: What the API Copyright Case Means for Australian Businesses

What happens when you write your own software code, but deliberately make it work like someone else’s?

That question sat at the centre of one of the most significant software copyright disputes of the past two decades: Oracle America, Inc. v Google LLC.

The dispute ran for more than a decade, reached the US Supreme Court and involved a fundamental question about where copyright protection ends and software functionality begins.

For Australian businesses, there is another important wrinkle. Google ultimately succeeded because of the US doctrine of fair use. Australia does not have an equivalent general fair use defence.

So, while Oracle v Google is a US case, it offers some valuable lessons for Australian software developers, SaaS businesses and founders — including some lessons about what not to assume when borrowing from US technology cases.

How did Oracle and Google end up in court?

The story begins with Java.

Java was originally developed by Sun Microsystems and had become an enormously popular programming platform. When Google was developing Android, it wanted to make the new operating system attractive and accessible to software developers.

One way to do that was to let developers use programming commands with which they were already familiar.

Google and Sun discussed a possible licence, but ultimately did not reach agreement.

Google then developed its own implementation for Android. However, it copied approximately 11,500 lines of what is known as Java declaring code, forming part of 37 Java API packages.

Oracle subsequently acquired Sun and, with it, the Java technology and associated intellectual property rights.

In 2010, Oracle sued Google.

What exactly is an API?

API stands for Application Programming Interface.

In very simple terms, an API provides a way for one piece of software to interact with another.

Think of it a little like ordering from a menu.

The menu tells you what is available and how to ask for it. You don't necessarily need to understand what is happening in the kitchen to place your order.

Software APIs perform a somewhat similar role. They allow developers to request particular functionality using defined commands.

This was important for Android because developers who already knew Java could use familiar commands rather than learning an entirely new system.

Google largely wrote its own underlying implementation. But it retained parts of the familiar Java interface.

And that distinction became extraordinarily important.

"But we wrote the code ourselves"

This is one of the reasons Oracle v Google remains such an interesting case for businesses.

There is a common assumption in software development that copyright risk can be avoided simply by writing new code.

Sometimes that may be true.

But copyright questions can become considerably more complicated where a developer recreates elements of the structure, sequence or organisation of an existing system.

Oracle argued that Google's use of the Java API declaring code infringed its copyright.

Google disputed that position and, importantly, argued that its use was protected by the US doctrine of fair use.

The litigation then spent years moving between courts, with different findings at different stages of the proceedings.

Eventually, the dispute reached the US Supreme Court.

What did the Supreme Court decide?

In 2021, the Supreme Court ruled in Google's favour.

But there is an important qualification.

The Court did not finally determine whether the relevant Java API material was protected by copyright.

Instead, it assumed for the purpose of deciding the case that the material was copyrightable and considered whether Google's particular use amounted to fair use.

The Court concluded that it did.

Among other things, the Court considered the functional characteristics of the declaring code, Google's purpose in using it, the proportion of the Java API material that had been taken and the potential market effects.

Google had used the material as part of creating a different computing environment — Android smartphones — and the Court considered its use transformative in the particular circumstances.

That was enough for Google to succeed.

But this is where Australian businesses need to be particularly careful when reading about the case.

Fair use and fair dealing are not the same thing

The United States has a broad fair use doctrine.

Rather than providing an exhaustive list of circumstances in which copyrighted material can be used, US law requires courts to consider a range of factors when deciding whether a particular use is fair.

That gives US courts considerable flexibility when dealing with new technologies and unusual factual circumstances.

Australia does not have the same general fair use defence.

Australian copyright law instead contains a series of fair dealing exceptions for particular purposes.

These include circumstances such as:

• research or study;
• criticism or review;
• parody or satire;
• reporting news; and
• certain uses connected with professional advice and judicial proceedings.

The distinction matters.

It is not enough in Australia simply to argue that your use of copyright material was reasonable, innovative, transformative or "fair".

You generally need to identify an applicable statutory exception.

For a commercial software company copying material because doing so makes development easier or its product more familiar to users, that can be a very different proposition from the US fair use analysis applied in Oracle v Google.

So the lesson from the case is not that businesses are free to copy API structures provided they do something innovative with them.

The legal position is considerably more nuanced — and jurisdiction matters.

What does this mean for an Australian software business?

Imagine you are developing a SaaS platform.

Your development team identifies an established competitor and says:

"Their system works really well. Let's build ours the same way, but we'll write all the code ourselves."

That should prompt some further questions.

What exactly does "the same way" mean?

Are you copying an idea or functionality that copyright does not protect?

Or are you reproducing source code, screen content, documentation, graphics, database material or other copyright-protected expression?

Are you replicating the structure or organisation of an existing work closely enough to create an issue?

Are you using open-source or third-party components?

If so, what do their licences permit?

And has anyone documented where the various components of your software actually came from?

These questions become particularly important as a business grows.

The due diligence problem

IP problems have an unfortunate habit of becoming visible at precisely the wrong time.

A startup might operate for years without anyone asking detailed questions about the provenance of its software.

Then it seeks investment.

Or receives an acquisition offer.

Or licenses its platform to a major customer.

Suddenly, someone conducting due diligence wants to know:

Who owns the software?

That question can quickly turn into:

• Who wrote it?
• Were they employees or contractors?
• Were appropriate IP assignments signed?
• What open-source software is incorporated?
• What third-party APIs are being used?
• What licences apply?
• Was any part of the product based on a competitor's software?
• Can the company actually grant the rights promised in its customer agreements?

At that point, "our developer said it was fine" is rarely a satisfying answer.

Five practical lessons from Oracle v Google

1. Writing your own code doesn't answer every IP question

The provenance of the underlying code is important, but it isn't necessarily the end of the analysis.

Look at what your developers used as their reference point and what elements of existing products have been reproduced.

2. Understand your third-party dependencies

Modern software is rarely built entirely from scratch.

APIs, libraries, frameworks, open-source software and other third-party components can all come with licence conditions.

Maintain a clear record of what your product relies upon and the terms that apply.

3. Don't assume US copyright rules apply in Australia

This is particularly important with technology law because so much online commentary originates in the United States.

A US company successfully relying on fair use does not mean an Australian company could rely on the same defence.

4. Deal with IP questions before the business reaches due diligence

Trying to reconstruct the development history of a platform five years later can be painful.

Good IP governance from the beginning makes investment, licensing and sale processes considerably easier.

5. Protect your own software strategically

The other side of this case is identifying what your business has created.

Who owns the code?

Are contractor assignments properly documented?

What elements are confidential?

What should be protected through copyright, trade marks, confidentiality arrangements or contractual restrictions?

Your software may be one of the most valuable assets in the business. Treating its ownership as an afterthought creates unnecessary risk.

The bigger lesson

Oracle v Google involved two enormous technology companies, billions of dollars and litigation that continued for more than a decade.

Most businesses will never face a dispute on that scale.

But the underlying commercial problem is remarkably ordinary.

A business sees something that works.

It wants to create something compatible, familiar or better.

And somewhere along the way, the boundary between inspiration, functionality and protected intellectual property becomes blurred.

The time to work out where that boundary sits is preferably before the product has been built, launched and scaled.

If you're developing software, a SaaS product or another digital platform, an IP review can help identify what you own, what you're relying on and where potential gaps sit.

You can also use my free IP Audit tool at www.elisesteegstra.com/ip-audit to start identifying the intellectual property within your business.

Disclaimer: This article is intended for general educational purposes only and does not constitute legal advice. You should obtain advice tailored to your circumstances before acting on any information discussed in this article.