Regarding the legal digression: 1. "We've always had the right to re-implement interfaces" is a red herring. At one point one could have as well said "we've al

Regarding the legal digression: 1. "We've always had the right to re-implement interfaces" is a red herring. At one point one could have as well said "we've always had a right to own slaves." Also, re-implementing APIs may be valuable, but there may be even more value in re-inventing APIs instead, many of the reasons for which are mentioned in TFA itself. Case in point, being locked out of Java, Microsoft went ahead and built (by most accounts) a superior programming ecosystem, including a better API. 2. Not a lawyer, but from my limited understanding: Copyright law as currently defined is, IMO, not a good protection mechanism for code, resulting in cases like this. Whatever arguments you could make to exempt APIs from protection applies equally to code. In general copyright cannot protect anything "functional" in nature, but all code is functional! For instance, the exemption from 102(b) highlighted in TFA for "methods of operation" applies equally well to code. What is code if not a method of operation of the hardware it runs on? Copyright only applies to the creative aspect of anything, including written code, and as such APIs can have as much (or more) creative input as any implementation. In fact, often (and hinted at in TFA), if the API, or indeed any spec, is defined well enough, it's implementation becomes straightforward and requires little inherent creativity! Yet that code automatically qualifies for copyright. (Note that copyright will only protect the expression of an idea, not the idea itself. So when discussing copyrighting of APIs, remember that we are not discussing protecting, say, the concept of opening a file, but protecting the specific expression "new File(fileName)" or "File.open(fileName)" or "open(fname, 'r')". While this is a simplistic example, think of how this permeates the rest of the APIs.) 3. The case law for exemptions for interoperability in interfaces (Sega etc,) is, as far as I can tell, for systems to interoperate with each other. APIs on the other hand, are mainly for humans to communicate with each other when building systems that interoperate. Bloch even calls it out multiple times when he harps on the importance of documentation. As such, APIs are primarily a means of expression between humans - from those who provide the interface, to those who use it. So from a copyright perspective, I don't see how binary interoperability between systems, which is purely functional, can compare to textual expression between humans. In my mind, points 2 - 3 mean that Judge Alsup got it wrong and the Federal Circuit got it right. If this is something to be fixed, I'd say the real problem is the use of copyright law to protect code.