More to come on this case, but the bottom line is that the Federal Circuit held that “API packages are entitled to copyright protection” despite their functionality. The court writes “we thus decline any invitation to declare that protection of software programs should be the domain of patent law, and only patent law.”

The Federal Circuit’s decision is a stunner because the consensus, for almost two decades, was that APIs are either not copyrightable, or may be copied based on a defense of “fair use.” So the structure of an API call, such as the example in the opinion to find the maximum two two numbers — “public static int
max(int x, int y)”–can be copyright protected and you need a trial to determine fair use!? The implications on interoperability and compatibility of this decision are immense, particularly since they’ve disrupted the law that most in the computer industry have come to expect. They directly ignored the policy implications that were specifically recognized in the Altai case, and have set U.S. copyright law divergent with Europe, where APIs are simply not protected.

I’m troubled by the fact that the opinion appears to rely heavily on an amicus brief from Scott McNealy, which they cite for specific facts relating to the choices and considerations that went into the design of the copied Java APIs. These footnotes should be removed from the opinion because it’s improper to rely on an amicus brief to supply basic facts on which the decision is based. Amicus briefs are designed to explore broader policy implications or argue law from the established factual record–not to expand the record with facts that the defendant never had a chance to explore or cross-examine.

Then they should be citing the facts in the district court evidentiary record, not an amicus brief. McNealy was a witness at the trial, so the fact that the Court is citing an amicus brief from him rather than his sworn testimony before the district court seems to indicate that McNealy’s amicus brief contained information that he didn’t testify about at trial.

The footnotes are particularly troubling because the Federal Circuit’s opinion relies on the notion that if you have ANY options at all in the design of an API, then it’s copyrightable. And McNealy’s amicus brief is really the only concrete stuff they cite about the alleged innumerable options they explored in designing the API classes at issue.

Don’t be coy, if you’ve read the opinion, you know the two footnotes I am talking about are FN6 and FN14.

FN6, they cite the McNealy amicus for a “detailed example of the creative choices involved in designing a Java package.” They don’t cite any corresponding trial evidence to back that up. They say McNealy’s statements were “consistent” with the trial evidence but all they cite is generic attorney argument from Oracle’s appeal brief (not evidence) generally talking about how long it to implement Java and wrestling with what to include in the classes. There’s obviously a big difference between a generic statement about what to include, and a “detailed example of the creative choices” regarding the particular package described in McNealy’s amicus.

FN14, they cite McNealy as essentially unsworn expert testimony about how other operating systems (Windows, iOS) implement similar time zone functionality — again to demonstrate the core idea that the Java designers had multiple alternatives from which to choose. The footnote ends with a blanket statement that this is “consistent” with the trial evidence, but that’s obviously false because they cite nothing from the record showing any iOS and Windows comparison. They don’t even cite attorney arguments from Oracle’s brief as they did in FN6.

If the Federal Circuit had trial record evidence to support these propositions, it obviously would have cited it in its opinion.

This opinion will be savaged on many fronts, but the Court’s basic disregard of basic judicial processes, such as deciding cases based on the evidence actually presented at trial that was subject to cross-examination, is particularly troubling to me.

Oh Federal Circuit, just when I think you can’t make yourself look less qualified.

“Using the district court’s “java.lang.Math.max” example, Oracle explains that the developers could have called it any number of things, including “Math.maximum” or “Arith.larger.””

All of those perform the function of describing the result of the code though. Had oracle called the function “yetiface” or “boxcutter” you might have a point. If a programmer sees Math.maximum (and does anyone seriously buy that math.max and math.maximum are even different expressions?) he has an idea of what calling the function will do. If the programmer sees Yetiface, he has no idea. Math.maximum is naming providing a functional benefit. Keep in mind that this is against the backdrop that names themselves aren’t copyrightable.

I particularly like how later on they distinguish Lotus because the commands there (“copy” “paste”) were not creative. As if “copy” and “math.max” have any kind of different quality. After all, isn’t copy just one of many phrases that expresses the idea? Wherefore art thou make.same.as?? What BS.

“Because Oracle exercised creativity in the selection and arrangement…”

There may be code which is creative in its selection and arrangement, but API libraries are not them. This is like saying that a dictionary is copyrightable because it exercises arrangement that was subject to multiple expressions (why alphabetical? why not length of word?) and creativity as to what words are included. (“Tweet” in it’s twitter context made it in? Let me get my copyright stamp.) APIs include what they include in the order they include them for purely functional reasons.

I particularly like how later on they distinguish Lotus because the commands there (“copy” “paste”) were not creative. As if “copy” and “math.max” have any kind of different quality. After all, isn’t copy just one of many phrases that expresses the idea? Wherefore art thou make.same.as?? What BS.

Hilariously, the Fed Cir has finally found something even less popular among software writers than its software patent jurisprudence. The full scale attack by the IP bar against innovation and progress in software continues apace.

Well, this now nicely sets up a case for cert. seeing as the Fed. Cir. goes out of its way to highlight the splits among the circuits on some foundational issues.

I actually think the Fed. Cir. and the 9th mostly get the analysis wrong under 17 USC 102(b), and the Fed. Cir.’s opinion here takes the most extreme view I’ve seen reported. I think it’s almost impossible to reconcile the interpretations on the patent side of “process” and “useful” with the copyright analysis here.

I get that. The whole case is the Fed. Cir. applying 9th Cir. law. What I’m pointing out is that the Fed. Cir. tees up the fact that the way the 9th Circuit does it is different that how other circuits have done it. Which, if you ask me, leads to very different results in a case like this.