There's nothing ornamental about code (at least in the coding circles I've seen.) If you want to craft a sculpture in your code, print it and hang it on your wall, be my guest...

A copyright originates with an API because it is a work of authorship: someone created it in a mode of expression. There's nothing more complicated about it than that. There's nothing in the law that says functional expressions are excluded as non-copyrightable subject matter. The reason these copyrights on publicly-released APIs are not enforceable is because (for about the third or forth time I said here) there's fair uses and implied licenses.

I don't understand what you are trying to say. An API defines and/or references the objects in a library or other code object; it isn't really factual in the common sense.

You are correct that copyrights don't attach to recipes (the information that makes the dish possible to make), but they do attach to the expression of that information. Recipes are usually short and functional, so there's not much in the expression to protect. If you printed the recipe on a card with a picture or artwork, then that expression would be protected by copyright.

I think you've got a reasonably correct sense of the concepts. We may be arguing over definitions and language...

I don't understand what you're asking; I don't understand what you mean by the term "copyrightable".

I think you misunderstood what I said. I said that one can't make a direct copy of the code that underlies the API, but one can certainly write his own original code that implements the same functionality, and even uses anything copyrighted in the API if that is a fair use (names of functions and objects, as your library wouldn't be compatible/interchangeable unless the same names were used.)

And that's an argument in favor that your use of the API is fair. If you didn't need to use the API as written, then it might not be.

I don't agree with you there. What is a fair use is described here: http://www.copyright.gov/fls/f...

I think Google wins this one: the nature of the copyrighted work here is a specification that has been released to the public, so as to make the underlying libraries or other code usable.

Except that it is well-established that the API was published so the corresponding libraries/code could be used by outside entities writing Java applications. (It was Java, right?) Once the API has been released for public use, it is a standard and fair use to copy the portions that are required for use of that standard. It's also permitted by the license of the copyright implied by the release of the API as a standard.

The earlier films aren't "prior art" in the legal sense. (That term applies to patents, but not copyrights.) That's what I was explaining to readin.

It can be difficult to know what is in the public domain and what isn't (the date of authorship of a work can be unknown, and works can be dedicated to the public or for certain public use). But, if one's work is entirely original (as in doesn't contain any copied material except from sources that are proven to be in the prior art), then one can be safe. If one day you start whistling and come up with a tune that happens to be the same as the latest pop hit, and make yourself an original recording, then you haven't violated anyone's copyright (because you haven't copied anything). Just attaching "(c)" to your work doesn't give you the right to exclude everyone else from coming up with the same thing (but it might make it hard for them to prove their originality in court).

Oh, that old case (1879). Yes, the author (Selden) attempted to argue that copyright protected his method of bookkeeping (like a patent), and failed. Selden still had copyrights in his book, just not the methods described therein. Here's a quote out of that case for proof: "It may be conceded that Baker makes and uses account books arranged on substantially the same system, but the proof fails to show that he has violated the copyright of Selden's book, regarding the latter merely as an explanatory work, or that he has infringed Selden's right in any way, unless the latter became entitled to an exclusive right in the system."

Similarly, the author of an API has copyrights in that expression, too. What is at issue in this case is how far those rights extend.

The case you refer to is Feist v. Rural. Feist had copied the information contained with in the phone book published by Rural to make its own phone book. Rural had put some false entries in its phone book to prove the copying of its published information. Rural didn't invent or try to patent anything: phone books had been around for a long time. The Supreme Court ruled that Rural didn't have any copyrights in the information in published.

You're confusing copyrights with patent rights. They are two entirely different things.

EFF may or may not have made that argument (I'm too lazy to look), but that is not the best one by far. The information in a work of authorship is not protected by copyright, but the work itself still is. You could type up an alphabetical list of planets on your word processor, and that list would carry with it a copyright. Could someone copy the information in your list? Indeed they could. Could they even put your planets in the same arrangement? The answer is, yes, because there isn't any authorship involved in alphabetical listings. Could someone print your list and make a photocopy? Not without your permission: your list (in its entirety) would be a work of authorship, albeit a simple one.

An API is a work of authorship. Some software developer carefully thought out what it should look like; it is not a mere arrangement of facts or information. The reason Google will be permitted to use these APIs is because the use will be a fair use and because the owner of the copyright has impliedly granted a license for others to copy the API by making it a standard in the industry.

An API (or any other creation of a person) could be subject to both patent and copyright protection. APIs are not ordinarily patented because of the problems of (1) subject matter, (2) obviousness and (3) lack of meaningful protection (in that someone else can invent their own API and design around any narrow patent you might get to yours).

A derivative work still carries the benefits of copyright protection for those changes the author makes from the source material. The smallest improvement can be patented if it can be shown to be novel, be non-obvious, be patentable subject matter (which can be difficult for software), and if the inventor or owner of the rights chooses to undergo the expense to obtain the patent. This article doesn't reveal whether patents are involved here: the litigation concerned copyrights.

As the old analogy goes, property is a bundle of rights associated with a piece of land or other thing. Those rights ordinarily include the right to possess, to sell, to lend, to use, to copy outside of a fair use (for copyright law), to make (for patents), etc. When you buy something on the free market, you aren't buying all of the rights. The person/entity that you buy from may not even have all of the rights. If you buy a home, you'll buy it subject to the utility company's rights to its easement to enter and maintain the pipes, wires, etc. that are located in/on your property. When you buy a book from a bookstore, the bookstore doesn't have the copyrights: it has the rights only in the possession and sale of that copy of the book that it purchased from the publisher. It's been that way for centuries in english/american law.

Rights held by a person or entity (to land, works of authorship, or anything else) will either be enforced by the state (through civil courts) or at the point of a sword or a gun. There really isn't a better alternative to what we have (or at least no one has found it.)

Your solution would immediately bankrupt all software companies. I can't say that I like it...

and as far as I was aware, the U.S. Government doesn't bother to punish piracy except for the very worst offenders. (You wouldn't be one of those, would you?)