Today Oracle "rested" its copyright case, which means that it has called its witnesses and and presented the evidence it wanted to show to the jury at this stage. This doesn't mean that Oracle's active involvement ends, but Google now has, temporarily, a more proactive role.
Judge Alsup indicated to the jury that it might get to decide on the copyright part of the case next week. Not only will the judge have to decide on some substantive questions but he'll also have to make some determinations as to which subissues he decides as a matter of law and which ones will be left to the jury. For example, the judge might decide on copyrightability, and if the asserted APIs were held copyrightable (which would make a lot of sense to me), the jury might then have to decide on Google's "fair use" claims.
If the judge rules on copyrightability, which appears to be his plan, then that will be his most fundamental decision ("fundamental" to the outcome of this particular case) during the liability stage (i.e., phases 1 and 2) of the trial. The next decision of similar importance that he would make himself would probably be the one of whether or not to grant injunctive relief (which presupposes a finding of an infringement of valid intellectual property rights), and that one would be made at a very late stage.
Google's counsel argued today (as some of Google's friends previously did) that holding APIs copyrightable would be a "substantial departure" for the industry. I've been in this industry for more than a quarter century and while I would agree with Google that the decision is important and that many in the industry are interested in one outcome or the other, I believe the "substantial departure" claim grossly overstates the implications of a finding of copyrightability.
Neither have there been any judicial decisions in the United States that held APIs generally non-copyrightable nor does industry practice reflect much reliance on the assumption of non-copyrightability. During the trial it was mentioned that Sun also described APIs in its license terms as material that needed to be licensed -- and since patents don't protect API definitions per se, protection can only come from copyright.
I'm in contact with many companies in the industry -- large, medium-sized and small ones -- and none of my contacts has indicated profound concern about the API copyrightability decision coming up in the Oracle v. Google litigation. More than 1,000 of my professional contacts are connected with me on LinkedIn, and a subset of this group also on Facebook, and while I regularly post updates on smartphone patent lawsuits and links to my blog posts there, no one has told me specifically what would change for their company should Judge Alsup hold those Java APIs copyrightable.
To put this matter into perspective, a copyrightability decision in Oracle's favor wouldn't mean that all APIs are copyrightable in the Northern District of California: no matter how high the profile of this case may be, copyrightability would still have to be analyzed again next time this question comes up. In my view, case-by-case decisions are the pragmatic approach here. Bright-line, razor-like rules would be inconsistent with the law as it stands, and run counter to important innovation policy objectives. If Google believes that it would be better policy to exclude APIs from the scope of copyrightable subject matter, it should lobby lawmakers on Capitol Hill. Congress can pass laws that deprive certain creations of intellectual property protection, while the courts have to be very careful about that. That's also the case with respect to patent-eligible subject matter, as the Bilski decision showed.
There's another reason why it's appropriate to suggest that Google should pursue API non-copyrightability through lobbying rather than litigation: from January through March of this year, Google spent more money on lobbying in Washington D.C. than Apple, Facebook, Amazon and Microsoft combined (as media including The New York Times reported yesterday).
I did a long blog post this weekend to outline my thinking on API copyrightability. Previously, I did a fair amount of research into copyrightability case law in the U.S., and based on where the law stands, there's no way to avoid case-by-case analysis. Whenever I see people argue that certain decisions held APIs to be generally non-copyrightable, a closer look at the fact patterns of those cases and at the legal positions taken in the rulings shows that those cases aren't really applicable to the Java case. At a closer look, those decisions that appear to draw a bright line typically relate to material that one can produce without much creativity, if any, and/or leaves little, if any, choice to its creators. What apparently happened in some of those cases is that the judges looked at the case before them and made parts of their decisions sound much more generic than they actually were. For example, the Lotus v. Borland decision is frequently misread as ruling out the copyrightability of "interfaces" in general -- but there are so many interfaces out there, while that frequently-cited case related to a very basic kind of two-dimensional text-based user interface. In terms of complexity and creativitity, there's a world of difference between that kind of interface and the Java APIs.
There's also a recommendation for a decision -- not an actual ruling -- that recently came down in Europe: the European Advocate-General's position on SAS Institute Inc. v. World Programming Ltd. At the heart of that case is the copyrightability of a rather simple programming language. That one consists of basic words -- most of the names in the Java APIs are longer than the keywords of that language -- and, even more importantly, has a small vocabulary. In paragraph 71, there's an error of the kind I just mentioned: "As we have seen with SAS language, programming language is made up of words and characters known to everyone and lacking any originality." With the greatest respect, the Advocate-General cannot assume that no one would ever come up with a programming language consisting of words that are not "known to everyone and lacking any originality". He's right with respect to most (not even all) existing programming languages, but there's no technical reason for which this has to apply to every existing or future programming language. And I could give many examples of commands that are not "words and characters known to everyone".
In the Oracle case, Google's non-copyrightability argument made reference to the European SAS case. It speaks to the lack of applicable cases in its favor Google can find in the U.S. that it feels forced to cite a mere recommendation (not a final ruling) in a European case (subject to a different legal system) that is, at any rate, about a programming language (not a set of APIs) and based at least in part on misconceptions.
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:
