5 ms·

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 t

by grellas 14y ago

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#Update_5 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).

cromwellian 14y ago
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?
- grellas 14y ago
  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.

by grellas 14y ago

cromwellian 14y ago

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?

grellas 14y ago
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.