Credit: Dreamstime
The great billion dollar sumo match between Oracle and Google has been winding its way through the courts and is just about to reach the final round where the US Supreme Court will decide, among other things, whether an API can be copyrighted.
There are a number of nuances to the case including accusations of pure plagiarism, but the tantalising question about APIs and whether they might be copyrightable is giving programmers and their good friends, the lawyers, something to argue about for many billable hours.
On one side of the debate are programmers who are wondering if there’s one more legal gotcha that they’ve got to worry about when writing their code. Is this another reason to sit through more meetings with more lawyers?
On the other side are the very same programmers who are putting in long days creating wonderful APIs and want to be rewarded with control over their baby. In other words, it’s an opportunity for the same lawyers to validate the programmers’ creativity and bring in licensing fees.
The case has been decided both in Google’s and in Oracle’s favour by different courts at different stages. In the latest ruling, the Court of Appeals for the Federal Circuit decided “that Google’s use of the Java API packages was not fair as a matter of law” and started the process of assessing damages.
Now the Supreme Court has scheduled hearings for March 24, 2020, and may finally decide the case. Maybe not forever, though, because forever is a long time.
The details of the battle between Google and Oracle will be of interest to lawyers and programmers who are immersed in Java development for the Android platform, but the larger question about copyrightability affects almost every programmer who calls hundreds or millions of APIs almost every day.
Aside from a few coders working at the lowest level of machine code, APIs are a part of almost every programmer’s daily existence.
Should APIs be copyrighted? How much power should programmers have over others? Here are N different reasons that argue both for and against giving the programmers the power over their APIs.
For: Programmers wrote it
The law is very clear about copyright. If a programmer writes down some code, the programmer owns the copyright on the work. The programmer may choose to trade that copyright for a paycheck or donate it to an open source project, but the decision is entirely the programmer’s.
An API may not be standalone code, but it’s still the hard work of a person. The programmers will make many creative decisions along the way about the best or most graceful way to share their computational bounty. If the developers are going to sit through all of those meetings and endure all of those code reviews, the developers deserve to be recognised for the toil with a copyright.
Against: APIs are functional
APIs are purely functional and the copyright law doesn’t protect the merely functional expressions. If you say “yes” to a flight attendant offering you coffee, you’re not plagiarising or violating the copyright of the ancient human who coined the word “yes.” You’re just replying in the only way you can.
Imagine if some clever car manufacturer copyrighted the steering wheel and the location of the pedals. The car manufacturers have plenty of ways to get creative about fins and paint colours. Do they need to make it impossible to rent or borrow a car without a lesson on how to steer it?
The law recognises that there are good reasons not to allow copyright to control functional expressions. An API isn’t a great work of code, it’s just the functional set of buttons that set the code in motion.
For: Functions evolve too
My new car is semi-autonomous and when I’m on the highway I don’t need to use any of the pedals. I simply toggle some switches on the steering wheel to adjust the speed and the following distance. The computer does the rest.
Just because the car industry clung to the standard locations of steering wheels and pedals for decades doesn’t mean that there is no room for improvement. Car companies are exploring using joy sticks, levers, and other controls, and they should be rewarded for their effort.
It’s often surprising how many ways coders can express the same basic operations with their own personal style. When I teach programming classes, it’s usually simple to spot copying immediately because of the differences in the way that each programmer answers the questions.
Even the simplest questions have dozens or even hundreds of solutions that achieve the same end. Yes, the API may be just a functional gateway to a huge block of code, but we should reward the creative decisions embodied in it.
Against: Only one way
Sometimes there’s only one way to do something and the copyright law has an exemption for moments like that. The doctrine of “merger” offers a limited escape hatch from copyright control when there are no other options. If there are only a few ways to express an idea, the idea is said to “merge” with the few options available.
Since the law is said to prevent copying the expressions of ideas and not the ideas themselves, the merged ideas must be open to use by everyone. Anyone trying to duplicate a block of code is going to want to duplicate the API too.
For: APIs are closer to code than ever
At one point, an API was just the top layer of a huge piece of work. The cherry on the top of the sundae. The part of the iceberg sticking above the water line. No more.
Thanks to automation and clever developers, much of the code under the API is often boilerplate. It’s more and more common for most of the work to go into crafting the API, while the rest of it is filled in by some combination of serverless systems, frameworks, CMS tools, and smart databases.
The developer’s architectural choices of input format, workflow, state transitions, and responses are often the biggest decisions made along the way. Many of the big blocks of code underneath are a mixture of libraries and automatically generated functions. Oh sure, there can be some real bursts of creativity deep in the stack, but it’s a mistake to dismiss the art of creating the API.
Against: Titles aren’t copyrightable
The copyright law recognises that sometimes tight regulation makes work impossible. While writers will spend hours searching for the perfect short, pithy phrase to name their book or movie, there just aren’t enough short, pithy phrases to go around. And so the courts decided long ago that titles can’t be copyrighted.
There are at least 19 versions of a book called “The Night Shift” and three versions of “Winter’s Tale,” for example, all written by different authors.
Functions have names and these names, like titles, are in short supply. There are only a few ways to say “print” or “find data.” Insisting that every programmer create a clever new set of function names may have been possible in the 1970s when the first programming language was created but there have been a lot of functions written since then.
For: APIs are more than titles
Of all the work that goes into writing an API, choosing pithy names for the function calls is probably the least complicated. Humourless saps doing code review will probably get upset when you try to be clever or humorous, so most programmers stow the puns and Dad jokes knowing they’ll never pass.
The real work goes into the data structures, the format, and the options available to whomever is calling upon the API. Once these are decided, the names and titles practically write themselves.
Against: Fair use protects limited copying
An API is just a small part of a large block of code. Copyright law has long encouraged limited copying under the doctrine of “fair use.” This is the same principle that allows students, journalists, and other writers to paste verbatim quotes into their own documents without worrying about being sued for infringement.
For: Fair use is not for commercial competition
The question of what constitutes fair use has been a question for the courts for decades. In general, the doctrine is intended to help customers work with their books, music, or images without infringing. Quoting a block of text in a scholarly essay or a newspaper article is welcomed when the new author adds insight or commentary, increasing society’s understanding. There are also fair use exemptions for making backup copies of digital works.
The extent of this fair use, though, is limited by the amount it could hurt the sales of the original work. If the API is copied to compete commercially with the original work and displace it in the marketplace, the law is less welcoming.
Against: Open APIs are about freedom
APIs are a close cousin to open source. They’re born of the same urge to link, connect, and integrate. The developers create an API to allow others to use it. Letting others clone APIs without permission opens up the world to more healthy competition.
Others can create competing blocks of code with the same API and this will spur innovation. Developers shouldn’t spend their time trying to lock down their API; they should spend it on improving the code behind the API.
For: Open source likes copyrights
There are many definitions about what it means to be “open” on the Internet. Some of them border on anarchy, but the most successful and fruitful are the open source teams, which often depend upon the law more than most realise. All of the major open source licenses rely upon copyright law for their strength. If the copyright law were weakened, the open source licenses would be too.
Against: Copyrighting APIs would destroy the Internet
The Internet relies upon cooperation and anything that gets in the way of cooperation will make it harder for everyone to do cool things. Adding another layer of law to the APIs will force everyone to stop coding and start arguing over who has the right to do what. Work wouldn’t get done. Services would shut down as everyone sued everyone else.
For: Copyrightable APIs have been the law
Since Oracle won the last round, the decision became the guiding light for the lawyers until the Supreme Court weighs in. The Internet didn’t stop functioning. The APIs did not close up. The bits kept flowing.
Meh: Copyrightable APIs are no big deal
The Supreme Court’s forthcoming decision will certainly affect the shareholders at Google and Oracle. It will also give law schools new material to debate for decades. But most programmers won’t feel the effects for the simple reason that most API creators want people to use their API.
Perhaps they created the interface to make money. Perhaps they have information to share. But most APIs are designed to be used widely with no restrictions on the code.
Still, the decision will be important for those moments when the hearts aren’t so pure and open. If you’re going to be using another block of code and relying upon it to do something essential, it’s worth examining the license and considering your motives.
Are you trying to educate and illuminate, one of the major foundations for the fair use exemptions that the law recognises? Or are you just trying to avoid sharing your revenue with someone else, the someone who created the code you’re about to rely upon?
If you’re working against another person’s best interests, if you’re just being greedy, there’s a good chance the law will sense it and punish you. The good news is that most API authors want their API to be used and most programmers want to form a long-term and mutually sustainable way by abiding by the wishes of the API’s creator.
