Saturday, May 10, 2014

In Java case, Federal Circuit just declined to hold massive body of creative stuff non-copyrightable

Within the context of the "smartphone IP wars", yesterday's appellate opinion in Oracle v. Google was spectacular. An unprecedented comeback. Oracle now has more legal leverage over Google than anyone else, such as Apple, has ever had, even at this stage, where things may still take a couple of years before an injunction issues (and, of course, there is some uncertainty remaining with "fair use", though the Federal Circuit made certain limits of that defense clear as well).

But "spectacular" doesn't mean "novel". Let's be clear about that. About two years ago I already wrote that "Oracle v. Google can't MAKE APIs copyrightable -- they HAVE BEEN for more than 20 years". In that post I referred to the Johnson Controls case, which the Federal Circuit also referenced several times in its decision.

This morning I read -- cursorily for the most part -- various comments, including reports on the decision by media that are usually nonjudgmental, and I felt that some people were living in a parallel universe. This includes some of the people who unjustly bashed me after the erroneous district court ruling in 2012 because they didn't realize I had been consistent on copyright in the interoperability context for a long time -- going back to 2004, in fact, in connection with Blizzard v. bnetd (a client-server DMCA case).

Now they can't bash me because I was simply right. So whom are they bashing? The Federal Circuit. They still believe Judge Alsup (whom I respect but nevertheless disagreed with on some issues, particularly copyrightability) got it right. There's all this glorification. Yes, based on what I read from him (his filings) and about him, I have no doubts that he's an interesting, in many ways impressive person. But that doesn't make him infallible. His position on copyrightability wasn't even original: he simply adopted everything Google's counsel told him. And now the Federal Circuit has agreed with Oracle on each copyrightability-related point.

One may dislike the fact that the Federal Circuit generally supports intellectual property protection, and maybe does to a greater extent than some other courts. That's OK. What's not OK is to vilify and disrespect that extremely competent court. The circuit judges deal with technical issues every day because their court hears all U.S. patent appeals from district court rulings. Day in and day out they rule on claim construction (interpreting patents), infringement and non-infringement theories, invalidity contentions (comparing patents to prior art). And the decision was reached unanimously by a panel of three judges -- not just one, such as in the district court. I wouldn't even want to claim that these judges are better than Judge Alsup because they serve on a higher court -- if Judge Alsup had been appointed to the Federal Circuit (which depends on many things besides someone's capabilities) and had served on it for a number of years, I have no doubt at all that he'd be a well-respected circuit judge by now. But it would be ridiculous to assume that circuit judges are inherently less smart than district judges.

Judge Alsup became extremely popular in tech media (as a side effect, most likely unintended) and activist circles by saying that he learned to program Java because of this case. I'm also a programmer (by the way, the U.S. patent application I filed this week includes roughly 100 pages, much more than the average patent application, of sample code I wrote in C#, which is very much like Java), so I, too, liked to hear that. But then he issued that erroneous non-copyrightability ruling, and when I read it, I must say with the greatest respect that it did not look to me like something written by a programmer (I'm not saying he didn't learn Java, just that the ruling didn't reflect the related knowledge). One key issue with it was that he conflated the freely-available Java programming language (commands/keywords) with the APIs. By contrast, the Federal Circuit showed how to get that part right. The circuit judges made a clear distinction in yesterday's decision between APIs that may arguably be needed to even implement the free programming language per se (maybe three of them, maybe a little more) and those that are not tantamount to programming language keywords. That is the degree of analytical precision and accuracy that I missed in the district court decision, and I found it in the Federal Circuit opinion. I, as a long-time programmer who wrote ten computer books while in high school, found nothing whatsoever in the Federal Circuit opinion that suggested a lack of understanding of software technologies. But all sorts of people out there now blame the Federal Circuit for not having understood the technical part. That is outrageous.

Let's now get to the real issue, which is the substance of the decision(s) at issue and not the competence of the decision-makers (which others chose to make a big issue in the public debate, without any factual support).

The next major fallacy on the part of those who criticize the appellate opinion is that they substitute their policy views for where the law (statutory law and applicable case law) stands. That's common. Software patent-eligibility is a context in which it's particularly extreme. Anybody with a modicum of knowledge and the ability to shut out ideology can see that U.S. statutory law on patent-eligibility is expansive and inclusive, so the only way to create restrictions is through new legislation. Nevertheless, one effort after the other (recently, CLS Bank) is made to persuade judges to legislate from the bench. And when judges provide minor clarifications that move the goal posts by a quarter of an inch, some people claim that they've been moved by a mile.

The Federal Circuit would have had to legislate from the bench to an extreme extent in order to concur with Google and its supporters. It declined to do what it's simply not supposed to do. It focused on its job, which is to interpret and apply the law as it stands. Isn't it absurd that people who have an important job to do and decide to do that job -- but refuse to do a job no one elected or appointed them for -- then get bashed? Maybe all three circuit judges should have said at the hearing that they learned Java for this case. No one could have proved the opposite, and some people might not criticize the circuit judges now. But they focus on their job. Not on PR stunts. Not on currying favor with activists. They deserve praise, not insults, for their focus on the real thing.

If the Federal Cicuit had affirmed the district court's non-copyrightability ruling in this case, it would have become the first appeals court in the U.S to hold a massive body of (highly) creative, original material not to be protected by copyright.

The people who say that this ruling makes new law are unable -- they don't even try -- to point to appellate decisions in the U.S. that held anything comparable to Java in both creativity and magnitude to be devoid of copyright protection.

Even before API copyrightability became an issue in Oracle v. Google (in the early stages of the dispute it was just known to the general public that the case involved a copyright infringement claim, but not what it related to other than one sample file Oracle provided relatively early on), I talked about it on this blog (in connection with Linux and other copyleft software, in early 2011), and I looked at a number of cases that are now mentioned in the Federal Circuit opinion and some additional ones that were addressed in various briefs and in the district court proceedings. There's no shortage of U.S. appellate case law that held some stuff non-copyrightable because obviously there were always some people who tried to expand the scope of copyrightability in unreasonable ways. But every single one of those non-copyrightability holdings by appellate courts relates to fact patterns that are easily distinguishable from the 7,000 lines of Java API declaring code that Google conceded was highly creative and that it also conceded it had literally copied. Yes, this is a real case of copying, unlike Apple v. Samsung II, where copying was just a red herring that Apple used, with very limited success in the end.

7,000 lines of concededly highly-creative material -- this involves a combination of a quantitative criterion and a qualitative one. You won't find that combination in any of those other cases except when -- and this is just about fair use, not copyrightability -- all that was allowed was intermediate copying (making a few copies for internal development purposes, such as reverse engineering).

There was Lotus v. Borland, about a spreadsheet menu structure that Google's counsel admitted (at the appellate hearing) was not comparable to the Java material because it was so much smaller and simpler. At any rate, the Supreme Court was divided over that one.

A long, long time ago there was Baker v. Selden, where someone wanted a book on an accounting method to result in a monopoly over that method. But owning copyright in a text is different from owning every application of what the text teaches.

In Feist v. Rural, it was made clear that "sweat of the brow" is not a criterion for copyrightability. A phone directory may take a lot of work to put together, but ultimately it's just real-world data -- not original stuff of the kind that Sun Microsystems' engineers created when they wrote those APIs.

In Sega v. Accolade, all that was allowed was a combination of intermediate copying for development purposes (unlike taking stuff and building it into a new product that is distributed, which is what Google did when it hijacked Java for Android) and the copying of 20-25 bytes of code that only served as an identification (like an internal password) that was necessary to make games run on a console. 20-25 bytes. Not 7,000 lines.

So you can find non-copyrightability holdings by U.S. appeals courts for

  • vast quantities of non-original stuff (telephone directories etc.),

  • tiny quantities of original stuff (20-25 bytes, for example), and

  • small quantities of low-creativity stuff (spreadsheet menu structure, and even that one was affirmed only by a divided Supreme Court).

Nothing like the Java APIs.

Both Sega and the subsequent Sony v. Connectix case -- fair use and not copyrightability cases -- did not establish an interoperability exception to copyrightablity, as the Federal Circuit clarified but Google's supporters still don't want to recognize. I already addressed that one two years ago. The problem with reading Sega (which Sony is based on) as holding anything related to compatibility to be non-copyrightable is that this is not even an obiter dictum. It's simply not stated at all unless one takes a few words out of context.

Unless we all want total chaos, there must be a reasonable standard for what is res judicata, an issue that a court actually decided. The standard for what is an obiter dictum (something mentioned beyond the actual decision but expressing an opinion) is lower, but the "interoperability exception" thing does not even meet a reasonable dictum standard if you and I agree that even something that someone claims was said incidentally in a decision must at least be said with a minimum degree of clarity and specificity.

In Sega, interoperability was considered a laudable goal. Yes, it is. That fact weighs in favor of fair use. In that case, it did. Rightly so. So if you only do a few intermediate copies for yourself and you copy 20-25 bytes (a mere identifier), and that's what it takes to bring more games to consumers for a platform they've purchased, that may be fine. In that case, it was. Rightly so. But the Ninth Circuit (the West Coast circuit) didn't say that anything relating to compatibility -- which would require some very complex line-drawing if it was the law (which it is not) -- is by definition non-copyrightable. Every piece of software (including Java, as Oracle never disputed) involves ideas and functionality of the non-copyrightable (perhaps patentable, but not copyrightable) kind. §102(b) of U.S. copyright law ensures that copyright protection does not extend to those ideas and functions, but the expression is protected. So the Ninth Circuit said that Sega's software involved such higher-level ideas and functions, it can't protect those with copyright, and it's fair use to make a few internal copies to research that non-copyrighted functionality, and the justification for research is (in this particular case) that interoperability is a laudable goal. It didn't refer to what kind of code it is: object code, source code; instructions or declarations; textual or binary. Undoubtedly, Sega's software, like anyone else's software including Oracle's software, embodies concepts that fall under §102(b). But it's not even a dictum, much less res judicata, without a minimum of specificity. If one doesn't specify what §102(b) relates to, then the broadest interpretation would simply deprive all software of copyright protection, which without a doubt none of the Ninth Circuit judges intended.

So there is neither any applicable case law in the U.S. that holds a Java API-like combination of quantity and quality (originality/creativity) of material non-copyrightable nor is there an interoperability exception to copyrightability in the Ninth Circuit.

The full Federal Circuit (a petition for an en banc review is a given) or the Supreme Court couldn't and wouldn't create such an exception either. Google and others who want this have to talk to Congress. They don't even seem to try this, presumably because they know it won't happen since the software industry is overwhelmingly on Oracle's side.

Then don't blame the Federal Circuit for doing its job. The Federal Circuit opinion is extremely well-reasoned and, as I said, reflects an accurate understanding of how programming languages and APIs work. Unfortunately, many of those who have commented on it and will comment on it going forward may not even have read it in the first place. They just don't like the result.

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: