Computer Scientists, Legal Experts Explain To Supreme Court Why APIs Are Not Copyrightable
from the let's-try-this-again dept
Back in May, the appeals court for the Federal Circuit (CAFC) enhanced its reputation of consistently getting basic patent law wrong by deciding to get copyright law wrong too, in declaring that APIs were copyrightable subject matter, in the Oracle v. Google lawsuit. As we explained at the time, the court appeared to make some rather serious fundamental errors, not understanding the difference between software and interfaces (and worse, totally misquoting some experts). Last month, Google asked the Supreme Court to review the case. On Friday, a bunch of interesting amicus briefs were filed, asking the Supreme Court to fix the CAFC's big mistakes.Perhaps the most interesting was put together by the EFF, and was signed by 77 computer scientists, including many of the most well-known and most respected computer scientists around, including Hal Abelson, Brian Behlendorf, Ward Cunningham, Peter Deutsch, David Dill, Dave Farber, Ed Felten, Mitch Kapor, Alan Kay, Brian Kernighan, Guido van Rossum, Avi Rubin, Bruce Schneier and Bjarne Stroustrup among others. There are a lot more, obviously, but those were just a few of the names that stood out.
The key point made in the filing is that this upsets decades of what was considered a settled matter in computer science, while highlighting how much of computer history was built off of the recognition of non-copyrightable APIs, allowing for the creation of interoperable systems, much of which drove the early computer revolution. Here's the summary from the brief:
For decades, computer scientists have relied on the open nature of APIs to enable rapid innovation in computer technology. For decades, circuit courts have supported that reliance, concluding that Section 102(b) of the Copyright Act protects a programmer’s source code as creative expression, but does not cover the processes, systems, and methods of operation that code may employ to interface with other software. The district court correctly followed that precedent and rejected Oracle’s claim that the Java APIs could be copyrightable. Sadly, the Federal Circuit chose to split with the other circuits and reverse the district court. That decision upended decades of industry practice and threatens the basic principles upon which our technology sector was built.Next up, is a filing from CCIA written in part by Jonathan Band, which is noteworthy in part because Band co-wrote the book on copyright and interfaces (first published nearly 20 years ago), explaining how interfaces aren't copyrightable and why that simple fact was responsible for so much of the computer revolution. This filing similarly notes how much of history was driven by interoperability, but also digs deeper into what a mess it would be if the CAFC's view was determined to be correct:
Not surprisingly, the Federal Circuit’s decision has been harshly criticized. As many commentators have noted, if the Federal Circuit’s view had been accepted at the birth of modern computing, many important technologies would never have existed, and/or succeeded. For example, the widespread availability of diverse, cheap, and customizable personal computers owes its existence to the lack of copyright on the specification for IBM’s Basic Input/Output System (BIOS) for the PC. And open APIs were essential to many modern computing developments, including those of operating systems such as UNIX, programming languages such as “C,” the Internet’s network protocols, and cloud computing.
Today, open, uncopyrightable APIs continue to spur the creation and adoption of new technologies. When programmers can freely reimplement or reverse engineer an API without obtaining a costly license or risking a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to develop. Moreover, compatible APIs help 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. Without the compatibility enabled by the open nature of APIs, consumers could be forced to leave their data and programs behind when they switch to a new service.
The freedom to reimplement APIs also helps developers rescue “orphan” software or data—systems that are no longer supported by their creators. When a company stops supporting a computer platform or service, the ability to freely reimplement APIs protects the communities that rely on that software. Government entities and non-profi ts are especially susceptible to the orphan programs problem as they often cannot afford to upgrade and are left using legacy technologies for years or decades.
If a company could exercise proprietary control over the interface specifications implemented by its products, that company could determine which products made by other firms – if any – would be compatible with its software. And should that company have a dominant position in a particular market, it could use its control over compatibility to expand its dominant position into adjacent markets. Moreover, such authority would extend the rights under copyright beyond what is necessary to protect the original expressive elements that have traditionally been offered protection under American copyright law, and it would override limitations on copyright crafted to protect the public good.CCIA also reminds the Supreme Court that Oracle (and Sun) not to long ago were among those who fought strongly for the position that interfaces were not copyrightable and that interoperability should be allowed. The filing notes that Sun and Oracle fought hard against parts of the DMCA when it was introduced that would have blocked interoperability. For example:
Such a broad monopoly would have serious implications for consumer welfare. In the absence of competition during the effective lifespan of the product, the first developer would have little incentive to develop more innovative and less costly products. These negative consequences would be compounded by the fact that the personal computer revolution and the emergence of the Internet have produced an overwhelming need for interconnection between different elements of computer systems. Prohibiting competitors from accessing de facto standard interface specifications would lock users into a particular operating system or network software environment, and would inhibit the transfer of data between users with different computing environments.... The Petition shows a host of real-world problems and economic harms that would result if API copyright could foreclose compatibility, including the cost of rewriting interface code formerly understood to be unprotected, and lock-in costs resulting from consumers’ inability to switch operating systems or cloud computing providers.... Lock-in would deter competition, investment, and innovation in the burgeoning cloud computing industry, which is known to be sensitive to policy changes in copyright.
In short, in the computer industry, overly broad intellectual property protection directly restricts competition and innovation. This was the status quo in the computing environment in the 1970s. Once a buyer purchased a computer system, the buyer was essentially locked-in to that system: the system was incompatible with products manufactured by other companies, and conversion costs were high. Although “locking in” was extremely profitable for dominant vendors such as IBM, competitors and users suffered from high prices, indifferent service, limited choice, and slow innovation.
In a 1998 press release, Michael Morris, then Vice President and General Counsel of Sun Microsystems, argued that the DMCA as introduced would “impose[ ] a new and unnecessary layer of restraint on lawful access to those unprotected elements of computer programs that are necessary to achieve interoperability, thus placing developers of interoperable products at the mercy of proprietary vendors.”That resulted in changes to the DMCA to make sure that interoperability was allowed. And yet, now, Oracle (via its Sun acquisition) is trying to argue that the exact opposite is true.
Finally, Public Knowledge also submitted an interesting brief which lays out the ridiculous situation we're in today with an analogy using amusingly named stand-ins and products:
Say that Delphi Corporation manufactures screws. It hits upon a new design for a screw socket—the interface between screw and screwdriver—that is more efficient than the prevailing Phillips and flathead insertions. Capitalizing on this novel idea, Delphi manufactures a line of screws using this socket, which it calls Sumatra. The Sumatra socket is wildly popular. New lines of screwdrivers are made for the Sumatra socket. Engineering textbooks praise the Sumatra design. Wood-workers teach their sons and daughters to use it. And competing screw manufacturer Zillion decides to make its own screws compatible with the Sumatra socket. The screws otherwise differ, but use the Sumatra socket so that woodworkers need not purchase new tools.Rather than focusing on more recent rulings concerning software, the Public Knowledge brief goes all the way back to Baker v. Selden from 1879, which found that you couldn't copyright a set of blank ledger forms.
Only then does Delphi declare the Sumatra socket a sculptural work, suing Zillion for copyright infringement.
Oracle repeatedly points to the “intricate web of connections" of the Java API, in an effort to suggest that its structure, sequence and organization of the API is copyrightable. Oracle Brief, supra, at 26. But so too can uncopyrightable blank forms constitute an intricate web of connections. Selden’s book included 19 forms and 24 pages of demonstrative explanation designed “to compress almost innumerable accounts under a few specific, intelligible heads.” .... For either blank forms or APIs, intricacy does not confer copyrightability.It's also nice to see the Public Knowledge brief call out the simple factual errors in the CAFC ruling (some of which we pointed out in our post at the time):
Given that an API is factually on par with a blank form, it is unsurprising that the reasoning of Baker directly applies to the copyrightability of APIs. Baker held that blank ledger forms, including the “ruled lines and headings,” could not properly be the subject of copyright.... The Court said that copyright cannot cover “systems” or an “art”; the Java API is certainly a system, one that teaches the “art” of using the Java system....
The Java API is on all fours with the blank forms of Baker, both factually and legally. Since copying of the blank forms in Baker was permissible, copying of the Java API is too.
... the Federal Circuit misunderstands arguments that interfaces are more properly protected by patent law than copyright law... Google, several amici below, and the district court merely proffered the unremarkable argument that functional elements should be excluded from copyright law by § 102(b) and the idea/expression dichotomy... But the Federal Circuit mistook them to mean that software may only be patentable or copyrightable, but not both. The Federal Circuit further assumed that criticisms of software patents equate to suggestions to expand copyrightable subject matter to cover interfaces.Hopefully, these and other arguments convince the Supreme Court of just how wrong the CAFC was in its ruling. Recently, the Supreme Court has been pretty bad on copyright cases, while generally good on patent cases, so it's always a little nerve-wracking when copyright cases get there. The one bit of good news is that the Supreme Court has clearly found itself regularly questioning CAFC's interpretation of laws, since most of those patent cases come up via CAFC. The only reason this copyright case went to CAFC was because it started out as a patent case, though the patent issues got tossed out early on.
These propositions are flawed. First, the Federal Circuit t neglects that there is matter outside the realm of both copyright and patent; the court apparently supposed that every element of a software program must fit into one or the other. Second, the Federal Circuit fails to differentiate the discrete elements of a given software product that may be copyrightable and those that may be patentable, instead lumping those elements together into a single entity. Third, the Federal Circuit conflates programming interfaces with computer programs generally.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: api, apis, computer scientists, copyright, copyrightable subject matter, functions, interfaces, software
Companies: ccia, eff, google, oracle, public knowledge
Reader Comments
Subscribe: RSS
View by: Time | Thread
Simplified argument
Then the use of the banks' APIs have to be negotiated. Which due to the complexity of the financial world, it is not unreasonable for contracts to take a year or more.
Direct deposit APIs are affected, so everything will have to be by written check for the foreseeable future.
Then the credit card company APIs, expected to take 18 months or more to clear up......
[ link to this | view in chronology ]
Re: Simplified argument
Still too technical for mortals to understand (though I enjoyed it, thanks).
As I read through this (thank you, Mike, for an excellent and easily understood report on legalistic minutia :-), I thought it might be instructive to use the example of various countries legal systems' interfaces, as that's where the judges might more easily find common understanding. British Common Law is different from Napoleonic Code is different from Russian, Chinese, ...
This story also reminded me of how often learning about this stuff is like being cuffed upside the head. Somebody tried to patent accounting leger forms hundreds of years ago? Well, yeah, I guess some smart ass would have tried that considering what I see going on in law making today. Yet we're still fighting that battle today, yet again, something that the court had settled long ago. Why's it coming up again now? Why's it seemingly so easy for lawyers to forget there is settled precedents for some given situation? Easy money, perhaps?
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Where is Microsoft on this?
Ironically it is in their best interest to over turn this ruling. For the same reasons I am not sure why anybody would want to use anything related to Oracle if it is allowed to stand. It could result in a new era of free licensing activities.
[ link to this | view in chronology ]
Re: Where is Microsoft on this?
Not really. It's what they choose to do with the copyright that would be the issue, not the mere fact that copyright existed. If they chose to try and leverage the copyright in order to negatively impact suppliers and competitors, there would be a problem. There are other approaches that wouldn't get them into any trouble.
[ link to this | view in chronology ]
Re: Re: Where is Microsoft on this?
Unless permission is signed and delivered, a change of ownership or leadership of a company can change the attitude to use of APIs. Therefore there would be a risk of legal action, loss of use unless a license being is obtined first.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
Why would that question be embarrassing and to whom?
Is CAFC a case, or is it a lower court - you seem confused.
Please state the particular case(s) in which the SCOTUS attempted to rule by making analog analogues.
[ link to this | view in chronology ]
Brown Instrument Co. vs. Warner (1947)
In Brown Instrument Co. vs. Warner (1947), the U.S. Court of Appeals for the District of Columbia said "[Baker vs, Selden] involved blank forms for use in bookkeeping. They were intended to be written on by hand, and the blank forms now in suit are intended to be written on by a machine, but this difference is immaterial. Neither sort of form is intended to communicate facts or ideas. Both sorts are intended solely for use in making records of facts. Articles intended for practical use with a machine are not copyrightable... both law and policy forbid monopolizing a machine except within the comparatively narrow limits of the patent system."
This was a case involving a recording thermometer, and the special graph paper which had been made to with it. The manufacturer found it convenient to scale the graph paper to correspond to the machine's operation, rather than to attempt to design mechanical linkages to correct the anomalies in the machine. I don't know specifically, but I would guess that the recording thermometer was more or less like a household thermostat in construction, that is a coiled bi-metallic strip with a lever at the end, and a pen at the end of the lever, so that the pen moved in an arc with changes in the temperature, and some kind of motor which caused the paper to advance. The lines on the paper indicating time would have been curved to correspond to the pen's arc, and the lines indicating temperature would have corresponded to the pen's actual position at a given temperature. This is a fairly close fit to what an API does.
The manufacturer wanted to copyright the graph paper in order to make the machine useless without a fresh supply of legally protected paper. And the court slapped the manufacturer down. This case tends to supply a "deep precedent" for the uncopyrightability of API's.
[ link to this | view in chronology ]
Re: Brown Instrument Co. vs. Warner (1947)
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
So, for example, lets say you're using ABCPDF (real software I use) which has an API specifically built for interacting with PDFs. It has the following:
virtual int AddBookmark(string path, bool open)
http://www.websupergoo.com/helppdfnet/
That right there is a method signature. If you import their DLL you can call this to add bookmarks to a PDF. Technically, this isn't an API, its just the name of a call located within their API.
I've never heard of anyone reference an API and not be referring to the underlying code. So, if I was talking about the ABCPDF API, I would be referring to everything included in the DLL download.
Moving on from there.
So, my question is if I were setting up another PDF API of my own to sell, is this lawsuit claiming that I can't use that same method signature in my own code? Is it stating that the list of method signatures is the API, and I wouldn't be able to have my own method of the form:
virtual int AddBookmark(string path, bool open)
I'm just asking because I've seen mostly a mental distinction between an API and a list of method signatures. Two APIs would be distinct from each other if they were implemented differently (say one in C# and another in Java).
However, the article makes it sound like they are referring to APIs simply as a list of method signatures, so I want to be sure that's what is meant. Because, it would be crazy to try to copyright a list of method signatures, but not an API as I understand it. However, I know how crazy copyright can be, so I'm actually pretty afraid that it is in fact the former!
[ link to this | view in chronology ]
Re: Re: Re:
Huh? The primary design goal of a good API is to eliminate the need to know anything at all about the underlying code.
"Because, it would be crazy to try to copyright a list of method signatures, but not an API as I understand it."
Method signatures are a part of an API. You can divide an API into two broad parts:
The contract between the implementers of the functionality and the users of the functionality: that when a particular call is made, the implementation will react outwardly in a specific way.
The protocol by which you talk to the implementation. (This is technically part of the contract, but bear with me.) This is a bit like a language: if you speak in this specific way, the implementation will understand what you're saying to mean this specific thing. Method signatures are part of the definition of this "language" and are formally part of the API.
This is distinct from the implementation behind the API. Just because you make the call matching the signature "virtual int AddBookmark(string path, bool open)" doesn't mean that the implementation handles the parms "path" and "open" as a string and bool internally. It just means that's how you talk to it, nothing more.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Right, but that underlying code has always been copyrightable as far as I know. That's why I'm asking if this is about *code* or *signatures*, and it looks like this is actually about signatures, which is unsettling.
"Method signatures are a part of an API."
A part of, yes. That's why I'm asking. So, really, this isn't about, for example, the ABC PDF API (ie, the downloaded DLL) being a copyrightable thing. Of course it's a copyrightable thing.
This is, apparently, about a list of method signatures being copyrightable.
Which is absolute nutballs crazy. Lists shouldn't be able to be copyrighted. The mind can't even comprehend such a stupid concept. I hope SCOTUS buries this entire idea, but I won't hold my breath.
[ link to this | view in chronology ]
Re: Re: Re:
So, the upshot of all this is if you want to use C, you'll need to buy a SysVr4 licenced Unix box to get an AT&T compliant C compiler. Borland and Microsoft C cannot exist, Mix Power C is right out, and don't even think of creating gcc. I guess we may as well close up shop on ISO Standards too.
Asinine. Way to promote the useful arts and all that, Supremes.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Neither are exclusive to C/C++.
[ link to this | view in chronology ]
Re: Re: Re:
This is not true. The implementation would be different, the API itself would not. This is the crux of abstraction; providing a standard method of interaction, regardless of the underlying concrete implementation.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
int Math.Max(int,int) would indicate that a method named "Max" expects two integer values to get passed in and one integer to come out as the result.
[ link to this | view in chronology ]
Re: method signatures
That is indeed what Oracle is suing Google over. Though, technically, they are claiming that the collection of method signatures is copyrightable.
They already sued Google over the implementation of those methods, but Google did a (mostly) clean-room implementation. Google was found to have infringed something like a dozen lines or so, and they settled for zero dollars in damages.
Here is the relevant part of the district court's ruling:
This is the part that was overturned by the appeals court, and is the subject of the Supreme Court case.
[ link to this | view in chronology ]
Re: Re: method signatures
[ link to this | view in chronology ]
HAHA i hope they copyright it
HEY SUPREME RETARD COURT BE ALL YOU CAN BE !!!!
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
You don'tlet a child die because the parents refuse to give it medicine just so you can say, "see? You should have given the child medicine."
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Actually
API's are like recipes for how to get things done by calling API functions on computers. Recipes are printed in a cookbook and people who want to use the recipe can cook the dish that is described. Companies that publish cookbooks NEVER EVER sue people for cooking the dishes that are listed in the cookbook. I mean what would the point be? The cookbook would be useless. Just like APIs would be useless if using them was a punishable copyright offense.
Therefore, I think what the supreme court should do is declare that yes, API's are copyrightable, BUT using API's is an exercise in FAIR USE and cannot be punished.
[ link to this | view in chronology ]
Is it bad that I recognised only two names from the above list (Ed Felten and Bruce Schneier)?
[ link to this | view in chronology ]
Re:
It's bad that the two names didn't include Brian Kernighan (creator of AWK, co-author of "The C Programming Language" with C creator Dennis Ritchie) or Bjarne Stroustrup (creator of the C++ language).
If you've studied CS, you'll probably know Hal Ableson (co-author of the SICP book on Scheme), Peter Deutsch (who I assume is L Peter Deutsch, Smalltalk and Lisp implementation author, Ghostscript creator), or Mitch Kapor (Lotus founder, original member of the EFF, chair of Mozilla).
The others I had to look up, but they're all really heavy-duty programmers and technology experts. You'd be hard pressed to find a group more knowledgeable about programming anywhere.
[ link to this | view in chronology ]
Re: Re:
Just sayin'. Might want to get your eyes checked.
[ link to this | view in chronology ]
Re: Re: Re:
Speaking of getting eyes checked, I'm not seeing the Google v Oracle cert petition over at SCOTUSblog: “Petitions We're Watching” ? What's up with that? Anyone know?
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re:
Yes. Very bad.
It's even worse that Masnick didn't think some of these other guys "stood out". Looking over the bios at the end of the brief...
—AWK.
—The Mythical Man-Month. And it happens to be Fred P. Brooks. Why do I know his middle initial off the top of my head?
—well, Masnkick mentioned him up above, didn't he?
—the co-author of one of my textbooks.
—yeah, I know he founded Lotus.
—the “K” in “K & R”. Yeah, and I already mentioned Aho up above for the “A” in AWK. Guess where that “K” in AWK comes from, too.
[ link to this | view in chronology ]
Re:
—see Hennessy.
—doesn't really belong with all these famous superstar big-shots.
—yeah, I've talked to him.
—Schneier on Security. Also Applied Cryptography, Second Edition. And Blowfish, etc., and more recently, Skein.
—never mind about that.
—what can I say about Ken?
—Cygnus, acquired by RedHat.
Samba, and rsync.
—also not a big-shot superstar.
—I've talked to him, too.
Hi, Dan!
[ link to this | view in chronology ]
Re: Re:
Yeah. Python? WTF is that shit? This guy's trying to claim for inventing snakes? WTF?
Oh yeah, /s, by the way in case it wasn't obvious.
[ link to this | view in chronology ]
Re: Re: Re:
Well, it's not we're talking about Larry Wall, is it?
Btw, did I miss Larry while I was saying “Hi” to Professor Wallach?
[ link to this | view in chronology ]
Re: Re: Re:
Watch it bud! I could replace you with a perl one-liner.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Anyone know what the deadline for amici briefs is?
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
It also depends on how social you are. A lot of programmers are fairly introverted. And I sometimes describe myself as “entirely anti-social”.
There were a lot of names I didn't see on that list. Maybe I just skimmed over them.
[ link to this | view in chronology ]
Is it bad? I don't know, but
[ link to this | view in chronology ]
Applicability of Baker vs Selden
A blank form can be thought of as a standardized method of communication(transfer of data). Two companies could use the same blank form, but have entirely different business processes to handle that form once it has been submitted.
An API is nothing more than a standardized process for communication with a series of guaranteed responses. To illustrate:
At a conceptual level, instruction sets are essentially the same thing, and protocols differ only in that the guarantees apply to the process as well as the responses. What this means is that if the SCOTUS rules in favor of Oracle, then it is a matter of time before the ruling is applied to protocols and instruction sets, and we either end up with a tangled web of rules and exceptions for dealing with software, or the world of technology comes to a grinding halt while license agreements are made, lawsuits are settled, etc.
In the world of software development, we call this dependency hell.
[ link to this | view in chronology ]
I find it interesting that so many computer scientists recognize how patents and copyrights slow innovation down to a crawl.
[ link to this | view in chronology ]