IP Law News

INSIGHT: Fair Use of APIs in Medical Software Following Oracle v. Google

Nov. 27, 2018, 1:01 PM

The medical software field is a crowded one, but you think your new company is going to change the game. Your platform is going to connect disparate medical records systems, communicate with all types of wearable health devices, and even support interactions with competitive systems, which you hope to eventually replace. Although your platform has numerous advantages over the others, many potential customers are wary of switching to it because they would have to rebuild the customized software functionality they have developed over the years that depends on your competitors’ application programming interfaces (APIs). To assuage such concerns, however, you have built your software from the ground up, and made sure that anything that talks to your competitors’ systems can talk to yours too. In other words, you had to copy and implement certain elements from their APIs, such as function declarations and package names, so that customers could transition seamlessly from a competitor’s platform to yours. You would argue that doing so is necessary for compatibility and good for competition. But could any copyright infringement issues be implicated here?

Perhaps, according to the latest decision to come out of the Oracle v. Google saga. You may have heard about this case before, during its travels up and down the court system over the past eight years. Most recently, this past March, the Court of Appeals for the Federal Circuit (“CAFC”), applying Ninth Circuit case law, found that Google’s replication of certain copyrighted Java API packages in its Android platform was not fair use, and remanded the case to the district court to determine damages for copyright infringement. But, more importantly, why does this matter? And what are the implications of this decision for medical software and device providers? To understand the importance of this decision, it is worth a closer look into copyright law generally, the procedural history of Oracle, and how the CAFC evaluated the issue of fair use.

Copyright, as Oracle certainly makes clear, can be a pretty powerful tool for protecting intellectual property. Copyright can cover many mediums, including artwork, movies, music, and critically, for purposes of this article, software. It does not take much ingenuity to create something copyrightable—indeed, only a modicum of creativity is needed for an original work to automatically gain copyright protection. Then, following creation, the copyright on a newly-created work can approach and even exceed 100 years. This is generally overkill in the software world, where copyright will persist long after technology has advanced.

Despite all this, equity necessitates that not all works of authorship be afforded copyright protection. Courts have carved out exceptions to copyrightability where, for example, the expression at issue is more functional than creative, or has limited ways of articulation. To illustrate, consider a short block of JavaScript code that, when executed, moves and resizes a browser window. In seeking to achieve the same functionality, any JavaScript programmer will necessarily arrive at the same or substantially similar code. To afford copyright protection to this block of code would seriously limit the ability of others to provide the functionality needed for web page manipulation. Thus, where expressive alternatives are limited or nonexistent, or where expression is highly functional, copyright law may offer little or no protection.

It is not lost on courts, however, that while software is highly functional by nature, complex works of software can overflow with creative expression, particularly when there are many methods of achieving the same functionality. Beyond the lines of code, i.e., the “literal elements,” of a software program, there is something else rather interesting that can be protected by copyright: the “non-literal” elements, which include the structure, sequence and organization (“SSO”) of the code. Indeed, it was partly on this basis that the CAFC, in a 2014 decision from an earlier appeal in Oracle v. Google, ruled that the Java APIs at issue were copyrightable. More specifically, the CAFC found that the particular manner in which each API package was named and organized amounted to creative and original expression. Google, the court stated, in its efforts to implement Java-like functionality on Android, could have chosen different ways to express and implement the functionality that it copied.

Following the 2014 decision, the implications of copyright protection for APIs were covered in great detail, but much uncertainty still lay around how a court might respond to an API copyright infringer’s fair use defense. Briefly, fair use allows the unlicensed use of copyrighted works in limited circumstances, such as criticism, education, and news reporting. Determining whether an activity qualifies as fair use requires the balancing of four fair use factors set forth in the federal Copyright Act, which are further described below. In Oracle, the District Court for the Northern District of California initially put the question of fair use to the jury, who found in that Google’s use of the API declaring code and SSO of the 37 Java packages constituted fair use. After the district court denied Oracle’s post-trial motions, the case arrived again at the CAFC in 2017 to evaluate the issue of whether Google’s activities were fair use, with it already being established that Google infringed Oracle’s copyright on the Java APIs. Ultimately, the CAFC was not persuaded by most of Google’s arguments, or at least any of the ones that mattered, and a finding of no fair use was rendered.

Specifically, the court evaluated and then balanced the four fair use factors established by U.S. copyright law: (1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; (2) the nature of the copyrighted work; (3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and (4) the effect of the use upon the potential market for or value of the copyrighted work. The court examined all the factors in detail, but the first and fourth factors weighed most heavily in the final decision.

Purpose and Character of the Use: Under this factor, the CAFC evaluated whether Google’s use of the Java APIs was commercial in nature, rather than for educational or public interest purposes. Although Google provided Android under an open source license, the court found that there was an indirect commercial benefit from providing something for free that would ordinarily require payment. Also relevant to his factor was whether Google’s use was “transformative,” such that it altered the original with new expression or served a new purpose, as opposed to merely acting as a replacement for the original. The Court found that Google’s selection of certain APIs with new implementing code adapted for use on mobile smartphone devices was not considered to be transformative—the APIs served the same function on both the original and new platforms, and Google did not alter the expressive content or message of the copied APIs. That Google wrote its own implementing code was irrelevant.

Nature of the Copyrighted Work: For this factor, the court considered whether the Java APIs fell more on the side of creative (and more worthy of copyright protection) or informative (and less worthy of protection). Although the court found that the APIs were not entitled to the strength of copyright protection afforded highly creative works and, thus, that the “nature” factor weighed in favor of fair use, the Court noted that this factor has little significance in the overall balancing test.

Amount and Substantiality of the Copied Portion: The question here is whether the copyright infringer took a quantitatively or qualitatively significant portion of the original work. Noting that Google copied the SSO of 37 APIs in their entireties, and ultimately copied much more code than necessary to write in the Java language (even though a small portion of the Java language as a whole), the Court found this factor neutral at best, and arguably weighing against a finding of fair use.

Effect on the Potential Market: This factor, considered to be the most important of the four, required to court to determine whether Google’s copied API packages effectively supplanted Oracle’s Java API packages in the marketplace. This involved not only considering harm to the actual or potential market for the original APIs, but also harm to the market for potential adaptations of the APIs (such as adapted APIs for smartphones) that Oracle might develop or license others to develop.

The court pointed to Oracle’s licensing efforts as evidence of market harm. Oracle had earlier licensed Java SE for the Amazon Kindle. However, after Android was released, Amazon used the free nature of Android as a bargaining chip to negotiate significant licensing discounts for newer Amazon devices. One important point to note here is that, in copying the Java APIs and providing its own mobile device Java-compatible platform, Google deprived Oracle of potential revenue from developing and commercializing its own mobile Java APIs, as well as potential revenue from licensing the Java APIs to others who might have adapted the APIs for mobile devices. That Oracle had not yet developed a smartphone device or platform at the time was irrelevant as a matter of law, as it was still a potential market for Oracle to enter and derive revenue from.

Ultimately, the balancing of these four factors led to a finding of no fair use—i.e., indefensible copyright infringement by Google.

Thus, we have on the books a series of federal court of appeals decisions finding that APIs may be copyrightable, and that when they are, infringers may lack a fair use defense. Although the decisions specifically address the Java API, the concepts discussed by the CAFC could apply to software APIs of any flavor, irrespective of programming language or field. As such, a web services API used for medical device communication, for example, could be entitled to copyright protection, assuming that it embodies some creative expression in its SSO, or otherwise.

In applying the fair use teachings of the CAFC to medical device and other healthcare software, there are some interesting points to consider. First, to the extent a copyrighted API is incorporated into such software without a license, it is better, from a fair use perspective, to transform the nature, function or purpose of the API in some manner, rather than having the API perform the same functions in both the original and new uses. For example, merely porting the API to a different platform (e.g., porting the API from a desktop platform to a mobile medical device), without more, may not be a transformative use. In contrast, in Sony Computer Entertainment, Inc. v. Connectix Corp. (9th Circuit, 2000), the defendant was found to engage in “modestly transformative” use when reverse engineering Sony’s software to gain access to unprotected functional elements and create a software program to allow consumers to play PlayStation games on a personal computer. There, a wholly new product with entirely new code was created, and the intermediate copying during the reverse engineering was performed to produce a compatible product. As such, copying portions of an API for the purpose of compatibility may favor a finding of fair use, but it is likely that the resulting compatible work would also have to be functionally or expressively different from the original work in a meaningful way.

Second, market players should consider the commercial nature of a work and its market effects. A company using an open source implementation of, for example, a copyrighted healthcare data transfer API made by another, or open sourcing its own implementation of the same API, may actually work against it in the fair use analysis. Google had argued that, because Android was open source and freely available, its use was noncommercial. Regardless of commercial motives, providing something for free can cause indirect market harm when that thing would normally require payment. It follows, then, that if a company’s medical device or software platform incorporates open source software, it should ensure that any APIs included in that software are in fact open source or open standard implementations, rather than copies or adaptations of a proprietary API.

It should be reiterated that the CAFC decided Oracle by interpreting Ninth Circuit law. Normally, copyright cases are appealed to the circuit court having geographical jurisdiction. The CAFC had jurisdiction here because Oracle had asserted patent infringement in the case, and the CAFC has exclusive appellate jurisdiction over all appeals from patent cases. It is difficult to predict whether the outcome would have been different had the Ninth Circuit or another circuit court more experienced with issues of copyright law heard the case. Given the uncertainty surrounding the patentability of diagnostic patents and software, and given the Federal Circuit’s rulings in Oracle, however, companies developing such technology may try to protect themselves by procuring, and litigating, both patents and copyrights. If so, the CAFC may hear even more copyright cases. Regardless, the CAFC’s treatment of fair use may have at least persuasive influence (albeit not binding effect) on other courts in the years to come.

Taking all this into account, as well as the fact that fair use cases are very fact-specific and somewhat unpredictable, the clear inference to be drawn under current law is that copying a competitor’s medical software or device API may carry significant potential liability. The most risk averse approach when it comes to APIs would be for a company to develop its own API from scratch or support open standards in its software, incorporating, for example, an API implementation of the Fast Healthcare Interoperability Resources (FHIR) standard for electronic health records exchange. Alternatively, in some instances, the owner of an API copyright may provide options to license its API, which may include implementation code, as well. However, if none of these options are practical, substantial care must be taken in copying even a portion of someone else’s API. If significant, even indirect harm to the actual or potential market for that API (or adaptations of the API) is a realistic possibility, and making a fair use case may present a battle up a particularly steep hill.

Michael Cottler is a partner in the firm’s Litigation Department, where he focuses his practice on intellectual property, with a concentration on patent issues in the areas of biotechnology, pharmaceuticals (small molecules and biologics), consumer products and medical devices.

Steven Argentieri is an associate in the firm’s Business Law Department and a member of the Technology and Life Sciences groups. He specializes in domestic and international intellectual property portfolio strategy, patent prosecution, patent validity and infringement opinion drafting, patentability and freedom to operate searching, open source software, technology transactions and licensing, and intellectual property support in mergers, acquisitions, IPOs, sales, and investment transactions.

To read more articles log in. To learn more about a subscription click here.