Yesterday, the US Supreme Court ruled that Google’s usage of Java APIs was legal, and the US IT industry breathed a sigh of relief.
The Supreme Court’s decision
What exactly did the court say? The ruling itself was very narrow. The dispute was over code that defines an API, which constituted a mere 0.4% of Java’s source code. The court made a strong distinction between interface declarations and the implementation code, so the ruling has no impact on the vast majority of software code out there. Furthermore, they declined to rule if interface code is copyrightable; instead, they invoked the fair use doctrine.
They were cautious in how they applied fair use, noting that Android is not a competing substitute for Oracle’s Java SE and that Oracle may have even benefited from Android increasing Java’s overall popularity as a language. What we find particularly interesting, though, is that the court distinguished software from other copyrightable media. It noted that computer code, unlike books and movies, has a functional purpose that creates a public interest unique from all other copyrightable media. This allowed the court to define a fair use precedent for computer code that seems to be more lenient than other media (although you should consult your local legal scholar to weigh in on the intricacies of those differences).
The court also noted that copyright protects expressions of idea but not the ideas themselves. Patents, in contrast, protect ideas — but Oracle’s patent claims had been rejected by lower courts long before it reached the Supreme Court. The court correctly distinguished between interfaces and the code implementation behind the interface. An interface definition is merely an idea of what the computer could do while the implementation code is the expression of that idea.
An analogy would be if you were to describe how to construct a room. Perhaps you want it to have two windows, a closet, and a wall-embedded bookcase. That’s a noncopyrightable idea. Different architects may create different implementations of how to express that idea through their own unique copyrightable drawings. Although the court did not say if code declaring an interface idea is copyrightable, the fact that it straddles both the worlds of non-copyrightable ideas and their copyrightable expressions gave them enough wiggle room to say that it’s a gray area. That grayness lends more support for invoking fair use principles and ensuring innovation is not stifled.
One of the arguments that seemed to lean in Google’s favor is the fact that there are only so many ways you can write code declaring an interface.
The risk management impact
Risk management professionals are also breathing a sigh of relief. Today, legal and compliance teams leverage the license risk features in software composition analysis (SCA) tools to identify non-compliant or high-risk licenses in open-source packages (and sometimes in proprietary third-party packages as well). Many SCA tools also look for code snippets or pieces of code copied from open-source libraries into the developer’s own source code artifacts. Depending on the uniqueness of the snippet, this sort of copy and paste could constitute a license violation. Legal and compliance teams understandably want to avoid any potential liability around code ownership, so a mature organization will make sure that they use all software according to the stated license and only those components with licenses that meet corporate policy.
Imagine if the court had ruled that Google had infringed on Oracle’s copyright. Those ownership and liability questions would have become a lot muddier. Every organization would be rescanning their code to look for API declarations that would put them at similar risk — and the time spent analyzing code, discarding false positives, and making educated guesses on risk levels would have led to a lot of late nights in the development, compliance and legal departments.
A ruling in Oracle’s favor would have opened the door for copyright trolls much like we’ve seen happen in the realm of software patents. That would have given even more power to big tech to sue their competition out of business. We would have worried that the specifications of any open standard could have become the target of lawsuits since they express interfaces, which was the type of code being disputed in this lawsuit. Litigation fears might have caused tech companies to avoid building APIs based on an open standard, which could have crippled parts of America’s tech industry. It reminds us of the 1990s: Federal law regulated encryption as a military munition under the Arms Export Control Act. That law drove encryption innovation overseas to nations that don’t have such laws. Experts estimate that by the mid-1990s, US companies had suffered billions of dollars in potential losses as a result. Similarly, a win for Oracle could have pushed more tech innovation to companies based outside the US to avoid lawsuits.
Are APIs copyrightable?
Will lower courts find APIs copyrightable? Even though they did not rule on it this time, we believe the Supreme Court is nudging lower courts to say no. The written decision compares Java’s APIs to the Dewey Decimal System and spoken language itself: a sort of organizational system that defines a potential world of ideas and lets the user navigate into an actual world of actual tasks. We think that sends a strong signal that APIs are ideas, not expressions of ideas, and thus not copyrightable.
To understand the business and technology trends critical to 2021, download Forrester’s complimentary 2021 Predictions Guide here. This post was written by Senior Analyst David Mooter and Principal Analyst Sandy Carielli, and it originally appeared here.
