Having now read select parts of the judgement, this judgement is less broad than the title states. It also relies heavily on US-specific case-law. Firslty however, the judgement explicitly is directed at this one case and this one use of this specific API. A diffrent API, or a diffrent use of the API could dodge the exceptions listed and be copyrightable (although it looks like a very narrow out).There are a few short passages that summarize most of the relevant facts:
"Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new outputcan be creative, even inventive, including the choices of inputs needed and outputs returned.The same is true for classes. But such inventions — at the concept and functionality level —are protectable only under the Patent Act."
Thus, it is not contended that it is a creative act to create a (non-trivial) API.
However, this is tempered by a number of other restrictions in US law and case-law, namely:
"Under the merger doctrine, when there is only one (or only a few) ways to express something, then no one can claim ownership of such expression by copyright"
"Under the names doctrine, names and short phrases are not copyrightable."
"Under Section 102(b), copyright protection never extends to any idea, procedure, process, system, method of operation or concept regardless of its form. Functional elements essential for interoperability are not copyrightable."
"Under Feist, we should not yield to the temptation to find copyrightability merely to reward an investment made in a body of intellectual property."
The API as used is considered functional and thus part of the idea, not the implementation. This means it is potentially patentable, but not copyrightable. The judgement also notes that copyright does not give exclusivity to
all implementations of a specification, only to the one implementation attached to the copyright. The individual elements of the specification are then determined uncopyrightable as they are facts, short names, or the optimal representation of an idea (not and implementation). There is a note that a very badly designed API could be more easily covered by copyright, essentially stating that there is creativity in ineffciency, wheras as you approach the optimal API given your constraints, you essentially approach math.
The last factoid quoted is interesting however, noting that just because something is hard-to-do (-right) does not make it copyrightable.
The judgement also states that the API could be considered a taxanomy which normally could be protected, but since it is
also a command structure, allowing copyright to cover it would extend copyright to cover and idea, which is the exclusive territory of patents.
The distinction between what is covered by patent vs. copyright is vital, since patents in this juristiction last for 20 years, whereas copyright lasts for 95 years.