APIs: Copyright-Free and Integration-Ready
I’m sure you know by now about the API ruling by a federal judge in the Oracle vs. Google case. I was reading about it recently, and noticed that, as usual with these things, there are nuances to the judge’s ruling.
For instance, the Mercury News says the judge noted a few key reasons for his finding:
Google’s Android code was written largely independent of and without actually copying Oracle’s proprietary software.
- The structure of the APIs is like an organizing “system” or “method of operation,” and the U.S. copyright law is clear that you cannot copyright that.
But it’s this caveat from the article on the judge’s ruling that really caught my eye:
“This order does not hold that Java API packages are free for all to use without license,” Alsup wrote. “Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.”
So, I agree with ZDNet; it’s a narrow ruling. Before you go copying APIs, keep that in mind. On the other hand, the timing could prove critical, as more businesses and enterprises are finally embracing APIs as a strategic, revenue-driving tool.
On a related note, I was reading a Jaime Ryan’s response to the news. Ryan is the partner solutions architect of Layer 7.
He explains that, surprisingly, the API parts of the Oracle vs. Google dispute lead to a lot of questions from IT folks about APIs — which should tell business leaders that while APIs are a great business strategy, they can also be a bit complicated to understand.
Readers wanted to know if language APIs are different from Web, cloud, mobile or other APIs.
Ryan’s response, like the ruling, was nuanced:
Language APIs certainly appear to be different from Web APIs. They are bound to language syntax and define local functions, which are then compiled or interpreted into bytecode and executed on a low-level platform. Web APIs, on the other hand, are generally language-independent and use basic networking protocols to execute remote services often hosted by an external party.
But when you come down to it, they’re all by definition APIs, and so, serving the same purpose, he added.
And here is where he explains APIs in a way that, to my thinking, shows they should at least be counted as a sort of attachment for your integration toolbox.
“To use a travel metaphor, APIs are not a destination — they are the directions to a destination,” he writes.
Close enough, says I. And anyway, there are plenty of APIs that deal with integration. For instance, Informatica offers an Informatica Cloud API. If you’d like to peruse the integration-specific APIs, check out the tags for “sharing” and “file sharing.”
Written by Loraine Lawson and originally published in www.itbusinessedge.com