Last week I wrote about a talk I gave in Denmark on the subject of software patents, ahead of that country’s referendum on whether to join the Unitary Patent system. As I pointed out – and as many others have pointed out before me – one of the reasons that software patents don’t make any sense is that they are typically monopolies on an idea, not a specific implementation of that idea. That’s not how patents are supposed to work – you can’t get a monopoly on the general idea of a mousetrap, only on some particular new kind of mousetrap. As a result, it is often impossible to code around a software patent, because it applies to all implementations of the basic idea. That gives the monopolists in question a chokehold on both new products and innovation.
In my talk, I pointed out that software was unusual in that it could be both patented and copyrighted – even if software patents “as such” are not given in Europe, they are as “computer-implemented inventions” which are essentially indistinguishable from software patents, as the examples I gave in my talk demonstrated. Copyright is supposed to cover the expressive nature of code – just as it covers the expressive elements in a poem or novel. Last week, that “idea/expression dichotomy” was dealt a serious blow by a US court. Significantly, it is the same court – the Court of Appeals for the Federal Circuit (CAFC) - that is largely responsible for the software patent mess in the US.
The court decision [.pdf] concerns the long-running battle between Oracle and Google over the latter’s use of Java functionality in Android. Here’s the judgment’s summary of what it’s about:
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 predecessor of Oracle America, Inc. (“Oracle”) wrote these and other API packages in the Java programming language, and Oracle licenses them on various terms for others to use. Many software developers use the Java language, as well as Oracle’s API packages, to write applications (commonly referred to as “apps”) for desktop and laptop computers, tablets, smartphones, and other devices. Oracle filed suit against Google Inc. (“Google”) in the United States District Court for the Northern District of California, alleging that Google’s Android mobile operating system infringed Oracle’s patents and copyrights.
The patent claims were thrown out, leaving copyright questions. The latest decision is as follows:
we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection.
It seems pretty clear that the court thinks that APIs can be copyrighted, which runs counter to how most programmers would see things. Indeed, given the uproar this result has already caused, it would not be surprising if the decision were ultimately overturned. That uncertainty has already generated plenty of commentary, some of it more insightful than others. One of the best pieces I’ve read comes from Bradley M. Kuhn, whom I wrote about recently. As he himself notes, he has a curiously ambiguous relationship to copyright:
Many copyright policies of various jurisdictions, the USA in particular, are draconian at best and downright vindictive at worst. For example, during the public comment period on ACTA, I commented that I think it’s always wrong, as a policy matter, for copyright infringement to carry criminal penalties.
That said, much of what I do in my work in the software freedom movement is enforcement of copyleft: assuring that the primary legal tool, which defends the freedom of the Free Software, functions properly, and actually works — in the real world — the way it should.
As I’ve written about before at great length, copyleft functions primarily because it uses copyright law to stand up and defend the four freedoms. It’s commonly called a hack on copyright: turning the copyright system which is canonically used to restrict users' rights, into a system of justice for the equality of users.
However, it’s this very activity that leaves me with a weird relationship with copyright. Copyleft uses the restrictive force of copyright in the other direction, but that means the greater the negative force, the more powerful the positive force. So, as I read yesterday the Federal Circuit Appeals Court’s decision in Oracle v. Google, I had that strange feeling of simultaneous annoyance and contentment.
It’s a really thoughtful post, written by someone who has been living with that ambiguity for many years. But here I want to focus on what I think is its key insight:
in the original trial, Google did not admit to copying of any of Oracle’s text, documentation or code (other than the rangeCheck thing, which is moot on the API copyrightability issue). Rather, Google said two separate things: (a) they did not copy any material (other than rangeCheck), and (b) admitted that the names and declarations are the same, not because Google copied those names and declarations from Oracle’s own work, but because they perform the same functions. In other words, Google makes various arguments of why those names and declarations look the same, but for reasons other than “mundane cut-and-paste copying from Oracle’s copyrighted works”.
Kuhn then goes on to explain both why that’s probably true, and why APIs shouldn’t be copyrightable:
For we programmers, this is of course a distinction without any difference. Frankly, programmers, when we look at this situation, we’d make many obvious logical leaps at once. Specifically, we all think APIs in the abstract can’t possibly be copyrightable (since that’s absurd), and we work backwards from there with some quick thinking, that goes something like this: it doesn’t make sense for APIs to be copyrightable because if you explain to me with enough detail what the API has to, such that I have sufficient information to implement, my declarations of the functions of that API are going to necessarily be quite similar to yours — so much so that it’ll be nearly indistinguishable from what those function declarations might look like if I cut-and-pasted them. So, the fact is, if we both sit down separately to implement the same API, well, then we’re likely going to have two works that look similar. However, it doesn’t mean I copied your work. And, besides, it makes no sense for APIs, as a general concept, to be copyrightable so why are we discussing this again?
What’s interesting for me is that shows why copyrightable APIs are very similar to software patents: both are monopolies of such power that they prevent others from producing alternative implementations. That’s naturally problematic for open source – it means that it’s not possible to come up with free, compatible solutions created independently – but also much more widely. Even if you think it is a good idea to give one player a government-backed monopoly on an invention, making it impossible for others to compete with that invention through independent solutions that solve the same problem in different ways is clearly terrible for innovation.
And yet that is precisely the situation we are see are seeing in the US with software patents, and now with software copyright. The good news is that here in the EU, we have a 2012 decision from the EU’s Court of Justice saying that software functionality is not subject to copyright. That would seem to spare us from what might happen in the US in the wake of the CAFC decision, it it stands. Sadly, the same is not true for software patents, aka computer-implemented inventions, which look likely to wreak the same kind of havoc in Europe as they have in the US.