After this holiday weekend it probably won't take long before Judge Alsup, possibly after asking the parties some more questions in writing or at a hearing, rules on the copyrightability of the structure, sequence and organization (SSO) of Oracle's asserted 37 Java APIs. And after his decision, it won't take long (absent a settlement) before an appeal by whichever party disagrees.
With a view to the things to come, I have reread every copyrightability-related pleading in Oracle v. Google and looked up every reference to cases that were cited and appeared remotely relevant (even several cases that are unrelated to computer software). None of them -- including any combination of them -- rules out the copyrightability of sufficiently original APIs. It's a highly case-specific question. There's a significant probability that Judge Alsup and/or an appeals court will hold the SSO of these particular APIs (as opposed to the SSO of all APIs out there) copyrightable. No SSO of the originality and complexity of the one at issue here has ever been held uncopyrightable in the United States (not even by the EU Court of Justice, by the way). But that doesn't mean that legitimate concerns cannot be addressed. Uncopyrightability would be one way to ensure a competitive environment, but fortunately it's not the only way.
Let's firstly look at the extremely low threshold for copyrightability under U.S. law that some other decisions have already demonstrated and the implications for this case. Subsequently, I'll explain Google's competition-related arguments and why I don't think uncopyrightability is the answer. Finally, I'll discuss the extent to which fair use and FRAND licensing obligations can contribute to a solution in terms of a balanced overall framework (provided that FRAND is interpreted more reasonably by others than it is by a certain Google subsidiary).
The low threshold for copyrightability
For people who have hands-on programming experience it can be surprising to see how low the hurdle for software copyrightability is.
Judge Alsup also appears to have done a fair amount of coding, and even though he said that he had written code like the nine-line rangeCheck function a hundred times, he separated his personal value judgment from his decision on a Google motion to overrule the jury with regard to rangeCheck. Judge Alsup upheld the jury's finding in this respect. Google had made a de minimis argument that he rejected. Instead, he overruled the jury on the eight decompiled files, and if you look at them (I published them all more than a year ago), I'm sure Judge Alsup could write that kind of code any day of the week as well.
For code segments that contain executable instructions, it appears that the line between uncopyrightable and copyrightable code is drawn somewhere south of rangeCheck. For example, in Sega v. Accolade (one of Google's favorite cases) the Ninth Circuit found that an initialization key consisting "merely of 20 bytes of initialization code plus the letters S-E-G-A" was "probably unprotected" -- note the remaining uncertainty that the word "probably" reflects.
The SSO of the asserted Java APIs raises a different copyrightability question because an SSO is considered a non-literal element. Still, the fact that the hurdle for literal elements is low serves as an indication for the standard.
The parties' pleadings on API SSO copyrightability cite cases based on whatever appears to fit into a given context. All of those cases, whether they held SSOs copyrightable or not, relate to much less protectable material than what is at issue in this case. Obviously, the lower the standard for copyrightability is according to a given case, the better for Oracle in this context, while the most useful decisions for Google's purposes would be those that hold relatively large and complex SSOs uncopyrightable -- but those are impossible to find. In order to prevail here, Google needs an unprecedented kind of decision. That one would be useful to other litigants further down the road, but unfortunately is would also pave the way for some fundamental attacks on software copyright beyond the context of APIs.
I'm optimistic that Judge Alsup will do his best to ensure that whatever his decision is will be phrased in a way that can't have all sorts of unintended consequences. If he decided that the SSO of the 37 asserted Java APIs is expressive (in light of its large object-oriented structure with many interdependencies and design choices involved), that might encourage others to claim copyright in smaller and simpler APIs, but defendants could then point to differences between APIs asserted in future cases and those 37 Java APIs. There aren't too many APIs in the industry that have this scope and scale.
In the previous paragraph I used the word "large" and wish to clarify inhowfar size matters in this context. Size has an indirect but nevertheless important effect here.
If a category of data or code is uncopyrightable, size does not make a single data set or line of code less uncopyrightable. In Feist v. Rural, the Supreme Court rejected the "sweat-of-the-brow" test, a doctrine according to which material became copyrightable just because it took a lot of work to compile it. Instead, originality was established as an indispensable requirement, though the hurdle is low. In particular, Feist allowed the use of 4,000 entries from a telephone directory that had no creative structure (it was simply sorted by last name). The outcome (concerning copyrightability, not necessarily other legal theories) would have been the same even if the amount of data had been 100 or 1,000 times larger. Any number multiplied by zero amounts to zero.
For the copyrightability of APIs, size does matter if they have an original and creative structure. Organizing 400 classes, 4,500 methods and 7,000 declarations (those numbers are at issue in Oracle v. Google) in a way that programmers don't get lost is a far greater challenge than doing the same with a set of 4 classes, 45 methods and 70 declarations. In this smaller example, there isn't even a need to think about which classes to put into which package. There probably isn't much, if any, inheritance. Even this smaller API requires a significant degree of creativity, but complexity (at the design stage) grows at a more than linear rate. By contrast, the only bit of incremental "complexity" for a large phone directory is that it may have to be split up alphabetically into multiple volumes.
Here are some examples of U.S. court decisions on SSOs or generally on "interfaces" (though APIs aren't APIs, and APIs are fundamentally different from graphical user interfaces, which in turn are different from network protocols) that show how all of the relevant past decisions dealt with smaller and simpler bodies of work:
In the Feist context it's important to consider that, besides a simple (alphabetical) structure, the case also dealt with a compilation of preexisting data. The Java APIs, however, contain many thousands of lines that were authored by Sun.
I also mentioned Sega before. The 20 bytes of code plus the word SEGA were just the part that Accolade had to build into its games and redistribute. Other than that, the case was only about fair use as a justification for intermediate copying for the purpose of reverse engineering. As I explained on Tuesday, Sega and the follow-on Sony v. Connectix (also Ninth Circuit) case didn't narrow the scope of copyrightable subject matter based on compatibility considerations: they merely deemed copyrightability a legitimate objective for reverse engineering (and only within reason). But at any rate, the interfaces that were reverse-engineered in those cases were far smaller and simpler than the Java APIs. Connectix's opening appellate brief said in a footnote that the company "mplemented only 137 of the 242 functions implemented in Sony's BIOS" in its video game emulator. The structure was not an object-oriented one. Since Sega related to an even older platform, and in light of this memory map of the Sega Genesis, it's unlikely that the SSO of the relevant APIs was substantially larger or more creative. The Ninth Circuit nevertheless didn't rule out that Sega might have had an infringement claim with respect to Accolade's finished products.
In Mitel v. Iqtel, the Tenth Circuit didn't even declare a table of indices (1 to 7) and data throughput rates (110 baud, 300 baud, 600 baud, 1,200 baud, 2,2400 baud, 4,800 baud, 9,600 baud; 1 baud = 1 bit per second) competely unoriginal -- only "largely". For the remainder, it invoked the scènes a faire doctrine.
In Lexmark v. Static Control, the Sixth Circuit looked at two programs that were key to making toner cartridges work in a printer. The defendant didn't even dispute that the relatively larger one of the two, which "translates into over 20 printed pages of program commands", is copyrightable. The smaller one existed in two versions, one with 33 program instructions occupying 37 bytes of memory and the other one with 45 program commands using 55 bytes of memory. The court couldn't help but mention that the full name of the case, "'Lexmark International, Inc. vs. Static Control Components, Inc.'[,] in ASCII format would occupy more memory than either version of the Toner Loading Program".
The court then engaged in a detailed analysis of whether that small program was expressive. Ultimately the defendant prevailed on the basis that this program used the most efficient way of calculating toner levels and alternatives amounted to different methods of operation as opposed to different ways to express the same formula.
In Lotus v. Borland, "469 commands arranged into more than 50 menus and submenus" were at issue. Each menu item had a shortcut (typically its first letter). The menus were hierarchical, but that was it. No inheritance, no declarations that cross-reference each other, etc.
Computer Associates v. Altai is a seminal case because the Second Circuit established the Abstraction-Filtration-Comparison test for copyrightability and copyright infringement that is now used throughout and even to some extent beyond the United States. But the program at issue there was not huge. It was a mainframe job scheduling tool. The case dealt with two kinds of infringement. An earlier version of the accused product had stolen 30% of the code of the asserted work, while the more recent version (which gave rise to the AFC test) was a clean-room implementation. For the straightforward infringement of the earlier version, the court ordered "$364,444 in damages and apportioned profits". This means that a hypothetical infringement of the entire program would have cost approximately $1 million. (The amounts that Google and Sun discussed for a potential Java license fee were 100 times higher as a starting point.)
In Apple v. Microsoft, license agreements were in place and some of the material asserted by Apple was actually not Apple's own creation. Accordingly, the Ninth Circuit limited its analysis to only 10 (out of 179) user interface elements. Some of those were rather broad ideas like the concept of "overlapping windows" or that of a "close window" button.
In Gates Rubber Co. v. Bando Chemical Industries, the program at issue was a tool for determining "the proper rubber belt for a particular machine". The defendant used some of the mathematical formulae and constants. As far as constants are concerned, the Tenth Circuit didn't rule out that some constants can be copyrightable: it merely ruled out copyright protection for "scientific observations of physical relationships concerning the load that a particular belt can carry around certain sized gears at certain speeds given a number of other variables" because "[t]hese relationships are not invented or created; they already exist and are merely observed, discovered and recorded". Constants in APIs are sometimes dictated by realities (such as RGB values of colors) but they can also be created independently.
In Engineering Dynamics v. Structural Software, the Fifth Circuit "REVERSE[D] the district court's holding that computer/user interfaces in the form of input and output formats are uncopyrightable".
In CDN Inc. v. Kapes, the Ninth Circuit agreed with the district court that CDN's coin pricing guides are "wholly the product of [CDN's] creativity" as opposed to facts. Oracle has made it clear that the Java APIs aren't a compilation, but this 1999 ruling is an interesting indication at any rate.
In American Dental Association v. Delta Dental Plans Association, the Seventh Circuit ruled that a taxonomy can be copyrightable. In this case, the taxonomy classified dental procedures. It was a hierarchical structure. Each dental procedure was assigned a numerical code, a short description, and a long description. The Seventh Circuit said that "[d]ental procedures could be classified by complexity, or by the tools necessary to perform them, or by the parts of the mouth involved, or by the anesthesia employed, or in any of a dozen different ways". Therefore, "[t]he Code's descriptions don't 'merge with the facts' any more than a scientific description of butterfly attributes is part of a butterfly". The work as a whole was deemed copyrightable at any rate because of "original long descriptions". Then the court added: "But we think that even the short description and the number are original works of authorship."
Google really hates that decision.
Google also dislikes Johnson Controls v. Phoenix Control Systems, a case I discussed in this recent post. The computer programs at issue in that case served "to control wastewater treatment plants". Given that this is a case from the 1980s, and in light of the vertical focus of this kind of program, the SSO of this software must have been much smaller and simpler than that of the 37 asserted Java APIs.
Even Google's favorite EU court case, SAS Institute Inc. v. World Programming Ltd., relates to something that is not comparable in complexity and creativity to the 37 asserted Java APIs. While the decision rules that programming functionality cannot be copyrighted, it related only to a programming language (not an API) and some data formats (stuff that is not at issue in Oracle v. Google, and it still noted that a programming language could be copyrightable if it's a programmer's own creation. An EU case is of limited relevance to a U.S. decision, just like European courts can't order the death penalty only because some states still execute it and all Western civilizations have by now ratified various human rights treaties. That example may appear extreme, but even within the realm of intellectual property there are analogies. I bet that most of those who would like Judge Alsup to be persuaded by a misreading of the EU decision to hold APIs uncopyrightable are exactly the ones who protest against ACTA and would cry foul if European courts adopted certain clauses of the Digital Millennium Copyright Act or U.S. case law on business method patents.
Competition-related considerations
While I just can't see how Judge Alsup could find the SSO of the 37 asserted Java APIs uncopyrightable without going by a huge factor beyond previous U.S. court rulings that held non-linear elements of computer programs unprotected, I can see why Google wants APIs to be treated as a different animal. But it's one thing to agree that a concern is, at least in part, legitimate and another thing to agree that the context in which to address those concerns must be copyrightability. In my view, the existing legal framework doesn't support a broad-brush exclusion of APIs from copyrightability, but it does provide more reasonable solutions.
I mentioned before that Google argues the Sega and Sony decisions make it impossible, or at least much harder, to obtain copyright protection of whatever is functionally relevant to compatibility. I won't repeat why I think that's not what those fair-use-centric decisions said. But at a policy level, I do agree that compatibility is important.
What fair use might help prevent is that a platform maker publishes APIs and then uses his copyright in those APIs to prevent only some developers from writing applications that reasonably utilize them. But that's not the issue in Oracle v. Google since Google doesn't write apps for Java that Oracle wouldn't allow. Google has created an alternative denomination of Java.
Google tries a similar trick -- suggesting a conflict between interoperability and copyrightability -- in its argument that the merger doctrine or scènes a faire doctrine should apply. All of this comes down to Google saying that many programmers know Java so it must be legitimate to provide a partly familiar platform to them: it's kind of "expected". If there's only one way to reasonably express a particular element of a Java API, it must be copyright-free. Google wants all Java APIs to be uncopyrightable. The problem here is that rules like the merger doctrine and scènes a faire would only help Google to the extent that Sun, when it created those APIs, was limited in its choice or had to respond to expectations. Maybe there are some basic Java API elements for which this is true, such as the string data type or some simple mathematical functions, but Google makes this claim for everything, including countless elements of those APIs that were created by Sun without any restrictions (or industry expectations) of any kind applying.
Simply put, something that is copyrightable when it's created can't become uncopyrightable only because it's successful. Copyright holders don't become victims of their own success as far as the question of copyrightability is concerned.
When Judge Alsup largely denied Google's motion for summary judgment against Oracle's copyright claims last summer, he rejected certain parts of Google's motion particularly because Google wanted a "sweeping" decision instead of being more specific. I wouldn't be surprised if history repeated itself in the coming days. Google could have made an elaborate argument under the Abstraction-Filtration-Comparison test, but it didn't (though it frequently cites the CA v. Altai case I mentioned above). That's understandable from Google's perspective: when dealing with 400 classes, 4,500 methods and 7,000 declarations, it's not attractive to focus on a few items like "string" or basic mathematical functions that may indeed qualify for a merger or scènes a faire argument. It wouldn't solve the overall problem because Google there's too much material in there that can only be declared uncopyrightable if one comes up with a theory for the "sweeping" decision Judge Alsup refused to make in the summer.
The cases that Google cites in its favor largely have in common that the courts stressed the importance of balanced copyright law. Copyright shouldn't result in monopolies that are patent-like (if not broader) but don't have to meet similar criteria (novelty, non-obviousness, disclosure etc.) and would be in effect for an even longer period of time. There were some extreme cases such as Baker v. Selden (an author of a book on accounting practices later claimed a monopoly on what the book describes) or Allen v. Academic Games League of America (arguing, based on a claimed copyright in game rules, that card game tournaments were illegal without a special license from the author of those games) which related to high-level ideas. There were also some less extreme cases in which the courts had to remind everyone that copyright law must be balanced to achieve its stated objective.
By setting and maintaining a reasonably high standard for API copyrightability (in terms of originality, creativity and complexity), the courts can discourage and prevent API abuse. But copyrightability is not the only tool.
I said before that fair use can help in some cases, but I stand by my belief that Google's use of those Java APIs does not qualify for a "fair use" exception under the law.
The third pillar of a reasonable approach to API copyrightability (besides a standard for copyrightability that should not be too low, and access to fair use in cases in which it is warranted) is antitrust law. In other words, FRAND. I mean genuine, good-faith FRAND, not Googlorola-style prohibitive demands without a sincere intent to grant a FRAND license.
The EFF recently issued a statement on API copyrightability and I cricitized that the very example for a critical API that the EFF mentioned, Samba, was resolved several years ago (the EFF as an organization definitely knows) by the European Commission.
For Java, the question of whether there's a FRAND licensing obligation under antitrust law is a non-issue: FRAND licenses for clean-room implementations are already available.
The Java example shows that FRAND is different from a fair use exception in some ways. While fair use denies that a creator is entitled to a payment, FRAND licenses are typically royalty-bearing. And it's no less important to consider that FRAND licenses are often made available only to those who create a fully compliant implementation of a standard (whether a near-compliant implementation qualifies for FRAND under antitrust law is a separate question).
If Google made Android fully Java-compatible, it would be entitled to a FRAND license. In light of that, I don't think it's reasonable to expect Judge Alsup to depart from the standard for copyrightability (by a factor of 1,000 or more) or to invoke "fair use" when there actually is a FRAND option.
FRAND also has an advantage to implementers. For example, FRAND licenses relating to a standard typically cover all categories of intellectual property -- including patents that are essential (i.e., they are inevitably infringed by a reasonable implementation of a standard). Patent law doesn't have a "fair use" exception, and if you want to talk to a patent office about the public policy considerations Google puts front and center in the Android/Java case, good luck: patents are granted based on strictly technical criteria, and public interest exceptions only come into play under exceptional circumstances (such as in the event of an epidemia or national security concerns).
Antitrust law can't impose a FRAND licensing obligation in connection with every API, but it doesn't have to. If there are viable alternatives to an API, there may not be a FRAND obligation, but in that case, market dynamics will give the more available and affordable API a competitive advantage. But in those cases in which the market can't take care of itself, competition law can come to the rescue.
Just to be clear: I don't categorically reject competition-related arguments as far as intellectual property law itself is concerned. As far as my personal position is concerned, I'd like patent examiners to have to justify the grant of a patent in light of the fact that a patent is a (time-limited) monopoly. But we have to make a proper distinction between the way we'd like the law to be shaped and the way in which it can be reasonably applied today.
Google's position on competition and IP is contradictory in itself. On the one hand, Google endorses and now directs Motorola's abuse of standard-essential patents. On the other hand, Google wants free-of-charge and unrestricted access to certain Java-related IP and twists and turns the case law, suggesting that fair use cases established an actually non-existent conflict between copyrightability and compatibility and advocating that copyright holders should become victims of their own success. Right in the middle between those two extremes there's a balanced solution called FRAND.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
