.png)
Four years ago, give or take a few days, we wrote an article entitled Google wins, Oracle loses: Java API case closed.
The legal battle had been long, acrimonous and expensive, and many techies breathed a sigh of relief when the court case ended.
Some of the relief was down to the outcome: many programmers, as far as we can tell, felt in their hearts that the court’s decision was the right one.
Of course, at least some of the relief was simply the fact that it was over: no more squabbling in court over function calls in an application programming interface (API).
As we wrote back then, Oracle’s legal points seem to have been along these lines:
- Google didn’t copy Oracle’s code wholesale, but instead came up with its own implementations of the 37 Java API packages.
- Nevertheless, Google replicated the structure, sequence and organization of the overall code for those 37 API packages.
- The structure, sequence and organisation of those 37 API packages was copyrightable and thus Google infringed.
Taking both sides
Trying to see both sides, we offered the following analogy:
Taking Oracle’s side, you might think that the inventor of a programming environment should enjoy protection over the API itself. After all, isn’t the API part of the overall smarts of the system? If you think of it as the entrance lobby of the building that is your codebase, then it’s part of the complete edifice and thus as much private property as the corridors and offices themselves.
Taking Google’s side, though, you might argue the other way around. The API isn’t a strictly-private entrance lobby, but the public-facing doorway into the building: the part which actually opens onto the street. The invention is the codebase represented by the building into which the doorway opens, not the doorway and the street frontage itself.
Our opinion on the 2012 outcome was that independent software developers would surely welcome the judgement:
if you’re a software vendor trying to grow your business, persuading programmers to learn and write code for your API is what it’s all about. The more clients who can connect to your service, the better. But once you’ve grown your business, there’s something unappealing about being able to use the API alone to keep your clients locked in to your implementation.
Having someone rip off your implementation is clearly unacceptable. But being able to coast along with your current codebase whilst locking out competition doesn’t really help anyone.
As long as independent software developers are free to challenge you by “building a better mousetrap” – one which is not a clone or a copy, but which does the same tasks in a better way – then you’ll be under some sort of commercial pressure to continue to improve your own codebase.
If nothing else, this sort of pressure is good for security.
An important recent example of how API-based reimplementations have helped security by increasing choice and encouraging innovation is what happened after the Heartbleed bug in OpenSSL.
OpenBSD produced a plug-and-play replacement library called LibreSSL, Google came out with BoringSSL, and OpenSSL embarked on its own series of improvements, improving choice for everyone.
“For now”
Oracle and Google both seemed to agree with us in 2012 that the Java API court case had innovation at its heart.
Google said that “the court’s decision… [represented] a good day for collaboration and innovation.”
Oracle drew the opposite conclusion, arguing that “this ruling, if permitted to stand, would undermine the protection for innovation and invention.”
Indeed, Oracle was determined to see that the ruling didn’t stand, because there’s one little detail about our 2012 article that we omitted: the words for now at the end of the headline.
The case never did go away, and it’s all been played out again in a San Francisco courtroom over the past few weeks.
Now, the new result is in: the jury in the 2016 version of the court case decided that the reimplementation of those 37 Java APIs was “fair use”.
In short, Google has won again.
For now.
Oracle has already said that it plans “to bring this case back to the Federal Circuit on appeal.”
from Naked Security http://ift.tt/1sf01CK
0 comments:
Post a Comment