Contemporary judges, including on the Supreme Court, aren't interested in reconciling Oracle's argument with Baker v. Selden; there's no love for Baker. Courts may pay lip service to the notion that ideas can't be copyrighted, but the prospect of ruling as a matter of law that specific, concrete categories of works are categorically not copyrightable (especially if they're not patentable) seems illogical to them. Previous hard exclusions, like those related to automobile designs, textiles, and databases are already on the way out, unfortunately, just like the idea that entry into the public domain is a one-way street. The case law has been slowly moving in this direction for at least 20 years, but it's too painful for many to admit despite judges (e.g. Ginsburg) being crystal clear about the direction they want to take things.
Judge Alsup's original opinion declaring APIs not copyrightable is brilliant and the best argument anyone could possibly make. It is the best argument, period, IMO. But the basic premise is just anathema to the majority perspective on courts' role regarding the application of copyright law.
* Star Athletica LLC v. Varsity Brands Inc., 137 S. Ct. 1002 (2017)
* DC Comics v. Towle, 802 F.3d 1012 (9th Cir. 2015)
* Golan v. Holder, 565 U.S. 302 (2012)
One of the most important cases for contemporary copyright law was Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991). It was a nominal a win for the defendant, but in fact the opinion set a very low bar and effectively condemned the types of bright-line subject matter exclusions that a robust merger doctrine demands, such as in Baker v. Selden.
IIRC, Alex Kozinski wrote some opinions that best reflect the majority perspective today, but I can't find any good citations right now. His arguments are persuasive, but sort of miss the point. Baker v. Selder and the merger doctrine are classic common law solutions to statutory rights that breed complex litigation and inhibit competition. They're not supposed to be intellectually pure or rigorous defenses of legislative powers. Quite the opposite. But courts are far more conservative today and not inclined to exercise their judicial powers this way, with the notable exception of the First Amendment. In fact, certain First Amendment defenses to infringement are slowly becoming more viable, where once upon a time they were dismissed out of hand.
Star Athletica LLC surprised me in particular. Stripes and chevrons!
> 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 output can 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.
This mixes up the functional aspects of designing methods with the stylistic aspects of API design. Consider something like a 3D Graphics API. Some decisions are functional--for example, minimize call overhead or maximizing batching opportunities. That should not be copyrightable. But a lot of other decisions are stylistic. They make the API more elegant, or orthogonal, or intuitive, but are not functional in and of themselves. For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright.
> The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.
This is ipse dixit. How you view the "idea" depends on your generality. Direct3D and OpenGL have different ways of expressing the concept of creating a Z-Buffer. "Creating a Z-Buffer" is the "idea." There are myriad method specifications that can express that idea.
> To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function.
This is glossing over a major logical leap. It assumes you already have a method with a given signature, and writing the declaration is a mechanical process of specifying what signature corresponds to the method implementation. But what if you design the API by writing the declarations first, and filling in the methods afterwards? (Which is very often how its done!) You can write a method to do a particular thing but give it many different specific signatures.
Yes, it does mix them up. That's exactly what the merger doctrine is intended to do: the expressive character "merges" with the functional character.
From an abstract standpoint it seems that it gives short shrift to the purpose of copyright. But it's necessary if you want to maintain an effective distinction between ideas (including systems and processes) and creative expressions in determining copyrightable subject matter. In practice, if you look hard enough there's almost always some amount of creative originality in any piece of work, no matter how utilitarian it is; originality that by necessity must be copied. (Though Google didn't do itself any favors by stipulating to literally copy+pasting the Java API.) The whole point of the merger doctrine (at least an assertive application of it) is to prevent a court from looking too closely at certain classes of works which, through custom and experience, should be considered as having a principally functional character.
And that's why Google was bound to lose on this particular argument, because the experience and wisdom that begat the merger doctrine--that without a robust merger doctrine the distinction between idea and expression cannot be sustained in practice--has been forgotten. As time marches on earlier precedent has receded into the darkness and Feist becomes the first word on the matter; and all Feist really cares about is creative originality. The entire software industry, AFAICT, universally supports the notion that APIs, per se, shouldn't be copyrightable. (Contrast with software patents, where a substantial fraction do disagree.) But show me an actual implementation or API specification where you could with any degree of confidence [in litigation] separate the expressive from the functional character in a way that preserves the principle and allows you to reimplement the API with minimal risk. Ultimately it's really only viable if you have a special rule for APIs.
Of course, we still have Fair Use, similarity, and other defenses. But those are far more subjective, involve a substantial amount of litigation, and are generally high risk defenses. Without a bright line rule then as a practical matter people should and will be risk averse. Even if a court might judge a particular work functional, it'll never get the chance to say so.
The whole expression-idea dichotomy is a complete fiction. It's certainly not a law of nature. The idea of copyright is rather artificial as well. So it shouldn't be surprising that we will often face such dilemmas and inconsistencies where theory and practice meet. The purpose of the merger doctrine is to give "idea" its due when otherwise "expression" would almost always win out, despite what would be optimal for the promotion of new works. Theoretically the legislature could carve out exceptions, but legislatures suck at that sort of thing, despite what they often teach in law school. More often its the courts, who wrestle first-hand with the ugly technical details and the real-life interests at stake of applying (over years, decades, and even centuries) the abstract concepts, who are best positioned to carve out exclusions or to subtly put their thumbs on the scales to further the ultimate purpose of the law. But, again, this role of the courts is frowned upon today, at least in an area such as this.
I think the disagreement here is as a frequent API author I don't see any stylistic aspect in the design of API code. API code as an artifact itself is purely functional. This distinction becomes important because of the case precedent at hand.
Prior to creating any API, one must have a specification of the system the API is meant to model and control. If one skips writing the specification, that doesn't mean there isn't one, it's just largely in the brain of the implementer and possibly underspecified or inconsistent in spots. Every unit of API code therefore has an implied specification, whether or not a documented, written specification exists.
The API code is simply a mechanical translation of the specification into machine readable form. Parameter names, method names, those do not matter to the technical function of the system they are there solely to enhance use. The specification is possibly a patentable invention. A book describing the specification to a human audience is possibly a copyrightable work.
API code is neither of those things, rather it is an embodied practice of interacting with that specification in a machine-readable form and therefore IMO [IANAL] not eligible for copyright under Baker.
> For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright.
These structures are not inherent to the function of the API code, except incidentally due to implementation details. The purpose of these structures is to model the system being interacted with.
I think part of the misunderstanding here is the contemporary expectation that all code is self-documenting. Which is an admirable goal, but it obscures some important nuances about what an API as opposed to an API contract actually is.
API code, particularly old or highly specialized API code, has a TON of undocumented behavior, quirks, etc that exist. Where do they exist? Besides in the heads (optimistically) of the implementers, it also exists in the specification the API code together with its implementation translate.
> But what if you design the API by writing the declarations first, and filling in the methods afterwards?
Presumably it's the human and not the computer writing the API code so the human has some notion of what the API code is representing. The act of writing this code is translation. Just because the original is not always captured does not mean that it doesn't exist. It must exist for there to be API code in the first place.
