Developer Freedom At Stake As Oracle Clings To Java API Copyrights In Google Fight | TechCrunch

Editor’s note: Sacha Labourey is CEO of CloudBees was formerly CTO at JBoss. Follow him on Twitter @SachaLabourey. Steven G. Harris is senior vice president of products for CloudBees and was formerly SVP of Java Server Development at Oracle. Follow him on Twitter @stevengharris.

You could hear a collective sigh of relief from the software developer world when Judge William Alsup issued his ruling in the Oracle-Google lawsuit. Oracle lost on pretty much every point, but the thing that must have stuck most firmly in Oracle’s throat was this:

So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.

As the friends-of-the-court submissions supporting Oracle show, this ruling has a lot of entrenched corporate heavyweights up in arms, too. It’s not every day you find Oracle in bed with rivals Microsoft and IBM (via the Business Software Alliance), and you can bet that the common denominator is about defending the aging Empire from the startup Foundation. Add a former head of the U.S. Copyright Office. To sweeten the stew, why not sprinkle in support from various industry players in the arts. Former Sun execs Scott McNealy and Brian Sutphin have also piped in.

This lineup of amicus curiae briefs should be alarming to software developers in general and to the future of our industry. Why? Their collective argument is that Judge Alsup’s ruling is bad for business. It may in fact be bad for the old guard’s business that is increasingly threatened by changes driven by open source and cloud-based services. But make no mistake: if Judge Alsup’s ruling is overturned on appeal, it’s not going to be in your interest as a software professional.

You make some bets when you create an API, but they’re not about monetizing the API.

APIs exist for a reason: They act as the communication channel, the lingua franca, the boundary, between the provider of the implementation and users of that implementation — developers. Of course they require an investment to create. Deep expertise — and even taste — is required to create effective APIs. But, companies and individuals make those investments because they want developers to use an implementation that is exposed through the API. That implementation might give people an incentive to buy your hardware, software or services. Who knows, maybe it gives you a more effective way to sell ads.

You make some bets when you create an API, but they’re not about monetizing the API. They’re about monetizing the things the API unlocks access to. You’ll find APIs documented and used in many books, blogs and open-source projects. Adoption is probably the key measure of success of an API. But then if you encourage developers to use your APIs, why can you prevent them from implementing “the other side” of them? When Captain Picard orders a “Tea, Earl Grey, Hot,” at the Oracle replicator, he’s using a kind of API: “Object. [Qualifiers...]”. Google or anyone else should be able to create their own replicator without Oracle insisting they use some other syntax.

Oracle lost in their attempt to protect their position using patents. They lost in their attempt to claim Google copied anything but a few lines of code. If they succeed in claiming you need their permission to use the Java APIs that they pushed as a community standard, software developers and innovation will be the losers. Learning the Java language is relatively simple, but mastering its APIs is a major investment you make as a Java developer. What Android did for Java developers is to allow them to make use of their individual career and professional investment to engage in a mobile marketplace that Sun failed to properly engage in.

What about compatibility and fragmentation? We’re big believers in Java compatibility and the value of branding and compliance testing. We sit on the Java Community Process Executive Committee. There is no doubt that Android is a messy world of compatibility issues compared to Java, and that Google’s compatibility regime has been less than a blazing success. (Java ME is no panacea of compatibility, though, either.) By creating a new non-Java virtual machine (Dalvik) underneath Android’s Java API-based libraries, Google sidestepped the strict specification license restrictions of required compatibility and no subsetting, supersetting or namespace pollution. Not many of us can afford to do that!

Now is the time to decide who should hold the knife by the handle.

Regardless, thanks to Android using Java APIs, Java developers feel right at home with Android, even if it doesn’t come with a coffee cup logo on it. The economic reality for Java developers is that they’ve gained much more in opportunity from Android than they lost in compatibility assurances due to Android’s subsetting the standard Java platform APIs. We are working with others inside the JCP to advance the current rules to be more in sync with the fork-friendly open source and cloud world. We believe that Oracle’s quest for a legal stranglehold on the Java API, which itself has been advanced through the Java Community Process, has nothing to do with compatibility and everything to do with cashing in on Java at the expense of the community.

With the IT industry shifting from packaged software to a cloud-based service model, this debate becomes even more important. As companies increasingly invest in SaaS, PaaS and IaaS solutions, their operations will depend on third-party APIs. Formal standards are only just emerging and adding FUD over the legal standing of API usage in the meantime is going to place a drag on the industry.

Now is the time to decide who should hold the knife by the handle: Will our economy thrive and be more competitive because companies can easily switch from one service provider to the other by leveraging identical APIs? Or will our economy be throttled by allowing vendors to inhibit competition through API lock-in? And should this happen only because a handful of legacy software vendors wanted to protect their franchises for a few more years?

This decision will impact us for decades to come and will apply to a new IT model – the cloud; yet, this decision is being made now amid heavy lobbying by legacy vendors who are struggling to survive in this whirlwind of change. Developers, your long-term livelihood, the richness of technology choices, and the competitiveness of our industry are at stake.