> Why Oracle didn't sue Apache?

Simple: because they didn't have the motivation (see point (I)). Their goal wasn't to copyright APIs (that just was one of the many tactics used in court, and the one that just happened to win), but to get their share of Android. Suing Apache wouldn't have helped their goal in the least.

Also, while not relevant to the question, I will note that even if APIs are copyrighted, Harmony has a much stronger fair-use defense than Android: 1. It was done for the purpose of interoperability and 2. it was not intended to make a profit. Each of these is a fair use defense alone, and certainly together, but neither is true for Android (although the first might be partially true).

> Sun didn't sue Google in the 5 years Google used Android

Because they didn't have the resources and the inclination, as the company was already in a downward spiral and such a lawsuit could only have hurt them at the time. Google, however, fully expected them to.

> The ruling talks about API and API's has nothing to do with being a language level API or a "web API".

That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you.

More to the point, the reason copyright may apply to APIs but certainly not to protocols is because copyright law is not only concerned with the intent, abstraction, or use of the work, but also with its form. This why other IP protections (like patents) exist, to cover works whose form does not match those covered by copyright.

In particular, copyright requires a fixed representation (in text, image, recording etc.). So, for example, if I tell you a story, the story isn't copyrighted. But if I write it down -- or even record it -- then the text of the story or the recording is copyrighted. It doesn't matter that the purpose in all three cases was the same: to convey a story (once that fixed form is copyrighted, the protection may extend to non-exact reproductions, but that original fixed-form must exist). While a protocol may be described in a text and that text is copyrighted, the described protocol itself cannot be, because it does not have a fixed representation in text (a completely different text could describe the same protocol). A language API does have a fixed form.

> the appeal court ruled that the fair use question must be decided in the forthcoming case, nothing more. As any other copyright case

Yes, but that was the point. Google made some arguments that they believed would make APIs non-copyrightable. The court ruled that those arguments are fair-use arguments which are not relevant to the question of copyrightability, but may be used as a defense once APIs are copyrighted.

> No, it has to go to court so yes, any player must be concerned

Quite the opposite. It is the copyright holder who has to sue you. Any company would sue you if they believe they have a case, and you would still need to defend yourself in court when they do. The question of API copyrightability had never been decided, so even before the ruling there was a good chance you'd be sued, and you'd still need to defend yourself. Now, it is true that a ruling against API copyrightability would have removed this threat (which had existed even prior to this case), but now your position is not much different than before, only that except making two arguments (as Google did) -- that API are not copyrightable and if they are, you've made fair use of them -- you only have one: fair use.

> That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you.

A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol

> More to the point, the reason copyright may apply to APIs but certainly not to protocols is because copyright law is not only concerned with the intent, abstraction, or use of the work, but also with its form. This why other IP protections (like patents) exist, to cover works whose form does not match those covered by copyright.

But a web API is not a protocol and a communication protocol is not what is used to call Google Maps, beeminder or other web applications.

> Yes, but that was the point. Google made some arguments that they believed would make APIs non-copyrightable. The court ruled that those arguments are fair-use arguments which are not relevant to the question of copyrightability, but may be used as a defense once APIs are copyrighted.

NO, the appeal ruling had nothing to do with Google arguments about fair use. If there is a new trial to rule about the fair use is because in the original trial, the ruling about fair use was stalled by the jury and Judge Alsup stated that API's can't be copyrighted. And the Appeal court didn't wanted to rule about fair use

> Quite the opposite. It is the copyright holder who has to sue you.

Yes, but fair use is not automatically granted, so, you're in danger to be sued by the copyright holder. Microsoft can sue WINE developers or Amazon can sue anyone developing a clone of the AWS API.

> A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol

However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs.

> NO, the appeal ruling had nothing to do with Google arguments about fair use.

The court didn't rule on fair use, but it did address it. They said that now that it has been clarified that interoperability is not relevant to the copyrightability analysis, it may still play a role in connection with fair use. Namely, that Google interoperability argument isn't an argument against copyright, but rather a fair-use defense, which should be argued separately (http://www.fosspatents.com/2014/05/oracle-wins-android-java-...).

> Yes, but fair use is not automatically granted, so, you're in danger to be sued by the copyright holder

That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used if you are sued.

> However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs.

Still waiting an explanation about web API's not being a proper API. They are not protocols

> That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used if you are sued

So anyone is on danger of being sued by a copyright holder of an API.

> Still waiting an explanation about web API's not being a proper API.

It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs. Plain APIs -- like all code -- do have a fixed form. But no fixed form means no copyright.

The very beginning of the definition of US copyright says[1]: "Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device" (emphasis mine). There are other requirements, but without a fixed form no copyright may apply[2].

The bits of text comprising the names of JSON fields, while fixed, are too short (and lack the necessary structure) to be considered "a work" for copyright purposes.

> So anyone is on danger of being sued by a copyright holder of an API.

That has always been the case (because it had never been settled that code APIs are not copyrightable). A different ruling may have removed that particular threat, but it didn't. It certainly didn't add new legal threats.

But let me give you this advice: If you're a big company with deep pockets and you're coming after the income of another big company with deep pockets using something that may be law-related -- expect to be sued. In fact, I don't need to give you this advice because if you're a big company with deep pockets you probably know this, as you're already in the habit of suing and/or being sued all the time.

[1]: https://www.law.cornell.edu/uscode/text/17/102

[2]: The law also says: "In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work", which is the source of Google's argument that copyright doesn't even apply to actual APIs, but that's a whole other discussion, and is far from simple. E.g. a book's table of contents could also be argued to be a procedure or a concept, yet it is certainly copyrighted. Oracle said that an API is like a table of contents. There are good arguments for arguing either way. But again, not having fixed form stops the discussion in its tracks.

> It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs. Plain APIs -- like all code -- do have a fixed form. But no fixed form means no copyright.

You're joking, isn't?

> The bits of text comprising the names of JSON fields, while fixed, are too short (and lack the necessary structure) to be considered "a work" for copyright purposes.

What are you talking about? Do you really know what an API is and how web services are defined? You're confusing argument names with the API definition.

What piece of (substantial) text is replicated when you implement someone else's web API? If there isn't one then there is nothing to copyright.

The question of how web services are defined is not material. The question is whether a "API" = "fixed text" or not. For library APIs, the answer is yes, for web APIs the answer is no.

It is clear that you don't j=know what an API is if you say that a web API like Goole Maps or Beeminder is not a library API.

Or perhaps you're just trolling

For the purpose of this discussion there's no need to argue what an API is because it matters little. Like I said, it is like arguing whether a story is copyrightable or not. It turns out that whether something is a story is not the relevant question, but rather the (first) question is how is that thing (call it a story or foo) recorded in fixed form in tangible media. Java's APIs are recorded in fixed and tangible form; the Google Maps API isn't. Again, what it is may matter when you start asking further questions, but the very first thing in the US copyright code says that in order for something to be eligible for copyright it must be fixed in tangible media.

Just to make clear: I am not arguing that Java's APIs is copyrighted, just that there is good reason to see why -- from the perspective of copyright law -- the Google Maps API isn't, regardless of the status of the Java API. They could be absolutely identical from your perspective, and yet different enough from the law's perspective due to some minor detail that you -- but not the law -- may consider inconsequential.

Yes, it's utterly laughable. The sad thing is this isn't just him. This is actually what Oracle is arguing and the hoops they are jumping through to try and copywrite APIs for what they want but try and get around the very obvious problems.

You also can't label APIs as 'language level' either. It's ridiculous.

> This is actually what Oracle is arguing

Not at all. Oracle is arguing nothing regarding web APIs, and I'm arguing nothing about library APIs. My argument's and Oracle's do not overlap. Oracle is saying that library APIs are copyrightable, and I am saying that even if they are, web APIs cannot be.

> You also can't label APIs as 'language level' either. It's ridiculous.

You don't need to label APIs in any way (and what you find ridiculous has little bearing on the law). The relevant question to this particular discussion is whether what you're trying to copyright is a piece of text or not. A library API -- like all code -- is text. A web API isn't. If there's no fixed text to copyright, all other discussions are moot.

You could also claim that copyrighting code while not copyrighting algorithms is ridiculous because in your mind they are the same. However, as far as copyright is concerned, an algorithm can be described in many different words -- and therefore there is no fixed form to copyright -- while a piece of code is fixed, and therefore could potentially (and, in fact, is) be copyrighted.