Sophos Cloud Optix
The monster court case between Oracle and Google over copyright in the Application Programming Interface (API) of Java has concluded.
Oracle sued Google, accusing the search giant’s Android platform of infringing the Java-related copyrights and patents that Oracle acquired when it bought Sun in late 2010.
Oracle lost; case closed.
The conclusions of the court, in a lawsuit described in the judgment as “the first of the so-called ‘smartphone war’ cases tried [in front of] a jury”, seem clear enough. As clear, at least, as judicial prose can be to a lay reader.
Briefly put, 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 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.
The judgment takes the latter viewpoint:
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.
Independent developers will no doubt welcome this judgment.
After all, 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.
The proliferation and commercialisation of vulnerabilities and exploits over the past few years – sometimes in code which has been around for ages – gives weight to the argument that no widespread software system should ever be left unmaintained and unimproved.
–
PS. Remember I said “case closed” above? For now, at any rate, the battle is over. According to The Verge, however, war remains declared:
* Google. “The court’s decision…[represents] a good day for collaboration and innovation.”
* Oracle. “This ruling, if permitted to stand, would undermine the protection for innovation and invention.”
So an appeal seems likely. Wouldn’t it be nice, though, if even a fraction of those lawyerly costs were spent on security and privacy instead?
Good. Not only is the prospect of copyrighting an API terrifying, but now I can go for an Oracle certification with a little less guilt.
Google developed the Android "platform" roughly 3 years before Oracle acquired Java from Sun.If Sun felt that Google had infringed the Java copyright why didn't Sun bother to sue Google?Is Oracle now trying to claim "ownership" of everything related to Java?It seems to me as if this is another "Google didn't do anything that can be prosecuted" deal like in their Street View case.
Your question is probably: Who is Eric Schmidt?
It appears that the delight of Sun with Android development at the time led to an opportunistic grab by Oracle for something that was already out of the bag (or the lamp). Given the stakes it is not surprising that Oracle tried to pursue this. I too am glad, for the sake of all our pocketbooks, that Google won and hope that this win cannot be broken in the future.
I recognise that Sun must have licensed everyone to use its interface definitions, at least for the purpose of obtaining services from its software through them, but I can't see how your interface is not a specific expression of your design, and therefore as equally open to copyrighting as the active code.
If I created a box that looks exactly like an iPad, but the circuitry and software inside it that make it do all the iPady things owe nothing to the contents of Apple's unit, would this be OK? Surely, it's only the interface I'd have copied.
My analogy has overlooked the judgement's point, "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." However, I doubt very much of the Java API falls within this.
As a trivial example, the ordering of parameters is normally a free choice when you define a function interface (but not, alas, when you call it!). More compellingly, when I think back to the Windows API (which I used to know quite well), with its many complex data structures, I believe the chances, of two independent people expressing the idea, for most of its services, in identical ways, are vanishingly small.
You are missing just one thing:
There is only one way to express the Java API, and it’s the Java API.
Let's take a t-shirt as an example – the interface it offers is two holes for arms, a hole for a head, and a hole for an abdomen. Is a t-shirt the same as a jumper? A jacket? The manufacturing processes for each are completely different however they all offer the same interface to the user. They all offer the same functionality too – a warm, clad upper-body.
The process by which a product is made should be copyrightable; the resultant interface and functionality of that product should not. This is just my opinion though.