Computer programs are treated, for the purposes of copyright law, as literary works. As well as giving some legitimacy to the legion of people out there calling themselves Codepoet, this decision has the effect of making the division between idea and expression a key one in determining what is and is not ownable in a computer program. This is because it is a fundamental assumption in all doctrines of copyrightability that it is the specific expression that is protected, not the idea that underlies it. To take the example of a more standard literary work, it is a novel’s original arrangement of specific words on a page that is protected, not the events that make up its plot.
This division between idea and expression is slightly more complicated in the world of computer programs, however. Clearly the lines of code in a program’s source files are analagous to the words on a page in a novel, but what is a program’s ‘plot’? Is it the broad task that the program is written to achieve? How about the arrangement of code elements – say the way that the task is conceptualised as subroutines or objects? At what level of abstraction does a program pass from being an expression into an idea?
This question is an important one for anyone who is publishing code. While it’s easy to see that pasting someone else’s source code into your own program is likely to need the original author’s permission, it’s less clear whether borrowing someone else’s object model, data model or API definition is an infringing act. These questions have been being discussed both in the US and Europe recently as a result of a couple of high profile court cases.
In the US, Oracle and Google have been fighting over a range of intellectual property issues – both patent and copyright-related – for almost two years now. One key issue that remains unresolved at the time of writing is whether certain non-literal elements of the Java programming language are protected by copyright. This argument centres around what are essentially helpful code snippets that are provided to Java programmers by the creators of the language. These are arranged into named sets, with established conventions for calling them up and making use of them (APIs). The question at issue here is whether the naming of these sets and the conventions for making use of them is ownable.
In Europe, in a case covering similar though not identical ground, the European Court of Justice has ruled on an argument between SAS and WPL over the issue of whether a programming language and the structure of data files are ownable. The former question is closely adjacent to the Google-Oracle APIs issue: is a conceptual arrangement of useful items copyrightable? In this case the ECJ ruled that it is not, and drew heavily on the analogy with literature and natural language; books in English are ownable, but you can’t own English. On the issue of data files, on the other hand, the ECJ held that the structure of a data file is ownable as copyright as a part of the expression of a computer program. So here we have a real example of a concept which is not a literal expression but is still not sufficiently abstract to be an unprotected idea. (In the event this finding did not help the ‘owners’ of the data file format, as the act of infringement they were complaining about was legitimised by an exception in EU and UK law that permits certain acts in respect of computer programs if they are done for the purposes of facilitating interoperability.)
These issues may seem annoyingly abstract and inconsequential, but in fact they have deep significance for all software authors and consumers. While software is treated as a literary work in copyright law, its tendency to be more formally structured and complex than literature means that the division between idea and expression in it will tend to be hard to find. This in turn means that there is often a real lack of clarity on what aspects of a computer program can be legitimately reused by other software authors. This exposes the authors to risk, and means that we as consumers can find ourselves relying on software that infringes others rights and may be subject to unexpected licence fees or removal from the market. While not specifically an open source issue, it affects open source just as much as closed source. So the recent ECJ judgement and the forthcoming decision on API copyrightability in the Google-Oracle case are of real benefit to the IT community. Whatever the specifics of the decisions, their clarity will be useful.