Alsup is wrong.
Congratulations to Google for completing the trifecta, coming out victorious on all three key court challenges brought against them by Oracle, and thus making Java more free today than it was at any time in the past. But like so many technical decisions made by a non-technical judiciary and jury pool, Judge Alsup’s conclusion on the final bone of contention is wrong. He was wrong to declare that programming API’s cannot be protected by copyright.
An API is more than just a collection of components
Maybe you can't copyright the idea that a programming language needs a String class. Perhaps it's not that creative for an API designer to put a method named rangeCheck into a component named Integer. Maybe it’s not that earth shattering to put a flush method in the FileWriter class. But the Java API is more than just a collection of components with simple methods that, as Judge Alsup commented, "a high school student could do."
I agree with Judge Alsup on the rangeCheck dilemma. Indeed, a competent high school student could competently write the body of the rangeCheck method. I also think a high school class could come up with a decent list of methods that should be part of the Math class. But the Java API isn't just a simple collection of components that exist as little islands in a sea of bytecode.
The Java API is beautiful.
Programmers and developers are often slagged as being a bunch of uncreative nerds, but the best programmers I know are also the most creative people I have ever met. The manner in which classes in the Java API are related through inheritance, associated through interfaces, and intertwined through aggregation is as beautiful to me as any Van Gogh or Rembrandt hanging on the walls of the Getty. There is clearly intellectual property hidden there in the Java API, and since it's an accepted concession of the US judicial system that intellectual property is copyrightable, then copyright laws should protect the Java API as well.
Java developers know the truth
Developers know it. Java developers also tend to want Java to be free, so they're not out there rioting against the court's decision. But Java developers know the truth. Developers know how a solid API justfeels right. Developers can see and feel the symmetry, insight, beauty and creativity that goes into a well-developed API. And every developer worth his salt knows how miserable and painful it is to work with an API that was developed hastily, haphazardly and without forethought regarding the real challenges a programmer will encounter when leveraging it to implementing a solution.
Good APIs vs bad APIs
For example, the Java API is far from perfect. Let's face it, they screwed up the Date class. Every project I've ever been on is on fire with yellow warning lights in the column of every line of code that invokes the deprecated methods of java.util.Date. There's still debate on TheServerSide about what should be done with the Date class, and the lack of forethought into the complexity of designing that API component, over ten years ago, still permeates its way through modern enterprise applications. And more to the point, if every component in the API was delivered with so many inherent shortcomings, the Java API would have been tossed in the recycle bin long before its first official release. The reason the Java API is so universally and enthusiastically loved is because of the intellect and insight that went into designing it, and there should be some legal way to protect that type of effort.
Every developer who takes their first programming class is completely mystified by the utter silliness of all of the abstract classes and seemingly useless interfaces that pepper the Java API. Implementing all of these codeless interfaces always seems academic and laborious to a newcomer. But there's always a point where a developer leaves the college classroom and starts doing some real development where the light goes on and they hit that Eureka moment where they finally appreciate the benefit and beauty of the way the various Java components participate in interface based polymorphism, or inheritance based abstraction.
Maybe only developers know what developers know?
I don't think any lawyer or Judge on a district court would have any appreciation or understanding of what was written in the previous paragraph, but every Java developer does. Beauty, symmetry, form and functionality are only created out of nothing in the Bible. When it happens in the real world, it's a product of intellect and ingenuity, and when that type of ingenuity manifests itself in an API, the minds responsible for it are entitled to some type of protection for their creation.
When looking at the API question, perhaps too much emphasis gets placed on the minutia of the code. Looking at individual classes and methods would be like looking at a door and a support wall and telling Frank Lloyd Wright than none of his architectural drawings were worthy of protection because they're simply a bunch of doors, walls and support beams. It's easy to see the inherent beauty of a architectural drawing of a magnificent building. It's not nearly as easy to see how the same degree of beauty and creativity manifests itself in a magnificent programming API. That's the problem we run into as the judiciary goes from making complicated legal decisions to making complicated technical decisions.
Perhaps software is too complex and ephemeral to protect these days. Perhaps the ability of companies like Oracle to protect their intellectual property is being steamrolled by the open source ethos that is so rampant in the IT community.
Today, Java is more free than it was yesterday, but that's only because Judge Alsup made the wrong call by declaring that the Java API could not be protected by copyright.