Why Making APIs Copyrightable Is Bad News For Innovation
from the this-is-a-big-problem dept
But, rest assured, if this ruling holds, it will be bad news for innovators. Over a year ago, Sacha Labourey had a good explanation of what's at stake here:
APIs exist for a reason: They act as the communication channel, the lingua franca, the boundary, between the provider of the implementation and users of that implementation — developers. Of course they require an investment to create. Deep expertise — and even taste — is required to create effective APIs. But, companies and individuals make those investments because they want developers to use an implementation that is exposed through the API. That implementation might give people an incentive to buy your hardware, software or services. Who knows, maybe it gives you a more effective way to sell ads.In other words, properly recognizing that APIs shouldn't be covered by copyright benefits everyone, as it makes people programming on your platform more valuable since they have more options and more flexibility. The big companies who don't like this are being short-sighted. They're trying to lock in developers, by forcing them to only develop for their platform, but in doing so, are inherently making their own platform less valuable. If innovators can easily write for multiple platforms, the network effects apply across all of those platforms.
You make some bets when you create an API, but they’re not about monetizing the API. They’re about monetizing the things the API unlocks access to. You’ll find APIs documented and used in many books, blogs and open-source projects. Adoption is probably the key measure of success of an API. But then if you encourage developers to use your APIs, why can you prevent them from implementing “the other side” of them? When Captain Picard orders a “Tea, Earl Grey, Hot,” at the Oracle replicator, he’s using a kind of API: “Object. [Qualifiers...]”. Google or anyone else should be able to create their own replicator without Oracle insisting they use some other syntax.
Oracle lost in their attempt to protect their position using patents. They lost in their attempt to claim Google copied anything but a few lines of code. If they succeed in claiming you need their permission to use the Java APIs that they pushed as a community standard, software developers and innovation will be the losers. Learning the Java language is relatively simple, but mastering its APIs is a major investment you make as a Java developer. What Android did for Java developers is to allow them to make use of their individual career and professional investment to engage in a mobile marketplace that Sun failed to properly engage in.
The folks over at EFF properly note that this kind of freedom is truly important for innovation:
What kind of litigation and what kind of mess are we talking about? Tim Lee, over at Vox, has some ideas:
The implications of this decision are significant, and dangerous. As we and others tried to explain to the court, the freedom to reimplement and extend existing APIs has been the key to competition and progress in both hardware and software development. It made possible the emergence and success of many robust industries we now take for granted—for mainframes, PCs, workstations/servers, and so on—by ensuring that competitors could challenge established players and advance the state of the art. In other words, excluding APIs from copyright protection has been essential to the development of modern computers and the Internet.
When programmers can freely reimplement or reverse engineer an API without the need to negotiate a costly license or risk a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to create. Moreover, compatible APIs 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. The freedom to reimplement APIs also helps rescue “orphan” software or data—systems whose creators have either gone out of business or abandoned their product in the marketplace.
Today's decision puts all of that at risk, potentially handing Oracle and others veto power over any developer who wants to create a compatible program. What is worse, if today's decision is taken as a green light to API litigation, large and small software tech companies are going to have to divert more and more resources away from development, and toward litigation. That will be good for the legal profession—but not so good for everyone else.
One good example is the open source project Samba. It was created to allow users of open source operating systems such as Linux share files with Windows users. To do that, the Samba programmers reverse-engineered and then duplicated the functionality of the Windows file-sharing system. They didn't copy any Microsoft software; they simply duplicated the sequence of commands needed to transfer files, read the contents of folders, and perform other functions in the Windows file-sharing system.Meanwhile, over at the Disruptive Competition Project blog, Jonathan Band, delves into the many, many ways that the CAFC appears to have totally misread the historical precedents that bind the court. But, even worse, he notes that many innovators and programmers have relied on those precedents for years -- and now all of that work is thrown into doubt:
Samba has become hugely popular. Not only did Apple incorporate Samba into some versions of Mac OS X to allow Macs and PCs to communicate, many third-party companies also used Samba to build stand-alone file servers.
The legality of projects like Samba has been widely accepted for more than two decades. But under the Federal Circuit's logic, Microsoft might be able to sue a Samba for copyright infringement. If the Federal Circuit's precedent isn't overturned, companies could become more reluctant to reverse-engineer competitors' products in order to make them compatible.
Grimmelmann also warns that the vague language of the decision could open the door to frivolous litigation. For example, the decision could make it easier for a company to sue a former employee if he goes to a new employer and writes software similar to the code he wrote at his old job. Even if the programmer writes the new code from scratch, courts could find that it's similar enough to the old code to trigger copyright liability.
For the past 20 years, since decisions such as Sega v. Accolade, Computer Associates v. Altai, and Lotus v. Borland, computer programmers in the United States have understood that copyright does not protect program elements necessary for interoperability. Based on this understanding, programmers have freely copied these elements, which has encouraged enormous creativity, innovation, and competition in the digital environment. Judge O’Malley’s decision casts doubt on this understanding. By ruling that interoperability is relevant only to fair use, and not to protectability, Judge O’Malley would require every developer to perform a fair use analysis before developing an interoperable product. This would place U.S. programmers at a competitive disadvantage to developers in other jurisdictions that recognized that copyright does not protect program elements necessary for interoperability. The Court of Justice of the European Union, for example, in the 2012 decision in SAS Institute v. World Programming Ltd., ruled that program functionality, programming languages, and data formats were not protectable under copyright.While for non-programmers, all of this may seem like a minor, technical issue over whether some small bit of "software" is copyrightable, the practical implications of declaring APIs copyrightable will have vast and far-reaching implications for all kinds of innovation. This isn't just a bad ruling, it's a ruling that will create massive problems for today's innovators.