On Friday, the Court of Appeals for the Federal Circuit released its decision in Oracle America Inc. v. Google Inc. The dispute concerned allegations that Google copied elements from Oracle’s Java software platform when it developed its Android platform for the mobile market. The Federal Circuit handed Oracle a solid victory, ignoring Google’s push for an interoperability exception to excuse copying that was not for the purpose of interoperability.

The Litigation

The facts of the dispute are essentially this: Sun Microsystems (which has since been acquired by Oracle) developed the Java platform in 1996 with the idea of creating a virtual machine that allowed software to run on any platform or operating system – allowing programmers to “write once, run anywhere.” In 2005, Google acquired mobile startup Android, Inc. with an eye toward entering the mobile market. It entered into negotiations with Sun to license and adapt the Java platform for its mobile devices. The negotiations were ultimately unsuccessful – Google refused to “make the implementation of its programs compatible with the Java virtual machine or interoperable with other Java programs”, which ran counter to Sun’s commitment to interoperability.

So Google began to develop its own virtual machine to interact with the Java platform. It also wanted to take advantage of the developer community that Sun had built up rather than spending the time and effort building its own, so it copied the declaring source code from 37 Java API packages verbatim, as well as the “taxonomy” of the packages – the structure, sequence, and organization (“SSO”) of the packages and their respective classes. That way, developers already familiar with Java could easily begin writing programs for Google’s mobile platform, increasing its value.

The technology

This case does require some understanding of the technology at issue. The court begins by noting, “This copyright dispute involves 37 packages of computer source code. The parties have often referred to these groups of computer programs, individually or collectively, as ‘application programming interfaces,’ or API packages, but it is their content, not their name, that matters.”

The Java platform in its entirety provides an environment for programmers to develop applications that can run on any device or hardware. It essentially consists of the Java development kit (JDK) that programmers use to create their apps and the Java virtual machine (JVM) that runs the code, translating the app source code into source code that the machine the app is running on can understand.

Included in the development kit are a number of “ready-to-use” Java programs available to programmers to perform common computer functions – these are the API packages involved in the case. They are, in the words of the court, “shortcuts” that allow programmers to execute certain functions rather than writing the function from scratch. Each function is referred to as a “method.” Related methods are grouped together into “classes.” Related classes, in turn, are organized into “packages.”

The source code that the packages are composed of can logically be divided into two types: (1) the “implementing code” is the guts of the methods, the individual steps that comprise a specific function, and (2) the “declaring code” is the “header” that identifies the method and tells the programmer what the method needs, like what inputs must be provided and what outputs can be expected.

Oracle licenses its Java platform and API packages in three different ways: an open source license on its declaring and implementing code that is free but requires licensees to offer any changes or additions they contribute through open source licensing as well; a Specification license that provides licensees with the declaring code but not the implementing code; and a Commercial license, which allows businesses to “use and customize the full Java code in their commercial products and keep their code secret” in exchange for royalties.

The Procedure

A quick discussion of the procedure in the litigation here is also helpful, as it is a bit unusual. The issue of copyrightability – whether the declaring code and SSO are protectable in the first instance – was given to the trial judge to decide. The issue of infringement – whether Google’s copying of these intruded onto Oracle’s exclusive rights – was given to the jury, along with Google’s affirmative fair use defense. Because the issues were being determined simultaneously, the jury was instructed to assume copyrightability when it determined infringement and fair use.

The jury found that, presuming the API packages were copyrightable, Google had infringed, but it was unable to reach a verdict on fair use. However, the trial judge would later determine that the declaring headers and SSO were not protected by copyright, and Oracle appealed.

The Appeal

On appeal, it was undisputed that Google had “copied 7,000 lines of declaring code and generally replicated the overall structure, sequence, and organization of Oracle’s 37 Java API packages.” The question was whether these elements are protected by copyright. The district court had determined they were not because “(1) there was only one way to write the Java method declarations and remain ‘interoperable’ with Java; and (2) the organization and structure of the 37 Java API packages is a ‘command structure’ excluded from copyright protection under Section 102(b).”

Oracle argued that the district court was wrong when it “(1) concluded that each line of declaring code is uncopyrightable because the idea and expression have merged; (2) found the declaring code uncopyrightable because it employs short phrases; (3) found all aspects of the SSO devoid of protection as a ‘method of operation’ under 17 U.S.C. § 102(b); and (4) invoked Google’s ‘interoperability’ concerns in the copyrightability analysis.” The Federal Circuit agreed with Oracle on all its points.

Essentially, said the Federal Circuit, the district court approached the issue from the wrong direction, using doctrines meant to determine the scope of conduct that constitutes infringing activity in order to analyze the threshold question of copyrightability. (Or, as Lee Gesmer states it, “Filtration for interoperability should be performed ex ante, not ex post.”) The Circuit also held that concerns about interoperability that the district court brought up should be reserved for a fair use analysis.

Copyrightability

The Federal Circuit began its analysis by noting that “the application of copyright law in the computer context is often a difficult task” and then proceeded step-by-step through the question of copyrightability.

Computer programs can be protected by copyright as “literary works.” To be protected, a work must be “original” and possess “at least some minimal degree of creativity.” But protection extends only to the particular expression of an idea in a work, not to the idea itself. The Copyright Act refers to this distinction between ideas and expression in Section 102(b), which says:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

The Circuit observes that among the principles incorporated into this section is the rule that “those elements of a computer program that are necessarily incidental to its function are … unprotectable.”

It goes on to state that copyright protection extends to both literal and non-literal elements of computer programs. The literal elements include the verbatim source code. Non-literal elements include such components as the program’s sequence, structure, and organization. Here, Oracle was claiming copyright protection to both: “(1) literal elements of its API packages—the 7,000 lines of declaring source code; and (2) non-literal elements—the structure, sequence, and organization of each of the 37 Java API packages.”

As the court points out, no one disputes that these elements are original. What is at dispute is whether these elements are copyrightable under Section 102(b), and both parties disagree over the Section’s interpretation and application. In the end, the Circuit rejected Google’s argument that copyrightability of software programs is a two-step process, “wherein Section 102(a) grants copyright protection to original works, while Section 102(b) takes it away if the work has a functional component.” The court explained that both sections must be considered in tandem.

Abstraction-Filtration-Comparison

In order do so, the Ninth Circuit endorses the Second Circuit’s three step “abstraction-filtration-comparison” test.

In the abstraction step, the court “first break[s] down the allegedly infringed program into its constituent structural parts.” In the filtration step, the court “sift[s] out all non-protectable material,” including ideas and “expression that is necessarily incidental to those ideas.” In the final step, the court compares the remaining creative expression with the allegedly infringing program.

As the Federal Circuit explains, the second step involves consideration of “traditional copyright principles of originality, merger, and scenes a faire” to determine first whether expression is original to the programmer and second whether a particular element was included because of efficiency considerations, requirements external to the program itself, or taken from the public domain.

The first step of the abstraction-filtration-comparison test is part of the copyrightability analysis. The last question goes to infringement. In the Ninth Circuit, the second step straddles the line; questions of originality go toward copyrightability, while “concepts of merger and scenes a faire are affirmative defenses to claims of infringement.” According to the Circuit, “While the trial court mentioned the abstraction-filtration-comparison test when describing the development of relevant law, it did not purport to actually apply that test. Instead, it moved directly to application of familiar principles of copyright law when assessing the copyrightability of the declaring code and interpreted Section 102(b) to preclude copyrightability for any functional element ‘essential for interoperability’ ‘regardless of its form.’” The Circuit next addresses each holding of the lower court in turn.

First, the district court held that the declaring code was not entitled to copyright protection under the merger and short phrase doctrines. The merger doctrine prevents infringement of expression when that expression is the only way an idea can be expressed. For software, that means merger allows copying of elements that “are the only and essential means of accomplishing a given task.”

As stated above, however, the merger doctrine is used to determine infringement, not copyrightability. In addition, the district court improperly looked at merger from Google’s perspective. Instead, the Circuit explains, “merger cannot bar copyright protection for any lines of declaring source code unless Sun/Oracle had only one way, or a limited number of ways, to write them.” And, as the evidence shows, Sun/Oracle had virtually unlimited ways to write its declaring code.

Short phrases, of course, are not protectable, but as the Circuit observes, that does not mean any work that contains short phrases is not copyrightable. The relevant question is “whether those phrases are creative.” The Circuit explains:

By analogy, the opening of Charles Dickens’ A Tale of Two Cities is nothing but a string of short phrases. Yet no one could contend that this portion of Dickens’ work is unworthy of copyright protection because it can be broken into those shorter constituent components. The question is not whether a short phrase or series of short phrases can be extracted from the work, but whether the manner in which they are used or strung together exhibits creativity.

The Circuit ultimately concludes that “Oracle ‘exercised creativity in the selection and arrangement’ of the method declarations when it created the API packages and wrote the relevant declaring code,” thus affording them copyright protection.

Next, the Circuit looks at the “scenes a faire doctrine,” which the trial court rejected but which Google raises on appeal. This doctrine bars from copyright protection “commonplace expressions” such as stock characters and scenes. For software, says the Circuit, “the scene a faire doctrine denies protection to program elements that are dictated by external factors such as ‘the mechanical specifications of the computer on which a particular program is intended to run’ or ‘widely accepted programming practices within the computer industry.’”

Google argued that “because programmers have become accustomed to and comfortable using the groupings in the Java API packages, those groupings are so commonplace as to be indispensable to the expression of an acceptable programming platform.” The Federal Circuit rejects this argument. As with the merger doctrine, the scenes a faire doctrine involves the question of infringement, not copyrightability. And also like the merger doctrine, “the focus of the scenes a faire doctrine is on the circumstances presented to the creator, not the copier. The court’s analytical focus must be upon the external factors that dictated Sun’s selection of classes, methods, and code—not upon what Google encountered at the time it chose to copy those groupings and that code.”

Structure, Sequence and Organization

The Federal Circuit next looks at the trial court’s conclusion that the structure, sequence, and organization (SSO) of the API packages is not copyrightable because it is a “system or method of operation.” The trial court appears, to the Federal Circuit, to have reached this conclusion by relying on the First Circuit’s Lotus Development Corp. v. Borland International, Inc. decision.

In Lotus, as the Federal Circuit explains, software developer Borland sought to develop a spreadsheet to compete with the popular Lotus 1-2-3. In doing so, it copied the menu command hierarchy of Lotus 1-2-3—where commands such as “Copy,” “Print,” and “Quit” are arranged into menus and submenus—in its entirety in order to make it easier for Lotus users to switch. The First Circuit held that this menu command hierarchy is not copyrightable subject matter. It is instead a “method of operation” which Section 102(b) bars from copyright protection. The First Circuit defined a “method of operation” as “the means by which a person operates something, whether it be a car, a food processor, or a computer” and held that the menu command hierarchy is the means by which a person operates Lotus 1-2-3.

The Circuit agreed with Oracle that it was incorrect to rely on Lotus because “it is distinguishable on its facts and is inconsistent with Ninth Circuit law.” The Circuit explain that, unlike here, Lotus did not involve any copying of the underlying code, the elements copied were not found creative by the Lotus court, and the elements copied were “essential to operating” the system.

“More importantly,” says the Circuit, “the Ninth Circuit has not adopted the court’s ‘method of operation’ reasoning in Lotus, and we conclude that it is inconsistent with binding precedent.” The Circuit sees Lotus’s rule that functional elements are never copyrightable as inconsistent with the abstraction-filtration-comparison analysis, a conclusion the Tenth Circuit had also come to when it rejected the adoption of Lotus. Indeed, notes the Federal Circuit, “no other circuit has adopted the First Circuit’s ‘method of operation’ analysis.”

The problem the Federal Circuit sees with the idea that functional elements can never be copyrightable is that it would mean no computer program is protectable—“computer programs are by definition functional.” The Circuit ultimately concludes “that a set of commands to instruct a computer to carry out desired operations may contain expression that is eligible for copyright protection.” The Circuit explains what this distinction looks like in the case here:

On appeal, Oracle does not—and concedes that it cannot—claim copyright in the idea of organizing functions of a computer program or in the “package-class-method” organizational structure in the abstract. Instead, Oracle claims copyright protection only in its particular way of naming and organizing each of the 37 Java API packages. Oracle recognizes, for example, that it “cannot copyright the idea of programs that open an internet connection,” but “it can copyright the precise strings of code used to do so, at least so long as ‘other language is available’ to achieve the same function.” Thus, Oracle concedes that Google and others could employ the Java language—much like anyone could employ the English language to write a paragraph without violating the copyrights of other English language writers. And, that Google may employ the “package-class-method” structure much like authors can employ the same rules of grammar chosen by other authors without fear of infringement. What Oracle contends is that, beyond that point, Google, like any author, is not permitted to employ the precise phrasing or precise structure chosen by Oracle to flesh out the substance of its packages—the details and arrangement of the prose.

Interoperability

The lower court based its decision in part on the conclusion that “Google replicated what was necessary to achieve a degree of interoperability—but no more, taking care, as said before, to provide its own implementations” and reached this conclusion by relying on the Ninth Circuit decisions in Sega Enterprises v. Accolade, Inc. and Sony Computer Entertainment, Inc. v. Connectix, Corp.

But as the Federal Circuit points out, both Sega and Sony are fair use cases, not copyrightability cases. In addition, they are distinguishable because “defendants in those cases made intermediate copies to understand the functional aspects of the copyrighted works and then created new products.” Here, however, Google copied literal and non-literal elements of Oracle’s software into its own product, not to reverse engineer Java “to figure out the ideas and functionality of the original” in order to create “its own structure and its own literal code.”

The Circuit rejects too Google’s suggestion of a broader “interoperability exception” to copyrightability as inconsistent with Ninth Circuit case law and the abstraction-filtration-comparison inquiry (which the Ninth Circuit endorsed in Sega itself). The Circuit once again reminds of the fact that copyrightability is focused on the choices available to the plaintiff when creating the original program. It notes “the relevant compatibility inquiry asks whether the plaintiff’s choices were dictated by a need to ensure that its program worked with existing third-party programs.  Whether a defendant later seeks to make its program interoperable with the plaintiff’s program has no bearing on whether the software the plaintiff created had any design limitations dictated by external factors.”

The Federal Circuit reserves its strongest words against Google in its discussion of interoperability. “Indeed,” says the Circuit, “given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google’s interoperability argument confusing.” It goes on to point out, “The compatibility Google sought to foster was not with Oracle’s Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue.”

Fair Use

The Circuit ends by looking at Google’s assertion of a fair use defense, which the original jury was unable to reach a verdict on. Oracle argues on appeal that the Circuit should rule against fair use as a matter of law, saying “Google knowingly and illicitly copied a creative work to further its own commercial purposes, did so verbatim, and did so to the detriment of Oracle’s market position.” While the Circuit agrees that “Oracle’s position is not without force,” it ultimately holds that “due respect for the limit of our appellate function requires that we remand the fair use question for a new trial.” It does so because a number of material facts remain in dispute (fair use is a mixed question of fact and law).

First, disagreement remains over whether Google’s use is “transformative,” though the Circuit does point out that “Google overstates what activities can be deemed transformative under a correct application of the law.” Second, though it was error for the judge to consider interoperability in the copyrightability analysis, it may be relevant to a fair use inquiry. Finally, concerning market impact, the Circuit notes that Oracle disputes the district court’s finding that “Sun and Oracle never successfully developed its own smartphone platform using Java technology,” saying it had been licensing in the mobile and smartphone markets when Google copied its API packages, a move that harmed those commercial opportunities.

Next steps

This decision is just shy of a complete victory for Oracle. The Federal Circuit rejected all of Google’s arguments unequivocally. It agreed with all of Oracle’s arguments except for its argument that it should reject Google’s fair use defense—though even then, it showed a good deal of skepticism toward the defense (and, on the market harm prong, moved the needle more in favor of Oracle). But while nothing has been publicly announced yet, I imagine Google will seek a rehearing in front of the entire Federal Circuit before going back to the district court (and there’s always the chance Supreme Court review will be sought at a later point before any return to the district court).

Within hours of the decision, tech advocates and the tech press were already predicting the utter destruction of innovation. It has been called “potentially disastrous” and “dangerous” (along with predictable assertions that the judges involved must not understand technology). I believe, even if you disagree with the outcome of the case, these charges are greatly exaggerated. It’s difficult to see how interoperability is jeopardized by a case where the defendant deliberately set out to create a program that was not interoperable. And the decision does not impact the ability of developers using third-party APIs. At issue was not a defendant interacting with or using a third party’s API, but rather a defendant who copied and replicated an API qua API to be incorporated into its own platform.

I tend to agree with Oracle’s attorney Rosenkranz, who said, “There’s nothing at all astounding in what the Federal Circuit did.” The decision is methodical and well-reasoned. It correctly applies core copyright doctrines and existing precedent. No doubt it will become a seminal case in software copyright law, due in no small part to its thorough discussion of relevant doctrines, unless and until a full panel or the Supreme Court weighs in.

Share: Reddit Google+ LinkedIn

17 Comments

  1. Mr. Hart: I’d like to point out something in the article that is completely wrong. You said:

    “Included in the development kit are a number of “ready-to-use” Java programs available to programmers to perform common computer functions – these are the API packages involved in the case.”

    That is absolutely not what an API is. An API is simply a specification – nothing more. It may be written in code, but it is not a “program,” because it cannot be run. The software that runs the API calls was written in its entirety by Google. They only copied the specifications.

    You are of course forgiven for making this mistake, since the Court (which seems unaware of basic programming) seems to make the same mistake.

    This is why the ruling is terrible news for programmers. Of course, it affects the dozens of entities who, like Google, wrote their own Java virtual machine, which of necessity compiles API calls (a list of virtual machines is here: http://en.wikipedia.org/wiki/List_of_Java_virtual_machines). But it doesn’t just affect them. Every programmer who writes Java code must of necessity make those same API calls – so every single Java programmer could, under this ruling, be guilty of infringement if they don’t get a license from Oracle.

    To read about why this case is dangerous, from people who have a more tech-savvy view of the law, read this:
    https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-federal-circuit-reverses-sensible-lower-court

    • An API is simply a specification – nothing more. It may be written in code, but it is not a “program,” because it cannot be run. The software that runs the API calls was written in its entirety by Google. They only copied the specifications.

      I know next to nothing about APIs, so I appreciate your insight. I’m confused though by your claim. First you say an API cannot be run, and then you say there is software that runs an API. Maybe those claims are not inconsistent, but I’m having trouble understanding how they’re not. Also, let me ask you this: Are the specifications Google copied copyrightable? If not, why not?

      • “I’m confused though by your claim. First you say an API cannot be run, and then you say there is software that runs an API.”

        I probably should have said “run in response to being called by an API.” The API is a specification that software promises to follow; that is all it is.

        You’re probably confusing an API with a library. You wouldn’t be the first. Libraries are often distributed in binary form, and contain executable code. Think of the C++ standard library for example: there are lots of versions of the standard library (distributed by Windows, the FSF, Mac, etc), and that executable code can be copyrighted. What Oracle is claiming is that you can copyright things like “std::vector”. Not the code or library that implements a vector of bools, but the name of the thing.

      • API stands for application programming interface, it’s kind of like a specification for how to call external code. Most of the technology industry since perhaps its inception operates with the assumption that APIs are not copyrightable. Just one example, presumably IBM could like starting suing everyone making PCs because they copy the IBM PC BIOS API from the 80s.

    • Correct, I was using the terminology from the court decision, though I’d note that the district court, which ruled in favor of Google, also used this terminology. The court did note the distinction between specification and program (though not in that language), it just concluded that in this instance, it was not a legal distinction, for the reasons discussed in the article. I’d also note that if you look at the list of Java virtual machines, most of them are already licensed, and a few that aren’t are “clean room” implementations, meaning they hadn’t copied any expression from Java. As to the point that any programmer who makes an API call — rather than copying verbatim the API structure in order to create their own platform — would be liable for infringement under the ruling, that is simply incorrect, a point that even Oracle freely admits. Finally, to say that API’s can be copyrightable is not to say that all copying is barred — there may be a fair use defense available for interoperability or other purposes, which is what the district court is set to consider on remand.

    • Karl,

      1) The Electronics Frontier Foundation, a left-winged arm of Google that is funded by Google, is incorrect about the dangers.
      2) Wikipedia, another catastrophic copyright theft machine’s opinion is 100% irrelevant.
      3) Programmers writing API code are in no danger. It is the company that refuses to obtain a license after administering compilation of the code to interact with compiled software that are guilty here. It is clear, that any programming code can create the same result. In this case, Google, the theft machine of the planet, willfully knew, they required a lisence and didn’t get it—using their arm of theft of all people, from evcery corner, with appended ads to fund the snail-crawl of the court system to catch up.

      This poster has a computer science degree and IP law; therefore, you’re dismissed.

      • Ed:

        If you believe any of those things, you are truly beyond hope. For example, the EFF was around for years before Google even existed; the vast, vast majority of its funding comes from private donors, not corporations; and even among corporate donations, Google only donates a very small amount of what they get. Since the EFF is a non-profit, this is all in its annual reports.

        I know stupid Google conspiracy theories are de regeur with extreme copyright supporters nowadays, but don’t believe the lies.

        • Karl,

          The creation of the EFF is irrelevant from who funds them now. How do you know Google gives a very small, small amount. Like 41 Billion to the non-profit Mozilla foundatiuon, or maybe $10 Million to Wikipedia because they (Wikipedia) couldn’t come up with the full donation thus go to “all ads”.

          You know, in Aereo, Chief Justice Thomas said it best when Aereo’s lawyer admitted he was defending theft. “Lawyers do that, but that’s okay.” You clearly fit that role. Have a nice day, you didn’t manipulate this computer science degree and IP Law with documents as facts, not button pushing masturbation under the keyboard such as yourself.

          Oh yeah, Karl. Google lied in the Viacom case. There are four lights, go program another “for loop”. Thanks.

    • I may weigh in here, since I happen to know exactly what an API is – even wrote a couple myself and will expand upon them before this week is done (part of my day job).

      For a start, the question of whether an API is executable code is completely irrelevant to the issue of copyrightability. Computer programs – are protected as literary works, which themselves aren’t executable code (though, one might wonder what the execution of Ulysses might produce). What is at issue is the semantic effect achieved and here’s where Google’s case goes downhill.

      When designing an API – for example, the signature of a method – the programmer will consider the following:
      1. the kind of parameters the method must be provided in order to do what it does,
      2. the kind of value(s) the method will return, if any,
      3. the naming of the method and any parameters, which may impact usability (descriptive names allow for quicker identification of what the method does and what kind of parameters should be provided).

      The programmer has a variable degree of freedom with regards to the first two and virtually unlimited freedom with regards to the third.

      The question of copyrightability hinges on the parts where the programmer either has freedom of choice or when the programmer’s choice is obvious enough to be considered uncreative. For example, a method that calculates the area of a rectangle would necessarily require two numeric parameters (of any type): width and height and would return a numeric value of the result. Those elements of the signature would not be copyrightable under Section 102(b) because they are necessary elements of the procedure of calculating the area of a rectangle. Similarly, parameter names like width, breadth, height, length and method names like Area, AreaOfRectangle or even Rectangle.Area (since it’s Java we’re talking about) would be uncopyrightable under the “scenes a faire” doctrine – they are the common expressions used with regards to calculating the area of a rectangle.

      Thus the following method signature:
      double AreaOfRectangle(double length, double breadth);

      Would rightly be uncopyrightable.

      What about this method signature:
      double SnufflePuff(double snuffle, double puff, int flavour);

      This method also calculates the area of a rectangle (I leave it up to the user to choose which dimension is the snuffle and which is the puff) with the added bonus of giving us the result in the flavour we want (details in the API documentation).

      This signature could rightly be copyrighted, for two reasons:
      1. the flavour is a non-essential element that is a creative extension of the basic procedure,
      2. the naming convention is not in any way obvious or common in the context of the procedure.

      The only reason someone would duplicate the above signature would be to appropriate its recognition amongst developers.

      This whimsical example illustrates that a programmer is seldom in a position where only one way of writing a method signature (or any API element) is possible and only marginally more often in a position where only one way of doing it is obvious or optimal. It is likely that in the context of a larger API, two programmers working independently of one another would create works that differ significantly – especially once we get into package-class-method organisation, where the programmers’ degree of freedom is even greater. Which is tangential to the matter, in any case, because Google intentionally copied the Sun/Oracle API’s in order to get exactly the same user experience.

      In a different literary context, this case is like someone claiming that they should be able to make derivative works based on Lord of the Rings (without licence or royalties, of course), because people really like Lord of the Rings.

      The extent to which any particular element of the API’s in question is copyrightable would require an examination of that particular element and I’m not about to go through 37 packages of Java code to do so. However, I would like to point out that – given the principle of encapsulation in object-oriented languages, such as Java – the API is the foremost copyrightable element, because that’s what the third-party user actually interacts with (the implementation code is meant to stay hidden from the user). Going back to the Lord of the Rings example, it would be like saying that the fact we published the exact same book is ok, because we wrote our own motivations for the characters and background details that are actually invisible to the reader. It’s just silly.

      • Faza: Earlier tonight, I was writing a compiler to translate JVM machine instructions into SPIM code, handling register allocation and spillage. So, yeah, I’m pretty sure I know what an API is.

        • I’m sure you do. I was writing for the benefit of people who don’t – you’ll notice Devlin, for example, mentioned he doesn’t, above.
          Our individual knowledge of the subject matter is irrelevant, however, because this isn’t rocket science. The issues are fairly clear and the law can be applied in much the same way as it would to other classes of literary works. Just because some individual API elements might not be copyrightable – just like some individual sentences, or even whole paragraphs – might not be, we cannot make a blanket judgemnent that no API’s are copyrightable.
          Conversely, the fact that some – even fairly short – portions of literary works are copyrightable does not preclude people from writing new literary works, perhaps even using similar literary tool and there’s no good reason to suppose that the situation is any different with API’s. This ruling, should it stand, will have absolutely zero effect on the ability of people to write original API’s, but it will stop pirates – like Google – from wholesale appropriation of other people’s work and goodwill for their unilateral benefit. Which is how it should be.

        • Karl,

          You don’t know what an API is under the law. It’s what you think the law should be to benefit your agenda. Well, you have lost.

          Thanks.

  2. Terry, your assertion that Google “deliberately set out to create a program that was not interoperable” is nothing more than that: an assertion. And it is an assertion that fundamentally misunderstands software interoperability.

    Software interoperability does not solely mean that one can write a complete program once, compile it once, and run it anywhere. Sun’s slogan notwithstanding, even Java does not conform to such a strict notion, as Sun has multiple editions of Java, supporting different sets of capabilities, and a program written for one edition may not run (without changes) on a different edition.

    More generally, software interoperability often relates to the ability to make substantial (even if not complete) reuse of existing code. This is particularly true of object-oriented languages (Java is an object-oriented language), where one of the primary purposes of the class concept, class libraries and inheritance is to promote code reuse. Programmers will ordinarily create class libraries of their own which they subsequently reuse within many different programs. And it is a common development paradigm to encapsulate platform-independent functionality within class libraries that are then coupled with platform-specific code to produce different programs to run on different platforms, while achieving high levels of code reuse.

    This level of interoperability has a long history. For example, BSD and Linux were developed to largely (but not entirely) replicate the standard APIs of AT&T’s Unix operating system, and many operating systems have incorporated support for such by implementing POSIX interfaces. Such implementations typically do not allow perfect portability of source code across the various operating systems, but they do allow programmers to structure their code so the vast majority of it is platform-independent, and only a small portion needs to address platform-specific dependencies. (And even where the source code is entirely platform-independent, such programs always had to be separately compiled to run on a specific system.)

    And in fact, Dalvik actually is source-compatible with Java. It simply isn’t bytecode compatible, requiring compiled Java programs to be further compiled in order to execute on the Dalvik VM.

    You make the claim that other “clean room” JVMs don’t implement the standard Java class libraries. I’d appreciate it if you could cite some such JVM. It’s hard to imagine how such could actually be usable to execute virtually any (non-trivial) existing Java program. And certainly, popular “clean room” implementations, such as the open source Kaffe and IBM’s J9VM absolutely do provide clean room implementations of the standard class libraries. What “clean room” actually means is that the system has been developed by individuals who have never had access to Sun’s proprietary source code. But these implementations absolute comply with Sun’s published, public interface specifications for the libraries, just like Dalvik.

    If there were actually a legitimate copyright interest in those interface specifications, one would have to wonder whether Sun still has the right to assert such after having allowed other clean room implementations to be freely used for nearly 20 years now, and at least arguably, the development community having accepted and adopted Java because of the availability of such. It would seem like equitable estoppel, or laches, would likely apply.

    And for those who immediately rejected Karl’s suggestion that the Federal Circuit’s reasoning could hold ordinary Java users to infringe, this is not a ridiculous notion. For while the court’s logic may not apply to merely invoking an API, in object-oriented languages, it is routine to create new class libraries that utilize identical interfaces to an existing class library. This is an intentional feature of such languages: a new (child) class inherits from an existing (parent) class, overriding some or all methods (which intrinsically requires using identical interfaces), so that other classes/programs can use objects of the child class as objects of the parent class.

    It’s certainly entirely plausible that, under the Federal Circuit’s reasoning, such inheritance — one of the core concepts of object-oriented programming — would actually constitute copyright infringement!

    If we look at the analogy to grammar and words and paragraphs, an appropriate extension of that analogy to cover this situation would be to say that the court has suggested that while it doesn’t infringe copyright to use the same grammar and vocabulary, using (standard) idiomatic expressions does infringe. And if we really wanted to make the analogy accurate, we’d probably need to be talking about a language where 90% of the language were idiomatic expressions.

    You see, Java follows in the path of many modern languages that, over time, have attempted to move as much functionality as possible away from being a core feature built into the language specification, itself, and out into standard libraries. There are many features that would have been core language features in older languages such as COBOL, FORTRAN, Algol, or Pascal that become features of standard libraries in later languages, including Java.

    As a result, many language features of Java are actually implemented in standard class libraries. As a practical matter, support for Java without support for the standard class libraries would not be compatible with any existing Java software at all — third-party programs and libraries would have to be completely rewritten, with virtually no code reuse, whatsoever.

    The specification of a language, and the specification of standard libraries each involve many choices, both as to grammar and specific words. And once chosen, those choices become equally functional in nature, in both cases, in terms of interoperation with other software.

    The notion that the specification of a language, itself, is not subject to copyright, but the specification of corresponding features moved into standard libraries is subject to copyright is, quite simply, absurd.

    • Is there a hard and fast rule that language specifications are not subject to copyright? Is anyone actually advancing such a notion?
      Section 101 of the Copyright Act defines a computer program as: “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result”. A language specification certainly fits this wording (the language specification being a set of statements and instructions to be used indirectly). This does not run afoul of Section 102 (b), because the exact set of statements and instructions is completely arbitrary and mostly irrelevant to the embodied functionality. The copyrightability of one language specification does not preclude the creation of different language specification (there are rather a lot out there) that will achieve essentially the same result.
      The exact same reasoning can equally well be applied to APIs.
      In practice, there is a tendency to “open up” language specifications and standard libraries, mostly because a tight licensing scheme for something that has numerous comparable competitors (other language specifications) doesn’t make much business sense. A programming language is only as good as its popularity. I can certainly imagine, however, a situation where the creator of a language specification might allow for royalty-free use of the language in creating software, but nevertheless require anyone wishing to produce a compiler or interpreter to secure an appropriate licence. I don’t know whether this has ever been done.
      Moreover, what is beyond dispute is that non-standard proprietary APIs do exist, so there appears to be no good reason why the protections available to “non-standard” APIs should be denied to “standard” APIs. The court certainly seems to concur here.
      I wouldn’t put too much stock in the standard FUD being raised by the usual suspects (and yourself, Mr Greenfield) for the reason stated above: Oracle has no business in scaring people away from using their product. Furthermore, even if legal action were brought against an individual developer, the facts of the case could well lead to a ruling that the use was either non-infringing (under Section 102 (b) or “scenes a faire” – I already addressed this in a previous comment) or that it was fair. And that’s even before we consider that both the specification and implementation are available under open licences in this case, so the majority of uses are likely to simply be licenced in one way or another.
      The material facts in this case are Google developing an unlicensed version of Sun/Oracle’s standard library, copying the API and free-riding on the goodwill built up in the developer community by Sun and Oracle. The fact that they had originally sought a licence, but did not like the terms does not help their case one bit. In fact, it looks like a classic example of Google trying to pull a fast one.

      • Faza, if you want to have a serious discussion, by all means, let’s have a serious discussion — but leave out the dismissals with ad hominem attacks claiming FUD. You’ll note, I made no claim suggesting that Oracle is about to start suing individual developers. But in assessing any interpretation of law, it is highly relevant to understand what the implications of that interpretation are. That is, it doesn’t matter if Oracle are well-intentioned saints. It should be cause for some considerable questioning if the interpretation adopted would empower a party like Oracle to claim a copyright infringement, regardless of whether they actually pursue such.

        I made, I think, virtually nothing in the way of assertions as to what copyright law does or doesn’t say with respect to this, because I haven’t undertaken to study the relevant provisions of the law. Rather, I merely provided clarifying and correcting factual information. There is quite clearly no shortage of lack of understanding of the facts surrounding computer languages and software development here (and apparently, on the Federal Circuit), and Terry made what, to my view, was a clearly unsubstantiated (and in fact, almost certainly completely false) assertion that Google’s intention was not compatibility.

        As to law regarding language specifications, I took it as implicit from the fact that Oracle did not sue for infringement over Google’s implementation of compatibility with the Java language, itself, and from Terry’s, and others’, reviews of the case, that nobody is suggesting that creating a system compatible with a language specification (e.g., a compiler and/or run time system) infringes copyright. That creates a clear dichotomy, under this ruling, between the interface for a feature implemented as part of a language specification, vs. the interface for the same feature moved outside of the language specification and into a standard library.

        It should strike anybody as highly suspect if the same specification is considered not to be protected by copyright if it happens to be (arbitrarily) defined to be part of the language specification, yet protected by copyright if it is alternatively defined to be external to the language specification.

        And after reaching what I think is the very reasonable conclusion that such a difference in where a feature is defined should not matter for the purposes of copyright, I would almost certainly turn around your proposal: if the interfaces for “standard” APIs are not subject to copyright, why should the interfaces for any APIs be deemed subject to copyright?

        The fact that there is some creativity in choosing the interfaces seems incidental to the primarily functional role of interface.

        Let’s consider an example outside of software. Suppose I create a new electrical outlet, with a different arrangement of holes for a plug. Perhaps I choose to align the three holes, and make them each star-shaped. There’s some creativity in choosing that particularly configuration, but is it enough to outweigh the functional aspect of the interface?

        If my arrangement has some significant functional benefit, then I likely can obtain a patent and get ~17 years of exclusivity. More likely, it’s just an arbitrary configuration with no particular functional benefit over a standard outlet configuration, and so is not eligible for patent protection. (This is almost certainly the case for all software APIs.)

        However, if I am allowed to claim a copyright on the configuration, and prevent others from making compatible outlets (or plugs), then I can effectively grant myself a patent-like ability to prohibit others from manufacturing a similar product, and for a term roughly 5 times as long as a patent (and even when my invention wasn’t patentable, in the first place)!

        Now, to a lay person, this would seem to be precisely the sort of thing that Congress was trying to prevent, by 102(b).

        Yet this would seem to be precisely what the Federal Circuit has now ruled software developers can do, by saying that they can claim a copyright interest in the mere interface they adopt for their software.

    • J.S. Greenfield,

      You’re a angel investor for no other reason but to protect your losses and try to confuse the copyright lawyers. You lost the Aereo case huge. Goodbye.

  3. It’s like the difference, which most people seem to accept, that when I myself make one backup copy of a copy-righted DVD (or piece of software – not just an object that might essentially be a container for software pieces) and store said backup in some other presumably safe place, that my act does NOT infringe, but that if I were to make 100,000,000 copies and sell them to Wal-Mart at $10.00USD each, thus becoming a billionaire, I WOULD be infringing.

    So what google did and why were infringements. Probably not protected by fair use but that’s for some jury to decide. Oracle cannot put that same question to me if I make a copy on paper or as a backup of some of their API’s, whether by all the specifications or by the all the structures or by all the code. No infringement here, nor if someone else’s software that I rightly use calls some of their software on my equipment that I also use.

    Get it together, folks. No ownership of ideas. No right to steal either. And fair use means something like what it says, not limited to the uses the creator had in mind but certainly not using their work for my profit in a manner requiring ownership rights (purchased, rented, licensed) which I do not have for the purpose of making money.