Many articles are coming out about how the recent decision in Oracle America v. Google is going to destroy the ability to create and protect software in the United States. The latest doomsday prophet is Jie Lian in his IPWatchdog article entitled Oracle v. America: Fair or Unfair. As a longtime programmer and an expert in software copyright law, I can tell you that the Federal Circuit got it right, and the decision helps software developers and encourages software development because it leaves in place the copyright protections that have existed at least since the Software Copyright Act of 1980. I am sure that most of us can agree that software development has skyrocketed since 1980.
Dr. Lian explained the four factors that go into considerations of copyright fair use. Below I examine each of these factors and how the Federal Circuit got them right. For full disclosure, I was a testifying expert on the case for Oracle, and my consulting company Zeidman Consulting did much of the code analysis in the trial over fair use.
Factor 1: The purpose and character of the use.
This factor has to do with whether a copy is “transformative.” In other words, has the copy been transformed in some way so that it is no longer recognizable or no longer used in the same way. Using software code as the background in a painting would be transformative because while its expression is identical, the code in the painting performs no function. In contrast to that, using the same code to perform the same function but in a different program is not transformative.
Dr. Lian claims that “the Federal Circuit impose[d] a novelty element in the test of transformative use,” but that is not the case. Copyright protects originality not novelty, and originality is a much lower threshold than novelty as demonstrated in the case that Dr. Lian references, Feist Publications, Inc. v. Rural Telephone Service Co., where the issue was a copyrighted phone book. Actually, novelty was attempted to be introduced by Google, but the Federal Circuit rejected that. A transformation is not determined by the novelty of the use of the code, but whether the copied code represents the same function. Google purposely made the Android APIs 100% identical and 100% functionally compatible with Java so that they could be used immediately by programmers who already knew Java. There was no transformation
Factor 2: The nature of the copyrighted work.
Dr. Lian’s argument here seems to be that since the Federal Circuit thought that Google’s copy was not transformative then it should have put more emphasis on this factor. But here he buys into Google’s argument that the code expression was constrained by the functionality. Google argued: what else would you call a library of math functions but “Math”? However, not only was this by far the simplest example API of the 37 APIs at issue, programmers know that different vendors use different names for their libraries and library functions, often to purposely make them incompatible with libraries from other vendors. And while Google argued that the APIs were determined by functional considerations, their own internal emails belied this. They needed to use the exact, creative expression of the Java APIs, even though they could have written them many different ways, because Sun (now Oracle) had already educated programmers. Google wanted these same programmers to quickly adopt Android without needing to educate them.
Factor 3: The amount and substantiality of the portion used.
People like to talk about the 37 APIs as if 37 is an inconsequential number. First, infringing a copyright only one time is just as bad as infringing 37 times. However, to put this in perspective, those APIs contained roughly 11,500 copied lines of code, and were found in at least 13 versions of Android, comprising almost 150,000 instances of copying. I know because my company counted those lines. Dr. Lian references these lines of code but dismisses them because he says the code “enjoys only ‘thin’ copyright protection” and claims that the issue should be how this amount of code compares to the amount of code required to “develop an open platform.” First, it was the district court’s opinion that the protection afforded the API code is “thin,” but the Federal Circuit overruled that finding. Second, Dr. Lian shows a common misunderstanding of copyright law. The amount of code that was copied is entirely irrelevant to the protection that it gets. Otherwise, an infringer could simply take an important function and bury it within many lines of other code and claim fair use. Or the infringer could copy small but critical functions out of a large program or out of several large programs and be immune from a judgement against it. What is important is the amount of code relative to the function it implements. Fortunately, the Federal Circuit understood that the amount of code copied within a body of code is irrelevant.
Factor 4: The effect of the use on the potential market.
Here again, Dr. Lian buys into Google’s argument that it succeeded where Sun (now Oracle) failed, so there was no market for Java-based smartphones. The Federal Circuit correctly concluded that this argument is wrong. It is not a question of whether the owner of the copyright did or did not succeed in the market, but whether there was a market at all. Google demonstrated that there was a huge market for the code as evidenced by the sheer number of Android phones that have been sold. One can argue that Oracle would never have been able to sell so many phones or would not have profited from smartphones. In fact, Google made those arguments, but those arguments are just wrong. Google’s argument is like saying that I can steal your computer as long as I can show that I can make better use of it than you can. That’s not fair use, that’s still theft.
Overall, the Federal Circuit came to the correct conclusion, and it helps programmers, not hurts them. As a programmer, I am now assured that no other person or company can steal sections of my code and incorporate that code into their products without repercussions. If you need proof that copyright laws are a good thing for software developers, just look at the growth of software since 1980 in terms of lines of code, number of programs on the market, number of software companies, or revenue of software in any industry. By any measure, software innovation is encouraged by existing copyright laws and the protections it has been afforded for decades. This most recent ruling affirms that protection, and programmers should all be rejoicing.
Image Source: Deposit Photos.