The Oracle v. Google jury is now working on its verdict on Phase One of the trial, copyright liability. It has gone home for today, Tuesday, and will resume its work tomorrow, Wednesday.
The judge instructed the jury that, for the purposes of its deliberations, the structure, sequence and organization of the 37 asserted APIs are copyrightable. Edward Naughton, an experienced intellectual property litigator who isn't involved with this litigation, today published a strongly recommended blog post that explains what the jury will and, especially, will NOT decide. Also, if you're interested in Oracle's closing argument to the jury, the related slides are available here.
In this blog post I'd like to address a misconception that appears to be spreading like wildfire, maybe due to an orchestrated campaign. On the websites of Forbes and Dr. Dobb's Journal, articles spread -- probably for lack of better knowledge -- the false information that the copyright liability decision in Oracle v. Google could bring about major change and spell "the end of programming as we know it". The Forbes blog post cannot be taken seriously in the slightest because it says this here toward the end:
"But the consequences of this landmark case are potentially much broader for the software industry, as a win for Oracle could fundamentally change the legal standing of programming languages from their current status as generally free instruments to create software applications, to an altered status as products themselves that must be licensed by platform developers, hardware manufacturers, app programmers, and all the other participants in the food chain."
Lots of rhetoric, but totally besides the point. If the author of that post had ever looked up the docket, he could have seen more than one document in which Oracle could not have been any clearer when it clarified that the Java programming language itself is not at issue in this dispute. Again, it's formally not at issue. The headline of that Forbes blog post raises the issue of API copyrightability and then the article culminates in a sentence that is as long as it is pointless.
The Dr. Dobb's Journal article could also make a clearer distinction between API specifications (at issue) and programming languages (not at issue). That story is even more of a doomsday prophecy. It goes into more technical detail, but it gets even one of the most basic legal concepts wrong: the distinction between factual issues decided by a jury and legal issues decided by judges. Moreover, this was again written by someone who has almost certainly never read even one of the court documents. Here's one particularly wrong sentence -- it contains at least four (!) fundamental errors:
"The jury could affirm that the APIs are copyrighted but that the syntax of the function signatures are a fair use exception."
These are the clear errors:
No jury can "affirm" any legal rule. Juries cannot make or change the law. They can render verdicts on disputed facts.
The special verdict form on copyright doesn't ask a question of whether or not the APIs are copyrighted. Oracle and Google agreed that this is for the judge to decide. The jury form asks about infringement, a fair use exception, and issues related to Google's equitable defenses.
The jury won't decide on the "syntax of the function signatures". What's at issue? The structure, sequence and organization of the APIs. The syntax of function signatures is only going to be relevant to the extent that it forms part of a larger structure. There won't be a verdict just on function parameters etc.
Finally, if the jury decides in favor of a fair use exception, it will simply answer the related question with Yes as opposed to stating this separately for different aspects of the APIs -- and it won't become a new general rule anyway. Fair use is determined based on four factors, all of which must be considered in a highly case-specific way.
I could dissect other parts of the article in a similar fashion, but I guess one example is enough to show that some of what excites the impressionable and irritable crowds frequenting certain online discussion boards is completely inaccurate.
Still, more and more people now believe that the decision (and by this I include the judge's ultimate ruling on copyrightability) in Oracle v. Google could bring about massive change and spell doom. Not so.
This is a high-profile case, and that's why it will certainly be taken note of by many people who didn't previously pay attention to cases involving somewhat related issues. But if Oracle wins the API-related copyright liability (including copyrightability) part of the case, it will win because statutory copyright law in the United States and, in particular, the case law of the Ninth Circuit (and other circuits) already allow copyright holders to claim protection of the structure, sequence and organization of their works. Yes, already. On October 3, 1989, the Ninth Circuit held the following in Johnson Controls v. Phoenix Control Systems:
"A computer program is made up of several different components, including the source and object code, the structure, sequence and/or organization of the program, the user interface, and the function, or purpose, of the program. Whether a particular component of a program is protected by a copyright depends on whether it qualifies as an 'expression' of an idea, rather than the idea itself."
Look at the above list of "components", and then read the second sentence again: none of those components (one category of which is "structure, sequence and/or organization of the program") is generally unprotectable -- for any one of the components, what matters is the distinction between idea and expression. Para. 12 is even clearer:
"Source and object code, the literal components of a program, are consistently held protected by a copyright on the program. [...] Whether the non-literal components of a program, including the structure, sequence and organization and user interface, are protected depends on whether, on the particular facts of each case, the component in question qualifies as an expression of an idea, or an idea itself."
That paragraph basically says that copyrightability of source code and object code was decided before this case, and always in favor of copyrightability (except if too trivial to deserve protection, which this paragraph doesn't state, but I state it for the sake of clarity). And the copyrightability of non-literal components is an idea/expression question.
On to paragraph 13:
"Here, the district court found that the structure, sequence and organization of the JC-5000S was expression, and thus subject to protection. [...] This issue will no doubt be revisited at trial, but at this stage of the proceedings we cannot say that the district court clearly erred."
This means that the decision that gave rise ot the appeal determined that the structure, sequence and organization of the asserted computer program fell within the scope of copyrightable subject matter, and the appeals court (here, the Ninth Circuit) agreed with the district court as far as the legal theories are concerned -- facts are, of course, always case-specific. In this case, the district court had found that the structure in and of itself involved enough creativity to be an expression rather than merely an idea.
Judge Alsup told Google's counsel that Google had to address the Johnson Controls decision with a view to the Java APIs. I still haven't seen any convincing argument from Google why Johnson Controls wouldn't apply or why the Java APIs should be, under the Johnson Controls logic, anything other than copyrightable.
The kind of case law that Google presents isn't nearly as close to the Java API question as Johnson Controls. For example, in a very recent pleading Google primarily relied on Sega v. Accolade -- a case that was about making a few copies only for the purpose of reverse engineering as opposed to distributing software that gets activated on almost a million devices every day.
If anybody wanted to convince me that APIs are not copyrightable, I would challenge him or her to show me the case law that says this. There isn't any. People will come up with reverse engineering cases, or with Lotus v. Borland, which was about a very simple user (not programming) interface. Google's lack of cases supporting its position of non-copyrightability even led it to point the United States District Court for the Northern District of California to a mere recommendation (!) made by the European Union's Advocate-General to the highest EU court. A recommendation, not a decision -- and last time I checked, California wasn't listed among the 27 EU member states.
It's nothing more than misinformation that APIs are supposedly exempt from copyright protection in the United States. There is no carve-out in statutory law, and there's no case law that would have had this effect. It's all just a myth. A popular myth in some circles -- but still a myth.
Judge Alsup isn't going to make any fundamentally new law here if he finds in Oracle's favor. He doesn't have to be particularly "innovative", and he presumably doesn't want to if he can avoid it.
I want to be clear on this: I absolutely respect the position of everyone who doesn't want APIs to be copyrightable. I'm in favor of strong copyright but I'm against software patents, and I also want others to respect that position -- in fact, my clients include the owners of two of the world's largest software patent portfolios, and we simply agree to disagree on whether those patents should exist. I'm all for pluralism.
But if you believe APIs shouldn't be copyrighted, forget about the Oracle v. Google jury, which won't decide on this (nor will it decide on a general fair use carve-out for APIs). Forget about Google, which doesn't have any principled stance on the concept of intellectual property other than loving its own IP and disregarding that of countless others. Google will always only take care of itself. Software patents are a good example: in July 2011, Google published a very patent-skeptical statement on its blog. That statement, however, was inconsistent with Google's own history. And the following month, August 2011, Google announced its plan to acquire Motorola Mobility in order to "protect Android". In order to get that deal cleared by regulators, Google issued a statement on Motorola's ongoing assertions of standard-essential patents that effectively endorsed Motorola's abuse of FRAND-pledged standard-essential patents and promised more of the same. No principled opponent of software patents can support FRAND abuse. Google opted to fight fire with fire -- or even worse, conventional fire with a nuclear bomb -- because it thought that $12.5 billion would buy it a free pass for patent infringement. With the current API copyrightability discussion, it's the same thing all over again: Google will warn against the implications of something that isn't even new (Johnson Controls was more than 22 years ago), let alone dramatic, but it won't be interested in addressing the underlying issue if its own problem is solved somehow.
I know I repeat myself: it's legitimate to oppose the copyrightability of APIs. But if that's a major concern to you, where were you when Johnson Controls was decided? You probably didn't know that this was going to affirm a framework under which Oracle can now rightfully claim copyright protection for the Java APIs. I don't blame you if you did't know -- after all, there was no Google back then. But now you do know. Now you're equipped with knowledge that sets you apart from the aforementioned impressionable and irritable crowds. You now know that Oracle v. Google isn't a threat to programmers -- except that if Oracle lost, the outcome would discourage future investments in software development. And if you think the world is a better place if no API is ever copyrightable, then the only way you can achieve this is by raising the issue with lawmakers. Go lobby for a carve-out if you want one. Maybe you'll get it. If you do, it will overrule Johnson Controls and everything else. But Judge Alsup's job is to apply the law as it stands, and the jury won't even do that: it just has to render a verdict on a few case-specific issues of fact.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
