[zucker42]

I think the phone book analogy still falls short; two phone books can be organized different and have different adverts, styles, etc., but still fulfill the same function (allowing a reader to look up the phone number associated with a person or business). On the other hand, two APIs with different SSO do not fulfill the same purpose, since programs must be written to use one API or another.

It's much more similar to recipes. Recipes, like programs, are functional; they exist to produce useful output. Two different recipes calling for different ingredients/proportions can be used to bake similar cakes. However, the two cakes are fundamentally different, and copying the ingredients/proportions/steps of a recipe might be the only way to produce a cake quite as tasty as the one from the recipe.

Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted.

I think if we take the phone book analogy to it's logic conclusion, it must be okay for Google to use the API only if they change it to make it sufficiently non-interoperable, which seems highly unintuitive.

[jhanschoo]

> On the other hand, two APIs with different SSO do not fulfill the same purpose, since programs must be written to use one API or another.

According to the 9th Circuit opinion, for the purpose of whether an API is copyrightable, interoperability (with client programs) does not factor in. Interoperability comes into play on a case-by-case basis when considering whether or not the use of a copyrighted work is fair use.

So, to use the telephone book example, if machines have been built to interoperate with the old telephone book layout and cannot accept the new telephone book layout, the competitor may have a fair use case, but the competitor cannot argue that the layout of the original could not be copyrighted; at the time of designing the layout, there were many avenues to lay out the pages, but the holder chose a particular layout.

Intuitively, this differs from trademark law where use in a generic manner dilutes the trademark. With copyright, there was copyrightable creative expression in the API's SSO when it was designed, and because others have come to rely on the SSO aspects doesn't mean that the copyright of the API's SSO has become diluted.

> Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted.

At the time when the API is created, there is creative expression as to what the API should look like.

[zucker42]

> At the time when the API is created, there is creative expression as to what the API should look like.

At the time a recipe is created there is creative expression as to what ingredients will be in the recipe. Creativity/originality is a necessary but insufficient condition for copyright.

> According to the 9th Circuit opinion, for the purpose of whether an API is copyrightable, interoperability (with client programs) does not factor in.

I disagree with the 9th circuit here. To be clear, my argument is not that because copying is necessary for interoperability, APIs are not copyrightable. Rather, the argument is that because only one API (including SSO) fits any given purpose and because it is not functional in itself, the API is closer to an "idea", a "system", or a "method of operation" rather than a "literary work" under the Copyright Act section 102. A data structure with enqueue, dequeue, and size operations is an idea, not a concrete expression of that idea.

Plus I believe if the Supreme Court upsets 50 years of practice in the industry, they are essentially legislating.

[jhanschoo]

My bad, it's not the 9th. It's the Federal Circuit.

> At the time a recipe is created there is creative expression as to what ingredients will be in the recipe. Creativity/originality is a necessary but insufficient condition for copyright.

To use the recipe analogy, just as the functionality the API necessarily must provide are uncopyrightable, so a list of ingredients is uncopyrightable.

But once someone organizes their ingredients list; e.g. according to the first time they must be used in the recipe, that organization is copyrightable just as the hierachical organization (SSO) of Java's standard library is copyrightable.

> Rather, the argument is that because only one API (including SSO) fits any given purpose and because it is not functional in itself, the API is closer to an "idea", a "system", or a "method of operation" rather than a "literary work" under the Copyright Act section 102.

The Fed Cir. cites case law suggesting that the 9th, 10th, and 3rd, among others, found that just because something is a "method of operation" does not mean that they are uncopyrightable.

> A data structure with enqueue, dequeue, and size operations is an idea, not a concrete expression of that idea.

For a data structure with enqueue, dequeue, and size, there aren't really enough creative choices choices that can be made. The Java API is different; e.g. as the CAFC points out, their API for dates and timezones are organized very differently from iOS's, and there is sufficient creative choice there.

> Plus I believe if the Supreme Court upsets 50 years of practice in the industry, they are essentially legislating.

With regard to the effect on the software industry, it may be less than you think. For general cases a competitor may be able to provide a competitor2us.sh to convert uses of a competitor API to a functionally equivalent API.

====

For reference these are the Fed Cir opinions

deciding copyrightability: https://scholar.google.com/scholar_case?case=151970920513696...

deciding fair use: https://scholar.google.com/scholar_case?case=107451649356761...