Michael Hussey
Google v. Oracle. It’s a sensational case. A battle of tech heavyweights — and a software copyright case that went all the way to the U.S. Supreme Court. Millions of dollars are at stake. And the ramifications for software entrepreneurs are significant.
The facts are not in dispute. Google copied a portion of Oracle’s Java application programming interface (API) to create the Android operating system — the most installed mobile operating system in the world.
Oracle then sued Google for copyright infringement, but lost in federal district court. Then, surprising many, it won a major victory — a reversal at the U.S. Court of Appeals for the Federal Circuit — an appeals court directly below the U.S. Supreme Court.
The Federal Circuit, overturning the district court’s decision, decided that Oracle’s Java API is copyrightable. And in June of this year, the U.S. Supreme Court refused to consider the case.
Software developers routinely treat APIs as exempt from copyright protection. That was Google’s assumption when it copied the Java API. That assumption must now change. Under the court’s logic, nearly any API larger than a few words or phrases could be protected by copyright.
Now, Google and other developers who copy an API without having a license to do so may have only one defense: a doctrine in copyright law called “fair use.”
The jury in the district court case already considered whether Google’s copying was fair use, but was unable to decide. So this high-stakes case now falls back into the hands of a hesitant jury charged with deciding whether Google’s having used Oracle’s Java API for its Android operating system was in fact fair use. There is no way to predict the outcome.
Because using APIs is so common, startups, as well as established software companies, need to operate with a clear understanding of this legal battle. They need to understand the implications of this decision in order to avoid running afoul of others’ copyrights — and to leverage their own.
Copyright Versus Patents
The difference between copyright and patent protection is often misunderstood. In the context of software development, copyrights and patents protect two entirely different, non-overlapping aspects.
Patents protect functional aspects of software, such as processes and methods of operation. We generally think of these as features of the software. Reproducing patented processes and methods, even in independently written code, is patent infringement.
In contrast, copyright only protects artistic aspects of software code, not its functional aspects. Consequently, if software is protected only by copyright, then others may appropriate any of the features implemented by the software by simply writing their own code independently.
America’s courts have historically struggled with how to separate artistic aspects of software code from functional aspects. Because software is mostly functional, you might think that copyright protection of software is weak. Generally, you’d be right.
But copyright protection is very useful if someone copies either the source code or the compiled code. If someone literally copies all or a portion of such code, then a court would probably decide that at least some artistic aspects were copied, thereby infringing the original developer’s copyright.
But, you think, if that is the case, why would Google think it could literally copy a portion of the Java API? The answer is based on a well-established principle of copyright law that tries to prevent granting patent-like rights through copyright. Specifically, according to the Copyright Act, copyright protection in a work must not extend to any functional system or method of operation, regardless of the form in which the system or method is described in the work.
One reason for this copyright principle is the differing ease at which protection may be obtained. Copyright protection arises out of the creative effort of writing software. No application for copyright protection is required. In contrast, to obtain patent protection, an application must be filed at the U.S. Patent and Trademark Office. A highly trained patent examiner reviews the application against the state of known technologies. An examiner may only grant a patent when convinced that the claimed invention is new and not obvious over such technologies.
Google had argued that if the Java API were copyrightable, then copyright protection would effectively extend to the functional system described in the Java API. Thus, Google claimed, for anyone to create a functional system exactly as described in the Java API, they would have to copy the Java API.
Then, said Google, because copying the Java API would infringe Oracle’s copyright, its copyright effectively extends to the functional system described in the Java API — improperly granting patent-like rights through copyright.
The Federal Circuit disagreed. It reasoned that “the declaring code [in the Java API] could have been written and organized in any number of ways and still have achieved the same functions.”
For example, the Court argued that the Windows Phone API from Microsoft provides “similar functionality” with an entirely different structure, naming scheme and selection than the Java API. Whether Google could copy the exact functional system described in the API is apparently a question of compatibility, which the Court said should be addressed with a “fair use defense.”
Avoiding Copyright Infringement
One tip to avoid copyright infringement is developers should not copy a third-party’s API unless the developers have a license to do so. That sounds straightforward, but it is often difficult or impossible. Say a company plans to develop a new software product that will compete with a competitor’s existing software product. Customers will access the new software product through an API.
Competitor customers also access the competitor’s existing software product through an API. To encourage the competitor customers to switch to the company’s new software product, the company may be tempted to copy the competitor’s API. If the new API is the same as the competitor’s API, then the competitor customers would not need to make any changes to their code to use the company’s new software product.
In such a scenario, the company should not copy the competitor’s API without a license and rely on the fair use defense without first consulting a copyright attorney. Fair use is highly fact-sensitive — and highly subjective. A jury weighs multiple factors, and it is difficult to know in advance whether any fair use defense will succeed.
Surprisingly, if the innovating company develops a new API instead of making an identical copy of the competitor’s, it still risks copyright infringement. A copyright owner may prove that an original work has been copied by first proving that the accused infringer had access to the original work and second showing that the accused work is “substantially similar” to the original. In this “copy test,” direct evidence of copying is not a requirement.
So, developing a new API may risk infringement even if the new API is not identical to the competitor’s and was not actually consciously copied from the competitor. If the two APIs are found to be “substantially similar” and the developers of the new API had access to the competitor’s, then that competitor could successfully argue that the new API infringes their copyright.
You can surely imagine the scene in court where an attorney shows a jury the two APIs side-by-side, and points out all the similarities!
One way to mitigate this risk is to develop any new API using “clean room” development. In this approach, the desired functionality is given to a developer, who writes the new API from scratch without ever accessing the competitor’s API. This technique addresses the issue of whether one’s developers had access to the competitor’s API in the “copy test.”
If a company is a startup, though, all its developers may already have had access to the competitor’s API. That may make a “clean room” option economically unviable because the startup would have to hire one or more other developers who demonstrably had no access to the competitor’s API.
Instead, the company may deliberately try to make the new API different from the competitor’s. It may first instruct its developers to develop a unique new API based on the desired functionality without referring back to the competitor’s API; then it could compare the resulting new API to the competitor’s and modify any elements that are too similar. However, this “deliberately different” option is much riskier than the “clean room” option.
Protecting Software
How can a company protect its own software? One way is to publish its APIs just to make it easier to show that a competitor had access to them. Ideally, there also is another legitimate reason to publish its APIs, such as to provide online documentation for users. Then, if the competitor creates a substantially similar API, a company might succeed in a copyright infringement claim.
That brings us back to patent protection, which should be sought for new and innovative features. Although recent Supreme Court rulings such as the notable 2014 decision in Alice Corporation v. CLS Bank Intl. have made patenting certain categories of software inventions more difficult, patents on software features for many different technologies are alive and well.
Parting Thought: Issues For Some Entrepreneurs Are An Opportunity For Others
As just explained, the decision in Google v. Oracle is inconsistent with many software developers’ past view of APIs. As a result, many APIs now probably infringe another’s copyright. For better or worse, this creates opportunities for entrepreneurs to make money based on litigation or a threat of litigation. Some such scenarios might be viewed as the copyright analog of what have commonly become known as “patent trolls.”
Specifically, entities may emerge that purchase copyrights in original APIs, search for instances of others’ copying those APIs without a license and sue for damages. That surely would be an unintended outcome of the Federal Circuit’s decision — and one worth keeping an eye on.
This article is intended to provide information of general interest to the public and is not intended to offer legal advice about specific situations or problems. You should consult a lawyer if you have a legal matter requiring attention.
Comment