The Obama administration made a really dangerous and ignorant argument to the Supreme Court yesterday, which could have an insanely damaging impact on innovation — and it appears to be because Solicitor General Donald Verrilli (yes, the MPAA’s old top lawyer) is absolutely clueless about some rather basic concepts concerning programming. That the government would file such an ignorant brief with the Supreme Court is profoundly embarrassing. It makes such basic technological and legal errors that it may be the epitome of government malfeasance in a legal issue.
We’ve written a few times about the important copyright question at the heart of the Oracle v. Google case (which started as a side show to the rest of the case): are software APIs covered by copyright. What’s kind of amazing is that the way you think about this issue seems to turn on a simple question: do you actually understand how programming and software work or not? If you don’t understand, then you think it’s obvious that APIs are covered by copyright. If you do understand, you recognize that APIs are more or less a recipe — instructions on how to connect — and thus you recognize how incredibly stupid it would be to claim that’s covered by copyright. Just as stupid as claiming that the layout of a program’s pulldown menus can be covered by copyright.
The judge in the district court, William Alsup, actually learned to code Java to help him better understand the issues. And then wrote such a detailed ruling on the issue that it seemed obvious that he was writing it for the judges who’d be handling the appeal, rather than for the parties in the case.
Unfortunately, the judges at the federal circuit court of appeals (CAFC) didn’t pay attention and made a completely ignorant ruling, in which it became so clear that they didn’t understand the difference between software and an API that it was almost embarrassing. The decision quoted people in ways that were completely out of context, where the CAFC judges clearly misunderstood what was being said. This ruling would fundamentally kill off important forms of innovation if allowed to stand. It would be a disaster.
So, of course, the case has been appealed to the Supreme Court — and that’s where Donald Verrilli steps in. The Supreme Court asked the Solicitor General if the US had an opinion on the case. This apparently led to a healthy debate within the Obama administration over the position it should take. I know that there are people within the administration who understand these issues. Hell, Ed Felten has just been appointed deputy CTO for the administration and he, of all people, recognizes the difference between an API and software (in fact, he signed onto an amicus brief saying as much). He also (more than most) understands the copyright side of things and the potential impact of getting this wrong.
But instead of listening to the people who actually understand the technology, it appears that Verrilli sided with the copyright maximilist/technology-ignorant faction in the government. The final brief argues that the Supreme Court should stay out, that the CAFC got it right, and that it’s impossible to distinguish between APIs and software. Because Donald Verrilli has absolutely no clue how software works. That’s a fundamentally ridiculous argument, and argued out of near total ignorance of the basic facts of this case.
Just as a quick refresher, copyright law clearly states that:
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.
An API is, quite simply, a “system or method of operation.” It’s not copyrightable. That should be the end of the story. And yet, everyone who doesn’t get this keeps arguing that an API is the same thing as software itself. This is just flat out wrong. But Verrilli makes the same mistake:
Despite the inherently functional character of all computer code, the Copyright Act makes clear that such code can be copyrightable. Nothing about the declaring code at issue here materially distinguishes it from other computer code, and petitioner has identified no genuine conflict of authority concerning Section 102(b)’s applicability to circumstances like these. Although petitioner has raised important concerns about the effects that enforcing respondent’s copy-right could have on software development, those concerns are better addressed through petitioner’s fair-use defense, which will be considered on remand.
No, no, no and no. Everything about the declaring code distinguishes it from other computer code if you understand the first thing about computer programming. One is computer code. One explains an interface for communicating with computer code. They’re fundamentally different things.
It’s like arguing that there is fundamentally no difference between a recipe and a fully cooked meal.
And yet, that’s exactly what Verrilli and the Obama administration are now arguing to the Supreme Court. Because they don’t understand even the most fundamental things about code, and assume that because an API looks like computer code (because whoever wrote this brief is ignorant of coding), they’re the same thing.
Later in the filing, Verrilli, again, seems to assume that an API is the same thing as “computer code.”
If the Copyright Act contained no explicit references to computer code, one might reasonably conclude that such code is not protectable “expression” at all. Computer code differs in a fundamental way from many traditional means of literary expression. A book or newspaper article is meant to be read and comprehended by a human being as a description of an idea or story. Although many copyrightable written documents explain how practical tasks should be per-formed, there is typically a clear distinction between the written explanation and the actual performance of the task. Computer code, by contrast, is both expression and the actual means by which a computer is induced to perform the desired function. It therefore would not be unnatural to describe computer code as a “method of operation” or “system.” Nor would it be unreasonable to conclude that, as between a book on bicycle-building and the actual construction of a bicycle, computer code is more analogous to the latter.
Again, the entire basis of this paragraph is arguing something no one is arguing against. Everyone agrees that computer code is copyrightable. What we’re arguing is that APIs are not computer code — because they’re not. But because Verrilli and others can’t seem to wrap their head around this, they just lump it all together. And the argument, based on this faulty premise continues:
The Copyright Act as a whole makes clear, however, that the functional character of computer code cannot be sufficient to bring it within Section 102(b). If that were so, no computer code would qualify for copyright protection;
This makes no sense. At all. Of course, computer code is copyrightable. But an API that is just a method of how to interact with that code is not computer code.
yet the Copyright Act unequivocally recognizes that a person can own a copyright in computer code…. Rather, the uncopyrightable “method of operation” or “system” or “process” is the underlying computer function triggered by the written code—for example, an algorithm that the computer executes to sort a data set. The code itself, however, is eligible for copyright protection.
Again, yes, of course the code is copyrightable. But the code is not the API. It’s incredible how fundamentally the Solicitor General doesn’t seem to grasp this simple concept.
When the filing eventually tries to get around to the difference between an API and software code itself, it basically just throws up its hands, saying “well, it looks like code, so it’s all the same to us.”
That distinction does not withstand scrutiny. Both declaring code and implementing code ultimately perform the same practical function: They instruct a computer to work. The declaring code tells the computer to call up the implementing code, and the implementing code tells the computer to perform an operation, such as executing a sorting algorithm. Both are necessary components of a Java or Android method. And neither the declaring code nor the implementing code is what a programmer physically types when invoking a method.
Yes, and the recipe and the ingredients are both “necessary components” of a meal, but that doesn’t make them the same thing. Hell, to be more specific, the recipe and the description of how to prepare a meal are both necessary and they look fairly similar. But in copyright law the recipe is not copyrightable, while the description may be. That’s the same thing with software code and APIs. But because the folks who wrote this brief are either ignorant — or ridiculously chose to ignore those who do understand these things — we get this absolutely embarrassing brief from the US government. It’s a travesty.
Furthermore, Verrilli seems to be suggesting that the important Lotus v. Borland case which found that the layout of a computer program’s menu structure were not covered by copyright, was decided incorrectly!
The precise rationale of Lotus is not clear. Parts of the opinion purport to rest on the proposition that Section 102(b) can foreclose copyright protection for original expression…. But other parts of the opinion seem to apply a principle analo-gous to the merger doctrine, to the effect that, be-cause there was only one menu hierarchy that would allow users to operate the spreadsheet program in substantially the same way, the menu hierarchy (un-like the underlying code) could not acquire copyright protection…. Whatever the rationale of Lotus, however, the decision cannot reasonably be read to treat Sec-tion 102(b) as applicable to computer code itself, a form of expression that the Copyright Act clearly protects and that the First Circuit took pains to distinguish.
Also very wrong, is Verrilli’s repeated claim that these are issues that can be handled by a fair use analysis, rather than the question of whether or not API’s are copyrightable at all:
Indeed, many of petitioner’s specific contentions will be relevant to its fair-use defense on remand. For example, although it would be anomalous to use Section 102(b) to distinguish between different segments of a single work of authorship…, Section 107(3) instructs courts to consider “the amount and substantiality of the portion [of a copyrighted work] used in relation to the copyrighted work as a whole” in adjudicating a fair-use defense. That petitioner copied only respondent’s declaring code while writing its own implementing code should therefore be a relevant factor in the lower courts’ fair-use analysis.
But this, too, is wrong. There’s a big difference in saying “this is not copyrightable” and “this can be used thanks to fair use.” Fair use is (unfortunately) limited and dependent on a number of factors. Something that is not covered by copyright is open to all comers. The difference is really important and the Solicitor General doesn’t even care at all.
Unfortunately, the Supreme Court often follows the Solicitor General’s advice on cases (though, not always). If it does so here, it would be a travesty and truly dangerous for innovation. As a ton of top computer experts (including now deputy CTO Felten) noted in their own brief (put together by the EFF), the lack of copyright in APIs has been a key element in defining the way the digital world works. To find otherwise would be a massive hit to basic innovation. As that brief explained
Today, open, uncopyrightable APIs continue to spur the creation and adoption of new technologies. When programmers can freely reimplement or reverse engineer an API without obtaining a costly license or risking a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to develop. Moreover, compatible APIs help enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. Without the compatibility enabled by the open nature of APIs, consumers could be forced to leave their data and programs behind when they switch to a new service.
The freedom to reimplement APIs also helps developers rescue “orphan” software or data—systems that are no longer supported by their creators. When a company stops supporting a computer platform or service, the ability to freely reimplement APIs protects the communities that rely on that software. Government entities and non-profits are especially susceptible to the orphan programs problem as they often cannot afford to upgrade and are left using legacy technologies for years or decades.
It would be truly ridiculous that, just because the MPAA’s former top lawyer is so ignorant that he can’t comprehend the difference between an API and actual software, that the Supreme Court would allow such a terrible ruling as CAFC’s to stand.