In the wake of the Google vs Oracle trial and yesterday’s European Court of Justice ruling, there has been a substantial volume of debate first on whether APIs should be copyrightable, and second what the industry impact would be if they are. Because we’re getting a reasonable volume of inquiries on the subject, it’s probably worth documenting my position publicly here.
Regarding the first question, it will probably come as no surprise to those familiar with my positions on intellectual property mechanisms like patents [coverage] that I do not believe that APIs should be copyrightable. The original intent and purpose of intellectual property mechanisms such as copyrights, patents and trade secrets is to protect original inventors and thus provide the incentive for innovation. The non-trivial challenge is balancing the individual good versus the public good. With the authored code that creates APIs is already subject to copyright and the original inventions (regrettably) protected by patent, extending similar protections to the byproducts – the APIs – seems over-broad.
Irrespective of my opinion on the subject, what will the impact be should APIs prove copyrightable? It is likely to be extensive, cascading and a lesson in unintended consequences. Even parties with no intention of asserting their intellectual property rights concerning APIs – think authors of permissively licensed programming languages, as one example – will presumably be required to commit to non-enforcement, contractually. And obviously those parties wishing to realize another revenue stream, limit competition or both will ramp up legal actions around unlicensed usage of the APIs in question. It’s difficult to fully predict the downstream effects, but given the accelerating servicification of the world, a decision in favor of copyrightable APIs is likely to be at least as damaging as the patent system is today.
That said, it’s worth noting that many large entities are already behaving as if APIs are in fact copyrightable. The most obvious indication of this is Amazon. Most large vendors we have spoken with consider Amazon’s APIs a non-starter, given the legal uncertainties regarding the intellectual property involved. Vendors may in certain cases be willing to outsource that risk to a smaller third party – particularly one that’s explicitly licensed like a Eucalyptus [coverage]. But in general the low risk strategy for them has been to assume that Amazon would or could leverage their intellectual property rights – copyright or otherwise – around the APIs in question, and to avoid them as a result. Amazon, while having declined to assert itself directly on this basis, has also done nothing to discourage the perception that it has strict control of usage of its APIs. In doing so, it has effectively turned licensed access to the APIs into a negotiable asset, presumably an outcome that advocates of copyrightable APIs would like to see made common.
In general, it is increasingly apparent that the traditional legal mechanisms associated with intellectual property both cause more problems than they solve and inhibit more invention than they incent with respect to software. It is equally clear, unfortunately, that given the financial stakes involved, the status quo is likely to persist in more cases than not.
One final note, for those concerned that a decision that APIs are in fact not copyrightable renders the GPL invalid, I recommend this piece by John Bergmayer. It lays out the legal foundation – or lackthereof – to that argument nicely.
Disclosure: Eucalyptus is a RedMonk customer, while Amazon is not.
