There's been a lot of talk about the Oracle vs Google court case, and I was reading this when it occurred to me that I have a few reservations about the strength of Google's argument, and perhaps you'd like to hear them.
If you know about the technology you might want to skip ahead a bit, but I have to cover off some background, so we all know what we're talking about.
My thinking first took shape when the Apache Software Foundation (ASF), of which I am a member, was making its initial steps towards developing a Java Virtual Machine(JVM).
At its most simple abstraction the JVM is the thing that runs on your computer, and in its turn it executes the java programs, they are loaded into it. The JVM "hides" the differences between operating systems from the Java programs. For example Mac's and Windows might have different ways for a program to interact with memory, the JVM provides memory management which is the same for all java programs, to make this happen a Windows JVM will be different "inside" than a Mac one.
So Apache were attempting to create an Open Source JVM called Harmony, and it was during early discussions about the "Java Mail API" which I was involved in that I first ran into the issue which is being tested in court right now. (we will ignore the definition of an API at the moment, because we come to that a bit later, it stands for "Application Program Interface" but you don't need to know what that means)
I was PMC Chair of Apache James, a 100% Java email application server, and I had got chatting to the Harmony folks about one thing and another when the subject came up about whether an ASF licenced version of the JavaMail API would have a more natural home amongst the java email fanbois of the James project because it is a framework that allows people to write java programs that handle email more easily.
So I started to think about what this would mean from a code perspective, and began to untangle things in my head, here's where I get to the point, stop skipping!
The thing that we call "JavaMail" is composed of three parts, and this is true for many other Java API's including the ones in the court case, and in fact much of the JVM itself. Those parts are:
i) A specification or definition, this part is the API specification.
b) An internal component which makes one half of the software, This part is the API interface.
2a) An example of the other half that you are free to use, or to replace with an implementation of your own. This part is an implementation of the API, whoever wrote it.
If we use an analogy here, to avoid getting bogged down in abstract descriptions of computer science ideas, we can imagine that an airliner manufacturer would manufacture the floor in such a way as a seat manufacturer could manufacture seats which could be installed after the plane is built, without the plane having to be adapted.
In order for this to happen the specification for the floor connections would be published and made available to seat manufacturers, who would then compete their little hearts out to make the best/cheapest/lightest seats on the market compatible with the floor specification, and sell them directly to the owners of the planes to be installed after the plane is delivered.
The airliner manufacturer will make floors and install them in customers planes.
The specification is a piece of intellectual property, it has taken time to produce and does have some intrinsic value.
The situation in the Oracle v Google case would be analogous to the situation in which a rival airline manufacturer has published an identical copy of the specification of the floor, manufactured compatible floors and is wooing customers and seat manufacturers from the originator of the specification with the promise of compatibility for all the seats and tooling and expertise that they have invested in.
What Oracle are contending, or trying to, or failing to, or *ought to be* saying, is that the specification is not in the public domain, it is their intellectual property and they are within their rights to restrict its use to allow people to implement the replaceable parts (the implementations, the seats), and not the internal part (the interfaces, the floor). In other words, not only is it breach of copyright (as the court has recently determined) but it is also probably not "Fair Use" (which they are still to decide upon) for Google to produce an API of their own to Oracle's specification. If it is, then people are going to very quickly stop publishing API's that allow competitors to benefit from years of research and development.
Of course this is then masked by a big shit-storm of FUD and misdirection by both sides, trying to veer off the subject onto other more easily determined areas of IP law where they believe they have an edge, such as:
The "field of use" restrictions, which are important but not directly relevant to the API arguments.
Patent infringement, of course, which is the modern lawyer's soup-of-the-day for the whole decade and IMHO totally irrelevant here.
And the distracting but easy to comprehend copy'n'paste IP crime where code appears to have been copied from somewhere that it couldn't have been legally.
The last one is the worst FUD of the lot because that is copyright infringement, as is the case where the specification is used in contradiction to the terms of its licence, but its a different crime, a separate incident, qualitatively something else altogether .
From this point of view I don't think Google's position is as solid as they might want it to be, or as solid as the judgements may suggest, but the truth of the matter is that Sun caused this whole debacle by vacillating over the legal status of Java, the API's the JVM, the TCK and a raft of other things that they thought morally *ought* to be open source and free for people to use for any purpose but weren't in law, because they never made it clear enough what was being explicitly permitted and what was being benignly tolerated.
And that is why I have mixed feelings about the merit of Google's case, and some grudging understanding of Oracle's position, and a bad taste in the mouth about Sun's failed attempts to be Machiavellian with the IP laws.
And if you're wondering what happened to James and the JavaMail API, we never did take it on, its a very poorly designed API and would have brought us a lot of work with precious little benefit.
Danny Angus
blog.killerbees.co.uk
Labels
Friday, May 25, 2012
If Google and Oracle made aeroplanes where would your sympathy lie then?
Further Reading
-
Is Verisign a monopoly? Does it matter? - Senator Elizabeth Warren and Rep. Jerry Nadler recently wrote a latter complaining that VeriSign overcharges for for .com domains due to its market power...2 weeks ago
-
[ANNOUNCE] Apache NetBeans 18 Released - The Apache NetBeans team is pleased to announce that Apache NetBeans 18 was released on May 30, 2023. What's in the Apache NetBeans 18 release: https://...1 year ago
-
-
ApacheCon Europe 2019 – Day 1 - Plain Schwarz has added a photo to the pool: [image: ApacheCon Europe 2019 – Day 1] Day one of #ACEU19 kicked-off with a Barcamp and a couple of exciting...5 years ago
-
-
Export to JSON from MySQL All Ready for MongoDB - This post walks through how to export data from MySQL® into JSON format, ready to ingest into MongoDB®. Starting from MySQL 5.7+, there is native support ...6 years ago
-
ApacheCon Seville 2016 – Building a Container Solution on Top of Apache CloudStack- Steve Roles - Building a Container Solution on Top of Apache CloudStack- Steve Roles Cloud native applications running in containerised environments look set to create a...7 years ago
-
Nóirín Plunkett - https://www.flickr.com/photos/robertburrelldonkin/5729816462 smiles and socks retreating in co. wicklow now empty whiskey and secrets bar camping in ox...9 years ago
-
Hello world! - Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!9 years ago
-
Debugging MySQL Slow Queries With Many Joins - This week I encountered an issue that I hadn’t seen in a while. The ORM in a CMS project that I work on automatically joins to many subclass tables, causin...11 years ago
-
You’re invited to help us celebrate an unlikely pairing in open source - We are just days away from reaching a significant milestone for our team and the open source and open standards communities: the first anniversary of Micro...11 years ago
-
Boat For Sale - Boat For Sale: Price: £150 Terms and Conditions Oracle reserve the right to alter the web price of this acticle even after purchase. Price does n...17 years ago
-
-
-
-
I know nothing, I'm not a fortune teller, and you'd be insane to think that I am. This disclaimer was cribbed from an email footer I once received. It is so ridiculous I had to have it for myself.
Statements in this blog that are not purely historical are forward-looking statements including, without limitation, statements regarding my expectations, objectives, anticipations, plans, hopes, beliefs, intentions or strategies regarding the future. Factors that could cause actual results to differ materially from the forward looking statements include risks and uncertainties such as any unforeseen event or any unforeseen system failures, and other risks. It is important to note that actual outcomes could differ materially from those in such forward-looking statements.
Danny Angus Copyright © 2006-2013 (OMG that's seven years of this nonsense)
Comments: