Oracle/Google

For those who weren't paying attention (and it seems like almost anyone working in tech law was), oral arguments were held today in the U.S. Supreme Court in the long-standing litigation between Oracle and Google over the copyrightability and infringement of certain parts of Java (developed by SUN, now owned by Oracle) in Android. Transcripts from that argument, as well as the audio, should be posted on the Supreme Court website, probably later today.

A few general impressions, potentially apropos of nothing -- since predicting appellate outcomes based on oral arguments is a bit of a fool's errand:

1. The argument illustrates how technology lawyers often need to resort to non-technical analogies in order to make points about technical issues as they relate to the law. There's even a Twitter thread outlining all the analogies that were used just during this one oral argument. Analogies of this sort can be a bit of a mixed bag -- sometimes they help clarify a point for a judge (or Justice) with little background or training in technology, sometimes they muddle that point or omit nuance, and sometimes they are completely ineffective. I recall arguing a Markman hearing (this is a form of hearing that happens in patent cases to allow the judge to make a ruling on the scope of a litigated patent) where I analogized concepts in a patent to planetary motion in our solar system. It didn't seem to help the judge's understanding at all. The Supreme Court here seemed to be grasping for analogies to help them better refine their thinking on issues around Java classing/subclassing and declarations, but I'm not so sure any of the analogies used hit the mark. Only Justice Sotomayor seemed to want to skip the analogies and speak directly to how Java actually works (Justice Sotomayor may have the most copyright related experience on the Court now that Justice Ginsberg is gone; she even wrote an opinion on copyright infringement and fair use in a case filed by the creators of Seinfeld -- and Seinfeld was raised as one of the analogies during oral argument).

2. Although the Court had requested additional, later, briefing on the issue of respect for the original jury verdicts by the intermediate appeals court (the Federal Circuit), not a lot of the oral argument revolved around that issue. Most of the time was spent on the issue that many people have urged the court to decide -- how does one determine what types of code that is used in some way to interface either: a) should be copyrightable at all, or b) ought to be able to be used by others without fear of a copyright infringement claim, under the doctrine of "fair use" (called "fair dealing" in other common law jurisdictions, although that concept is not completely analogous)? At the time the additional briefing was requested, it seemed that the Supreme Court might be looking to dispose of the case under the Seventh Amendment (in essence preserving the jury's decisions), which was the angle that the Software Freedom Law Center had pursued in their amicus brief. This issue may still be the dispositive one (in which case, the litigation probably gets kicked back to the Federal Circuit to reinstate the jury verdict), but there seems to be a greater chance that the Supreme Court actually renders an opinion on issues around copyrightability and fair use.

3. On a couple of different occasions, the spectre was raised that a ruling in this case would "swallow up all computer software" into non-copyrightability. Given there's a pretty lengthy history of case law on the copyrightability of software, including several different tests for sifting between the copyrightable and non-copyrightable parts, that argument seems rather alarmist. But that questions like that are being raised might show that there is at least some discomfort with the lines that are asking to be drawn around non-copyrightability of APIs.

4. One of the more interesting aspects of the lower appeals court decision, and one which was not remarked upon during oral argument at the Supreme Court, was this statement by the Federal Circuit: "On remand, the parties stipulated that only 170 lines of code were necessary to write in the Java language. It is undisputed, however, that Google copied 11,500 lines of code—11,330 more lines than necessary to write in Java. That Google copied more than necessary weighs against fair use." This would seem to be an important factor that might be of relevance to whether or not the jury's decision on fair use ought to be maintained. One could imagine a decision that says that the replication of the 170 lines of code were fair use, but the remainder was not. The extent to which that distinction is important to the decision will remain to be seen in the written opinion.

5. There was also not much discussion during oral argument of the fact that there are a number of different decisions, applying similar but not exactly consistent, tests for determining whether and what kind of software code is and isn't copyrightable and may or may not be copied without fear of a copyright infringement claim. Justice Kagan referenced one of those decisions -- Altai, out of the 2nd Circuit, which gave the "abstraction, filtration, comparison" test -- but there are several others (mostly out of the 9th Circuit). Having clear and consistent tests for these issues, applicable across all courts in the U.S., would be of some help for those trying to negotiate these thorny issues, and based on oral argument there is at least some potential for that to happen.

6. The case was heard by an 8-member Court. The last time a significant software copyright decision made it up to the Supreme Court, the result was an even 4-4 split, so no significant decision was made. It would be a real shame to have that happen yet again in this case.

The written decision probably does not come out until next year, although there is also the chance of reargument if and when there is again a 9-member Court. The outcome is certainly to be closely watch, and will likely result in a lot of debate about how it might change how software copyrights work, and how programming is done, in the future.