The quoted exchange is between Judge Alsup and Oracle's counsel, David Boies, and concerns the issue of what damages Oracle intends to seek in phase 3 of this trial (phase 1: copyright liability; phase 2: patent liability; phase 3: damages). The jury hung on the major copyright claims and the judge has yet to rule on the ultimate question whether the 37 Java API packages at issue are even protectible by copyright. Oracle proved infringement concerning the nine lines of code constituting rangeCheck and the judge held as a matter of law that Google had infringed respecting a couple of test files that were subsequently removed from Android. In this context, under applicable law, Oracle may elect to get statutory damages of $150K for each of the infringements or it may elect to go after what are known as "infringer's profits" - meaning that it would ask the jury to award it damages measured by profits made by Google on account of the infringing acts. Mr. Boies is telling the judge that Oracle wants to go for infringer's profits "as a matter of principle" and the judge is telling him, in effect, that he is astounded that Oracle would be prepared to make a claim for a billion dollars (or some other very large number) based essentially on nine lines of code among the tens of millions of lines of code in Android and a few test files. Mr. Boies strains to offer various rationales for how Oracle might prove damages of this type, mostly tied to the idea that Google gained in time to market for its Android product by relying on the infringing materials. The judge basically tells him that this position is ridiculous and that he cannot believe that an attorney of Mr. Boies's stature would even make it (at one point, he notes that Oracle is trying to make a "federal case" out of this and, catching himself, says (I paraphrase here), "oops, this is a federal case . . . well, seeks to make a bigger federal case out of it than it is"). (The Groklaw report on this exchange is worth reading and even fun in spots - it may be found here: http://www.groklaw.net/article.php?story=20120515120106322#U...)
This exchange highlights the rather unfavorable position that Oracle finds itself in on the copyright issues. It has won nothing of significance and stands to get very little from the jury on these issues. Concerning the broader claims on which the jury hung, it still faces a potent objection from Google that it cannot assert copyright violations based on the 37 API packages owing to defects in how the Java program was registered with the copyright office. It also faces the risk that the judge or a court of appeals will hold that APIs are not copyrightable.
A word on this last item: Much as the developer community believes very strongly that APIs should not be copyrightable, the Ninth Circuit law that is binding on this judge (beginning with Johnson Controls in 1989) is not particularly favorable in that it provides that software programs are to be analyzed item-by-item on the facts of each particular case to determine whether any particular component is protectible expression versus an unprotectible idea, function, system, or method of operation (this is in stark contrast to the First Circuit, which held that judges could make categorical judgments that certain components are functional by nature and hence unprotectible by copyright (as opposed to patent), as the menu structure was held to be many years ago in the Lotus/Borland case. Google is arguing the issue categorically ("APIs are inherently unprotectible under copyright law") but this makes for a tough sell in a jurisdiction where the appellate authority has said that such issues cannot be categorically determined. Google has alternative arguments, the main one tied to a leading Ninth Circuit case (Sega) that Google argues enables copying of functional elements of any program needed to ensure compatability. But, in my view, astute as this judge is, he will be bound to apply the fact-specific approach, making it tough for him to adopt Google's strongest argument and thus significantly reducing the prospects for a definitive ruling from the judge along the lines sought by Google (of course, this might come on appeal, where the court is free to reshape its earlier precedents in light of modern-day realities in the software world).
Excellent analysis, but I have one question. So if you cannot categorically state that APIs should not be copyrightable (how does this relate to previous industry efforts around clean room engineering and cloning, like the IBM PC/firmware clones and x86 processor clones? Why did those escape the courts?) , how does one even go about, on a item-by-item basis, of providing APIs should be copyrightable?
For example, take the Java package java.io used for reading/writing files among other things. How can you construct an argument that the structure of the API itself should be copyrightable? And what would be an example of an API that couldn't be copyrighted for that matter?
Even though I am not averse to IP rights generally, I strongly believe they need to be applied with their proper goals in mind and that it is deeply prejudicial to all concerned when they are misapplied - in that vein, my view is that APIs should not be copyrightable, as this to me is an abuse of the principles of copyright (if a rare API design is so novel as to be worthy of protection, it should be protected by patent).
In the Ninth Circuit, however, the same Johnson Controls case that held that the components of a computer program are to be assessed item-by-item to determine what is protectible and what is not also set forth the (judge-invented) doctrine that the structure, sequence and organization of elements in a computer program can be protected by copyright even if the discrete pieces are not in themselves expressive. Taking this as its point of departure, Oracle argues at length about all of the "expressive choices" that were made in the 166 API packages that are part of Java (and in the 37 API packages specifically at issue in this case), how they are named in special ways, how they are structured to take certain parameters and not others, how some call certain classes and methods not others, etc. Oracle further argues that Google could have achieved the same functionality that it gained from copying the APIs through "other means" such as APIs with different names and the like and that it could have done so without using the identical "sequence, structure, and organization" used in the Java APIs. It analogizes all this to a musical composition that is readily protectible under copyright even though individual notes are not.
I personally think the Oracle argument is a crock but, when you are able to devote huge resources to developing a case, when you can hire the best experts who can attest to the countless forms of "creative expression" of the type alluded to above, when you can pay the best lawyers to spin it out endlessly from every conceivable angle, you get the scary prospect of a court buying into this sort of analysis and mechanically concluding that, yes, all this is protected by copyright because it is "expressive" and not merely functional. This is why I think that the judge, who is bound to follow the Ninth Circuit precedent, will really need to dig deep to make a definitive ruling here that APIs are not protectible by copyright as a matter of law. An appeals court will have more freedom, however, and can focus on the purpose of copyright law and on why it is absurd in light of modern programming realities to give any party the power to monopolize API-style functionality in ways that will paralyze the industry. The judge is a very good judge and he may also land on the right conclusion - it is just harder for him because he is bound by some restrictive precedents.
I'm having difficulty with this. I also agree that APIs should not be copyrightable, because that defeats the purpose of an API. Their value to technology in general goes down if people can claim copyright infringement if someone else implements the same API. And that is, I think, the true test for what should and should not be legal: how will this impact society? I think that being able to copyright an API is a clear harm to society.
My difficulty comes from the fact that designing a good API is hard, and I think that there clearly are creative aspects to it. Doing a good job requires having an intimate knowledge of the component being interfaced with, and how programmers are likely to use it. The mere fact that we have said before "This API sucks" implies that it is not just a mechanical process.
Basically, I want one result because I feel it's better for society. But based on first principles, that's not the conclusion I arrive at.
That's not my point. My understanding of grellas' argument for why APIs are not copyrightable (which, again, I don't want them to be) hinges on "expressive" versus "functional." I am not a lawyer, so I don't understand the legal version of those concepts, but as a layman, APIs seem to me to be expressive; they require creativity and insight to create. If anyone would like to explain why they are not considered "expressive" constructs under the law, I would be glad to hear it.
The "subject matter" for copyright is defined in 17 U.S.C. section 102. Part (a) of the statute defines what can be copyrighted (essentially, original works of authorship) and part (b) defines what cannot. For policy reasons, the (b) part says, in effect, that even if something is an original work of authorship (meaning it is expressive and creative and otherwise eligible for copyright), nonetheless certain things cannot be copyrighted because this would not further the goal of copyright law (to further the progress of science and the arts) and would otherwise potentially harm society.
Section 102(b) reads as follows: "In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."
The idea here is not to give anyone a monopoly via copyright over such fundamental concepts as ideas, etc. Things that are purely functional within systems and the like fall within 102(b) and cannot be copyrighted even if they are otherwise expressive. That is what Google is arguing about the 37 Java API packages in this case.
So did Huffman encoding. So did the Laplace transform. So did quicksort, red-black trees, and hell, even the Universal Turing Machine. These are all the result of many hours of creative endeavor, yet they are none of them copyrightable.
This is the same thing that makes Wolfram's claims of ownership of the existence of a proof of Rule 110 CAs as universal calculators particularly onerous.
I gladly accept grellas's arguments. But your examples are ideas, which would fall under patents, not copyright. Source code does fall under copyright, so we need reasoning to explain why APIs - which are a part of source code - do not.
"It analogizes all this to a musical composition that is readily protectible under copyright even though individual notes are not."
This is a nice analogy. APIs are more expressive than individual notes but hardly raise themselves to the level of a fully formed composition.
Imagine a list of musical phrases. That includes scales and progressions at the simplest level and pleasing variations on those themes but not enough to form a contained composition themselves -- at most a couple of bars.
Each entry could show what scales and progressions they are derived from and even suggest which other entries, in simple combination, are common or otherwise musically sound. Let's further assume that they are given convenient names.
Would that rise to the level of copyright? If someone were to create a distinct variation on that list but slightly different for use with instruments tuned in an unusual way but used all of the same names because ultimately the way all of the phrases relate to one another is the same, would that be fair?
I haven't thought this scenario all of the way through, but it seems useful to take my familiarity with software out of the process...I have to admit, at first blush, I am a bit torn.
Perhaps it's reading too much into things, but doesn't that raise the possibility that this judge, knowing more than the average about computer science, is working hard to carefully justify as definitive ruling as possible arguing against the copyrightability of APIs?
At least, that's my hope. The transcripts indicate that he understands the tech better than most.
This is somewhat off topic, but why does the same lawyer show up so often?
David Boies has argued in Bush v Gore, defended Napster, worked for SCO in SCO v Linux, argued the recent California gay marriage law, was the council for US team in the recent America's cup case, and now he's Oracle's lawyer here (at least I see the last connection).
I can't discern a pattern to those cases other than their high profile nature. Wouldn't it make more sense to hire someone that is an expert in computer IP law for SCO, Oracle, Napster type cases, a constitutional lawyer for the Gay marriage and Gore v Bush type cases, etc. How can one guy be the go-to for so many high profile cases?
Basically, the guy is a genius. Read his Wikipedia bio.
Praise of the man:
"The one talent of David's that stands out is his ability to lay out a course of action that would take into account any sort of complicated facts and develop a far-reaching scenario. It's a chess player's sense: If I do this, the following 15 things are going to happen, and if step 11 goes so, I'll do this rather than that. It's a fantastic game-playing ability." Thomas D. Barr, quoted in the New York Times Sunday Magazine, June 1, 1986
"The Boies memory is one of the first things cited when people discuss his strengths. What's most impressive about that gift -- focused as it may be by the intensified concentration that his dyslexia demands -- is Boies' uncanny ability to recall a key fact, legal citation or piece of contradictory testimony at moments of the most intense pressure." Time Magazine, "Get me Boies!" by Daniel Okrent, December 25, 2000
A trial is a problem in maximizing the reasoning, under law and supported by fact, presented to a judge and / or jury. Those audiences have limited bandwidth to begin with. The "under law" constraint largely drives which reasonings and facts will be most important -- especially as all that must cross a barrier of evidentiary rules and trial procedure. The ability to weave all of that into a coherent narrative is crucial to communicating to the audience.
Boies can grab enough of the subject matter to speak to the key legal issues, and to ask experts the questions that define the boundaries around those questions. Another lawyer might know more of the subject matter, but that won't matter if they can't translate that extra knowledge into legal strategy.
Remember also that while you might be able to find legally pertinent technical responses to Boies' work in court, you're reacting to that after hearing his strategy. Good trial communication requires telling a unified narrative -- if your story doesn't already provide a basis for your response, that response will be weaker and may even distract from the story you do have. Boies' ability to anticipate arguments, mentioned by another comment, is crucial to all this -- it's not enough to have an answer, you really need to have that answer in advance of his question.
It's his "trial" skills. There is a team of lawyers, each lawyer skilled in one particular aspect of the case. Mr. Boies's specialty is pulling all the information collected/discovered by the various attorneys and creating a grand advoacy plan that includes strategy and argument. So an attorney incredibly astute at patent law may not be so good when it comes to verbal argument (specifically, appealing to the sentiments of the jury is an art in itself, and few attorneys are able to master this skill) and overall case strategy, but is able to effectively assist Mr. Boies in preparing for trial.
As a former litigator turned startup founder, I can attest to the difficulty of assembling the right team with the ideal point man for a trial, and when you do find one you respect, he is worth every penny. David Boies is one such man - nobody has gotten fired for hiring him as the lead trial attorney.
Maybe for his litigation skills? I'm sure there's a large legal team behind the scenes that includes IP experts, but "litigation" is its own field - most lawyers never see the inside of a courtroom. There's rhetoric, witness examination, making motions and objections, and so much more than expertise in an area of law.
(IANAL but I helped AOL sue Sanford Wallace, and it was a sight to behold.)
This exchange highlights the rather unfavorable position that Oracle finds itself in on the copyright issues. It has won nothing of significance and stands to get very little from the jury on these issues. Concerning the broader claims on which the jury hung, it still faces a potent objection from Google that it cannot assert copyright violations based on the 37 API packages owing to defects in how the Java program was registered with the copyright office. It also faces the risk that the judge or a court of appeals will hold that APIs are not copyrightable.
A word on this last item: Much as the developer community believes very strongly that APIs should not be copyrightable, the Ninth Circuit law that is binding on this judge (beginning with Johnson Controls in 1989) is not particularly favorable in that it provides that software programs are to be analyzed item-by-item on the facts of each particular case to determine whether any particular component is protectible expression versus an unprotectible idea, function, system, or method of operation (this is in stark contrast to the First Circuit, which held that judges could make categorical judgments that certain components are functional by nature and hence unprotectible by copyright (as opposed to patent), as the menu structure was held to be many years ago in the Lotus/Borland case. Google is arguing the issue categorically ("APIs are inherently unprotectible under copyright law") but this makes for a tough sell in a jurisdiction where the appellate authority has said that such issues cannot be categorically determined. Google has alternative arguments, the main one tied to a leading Ninth Circuit case (Sega) that Google argues enables copying of functional elements of any program needed to ensure compatability. But, in my view, astute as this judge is, he will be bound to apply the fact-specific approach, making it tough for him to adopt Google's strongest argument and thus significantly reducing the prospects for a definitive ruling from the judge along the lines sought by Google (of course, this might come on appeal, where the court is free to reshape its earlier precedents in light of modern-day realities in the software world).