[eqvinox]

> From a purely technical point of view,

The technical point of view needs to be combined with the legal one here, and —

> At the same time, Oracle’s characterization of their API as “original software” is not entirely off base, as anyone who has spent time and energy creating and API would know. The amount of design and work required to create an elegant and useful API is huge, and while it would irreparably harm software as a field to call it copyrightable, calling it anything other than an “original” work is a weak position.

just because something takes a lot of work, that doesn't automatically mean it is copyrightable.

An API doesn't implement anything, it describes a function. Even if it describes a lot of functions and they mesh together really well, there's a distinction between "what" a program does and "how" a program does something.

To compare with literature copyright, there are a ton of romance novels out there — pretty sure you can find a lot of common patterns on "what" story they tell. However, only the "how" is copyrighted, you can't prevent anyone from writing a story with the same outline as an existing one.

(For literature, the problem becomes really tricky since the crossing over from "what" to "how" is kinda fluid; e.g. you can't just swap out character names. Software is actually easier there.)

[wbillingsley]

> An API doesn't implement anything, it describes a function.

Unfortunately, that is also a definition for the whole of programming: describing functions. In Java, the method signature gives only a very incomplete definition, but that is a factor of the programming language itself.

For example, you might wish to imagine a hypothetical language that has a type system so refined that the behaviour of any function is completely described by its type (1). In such a case there would be no difference between its description and its implementation.

(1) We'll leave aside the question of whether this is strictly possible. It would be possible to have more powerful type systems than Java's, and program designs that use such small and clear function definitions, that if you have the type signatures then filling in the code for them is more straightforward than designing the function definitions was in the first place.

[incompatible]

The API description of a single function seems too trivial to be copyrightable. All the functions combined could perhaps be covered by a database copyright, but I believe those aren't recognised in the U.S. Thus phone books or listings of television programs are not copyrightable.

[jhanschoo]

What Oracle has won on is in the Structure, Sequence, and Organization in the API.

The analogy with phone books is if someone else published a competing phone book, with the same positions for adverts and paid listings, and same distinctions between adverts and paid listings. The courts would find that such a phone book infringes as well.

To make the analogy more accurate, many consumers have since come to be used to the layout of the old phone book, and do not want to switch because they have to retrain their habits to use the competitor book. Competitor book argues that the old phone book layout has merged with the idea of a phone book, or that the old layout is essential to the use of a phone book. The circuit court disagrees.

[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...

[incompatible]

But we are talking about the source code representation of the API? Nobody cares about how its ordered or formatted: Google could change those aspects and programs would still link and run.

[marcoseliziario]

Exactly. An implementation of an API is copyrightable. Not the API itself. With a lot of goodwill, with some very generous interpretation, an API could be patentable, but copyrightable seems absurd to me.

[smadurange]

I don't think the comparison with literature makes sense.

API is what defines a software. For instance, if someone copies Microsoft suite full public interface (including the UI which is part of the interface it would be a problem even if the implementation was different).

API signature is the UI equivalent for a library/programming interface software. So, I agree with the original commentors concerns here. Oracle's got a point too.

[eqvinox]

> API signature is the UI equivalent for a library/programming interface software.

It isn't. "A main window with toolbars and an edit area." is the equivalent of the API signature. The layout, icons, ordering, etc. is artistic work of the "how" and copyrightable.

(FWIW by your logic, LibreOffice would be violating Microsoft's copyright already and we could only ever have one office suite in the world.)

[wbillingsley]

No, that's not a reasonable interpretation of his comment. Other OO VMs (e.g. dot NET) exist and do not have the Java API. Google's argument is that the API is required to maintain compatibility with Java programs, not bytecode-based VM programs in general.