2021 – a Big Year for APIs & Software Copyright
The time is ripe to take stock of software interface copyright on each side of the Atlantic. The subject has graced the US Supreme Court twice so far this year. In April, the Court handed down its long-awaited opinion in Google v Oracle, settling a decade-long API copyright dispute between two tech giants. In January, the Court rejected a certiorari petition in World Programming v SAS Institute, another long-running, if less well known, interface copyright litigation.
2021 is also a significant year for interface copyright this side of the Pond, though rather more symbolically: in May, the first Software Directive – the instrument setting the terms of software copyright in the EU and the UK – celebrated its thirtieth birthday.
All the while, the importance of APIs is growing. API calls are now said to account for over 80% of all internet traffic1 while the average app uses between 10 and 15 APIs.2
This article reviews the recent US cases and contrasts them with the approach taken in the EU and the UK. It finds that the traditional fault line between the two regions – more copyright protection for APIs in the US versus more flexibility to achieve interoperability in the EU and the UK – is still alive and kicking.
Google v Oracle – the US Position
Google v Oracle is a well-worn path by now.3 So we will skip the detail and get directly to this year’s key development: the US Supreme Court’s decision. These two questions were put to the Court:
- First, were the elements of the Java API that Google copied capable of being protected by copyright?
- Second, if ‘yes’ to the first question, was Google’s use of the Java API fair use?
The first question is often referred to as the ‘copyrightability question’. In general terms, it asks whether copyright protection extends to a software interface. The second question is the ‘fair use question’. Fair use is a statutory exception to copyright protection in the US. It involves balancing four ‘fair use factors’5 specified in statute to reach a conclusion that a particular use of copyright material is not infringing. Fair use is fact-specific and tricky.6
The Court handed down its decision in April. In an unexpected move, it reserved judgment on copyrightability and found in Google’s favour on fair use. Because it dodged one of the key questions of the litigation, this was seen as a surprisingly narrow holding.
The Court explained its reticence on copyrightability as follows:
Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute.7
In other words, this is an acknowledgment that interface copyrightability is a complex area, and a broad finding that could have unintended consequences is best avoided.
Moreover, the Court was divided. A firmly worded dissenting opinion criticised the majority view, concluding “[t]he Court wrongly sidesteps the principal question that we were asked to consider. Is [the Java API] protected by copyright? I would hold that it is.”8
The practical takeaway from all this is that, even after a decade of litigation, in the US the extent to which interfaces are copyrightable is unclear.
The Software Directive – the EU/UK Position
In the EU and the UK the boundaries of software copyright have their origin in the first Software Directive.9 The basic position, set out in Article 1(2), is as follows:
[Copyright protection applies] to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright.
The first sentence here is easy enough. The second is more difficult, but its overall effect is to import copyright’s traditional ‘idea/expression dichotomy’ into the realm of software copyright: expression is copyrightable, the ideas and principles which underlie expression are not. The second sentence does not say that interfaces do not get copyright protection. As in the US, the line is much less clear than this.
However, the EU/UK regime is generally viewed as taking a stance which favours interoperability (i.e. less copyright protection for interfaces) over copyright protection (more protection for interfaces). In large part this is because the Software Directive contains several specific exceptions where copyright protection for software does not apply.
There are two key exceptions to software copyright in the Software Directive: the so-called ‘black box’ exception in Article 5(3) and the ‘decompilation’ exception in Article 6. We will not dwell on the nature and extent of these exceptions here, except to note a couple of points.
First, the overall effect of the ‘black box’ and ‘decompilation’ exceptions is to clip the wings of software copyright. They legitimise some of the activities involved in creating competitive and interoperable software. The Software Directive polices attempts by powerful vendors to ‘contract out’ of these exceptions by insisting that contractual provisions contrary to them are null and void (Article 8).
Second, the ‘black box’ and ‘decompilation’ exceptions are narrow. While ‘black box’ is slightly more forgiving, ‘decompilation’ is shackled with three conditions and three further restrictions. In short, trying to rely on these provisions is a risky business, especially if the contract says otherwise (as we will come on to see).
As a brief aside, before we get to our second interface copyright case, the history of the ‘black box’ and ‘decompilation’ exceptions really is fascinating. Think: lobbying wars fought between powerful US software houses in Europe and further afield in the late 1980s and early 1990s as governments were working out how to regulate software IP.10 Think also: ECIS and CBEMA (the European Committee for Interoperable Systems and the Computer and Business Equipment Manufacturers Association).11
SAS Institute v. World Programming – quick recap of the facts
Our second interface copyright case is SAS Institute v World Programming. Like Google v Oracle, this case has spent the last decade in the courts – this time in England, at the CJEU and in the US – with the US Supreme Court denying a certiorari petition by World Programming in January 2021.
Briefly, these are the facts:
- SAS and World Programming are both software houses. SAS is based in North Carolina. It develops analytics software. World Programming is a British software company.
- World Programming took a licence to SAS software. The licence was a click-wrap licence, governed by North Carolina law. In effect, the licence terms purported to prohibit the use of SAS’s software to develop competing software.
- Despite this restriction, World Programming used SAS’s software to produce the World Programming System, a competing software product which emulated the functionality of SAS’s software.
- World Programming did this by observing the functioning of SAS’s software. World Programming did not have access to the underlying SAS source code.
- In 2009, SAS sued World Programming in the UK for copyright infringement and breach of contract.
- In 2010, SAS brought the same case against World Programming in the North Carolinian courts.
The following paragraphs unpick the contrasting outcomes in the English and the US courts.
SAS Institute v. World Programming in the UK – the ‘black box’ exception trumps copyrightability
The English courts found in favour of World Programming. First, by observing the inputs and outputs of SAS’s software to produce its own replica software (but without copying the underlying code) World Programming could benefit from the ‘black box’ exception in Article 5(3) of the Software Directive. Second, insofar as the terms of the clickwrap licence prohibited behaviour that would otherwise have been permitted by the ‘black box’ exception, those terms were null and void.
Why was this case relevant to interface copyright in particular? One of the aspects of the SAS software World Programming copied was SAS’s data file formats – i.e. the interfaces between a data file and the software that ‘reads’ those data files. The High Court, having referred some interpretive questions to the CJEU, found that:
Copyright in a computer program does not protect… its interfaces (specifically, its data file formats)… from being copied.12
Pausing briefly before we return to the US, the High Court’s finding is a strong holding about the limits of interface copyrightability. There is a distinct contrast between this position and the ambivalence of the US Supreme Court’s copyrightability decision in Google v Oracle. The distinction becomes even more pronounced when the US courts handed down their decisions in SAS Institute v World Programming.
SAS Institute v World Programming in the US – “more protective” of copyright
Despite the outcome of the English litigation, the North Carolina court found in SAS’s favour. It found that World Programming had breached the terms of its licence with SAS. It also found that World Programming had behaved fraudulently – the fraud consisting of an implied representation that World Programming intended to abide by licence terms prohibiting the creation of competing software, which terms World Programming would subsequently argue were null and void under English law. The North Carolina court awarded SAS c. USD 80m in damages.
An extract from a 2017 judgment handed down by the US Court of Appeal for the Fourth Circuit helps to illustrate the underlying fault line which led to the contradictory outcomes in the two regions:
North Carolina public policy and EU public policy are in clear conflict in this case. The EU Directive that was dispositive of the contract claims in the UK litigation13 has no equivalent in North Carolina. Instead, the United States has taken an approach that is more protective of intellectual property, and North Carolina courts have taken an approach that is more protective of the sanctity of contract, including broad deference to the parties to elect the governing law… [Deferring to the prior UK judgments] would frustrate these policy goals by barring a North Carolina company from vindicating its rights under North Carolina law on the basis of the EU’s contrary policies.14 [Emphasis added.]
Conclusion – the bigger picture
This article has traced a longstanding tension between the US and the EU and UK approaches to software interface copyright. In essence, while the starting point in both regions is that computer code gets copyright protection, the EU and the UK tend to favour interoperability and the US favours copyright protection.
As a parting observation: we should not be too surprised by all this. Regional versions of software copyright rules do not set out universal truths in law, nor do they aim to. Instead, they reflect the social, political and economic priorities of the region in question. It makes sense that the US – the region whose companies and citizens have benefitted from an historically dominant software industry – should legislate in favour of the incumbents (pro copyright). Equally, we might expect the ‘challenger’ regions – the EU and the UK, among others – to create a rulebook which gives their domestic industries more of a chance (pro interoperability).
——————————
Notes and sources
