Intellectual property rights might not entitle Apple to any 'commission' on app revenues, but in any event nowhere near 30%: court misunderstood Epic's lawyers

For a blog with "patents" in the name it would actually have made a lot of sense to start the discussion of the Epic Games v. Apple ruling with the intellectual property aspects of the case. But I had to combat disinformation of app developers regarding the practical effects of the injunction (should it ever be enforced).

The court ruling is unfair to Epic with respect to what it actually wanted and argued. (Some would argue that it's unfair in other ways, too, but I wish to keep a narrow focus in this post.)

In the decision, Judge Yvonne Gonzalez Rogers accuses Epic of "overreach" and suggests that Epic wanted Apple to receive nothing from app developers, though even her own decision notes that "Epic Games does not venture to argue that Apple is not entitled to be paid for its intellectual property." The passage I just quoted is an understatement. Epic's counsel unequivocally said during closing argument that Apple is entitled to reasonable and non-discriminatory compensation for any intellectual property, but an antitrust case is always about putting an end to illegal practices (without necessarily replacing them with an alternative compensation scheme right away). It was not about a free ride. It was about not letting Apple (ab)use its App Store monopoly, and subsequently one could still talk about IP (but not in that same case).

I have no idea what Epic's appeal will focus on, but I wouldn't be surprised if the appeals court agreed with Epic that a sequential approach is precisely the way antitrust law works: you stop the illegal practice first, and then the defendant can come up with a new practice, which may invite further challenges (but those won't happen, or at least won't have merit, if the new practice is reasonable and non-discriminatory). The appeals court may tell the district judge that the purpose of a unilateral conduct case is not to replace an illegal practice with a legal one.

One question that some people are asking themselves already is whether Apple will seek its App Store commission on payments made outside an iOS app but because of an app linking out to, for example, a website. As I explained in my previous two posts, there's no way that Apple would have to tolerate alternative payment systems. The court made it clear that it's just about generating awareness for offerings on other platforms while Apple remains free to require the exclusive use of its own IAP system, and Apple will benefit from the legal standard, which allows Apple to interpret the injunction (in light of the underlying order) in the way most favorable to its own interests, as long as it's not unreasonable.

In practical terms, it would be possible but a real hassle for Apple to have to collect app commissions from developers that are generated through other payment systems. Apple couldn't possibly audit each and every developer's books. Maybe it could impose some severe penalties for fraud and then just perform audits in suspicious cases plus a few random audits. But we don't really have to think too much about that. Again, the injunction--if and when it actually gets enforced--is not going to be a major problem for Apple. They can reasonably interpret the court ruling as not having to condone any "end run" around its IAP rule, such as a mere web shop where users purchase digital items they consume on iOS.

With some console makers not allowing cross-wallet/cross-purchase (or seeking an additional compensation for cross-play), Apple could take the same position now. That would have political implications, but the Epic v. Apple ruling doesn't prohibit it.

As some people are discussing now, the court says that Apple could collect a commission even on sales through other app stores--though it would then be an IP license fee in the form of a percentage of sales, which is why the term "commission" doesn't fit. I think the court should have defined the term more narrowly. (On a previous occasion I also criticized Apple for broadening its meaning.)

What the court got absolutely right is that the 30% cut is not a market rate for the intellectual property in question. The court even takes note of "Apple’s low apparent investment in App Store-specific intellectual property." The commission is practically imposed and enforced because of Apple's app distribution monopoly. The term "gatekeeper" (which is very popular in EU tech policy and law) doesn't appear in that ruling, but that's what it's all about.

That leads us to an interesting question: what is the commission rate going to be in a future scenario (it's really a question of when--not if--this happens) where new legislation and/or a successful appeal by Epic would do away with the gatekeeper toll and would instead leave Apple with only one tool at its disposal--IP enforcement--to collect money from developers?

What if (actually, when) developers can publish iOS apps without depending on Apple's app review because they can go through alternative app stores (and "sideloading")?

The Epic v. Apple ruling explains the following:

"Apple distributes its basic developer tools for free but charges an annual fee for membership in its developer program to distribute apps and which allows access to, for instance, more advanced APIs (many of which are protected by patents, copyrights, and trademarks) and beta software."

"Apple’s intellectual property as it relates to the iOS ecosystem generally are significant. The record is undisputed that Apple holds approximately 1,237 U.S. patents with 559 patent applications pending. With respect to the App Store itself, Apple holds an additional 165 U.S. patents with 91 more U.S. patent applications pending. Other than these patents, Apple does not identify specifically how the rest of its intellectual property portfolio impacts the technology at issue in this case nor does it specifically justify its 30% commission based on the value of the intellectual property. It only assumes it justifies the rate."

Given this year's Supreme Court decision in Oracle v. Google, I can't see how developers' use of Apple's APIs would not constitute fair use. Google even got away with incorporating APIs into a new product that competed with (and ultimately displaced in the mobile market) the original platform (Java). Developers, however, don't use Apple's APIs to build a new operating system: instead, they build applications, with a strong presumption in each case that it constitutes transformative use.

Patent counts mean little. Epic wasn't going to turn this antitrust dispute over Apple's App Store monopoly into a declaratory judgment case over Apple's iOS and App Store patents.

If Apple had to resort to patent litigation against app developers in order to collect a commission, it would have to overcome developers' non-infringement and invalidity defenses. Developers would likely also raise equitable defenses, but let's not get into that here.

Those patent numbers may seem staggering, but they could melt down very quickly as most of those patents might simply never be infringed by a developer and others might get invalidated once challenged. If any valid patents are actually infringed, the next question is whether developers could work around them. Let's assume, just hypothetically, that there would be one or more valid patents left that are infringed and cannot be worked around. Then we get to the remedies stage.

Seriously, Apple wouldn't get anywhere near 30% (or even 15%) of developers' revenues in the form of damages or ongoing royalties.

The only way Apple could theoretically still get its 30% cut would be if it obtained an injunction. In the U.S., Apple would have to meet the eBay v. MercExchange standard. Developers would argue that Apple actually benefits from the availability of apps and makes money on its devices. That would up the eBay ante for Apple. In some other jurisdictions, particularly Germany, Apple could obtain injunctions more easily, but it probably has fewer patents there.

Even if Apple obtained an injunction, it might then face an antitrust challenge to its rates--with the same arguments Apple makes against standard-essential patent (SEP) holders. Sure, Apple would argue that it never made a FRAND licensing promise with respect to its iOS IP. But in Europe, SEP case law is antitrust-, not contract-based, and Apple made the same arguments there (and it also brought antitrust claims in the U.S. over SEPs, such as against Samsung, though in vain, and against Qualcomm, though the San Diego Apple v. Qualcomm case settled during opening arguments).

To sum it up, Apple needs the gatekeeper's leverage to collect its 30% (or 15% under the Small Business Program) commission from app developers. On an IP basis, at least in the U.S. (where it would likely be denied patent injunctions against developers), Apple would get nothing or a much smaller amount. In light of the risk-opportunity ratio, Apple might not even have an incentive to bring any IP infringement litigation against developers.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Supreme Court deems Google's use of Java APIs in Android fair use, thus no infringement--doesn't reach API copyrightability

Based on how the Google v. Oracle Supreme Court hearing went in October 2020, it appeared to be a given that the Java APIs in question were copyrightable, and the fair use debate was over whether the Federal Circuit had correctly ruled against Google or whether the San Francisco jury would have had to be afforded so much deference that a judgment as a matter of law wasn't warranted. In the former case, the case would have gone back to San Francisco for a remedies determination. In the latter case, the Federal Circuit would likely have remanded for a retrial, as Oracle was disadvantaged by the district court.

Surprisingly, the Supreme Court has just declared Google's copying of thousands of lines of declaring code to be fair use, thereby substantially weakening software copyright protection in the United States as there had not previously been a case involving such a substantial amount of undisputedly original and creative program code that someone else was allowed to incorporate into a competing product and distribute billions of times.

This decision was supported by six of the nine justices. Only Justices Thomas and Alito dissented (and noted that the majority didn't want to address copyrightability because it couldn't have reached its fair use conclusion thereafter). Justice Barrett was appointed after the hearing.

The per curiam focuses only on fair use. Copyrightability didn't have to be addressed as the case has been resolved in Google's favor, more than ten years after it was brought. Last July, I already expressed concern that the court might not say much about copyrightability. At the time, I wrote:

"If the Supreme Court answered the 'fair use' question in Google's favor on the basis of jury deference [it now actually did so on the merits], it might or might not discuss the standard for software copyrightability in detail. Whether the Federal Circuit's copyrightability holding would be affirmed explicitly or (by reaching "fair use") mostly implicitly, the copyrightability of API code would continue to be a reality in the United States."

Given that the justices were pretty much unanimously leaning toward copyrightability in October, it would be quite risky for anyone to consider API declaring code uncopyrightable. However, technically the Federal Circuit's copyrightability decision hasn't been affirmed either.

Contrary to what many others will say, today's decision is bad news for software developers. We do need certain fair use rights, sure. But overreaching fair use encourages infringement. The simplest way to put it is this: if someone created a platform and later turned around on developers, alleging copyright infringement by continuing to use some API code in the apps themselves, that would raise issues--and if developers didn't have an equitable defense anyway, they should at least have fair use rights. In Oracle v. Google, however, the issue was much more narrow: it was about a new platform using another platform's API code to compete--in fact, displace--the older one.

The syllabus says: "In reaching this result, the Court does not overturn or modify its earlier cases involving fair use." That sounds like the ruling is meant to be of only a narrow scope. But it doesn't change anything about this being a major departure from what the fair use standard used to be, especially with respect to software. It definitely stretches the envelope, weakening copyright as a vehicle for protecting software.

Copyright and patents are intellectual property regimes that were created in centuries before the advent of computer programs. Without digressing into details, software patents are among the most controversial categories of patents (second only to so-called "patents on life"). With copyright, there are plenty of issues as well. For example, it is commonly accepted that object code--and not only source code--is protected by copyright. But object code is technical, binary, machine-readable, not human-readable. It's a stretch to apply copyright protection to object code, but in the alternative one would have to come up with a software-specific sui generis IPR. It has been suggested that a sui generis right--somewhere between copyright and patents--is needed, though no such initiative has gained traction to date. I wouldn't rule out that it might happen in the future, but certainly not in the near term.

There are also external factors due to which copyright protection of software as well as software licenses that rely on copyright to mandate reciprocity, which is called copyleft (and also weakened by today's ruling) are less key today than they were, say, 20 or 30 years ago: cloud computing and platforms.

• When software actually gets distributed to end users, it's much easier to identify copyright infringements. And copyleft generally applies only to distribution. As long as software stays on a server, it may commit infringements that are never detected, and most copyleft licenses just don't apply.

• In the platform economy, might all too often makes right. That's why Epic Games is suing Apple (the trial is less than a month away). Apple's airtight control of iOS and of what gets installed on a billion users' devices doesn't depend on whether APIs are copyrightable or whether software is patentable. Some copyright protection is needed because otherwise someone could just steal iOS and build alternative iOS devices--but they don't even need to own the copyright in their APIs as long as the operating system allows only Apple's own App Store to install apps, which in turn are "curated" by Apple and only Apple. It's all about market power, and the only remedy against that one is antitrust--or antitrust-like laws such as the upcoming EU Digital Markets Act--as fair use wouldn't open the App Store.

  There's plenty of people out there now who are celebrating today's Supreme Court decision as promoting innovation, competition, and openness. In reality, the net effect will be the opposite. When Sun created Java, they allowed everyone to make and publish apps for it. Sun adopted a dual-licensing model under which you could either get Java under the GPL free software license or take a commercial license. Sun is history--it was acquired by Oracle. The next company contemplating the development of a comparable platform will look at what happened in Oracle v. Google. Against that background, it may either be discouraged from making the investment in the first place--or it may be encouraged to pursue an Apple-like platform business model ("walled garden") and create network effects through a non-open system with cloud components, an exclusive app store, and so forth. In other words, if you can't own software, you'll try to own (access to) users.

The case appeared dead in 2012 after the district judge held thousands of lines of program code uncopyrightable, and a few years later after a second jury agreed with Google on fair use. The appellate attorney they call the Defibrillator, Orrick Herrington Sutcliffe's Joshua Rosenkranz, twice managed to revive the case. Every time he won an appeal, Google appointed a new lead counsel. Ultimately, Goldstein &amp, Russell's Thomas Goldstein won the case for Google. (By the way, Mr. Rosenkranz is on Apple's team against Epic, so we may soon see him in action in a high-profile software platform case.)

Lawyers are not the reason Oracle lost this. Google's network of allies and supporters, including a number of organizations funded by Google, have for more than a decade been campaigning against Oracle's case. Oracle never managed to convince large parts of various relevant communities (which are mostly just vocal minorities) that what it was trying to achieve here would ultimately be good for developers. Certain justices indicated at the October hearing that they were aware of widespread concern over an Oracle victory being harmful to software development. That was just fear, uncertainty, and doubt (FUD). But it worked.

It may also have helped Google that the Supreme Court has had to overrule the Federal Circuit in a number of patent cases, so the Fed. Cir. may have a certain reputation of being exceedingly right holder-friendly. I've seen Federal Circuit decisions that really went too far. In this case, however, the Federal Circuit was absolutely right about (un)fair use.

[Update 1] I tweeted this remark concerning the term "user interface":

„User interface“ is apparently a term with an ever-expanding scope. Until I saw the passage attached to the tweet below, I used to think the Java APIs weren’t a UI. I know other cases where API and UI overlap, such as SQL queries or when I manually made SYS calls on a Commodore. https://t.co/OgbH27qkd1

— Florian Mueller (@FOSSpatents) April 5, 2021

[/Update 1]

[Update 2] Oracle issued the following statement attributable to Dorian Daley, Oracle's EVP and General Counsel:

"The Google platform just got bigger and market power greater — the barriers to entry higher and the ability to compete lower. They stole Java and spent a decade litigating as only a monopolist can. This behavior is exactly why regulatory authorities around the world and in the United States are examining Google's business practices."

[/Update 2]

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Bench reading: what the Supreme Court justices said about APIs being copyrightable in yesterday's Oracle v. Google hearing

Other than a potential remand of the "fair use" question to the Federal Circuit, Google cannot realistically hope for anything positive to come out of yesterday's Supreme Court hearing in Google v. Oracle America (petitioner v. respondent as opposed to plaintiff v. defendant): the Android maker's non-copyrightability defense has a snow flake's chance in hell.

I wrote yesterday's triumphant post on the basis of having listened to the hearing on C-SPAN Radio (over the web). Now I'd like to go over what the justices said in the copyrightability context based on the transcript (PDF). I'll sort this by judge, in the order in which each judge first addressed this subject (seniority). And I'll then provide my interpretation.

Chief Justice Roberts

"Mr. Goldstein, let's say someone copies the headings in your -- your brief and they copy the organization in your brief, which sections you put first and how you organized them. Is your argument -- would your argument say that that's perfectly fine so long as they write their own text?"

This is consistent with how Oracle to the Federal Circuit years ago, with its Harry Potter analogy, which was just genius. The problem this posed to Google is that they'd either have to argue computer programs are different (which they tried yesterday, to no avail in the copyrightability context) or they'd have to take a very expansive view on what's not copyrightable.

"I understand your merger doctrine -- argument is different, but I -- I don't think that was the question I asked."

Google's counsel was being evasive again, so the Chief Justice said:

"Well, if you're talking about necessary to do so, and, again, you're force -- forcing me back to the merger -- to the merger doctrine, and that's -- that's fine, but the only reason that there's only one way to do it is because Sun and Oracle's product expression was -- was very successful. There were a lot of ways to do it when they did it. And the fact that everybody -- programmers really liked it and that's what everybody used, it seems a bit much to penalize them for that."

I love that part. First, the Chief Justice gave up on eliciting a real answer from Mr. Goldstein on the book analogy, which obviously made Google's argument look every bit as weak as it was. Second, the Chief Justice identified the fundamental flaw in Google's reference to the merger (of fact/function and expression) doctrine: while the doctrine applies to the situation at the time something is created, Google wants the court to time-travel and make Oracle, as Sun's acquirer, a victim of its own success with Java by saying that now the structure of those Java APIs is a method of operation and there is, therefore in Google's view, only one way to express them.

"I don't think it's a patent right. I mean, it's the -- it's their particular expression. And you want to -you say the only way for you to say what you want to say in the --the new material that you provide is to copy -- copy theirs. That's not a -- a patent. That's -- that's copyright."

At this point Mr. Goldstein had already lost (and as I wrote yesterday, he's great but Google has no non-copyrightability case by any stretch of the imagination) on three counts: he was evasive on the book analogy; his merger doctrine argument failed because he wants to retroactively apply it; and his claim that Oracle was trying to use copyrighted works to achieve a patent-like monopoly is nonsensical because it's about expression (about something that was written, not about an abstract functionality).

"[B]efore you get into fair use, you say that was the only way for you to do it. But, you know, cracking the safe may be the only way to get the money that you want, but that doesn't mean you can do it. I mean, if it's the only way, the way for you to get it is to get a license."

As came up several times in this ten-year litigation, the makers of Android were even negotiating a license, but decided to go ahead without one.

"Well, all right. I mean, you're --but what about the -the --the combination to the lock on the safe? Can you copy that just because somebody else has it and that's the only way to get in?"

Mr. Goldstein tried to give the "safe" analogy a spin for his purposes, but the Chief Justice didn't buy it that what Oracle was trying to achieve with its copyright assertion was a broad monopoly over how to do something.

"Mr. Rosenkranz, let's say you want to open a restaurant. You've got a great new chef. He's got great new dishes. And you say: Well, we've got to figure out what the menu should look like. You know, of course, you're going to have, you know, appetizers first, then entrees, and then desserts. Now you shouldn't have to worry about whether that organization is copyrighted.

"And I think Mr. Goldstein is saying that that's what's going on --on here. Every restaurant organizes its menu that way, and you don't want to discourage people from opening it because they're going to have to spend their own time trying to figure out what the menu should look like.

"Why isn't that exactly what Google is saying here?"

The Chief Justice used an analogy here that involves a much simpler and smaller structure than the Java APIs. That's why Oracle's counsel then noted the Java APIs "fill the blanks in 30,000 times over, and each item had its own description that no one else was using."

"Well, you say that they did have a choice; in other words, your work did not leave them with no -- no option. Well, what choice did they have without having to spend billions of dollars, which would be wasteful and impede the development of the high-tech business?"

This is now a policy question, and Oracle's response was that Microsoft and Apple (by coincidence, Mr. Rosenkranz has also been appellate counsel to them on various occasions) actually did just that, and that the idea of copyright law is that you do have to come up with your own creation. That applies to all fields of IP law, in fact: patent holders will also argue that someone should just work around (or take a license if available).

"Mr. Goldstein says the most efficient, the best way to do it, the way to keep programmers doing new things, rather than old things, is to use Java."

This question was so broad and general that it wasn't clear whether it was still about copyrightability or whether the Chief Justice had moved on to fair use, especially with the occurrence of the verb "to use." Oracle responded in both respects.

Justice Thomas

He hardly ever asked questions while Justice Scalia was alive. But since then I've heard him ask very interesting questions. He's a great thinker.

"Mr. Goldstein, you seem to rely quite a bit on Section 102. Why don't we rely on Section 101, which is more specific with respect to computer programs?"

This 101/102 distinction reminds me of the Federal Circuit hearing, where Oracle's counsel Joshua Rosenkranz explained, and the appeals court appeared to agree, that Section 101 is where copyrightability is decided, while Section 102 is more about what scope it then has. Interestingly, Mr. Goldstein didn't disagree. He just tried to thread the needle somehow with the help of the merger doctrine, which the Chief Justice had already shot down.

"So at what --at what point should we determine the merger, whether or not there is merger? When Oracle or Sun develops this program or when you decide to use it?"

Google's merger argument again fails because of their time travel type of proposition. But Mr. Goldstein tried nonetheless (as the alternative would have been to just concede the case away, though that would have been warranted) to defend the retroactive approach, and pointed to Baker v. Selden, a case I discussed in 2013. Justice Thomas then came up with an interesting analogy to Google's idea that someone should become the victim of their own success:

"You know, you could --someone could argue, though, that, look, if a -- a team -- if a team takes your best players, a football team, that the only way that those players could actually perform at a high level is if you give that team your playbook. I don't think anybody would say that is --is right."

Mr. Goldstein then tried to drive the point home that Oracle wanted a captive audience in terms of the programmers using Java or, as he called it, "prisoners" and not a "fan base." But that was again just him being evasive, as Justice Thomas obviously noted:

"Well, actually, my concern was having to turn over the playbook. But let's go to fair use briefly [...]"

So far, Mr. Goldstein still hadn't given a single answer in a strict sense to any of the questions that the Chief Justice and by now the most senior Associate Justice asked.

"Mr. Rosenkranz, in your brief, you seem to be arguing for more than the declaring code. If I'm right there, do we need to decide more than that?"

Oracle of course said it was just about the declaring code, but with declaring and implementing code not being practically distinguishable from a copyrightability point of view, it might have seemed that they were going beyond just declaring code.

Justice Breyer

When it comes to patents, he's relatively defendant-friendly. But patents and copyrights are different fields of IP law.

"Well, I have a question for each side that I'm trying to answer in my own mind. For you, I'd --I'd like to ask this: I write down at the computer, I have a computer in front of me, and I put java.lang.math.max(410), okay? And that calls up a certain program, which you did not copy, the one it calls up, which is setting the switches of a computer.

"Well, the thing I --the words I just spoke also call up a particular program, i.e., a set of computer switches that will get me to the program that does the --you know, that does a particular thing.

"Well, it's a computer program, isn't it? And you can copyright computer programs. And so what's the difference between java.lang, et cetera, which sets switches on the computer, and any other program that sets switches on the computer?"

This is a point I've been making for a long time: in order to deprive API-related code of copyrightability, one would have to generally narrow the scope of copyrightable works in the computer software context. As a programmer I know that the java.lang.math.max function requires two parameters to make sense, but that doesn't change anything about Justice Breyer having asked an excellent question that added value to what the Chief Justice and Justice Thomas had said.

"I bet there aren't -- just one way to do it. Why is there just one way to do it? If you spent enough time and you had the most brilliant computer programmers, don't you think they could devise a system of calling up the Java program, though it might be expensive to do and take a long time, that didn't use the word java.lang.math?"

This is also one of the fundamental truths in this case: Google alleges that something is like a real-world fact. It's like talking about the capital of the United States, and of course its name is Washington, so anybody talking about it has no choice about that name. You might be able to use a nickname, or a metonym. Well, you can say "D.C."--a synonym in most contexts. But the API code at issue here was freely defined.

During Oracle's argument, Justice Breyer said the following about copyrightability:

"All right. Please assume with me the following: Assume that the --what you read, the computer --computer programs which do something, after all, are copyrightable, but then it says methods of operation are not, whether they're computer programs or not.

"The problem for us is, is this more like Baker v. Selden, where they said the accounting is not, it's a method of operation? Or is it more like an ordinary computer program?

"All right. Now what I got out of reading through this very good briefing is, look, Java's people divided the universe of tasks, of which there are billions, in a certain way. All the things that tell the computer to do one of those things, we'll do. But that which tells the computer which to do, that's the declaration.

"Here is what it's like. It's like, as Judge Boudin said, the QWERTY keyboard. You didn't have to have a QWERTY keyboard on typewriters at the beginning, but, my God, if you let somebody have a copyright on that now, they would control all typewriters, which really has nothing to do with copyright.

"Or it's like switchboards on old-fashioned telephone systems. You could have done it in 1,000 ways. But, once you did it, all those operators across the world learned that system, and you don't want to give a copyright holder a monopoly of --hmm -telephone systems.

"Or it's like, to use the Chief Justice's example, a chef who figures out brilliant ways of mixing spices and then putting the spices for this and that in a certain order on a shelf, and then he writes something that tells you which shelf to go to and which shelf to pick out and which spice to pick out for which dish.

"Now all those things are somewhat ordinary programs, but they also are doing something. They're giving you an instruction as to how to call up those programs that reflect Java's organization.

"And at this point in time, it's really tough, just like the QWERTY keyboard, to go backwards, and very bad consequences will flow if you don't see that distinction. Okay?

"Long question, but that's what I got out of their method of operation argument. And I wanted you to say what you want about that."

Oracle's counsel was quick to point out that those analogies were more mechanical than the expressive Java API code. Anyway, the long statement Justice Breyer made suggests he understood the problem of Google making a retroactive-retrospective type of argument.

Justice Alito

"Mr. Goldstein, I -- I'm concerned that, under your argument, all computer code is at risk of losing protection under 102(b). How do you square your position with Congress's express intent to provide protection for computer codes?"

This concern is simply damning for Google. And it's consistent with the issue Justice Breyer raised.

"Well, there have been --a lot of questions already about the merger argument, but how do you respond to Oracle's argument that you're -you are arguing in a circle, that there is only one way to write a declaring code like Oracle did?"

If this case had been put before Justice Alito alone, it would have taken him only a few minutes to dispose of the non-copyrightability defense.

Justice Sotomayor

"Counsel, I --I -I go back to the essence of the question that I think my colleagues are asking, is how do you differentiate between declaring codes and implementing codes? Because you agree --you agree that you couldn't have copied their implementing code because there are multiple ways of doing that.

"But you fight the declaring codes because there are multiple ways of declaring as well. Apple has a different way of declaring the same functions. They spent the billions of dollars necessary. Presumably, you could have.

The fact that Apple built a smartphone operating system without doing this was a very strong one. It's just absurd that Google--trying to keep a totally meritless defense alive--then tried to distinguish iOS from Android because they used a different programming language.

"And yet, you spent so much time in your brief convincing me that implementing and declaring codes go together in this hand. They merge. How do we draw the line?"

We can see here that Justice Sotomayor is not willing to weaken copyright protection for computer programs in general only to suit Google's needs.

"May I --may I stop you right there? That's the nub of the problem, which is, what gives you the right to use their original work? What --how do you define 'method of operation' so that there's a clean line between that and when you have to create new code?

"Like an implementing code."

"My problem with your argument is, what's your definition of 'interoperability'? It seems one-directional. You seem to define it as the extent to which existing third-party applications can run on your platform, but not whether apps developed on your platform can run on systems that use Java SE. So it's one way."

Here I think Justice Sotomayor made a very important point (Google wanting to take, not give) but not in the most suitable context. She had actually, inadvertently, already started to talk about something that has no bearing on copyrightability but only on fair use.

"So could people now copy your --your --you now have developed many different packages and platforms and things like that. Can they copy yours now?"

Mr. Goldstein then replied in a way that would keep all options open for Google to sue anybody later, just trying to distinguish the cases. And judges easily see through that.

During Oracle's part, Justice Sotomayor focused on the potential impact of the decision:

"Counsel, at the -in your beginning statement, you had the sky falling if we ruled in favor of Google. The problem with that argument for me is that it seems that since 1992, and Justice Kagan mentioned the case, the Second Circuit case, a Ninth Circuit case, an Eleventh Circuit case, a First Circuit case, that a basic principle has developed in the case law, up until the Federal Circuit's decision.

"I know there was a Third Circuit decision earlier on in the 1980s. But the other circuits moved away from that. They and the entire computer world have not tried to analogize computer codes to other methods of expression because it's sui generis.

"They've looked at its functions, and they've said the API, the Application Programming Interface, of which the declaring code is a part, is not copyrightable. Implementing codes are.

"And on that understanding, industries have built up around applications that know they can --they can copy only what's necessary to run on the application, but they have to change everything else. That's what Google did here. That's why it took less than 1 percent of the Java code.

"So I guess that's the way the world has run in every other system, whether it's Apple's desktop or Amazon's web services, everybody knows that APIs are not --declaring codes are not copyrightable. Implementing codes are.

"So please explain to me why we should now upend what the industry has viewed as the copyrightable elements and has declared that some are methods of operation and some are expressions. Why should we change that understanding?"

When she refers to Google just taking less than 1% of the Java code, it sounds as if she conflated copyrightability and fair use, and maybe that was her intention, or maybe it just looks like it.

I believe some others who listened to that part have attached way too much important to the impact assessment. The law doesn't work that way. Yes, policy matters, but none of what Justice Sotomayor said in that long passage really shows a path under the law as it stands to arrive at Google's desired result, even if she desired it as well, which is not even a given (though she was relatively sympathetic to Google in some contexts).

Justice Kagan

"Mr. Goldstein, I have to confess to being a little bit surprised or confused about some of the arguments you're making this morning. And maybe it's just me and I don't understand it, but I'm hoping you'll explain it to me, because, when I read your briefs, I took you to be making a somewhat different argument, principally, than the one you're making today."

This impression of shifting-sand arguments or even self-contradiction is obviously a lawyer's nightmare.

"I took you to be saying that the declaring code is unprotected because it's a method of operation, that it's what allows Java programmers to operate the computer, and to be setting forth a pretty flat rule on that --of --of that kind.

"And --and I don't hear you saying that today. Instead, I hear you saying, you know, the real question is, are there multiple ways of doing the same thing?

"So are those different arguments? And which one are you making?"

Google's lawyer then wanted to have it both ways. And he tried to appeal to her by saying that his approach was "textualist."

"Excuse me. Sorry, Mr. Goldstein. But, if --if --if --if that's your test that you're focusing on today, is that essentially the test that comes out of the Second Circuit Altai case? Is there any difference between what you're saying today and --and --and what Altai says, which is essentially that we have to figure out how to separate out the expressive elements of something?"

This is the filtration approach, and her reference to this makes it a possibility that her understanding of copyrigh case law is particularly deep. The above was the most sophisticated question in my view as far as appellate case law on copyright is concerned. Other questions--asked by other justices--had other strengths, such as Justice Alito being super-efficient and Justice Thomas using interesting analogies.

"And if I could go back to something that I think the Chief Justice was asking about, I mean, suppose I'm --I'm --I'm sitting in a mathematics class and the professor says: Do a proof of --of --of something or other. And, you know, it turns out that 20 people in this mathematics class actually come up with more than one proof, and some are better than others, you know, some are elegant and some are less elegant.

"So there are more than one way of proving whatever proposition there is. How do we deal with that? I would think that that's pretty analogous to the situation here, that there are more than one way and Oracle happened to come up with a particularly elegant one."

Mr. Goldstein then tried to evade that question, and while Justice Kagan thanked her, I doubt he managed to convince her.

"Mr. Rosenkranz, as -as I understand it, there are two features of your declaring code that you think merit copyright. And I want to make sure I'm --I'm --I'm right on this first.

"The --the first feature, and this is pretty basic, is that we need some way of connecting a programmer's inputs, whatever they happen to be, some way of connecting those inputs to implementing code.

"And then the second feature is that there needs to be a way to organize those inputs, those calls, into various classes and packages.

"So one is like the trigger and one is the method of organization. Is that right? Is that the thing that you're saying merits copyright?"

Oracle clarified that it's about the declarations themselves, but also their structure, sequence, and organization.

"Okay. So let's start with that, the taxonomy, the structure, the organization, and we can, if we have time, get back to the other.

"I'll give you an example that's similar to one that the Chief Justice used, but I think you won't be --you won't be able to answer in quite the same way.

"Suppose I own a grocery store and I come up with a really terrific way of organizing all my fresh produce, all my fruits and vegetables, into these categories and sub-categories, very intuitive for the shopper. And this is not the standard way. So it's different from the Chief Justice's hypothetical in that way. It's novel. And it's great. And a rival grocery store, all rival grocery stores want to copy it.

"Do I have a copyright claim?"

Oracle then explained that not every structure, sequence, and organization is copyrightable. It depends on what the structure consists of.

"So why is it worlds different? I mean, it seems to me that there are all kinds of methods of organization in the world. You know, whether it's the QWERTY keyboard or whether it's the periodic table or whether the system of kingdoms and classes and phyla and so forth that animals are organized into.

"I mean, there are a thousand ways of organizing things, which the first person who developed them, you're saying, could have a copyright and then prevent anybody else from using them."

It then appeared Oracle answered the question satisfactorily, especially when reminding the judge that the material in question spans 600 pages in the appendix.

Justice Gorsuch

"Good morning, Mr. Goldstein. If --if I understand the conversation so far, you are moving past, rather rapidly, the --the primary argument in your brief that the code just simply isn't copyrightable.

"And I --I --I think that's probably a wise move given the fact that 101 says computer programs, including statements or instructions, in order to bring about a certain result, may be copyrighted.

"We might not think otherwise that it should be, but there it is. And, normally, the --the specific instruction there in 101 would govern the more general idea-expression dichotomy in 102. So am I right, that we can move past that rather rapidly?"

This question by Justice Gorsuch is an excellent statutory one. And when Mr. Goldstein said he actually argues the merger doctrine, the justice replied:

"So I take that as a yes. I'll be honest with you."

It wasn't good news for Mr. Goldstein, but such forthrightness is actually helpful.

"So, if we're moving straight on to the merger doctrine, there, I guess I'm stuck in a similar place as Justice Kagan, which is the argument strikes me very much me as I wish to share the facilities of a more successful rival because they've come up with a particularly elegant or efficient or successful or highly adopted solution in the marketplace, and --and ride on --on --on their innovation.

"What do we do about the --the fact that the other competitors, Apple, Microsoft, who I know is one of your amici, have, in fact, been able to come up with phones that work just fine without engaging in this kind of copying?"

Apple had been mentioned by Justice Sotomayor. Now Justice Gorsuch adds Microsoft. And in a way Justice Gorsuch created a synthesis of Justice Thomas's statutory approach and Justice Kagan's additional reference to case law.

"[I]sn't it pretty difficult to say that this is an essential facility-type problem when --when others have managed to --to innovate their way around it?"

Interestingly, Justice Gorsuch drew an analogy to antitrust law here. And my position has long been that the problem of access to copyrighted APIs should be solved through compulsory licensing on FRAND terms under an antitrust duty to deal.

"[I]f we're worried about ideas and expressions merging, and --and others have been able to accomplish the task without reliance on what --what you might claim to be the essential facility, where --where do we stand?"

Here, Justice Gorsuch checkmated Mr. Goldstein. Simple as that.

Justice Kavanaugh

"To the extent you're still making the method of operation argument, the other side and the solicitor general say that declaring code is a method of operation only in the same sense that computer programs as a whole are methods of operation and that, therefore, your method of operation argument would swallow the protection for computer programs.

"Your response to that?"

Again the concern I share over copyrighability not being the vehicle for distinguishing between declaring and implementing code.

"On your merger argument, one concern that has been raised already is the timing issue. Another concern that I want you to respond to is that it seems to define the relevant idea in terms of what you copy. You're not allowed to copy a song just because it's the only way to express that song.

"Why is that principle not at play here?"

The reference to a song not being free for the taking "because it's the only way to express that song" again exposes Google's approach of saying that something popular loses copyright protection. Mr. Goldstein then claimed they weren't "defining merger self-reflectively," but not in a convincing way.

"One of the points in some of the amicus briefs, and I want to compliment the briefing of the parties and all the amicus briefs, which have been enormously helpful, of the 83 computer scientists is that the sky will fall, in essence, if we rule against you in this case, threaten significant disruption.

"One question I had about that, though, is the Federal Circuit ruled in 2014, this Court denied cert in 2015 on the first issue. I'm not aware that the sky has fallen in the last five or six years with that ruling on the books.

"I know it's different if we rule here, but can you respond to that?"

I got the impression yesterday, as I also noted in my post right after the hearing, that this impact assessment type of question may play a major role in the discussion between the justices. And it's not just about copyrightability, where Google has no prayer, but even more relevant with respect to fair use, where there isn't a clear majority--however, fair use is so fact-specific (and in this case also a procedural matter--standard of review) that I don't think one needs to be concerned even if one agreed with Google on pretty much everything else. We're not talking about a general finding that APIs can never give rise to a fair use exception. It's about only this (extreme) case.

"And welcome back, Mr. Rosenkranz. I just want you to follow up on two of my colleagues' questions. First, any more you want to say about Justice Breyer's QWERTY keyboard question? And, second, Justice Sotomayor's question about settled expectations and --and I would add the 83 computer scientists' concern about threatening significant disruption. If you could just follow up on those two, and I have no further questions after that."

The way I understood this was that he just wanted to give Oracle's counsel the chance to complete whatever he wanted to say before, or to maybe optimize his argument.

Later, Justice Kavanaugh also gave the Deputy Solicitor General of the United States, Malcolm Stewart, a chance to talk about copyrightability:

"Good morning, Mr. Stewart. One question on merger doctrine and one question on method of operation.

"First, Google says in its reply brief that the dispositive undisputed fact in this case is that the declarations could not be written in any other way and still properly respond to the calls used by Java programmers.

"Are they wrong in saying that?"

And another chance:

"And the method of operation, Google says that the declarations are a method of operation because they are for the developers to use, while the implementing code instructs the computer.

"Your response to that?"

Those questions didn't change anything about my impression that the SCOTUS will either affirm the copyrightability finding unanimously or, less likely but possible, "only" near-unanimously.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Supreme Court inclined to affirm Federal Circuit's copyrightability holding in Oracle v. Google, possibly unanimously--fair use may be remanded

Judge William H. Alsup of the United States District Court for the Northern District of California may go down in history as the only U.S. judge ever to have found that code related to application programming interfaces (APIs) is not copyrightable only because it's related to APIs. Or one of only two judges, should Associate Justice Sonia Sotomayor dissent from what otherwise looks like a unanimous affirmance of the Federal Circuit's copyrightability holding. But even Justice Sotomayor is at best having second thoughts and far from being totally in the tank for Google on this part.

The points that Google's attorney, Thomas Goldstein, made on the copyrightability part were simply ridiculous (he's a fantastic lawyer--the problem is that Google has no non-copyrightability case), and in the first part, every one of the Justices asked questions that suggested a strong inclination to side with Oracle on this part.

There was pretty much a consensus that copyrightability is determined based on the situation when something is written, so the merger and method-of-operation exceptions don't apply if they're basically used as a defense to subsequent infringement (which is where fair use comes into play, but irrelevant to copyrightability). Therefore, Google has no path to victory on copyrightability. Game over in that regard.

I've been saying for about ten years--and this case just celebrated its tenth anniversary in August--that regardless of the Merger Doctrine or any other theory, API declaring code is simply code. The Supreme Court of the United States made it clear today, and will do so in writing. I already considered this outcome quite likely when I looked at a procedural order three months ago.

Words cannot express how much I look forward to the SCOTUS opinion after all of this time and absolutely unjustified attacks. Certain morons will get their comeuppance. But, to be very clear, there are some people who sided with Google on this question whom I respect a great deal. Those people know, or they can figure based on how respectfully I've interacted with them at all times, and because they didn't disparage me regardless of our disagreement on API copyrightability. By "morons" I only meant the unreasonable ones who blamed me in unacceptable ways against the backdrop of what was simply a massive legal error on the district judge's part.

Now, with respect to fair use, the problem is the standard of review because the "fair use" finding was a jury verdict.

Orrick's Joshua Rosenkranz argued that the Federal Circuit applied the "no reasonable jury could have found otherwise" standard, but that the correct standard would be de novo for the legal conclusions that a fair use determination involves.

My feeling is that the Supreme Court may find that the more deferential substantial evidence standard needs to be applied, and that in this case a majority of the justices may very well remand the case to the Federal Circuit. It's also possible that Oracle wins affirmance on "fair use" (especially since a split 4-4 decision would be sufficient for affirmance), but I doubt it. There appears to be some concern among the justices that with all the support Google got from amici curiae warning against the consequences of affirmance they somehow feel they shouldn't decide against what Google managed to present as industry practice and expectation.

Assuming that there is a remand of the "fair use" part, which I consider more likely than the other way round (though nowhere near as certain as affirmance of the copyrightability holding), the Federal Circuit would not be too likely to overrule the jury again. But it would then pick up where it left off last time, and Oracle had strong arguments (that also appeared to get traction with the appeals court) for a retrial. Judge Alsup made some pretrial decisions that unfairly disadvantaged Oracle.

I think is a clear case of unfair use, but I'm like ten times more interested in the copyrightability part, and so happy that this one is going to be clarified for good. I was the only one to openly welcome Google's petition for writ of certiorari despite hoping for affirmance. That's because I'm all about the issues, not about the parties. I wanted the copyrightability part to be resolved for good, and on a nationwide basis. A Federal Circuit decision applying Ninth Circuit law would have been of only limited value--it wouldn't have been binding on anyone, not even on the Federal Circuit itself. The highest court in the land is going to provide definitive clarification that API code is not going to be treated differently from a copyrightability point of view than other program code. It's about original creativity, stupid.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Supreme Court affirmance of API copyrightability ever more likely--deference to jury (with respect to "fair use") is Google's last line of defense

For a few years I've limited my commentary on the Oracle v. Google Android-Java copyright case to procedural matters, without reiterating the reasons for which I believe the thousands of lines of Java API code asserted in that case are protected by copyright, and their use by Google was unfair. While I agree with Oracle on substance, I did publicly support Google's successful cert petition because I care about the key issues far more than about specific cases.

I'm going to continue to steer clear of arguing the issues. But I am still following the proceedings, and I have bad news for those who hated the Federal Circuit's copyrightability holding: with respect to copyrightability, it looks like Google is more likely than not to lose.

Due to the coronavirus crisis, oral argument was postponed on very short notice in mid-March, and later rescheduled for the next term (October 2020 at the earliest). Then, in early May, the following order was entered:

The parties are directed to file supplemental letter briefs addressing the appropriate standard of review for the second question presented, including but not limited to the implications of the Seventh Amendment, if any, on that standard. The briefs, not to exceed 10 pages, are to be filed simultaneously with the Clerk and served upon opposing counsel on or before 2 p.m., Friday, August 7, 2020.

This is about deference to the jury with respect to "fair use." The jury had found in Google's favor, so this is, per se, a potential Get Out of Jail Free card for Google, and apparently one that a group of law professors had raised in an amicus curiae brief. But it also means Google's non-copyrightability argument is struggling--or may already have failed definitively--to get traction with the top U.S. court for the second time in about six years.

That's simply because the second question ("fair use") won't be reached unless the first (copyrightability) is answered in the negative for Oracle. "Fair use" is a defense to infringement, and you can't infringe what isn't protected in the first place.

It's unclear how many justices proposed the request for supplemental briefing. It might have been only one, but it will have taken support from several others for this order to be entered. There is quite a possibility of multiple justices--potentially a majority--already having concluded that Google can't prevail on its non-copyrightability argument. The hearing was postponed on such short notice that many if not all of the justices are quite informed; at a minimum, their clerks had concluded their analysis at that stage.

If the Supreme Court answered the "fair use" question in Google's favor on the basis of jury deference, it might or might not discuss the standard for software copyrightability in detail. Whether the Federal Circuit's copyrightability holding would be affirmed explicitly or (by reaching "fair use") mostly implicitly, the copyrightability of API code would continue to be a reality in the United States.

In the same scenario (and I'm not suggesting that it's likely--the fact that the SCOTUS requests additional briefing doesn't mean it will necessarily agree with Google on jury deference), those opposing the protection of API code under copyright law wouldn't really make headway beyond this particular case (and even in that one, there'd simply be a remand to the Federal Circuit). It would be a procedural decision, centered around the standard of review, far short of agreeing with Google's "fair use" defense in its own right--and next time a different jury, ideally instructed by a different (more balanced) judge, might simply find otherwise. It wouldn't be precedential with respect to the substantive issue.

After Oracle won the first of two rounds in the Federal Circuit (with Orrick Herrington Sutcliffe's Joshua Rosenkranz as lead counsel), Google already requested certiorari, but the Supreme Court declined. That fact, combined with the May 4, 2020 order that implies copyrightability, suggests quite strongly that Google is facing an uphill battle in that regard.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google will likely ask the Supreme Court for a second time to review API copyrightability

As I wrote about six months ago when Google was preparing a petition for en banc rehearing of the Federal Circuit's Oracle v. Google Android-Java copyright decision, I'm not going to reiterate my longstanding positions (which haven't changed) on that case. However, Google filed an application for extension of time within which to file a petition for a writ of certiorari (request for Supreme Court review) about a week ago (PDF on Supreme Court website), so I wanted to update my readers in purely procedural terms.

In late August, the Federal Circuit denied Google's petition for a full-court review of a decision that (as I predicted) held the incorporation of many thousands of lines of Java API declaring code into Android did not constitute fair use.

Without the requested extension to January 25, 2019 (which was granted four days ago), Google would have had to file its cert petition in late November.

This time around, Google is trying its luck with a new Supreme Court counsel: Williams & Connolly's Kannon Shanmugam. Presumably, Oracle will continue to work with Orrick's Joshua Rosenkranz, who scored two Federal Circuit wins over Google on Oracle's behalf and fended off Google's original petition for writ of certiorari (which was about copyrightability). What he and his team have achieved in this case, and in some others, is nothing short of amazing.

As Google's application for an extension of time noted, its recent en banc petition related to both copyrightability and "fair use." I venture to guess Google's second cert petition will likewise raise both issues. One of Oracle's key arguments against the first cert petition (though we'll never know which argument bore most weight with the Supreme Court a few years ago) was prematurity: there had not been a final judgment on infringement. Chances are Google will try again.

This is now the longest-running smartphone IP dispute. It started more than eight years ago--in mid-August 2010--with Oracle's original complaint in the Northern District of California. Even Apple v. Samsung ended after "only" about seven years.

From a "justice delayed is justice denied" point of view, I don't think anyone can blame Oracle for presumably fighting very hard against Google's cert petition. However, as an app developer and IP blogger I would like the Supreme Court to grant cert--and to affirm both Federal Circuit opinions. That would provide definitive legal certainty, nationwide, on questions that many of us care about (no matter on which side we come down).

Fortunately, there is no vacancy on the Supreme Court. As some of you may have noted on Twitter and/or LinkedIn, I supported the #ConfirmKavanaugh campaign at all stages.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google's Android-Java "fair use" trial win over Oracle is virtually certain to be overturned

I haven't blogged about this case in a long time and won't spend much time now, but I wish to be of service to my readers here since there doesn't seem to be any reporting in the IT press about how yesterday's Oracle v. Google Federal Circuit hearing went. To the extent anyone reported at all, it appears those reports were either written before the hearing or, if after, they're behind paywalls (or at least Google News doesn't find them).

I won't reiterate my unchanged position on the case in general and "fair use" in particular now. All that matters is what's going to happen now, and it would be a major surprise if last year's ruling by Judge Alsup in the Northern District of California, based on a jury verdict that came into being under circumstances I harshly criticized at the time, was affirmed.

The Federal Circuit yesterday published the official recording (MP3) of the hearing. The panel, which previously held the Java API declaring code copyrightable (it's no secret that this has been my view for a long time), does not appear to agree with Judge Alsup's decision to withhold evidence on non-mobile Android devices (desktop PCs etc.) from the jury. The only question at this stage appears to be whether the appeals court, after finding that this decision and possibly some others were wrong and prejudiced Oracle, will resolve the "fair use" defense by throwing it out directly as a matter of law or, at a minimum, remand for a retrial. I think the probability of a JMOL is greater than 50%.

When listening to the recording, you'll see that the appellate panel firstly was very interested in Oracle's JMOL argument and even allowed five minutes above and beyond the originally allotted time. Then Google's appellate attorney got a very rough ride. The most impressive part of the recording is the last five minutes: an amazingly powerful rebuttal statement by Orrick's Joshua Rosenkranz. This is as good as it gets.

While no one said so at the hearing, I believe Judge Alsup completely destroyed his credibility with the Federal Circuit by excluding absolutely essential and outcome-determinative evidence. He's in for a second reversal in the same case--which is unusual, but he had it coming.

When the appellate opinion is handed down, many people will be surprised that the case is still alive. But you won't be because I felt I had to tell you since, to the best of my knowledge, no other free-to-read website has done this job, at least not yet.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Oracle v. Google: jury finds in favor of "fair use," as no reasonable, properly-instructed jury could have

Courtroom tweeters in San Francisco have just reported that the Oracle v. Google retrial jury has found in favor of Google, i.e., has determined that Android's use of the declaring code and structure, sequence and organization of 37 Java APIs is "fair use."

This is the outcome of a rigged (for emotional, not financial reasons) retrial. It's absolutely wrong. This here is a far cry from anything any appeals court ever deemed to constitute fair use.

At the outset of the trial, I had already predicted that the jury was more likely than not to find for Google. I said 55%-60%. That was based on the fact that pretrial decisions by Judge Alsup had already favored Google, and his jury instructions on the "fair use" rules were unbelievably unfair and biased. They made it sound like the hurdle for "fair use" was rather low, while it's actually just meant to be an EXCEPTION (and copyright protection is the norm).

Also, while Google was able to present all of the "evidence" and testimony that helped its defense, Oracle had been precluded from presenting the entirety of its willful-infringement evidence.

Presumably, Judge Alsup will deny Oracle's motion for judgment as a matter of law (JMOL), if his jury instructions are any indication. Then Oracle will appeal again. I predict Oracle is very likely to succeed once again on appeal.

Judge Alsup has already said he knows there will be appeals. Last time, Oracle's appeal didn't end well for him. What the circuit judges said at the appellate hearing was anything but flattering for him.

I almost forgot to mention, before going to bed (and I'll sleep well because all's well that ends well), that a jury verdict obviously has no precedential relevance of any kind. As I wrote before the trial even started: this trial wasn't going to resolve the question of unlicensed, incompatible API reimplementations either way. Several hours before the verdict I said on Twitter that trial courts are the WRONG forum to resolve overarching, big issues--and especially in this case.

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+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google's 'fair use' defense against Oracle is an insult to human intelligence: Android's use of Java APIs violates copyright

There's a whole lot of doomsday stories out there on the Internet about Oracle v. Google, the Android-Java copyright case. In reality, the ongoing trial, in which jury deliberations will begin shortly, is not going to provide clarification regarding incompatible, unlicensed reimplementations of application programming interfaces (APIs) either way.

Let me be clear about this: I believe in pluralism, and that's why people certainly have every right to campaign against intellectual property (IP) protection of the declaring code and structure, sequence and organization (SSO) of APIs. What I do take issue with is that the anti-API IP crowd consistently advocates a misguided approach. If they wanted to talk to lawmakers on Capitol Hill about copyright and APIs, that would be democratically legitimate. If they showed a case in which a major API owner abused its rights in an anticompetitive manner, I'd most probably support a call for compulsory licensing. But after that non-copyrightability idiocy that failed at the appeals court (and that the Supreme Court declined to buy), the anti-API IP movement now picks a second inappropriate vehicle: the "fair use" exception to copyright infringement.

I'm investing a lot in software development (you'll see the results later this year) and I will fight hard against anyone seeking to unreasonably weaken software IP for purely ideological reasons. App developers like me would suffer collateral damage if anti-API IP advocates got their way on the wrong basis. On the right basis, such as compulsory licensing, I wouldn't have a problem with it. But I'll continue to speak out against a carpet-bombing of software copyright that would render even the most creative program code unprotected. That's where I draw the line, and the longer this takes, the more people will likely agree with me.

I'm 100% independent from Oracle but 100% behind its motion (filed Tuesday) for judgment as a matter of law (JMOL) against Google's "fair use" claim. And after reading Google's opposition brief, filed last night, my support for Oracle's motion is undiminished and I may be even more determined now because Google's lawyers have filed something utterly absurd.

To all you dreamers out there: it's time to wake up and face the facts. And the law.

The only regard in which Google has a point is that Sun Microsystems' management, including one of the industry's worst CEOs ever, failed to make it consistently clear to Google that the way it incorporated the Java API headers into Android was against the law. And failed to enforce. That combination of inconsistencies and weakness, however, is still a far cry from Google having had a license or that Java was "fair game." In fact, even the very Google-friendly jury in the first (spring 2012) trial accurately concluded that Google didn't actually rely upon its conduct being permitted. The retrial jury would almost certainly arrive at the same conclusion, and Oracle has shown some strong evidence that proved Google believed it needed a license at least for the sake of legal certainty, but most of the willful-infringement evidence has been withheld from the current jury by an unfair, biased, partial judge an IP lawyer (and software developer) described as a "sore loser."

JMOL in Oracle's favor is more than warranted because no reasonable, unbiased jury could possibly side with Google on "fair use" in this case. Google bears the burden of proof, but its defense is incredibly weak. You can read this in excruciating detail in Oracle's JMOL motion, which I published a few days ago. What I'll do now is point out the key deficiencies of Google's "fair use" defense, factor by factor based on the four-factor test in 17 U.S.C. § 107.

1. "the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes"

There's no dispute about this being commercial. If Judge Alsup had followed the instructions from the appeals court more clearly, he wouldn't have stricken the adverb "purely" before the word "commercial".

The availability of (most but not even all of) Android on open-source terms changes nothing about this.

Commercial use doesn't automatically defeat a "fair use" defense, but it does up the ante for Google.

Commercial nature is one of several aspects of the purpose and character of the use. The one Google mostly stresses here (and no doubt it's going to be key on appeal) is whether its use was "transformative." And it's this area in which I find Google's argument most absurd. It provides a large part of the reason for the headline of this post calling Google's defense an insult to human intelligence.

The fact of the matter is that any given API header has the same meaning in Android as it had and continues to have in Java. There's no change of expression or meaning here whatosever. So Google is making a context-based argument: Android is a mobile operating system and it's open source. I'll say it bluntly what I think of this: transformative my ass!

First, Java was in use on a huge number of mobile devices (BlackBerry, Nokia, Samsung etc.) before Android. Some of those device makers have meanwhile adopted Android, and others have more or less gone out of business. But at the time Android was launched, no one needed Google to take Java to mobile phones, and even Eric Schmidt, Google's former CEO and now the executive chairman of its corporate parent (Alphabet), conceded that BlackBerry phones were smartphones.

Second, Java was already available on open-source terms (OpenJDK) at the time, but Google didn't want to have the so-called copyleft obligation of contributing derivative works back to the free and open-source software (FOSS) community. The open-source argument is furthermore ridiculous because Android is licensed on Apache terms, meaning that anyone can take that code and build closed-source, proprietary software.

2. "the nature of the copyrighted work"

Already at the time of the first trial, exceptional creativity in API design had been conceded. There's plenty of evidence for it in the current record, such as an admission by one of Google's own witnesses that API design is more of an art than a science.

The (flawed) jury instructions suggest that something functional (such as program code) gets weaker protection than something very creative. However, here we are talking about highly creative and expressive code.

This is also an aspect that could become a big topic on appeal because it threatens to vitiate all software copyright. I also think it's at least unbalanced to suggest weak protection of software in connection with the second factor without simultaneously clarifying in connection with the first factor that functional arguments for "transformative" use are generally weaker than creative arguments. The perfect "fair use" case involves, as § 107 says, "criticism, comment, news reporting, teaching (...), scholarship, or research." I also think that parody is at a level with that list. But if you take someone's program code and simply build another program, you don't criticize, ridicule, comment, report, teach or research anything. You just steal. Nothing more than that.

It's very rare that someone uses program code for the purpose of criticism/parody. One of the very few examples I know is only a few months old: the Trump programming language. I don't think it treats the candidate fairly, but that doesn't matter: this clearly is a humorous use of program code. Android, however, is just another program, not a parody, nor commentary.

3. "the amount and substantiality of the portion used in relation to the copyrighted work as a whole"

I don't blame programmers for misunderstanding this part, but I've also seen some inexcusable nonsense from at least one lawyer about this.

While there's a lot more implementing code in those Java APIs than declaring code (as in any computer program), this factor must be seen in light of the applicable case law. Taking the "heart" of a work is what Google has done here, but there's also plenty of case law that shows even a minor percentage of an overall work is often enough to defeat a "fair use" defense. For example, the Supreme Court held in its 1985 Harper & Row v. Nation Enterprises ruling that even just copying a Gerald Ford speech manuscript of 300 words taken from a biography was enough to constitute copyright infringement.

Here we're talking about 11,000 lines of code, more lines of code than NASA used to control the Apollo moon landing.

Oracle's JMOL motion provides additional examples from the case law.

4. "the effect of the use upon the potential market for or value of the copyrighted work"

Java may still be popular in some other areas, but Oracle has shown plenty of evidence of losing business from customers such as Samsung (which is now the biggest Android device maker). Now, Google (and potentially Judge Alsup) would like to make a distinction between Java ME and Java SE. The stolen code has been taken from Java SE; Java ME was the mobile edition. But the question of whether Java ME was a derivative work of Java SE or vice versa is ultimately not going to decide this case.

Key holdings in Google Books case

Last month, the Supeme Court declined to take a look at the "Google Books" case. Earlier on, the Second Circuit had ruled in favor of Google's related fair use defense, and as I explained at the time, the rationale actually supports Oracle's case against "fair use" in connection with Android. I'd like to just quote and briefly discuss two key passages from the Second Circuit's Google Books ruling:

• "Google's division of the page into tiny snippets is designed to show the searcher just enough context surrounding the searched term to help her evaluate whether the book falls within the scope of her interest (without revealing so much as to threaten the author's copyright interests)"

  Note particularly the part in parentheses. Google Books basically provide a teaser that can generate book sales. But Android does not use only so little of Java that programmers would ultimately prefer the real thing.

• "Snippet view thus adds importantly to the highly transformative purpose of identifying books of interest to the searcher. With respect to the first factor test, it favors a finding of fair use (unless the value of its transformative purpose is overcome by its providing text in a manner that offers a competing substitute for Plaintiffs' books [...])"

  Here, too, the part in parentheses is key. Android crossed the line because it did become a competing substitute for Java-based mobile platforms.

The body of evidence is far stronger now than in 2012

There was enough evidence on the table back in 2012 that I called Google's "fair use" defense a fairy tale. But now there is so much more evidence, especially but not only regarding market impact, that no jury should even have to deliberate. This is a no-brainer. It's unfair use. As unfair as it gets. It may require an appeals court, though, to arrive at the correct result.

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+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Oracle moves for judgment as a matter of law against Google's 'fair use' defense to Java copyright infringement

Oracle has just filed a JMOL (judgment as a matter of law) motion against Google's flimsy "fair use" defense in the Android-Java copyright infringement case. Oracle's lawyers argue (and I agree) that, after the close of Google's "fair use" case, no reasonable jury could conclude that the way Android hijacked Java constitutes "fair use".

I can't comment on it until much later today, but I did want to publish this important motion immediately. It's the key motion in case the jury (which did not get to see some of the most important evidence and may have been confused by some of the testimony presented) finds in Google's favor. In that case, Oracle will -- no doubt -- appeal and argue that denial of its JMOL motion constituted an abuse of discretion (which it would also be in my opinion). Here's the motion for now:

16-05-17 Oracle Motion for JMOL on 'Fair Use' by Florian Mueller

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+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Here's a MOUNTAIN of willful-infringement evidence the Oracle v. Google jury won't see in trial phase one

Further below you can find a very long list of items in the evidentiary record of Oracle v. Google (the Android-Java copyright infringement case) that will convince any reasonable person not affiliated with Google that Google was fully aware of the legally problematic approach its Android team took to the Java APIs. You'll find amazingly clear internal emails and presentation slides that simply leave no doubt about this. The potentially worst part is at the very end: Google attempted to conceal its use of the copyright materials for as long as possible because Googlers believed Sun was going to come after them. If the jury saw all of this now, Google's defense would be toast, but Judge Alsup doesn't want the whole truth to be put before the jury at the most critical stage...

As you can see, this blog's Oracle v. Google anti-unfair trial campaign--not affiliated with any party in any way whatsoever--is continuing. In response to my most recent post in this series, two U.S. lawyers, one with a focus on litigation and the other one with a specialization in IP, agreed with me publicly (on Twitter). The litigator said that Judge Alsup's plan to tell the jury about his (fundamentally flawed and reversed) original non-copyrightability holding is "begging for a mistrial," and the IP lawyer, who has practiced before Judge Alsup, called the judge a "sore loser, that's all."

Now Judge Alsup filed a request for information from the parties that does nothing to rebuild my confidence in his handling of this case. He now wants the parties to explain whether Google may have had good-faith reasons for considering Oracle's API-related declaring code (the lines of code and their structure, sequence and organization) non-copyrightable:

"From 2012 to 2014, the law in this case held that the declaring lines of code and the structure, sequence, and organization were not copyrightable. That was reversed by the 2014 ruling of the Federal Circuit, but an issue for us in this follow-on trial is whether and to what extent the jury may consider the law in the case prior to the 2014 holding by the Federal Circuit in evaluating willfulness and bad faith by Google during that period. Please cite decisions on point on or before MONDAY AT NOON. Please include decisions, pro and con, not just those on your side."

Oh no. If the Federal Circuit had changed the law on this, the Supreme Court would have heard the case. That would have been a clear circuit split, and Google had mobilized so many of its supporters to give weight to its cert petition that the Supreme Court certainly won't have assumed nobody was interested in the matter.

It does give the impression of being a "sore loser" when someone doesn't want to understand--but maybe he will after Oracle responds to this order--that his ruling was an extreme outlier. Before Judge Alsup, no other U.S. court ever held a similar combination of quantity and creativity of original (!) human-authored text non-copyrightable. There were cases in which large amounts (even larger than what's at issue in this case) of non-original, non-creative data were deemed non-copyrightable, such as telephone directories. There were also cases in which very small amounts of original material were denied copyright protection. But no one else ever held many thousands of lines of original, concededly (even Google's witnesses said so) highly creative material non-copyrightable.

Yeah, there were some "fair use" cases such as the famous Sony and Sega decisions, which Circuit Judge O'Malley told Google's counsel (the same one as in this trial, Robert van Nest) to stop raising in connection with copyrightability because they had no bearing on it. The holdings of those "fair use" cases amounted to using a few bytes in a game and to making a few private (!) copies of games in order to reverse-engineer them. That's just so very different from distributing thousands of lines of code on billions of devices.

So this latest "request for briefing re willfulness and bad faith before Federal Circuit decisions" is nothing more than the expression of a constant state of denial. It's disrespectful of the clear findings of the three higher judges than him who ruled on this last year. It also puts Judge Alsup at loggerheads with the U.S. government, which found Google's cert petition flawed and recommended its rejection last year. The Department of Justice clearly concluded that Judge Alsup's ruling had been an outlier and that the Federal Circuit opinion merely reiterated what the law had been all along. But Judge Alsup doesn't want to accept this reality.

The trial structure--bifurcation with "fair use" first, damages second, and most of the willfulness evidence being limited to the second phase, which may not even be reached if Google's counsel and witnesses once again confuse the jury--is one of various indications of an unfair approach to this retrial that harms Oracle. While Google can raise all sorts of issues in phase one that the jury could mistakenly (or just subconsciously) view as buttressing Google's "fair use" fairy tale, Oracle is very limited in its reference to such evidence in phase one. Some stuff has come up in connection with cross-examinations, such as the "half-ass" email this blog already published last August (it wasn't first to publish it, but it was first to draw attention to it).

It's easy for me to see what Judge Alsup's latest request for briefing is about: he knows that if Google loses (despite some people's efforts to avoid it) trial phase one and its "fair use" defense is thrown out, willfulness could become a big issue in phase two and, especially, a subsequent judicial decision on injunctive relief. About five years ago, Judge Alsup himself told Google it was "on the losing end" of the so-called Lindholm email and particularly highlighted the serious implications of willful infringement for injunctive relief:

"You're going to be on the losing end of this document with Andy Rubin on the stand. You think about that," Judge Alsup told Google's counsel. "And I want to say this: Willful infringement is final. There are profound implications of a permanent injunction. I'm not saying there is willful infringement, but that is a serious factor when you're considering an injunction."

So what if the jury finds Google infringed willfully? Then Judge Alsup could still "acquit" (not in a legal, but practical sense) Google by holding there was no objective willfulness as Google had, in his opinion (contrary to that of the higher courts), good reasons for believing it was in its right to use the material at issue. At this stage I predict Judge Alsup to do so later on, though I'd like to be proven wrong.

As I wrote above, Oracle is limited in its ability to put all the willfulness evidence before the jury at the right point in time, which would be now. But I have no working relationship with Oracle at this stage (and don't plan on having any again), and I'm free to publish things that are in the public record. And that's what I'm going to do now. I'm now going to show you the complete list of willfulness evidence that Oracle's counsel filed on September 14, 2015 (doc. no. 1312; please note I've restructured the content of that document for the purposes of this blog and added the second-level headings), some but not all of which has been or will be shown to the jury before its decision on "fair use":

1. Google Knew Sun Claimed Copyright in the Java API Packages

1.1 Bob Lee testimony

Bob Lee, former Google Core Library Lead for Android, testified at trial that he: (1) consulted Java docs when implementing APIs for Android; and (2) observed copyright notices on those documents.

1.2 Brian Swetland testimony

Brian Swetland, senior staff software engineer for Google, testified that he knew, while working for Android, that Sun claimed copyrights on its method signatures:

"Q. You were aware [between 2000 and 2004] that Sun's position was that the method signatures, the specifications, method signatures were copyrighted, correct?

A. I do recall mention that Sun claimed copyright on the method signatures.

. . .

Q. Nothing had changed between the time you were at Danger and the time you were at Android, correct?

A. Nothing about since -- very, very broad.

Q. Your knowledge about what Sun claimed about its copyright and the method signature had not changed?

A. That is correct."

1.3 Andy Rubin email of March 24, 2006

Andy Rubin, then-SVP of Google in charge of Android, wrote an email stating that "Java.lang apis are copyrighted" and that since "[S]un . . . own[s] the brand and ip[,]" "[S]un gets to say who they license the tck to[.]"

1.4 Google-internal document of March 6, 2008

"In an internal Google document rehearsing the 'Mobile + Android' narrative, Google anticipated that it would be asked whether 'Android's Dalvik VM violate[s] Java's IP restrictions"” and had no answer to that question."

1.5 Alan Donovan email of April 9, 2008

Alan Donovan, software developer at Google, wrote an internal email to [email protected] explaining how to turn off "Sun proprietary API" warnings issued by the Java compiler.

1.6 Dan Bornstein email of April 2009

Dan Bornstein, then-technical lead for the Android Dalvik virtual machine and core libraries, emailed that "Bob is right: We don’t ‘own’ the java.* API and so can’t go around altering it."

2. Google Knew Throughout That it Needed a License to Use the Copyrighted Materials

2.1 Rubin agreement (as CEO of Danger, his previous company) with Sun of October 19, 2001

Andy Rubin, as CEO of Danger, signed a confidential disclosure agreement with Sun relating to possible licensing of Java Technology by Danger from Sun.

2.2 Rubin agreement with Sun (as CEO of Danger) of August 26, 2003

Andy Rubin, as CEO of Danger, helped negotiate a license with Sun to allow Danger to do a clean room implementation of Java ME.

2.3 Swetland aware of Danger license deal with Sun

Brian Swetland, senior staff software engineer for Google, knew that Danger had taken a license from Sun for use of Java's method signatures:

"Q. . . . [Y]ou did know that Danger took a license from Sun . . . correct?

A. Correct.

Q. And you knew that the reason that Sun gave for why Danger was required to take a license was that Sun held a license on the method signatures, a copyright on the method signatures, correct?

A. Well, I heard that from Andy [Rubin.]"

2.4 Google-internal PowerPoint presentation of April 24, 2005

Internal Google PowerPoint presentation, with talking points for Andy Rubin, stated that even if Sun and Google could not agree to a co-development partnership, Google would still have to take a license from Sun for Android's use of Java, and complained that such a license would "put[] Sun in a position of control."

2.5 Google-internal presentation of July 26, 2005 entitled "Android GPS: Key strategic decisions around Open Source"

An internal Google presentation entitled "Android GPS: Key strategic decisions around Open Source” concluded that Google "[m]ust take [a] license from Sun" and proposed that "Google/Android, with support from Tim Lindholm, [would] negotiate[] the first OSS J2ME JVM license with Sun."

2.6 Rubin email of July 29, 2005

Andy Rubin sent an email attaching a document summarizing internal Google discussions relating to licensing Java from Sun. The document states that "Google would like to work with Sun to conceive of and agree to a license that enables Google to release to the Open Source community, under a license of it's [sic] own choosing, it's [sic] internally developed CLDC based JVM." The document further states that "Google needs a TCK license."

2.7 Rubin email to Page of October 11, 2005

Andy Rubin sent an email to Larry Page proposing that Google "take a license [from Sun for Java] . . . . We'll pay Sun for the license and the TCK." The email further stated that "[i]f Sun doesn’t want to work with us, we have two options: 1) Abandon our work . . . – or – 2) Do Java anyway and defend our decision, perhaps making enemies along the way[.]"

2.8 Lindholm email thread of October 25-26, 2005

Tim Lindholm sent an email to Andy Rubin stating that "perhaps the key exercise [with Sun] probably remains trying to find an enforceable license that requires compatibility but otherwise does not impose cost or onerous conditions on distribution and use[.]"

2.9 Rubin email of December 20, 2005

Andy Rubin wrote an email to other Google employees recommending that "either a) we'll partner with Sun as contemplated in our recent discussions or b) we'll take a license."

2.10 Lindholm email of February 10, 2006

Tim Lindholm wrote an email to another Google employee, copying Andy Rubin, stating that he had recently been "helping negotiate with my old team at Sun for a critical license."

2.11 Gupta-Rubin email thread of March 16-April 19, 2006

Vineet Gupta of Oracle and Andy Rubin of Google exchanged several emails in an attempt to negotiate between the companies a Collaboration Development and License Agreement.

2.12 Desalvo email of June 1, 2006

Chris Desalvo, a software engineer at Google, wrote an email to Andy Rubin asking him: "With talks with Sun broken off where does that leave us regarding Java class libraries?"

2.13 Bornstein email of June 12, 2006

Dan Bornstein, technical lead for the Android Dalvik virtual machine and core libraries, wrote an email to the Android engineering team acknowledging that Google's use of Java was dependent on reaching a deal with Sun: "As for what set of java.* classes we're aiming for, that's still somewhat of an open question, the resolution of which will undoubtedly hinge on what happens (or fails to happen) with Sun."

2.14 Swetland email of August 16, 2006

Brian Swetland, software engineer, sent an internal Google email stating: "we are building a java based system: that decision is final[.]"

2.15 Rubin email of November 12, 2006

Andy Rubin learned that Sun was open sourcing Java SE, Java ME, and Java EE under a GNU General Public License, and engaged in an email discussion about how and whether Google could use that license in order to obtain the desired rights to Java. The discussion pointed out that the "GPL license (sun's license) doesn;t [sic] work for us."

2.16 Swetland email of March 29, 2007

Brian Swetland of Google wrote an email to Dan Bornstein, also of Google, copying an Android Engineering email list, explaining with respect to Android: "[T]he fact that we are not likely to run TCKs and unlikely to be able to call it Java is not due to desires on our part, but to legal/contractual hurdles imposed by a certain external entity."

2.17 Rubin-Schmidt email thread of May 10-11, 2007

Andy Rubin wrote an email to Eric Schmidt stating "I'm done with Sun (tail between my legs, you were right.) They won't be happy when we release our stuff, but we now have a huge alignment with industry, and they are just beginning."

2.18 Gupta-Rubin email of August 2, 2007

Once Google made clear to the public in the second half of 2007 that it was working on a Google phone, Vineet Gupta of Oracle emailed Andy Rubin to ask what Google was planning and to discuss licensing. Andy Rubin did not respond.

2.19 Lee email (to Schmidt) of May 30, 2008

Bob Lee, former Google Core Library Lead for Android, emailed Eric Schmidt, Google’s chairman and then CEO, that: "Sun puts field-of-use restrictions in the Java SE TCK licenses which prohibit Java SE implementations from running on anything but a desktop or server. These restrictions prevent Apache Harmony from independently implementing Java SE . . . not to mention Android (though that's water under the bridge at this point)."

2.20 Gupta email of October 1, 2008

In an internal Oracle email, Vineet Gupta of Oracle reported on a recent discussion with executives in which they discussed "a license to Google that enables them to make Dalvik compatible, get the Java Brand – [and] any one downstream that wanted the Brand (and IP protection) would need to come back to Sun for the license as well (I assume TCK).”

2.21 Schmidt testimony about Google's legal worries in 2009

Eric Schmidt, Google's Chairman and former CEO, testified that in 2009, "Google was sufficiently worried about being sued that it thought about buying all the rights to Java."

2.22 Sobota email of February 19, 2009

Dave Sobota, a director of corporate development at Google, sent an email to Tim Lindholm, Bob Lee, and others proposing that "Google buys the rights to Java from Sun (patents, copyrights, etc)." The email stated that this proposal was "Good for Google" because "Our Java lawsuits go away." It further stated that a possible bad alternative if Google did not buy the rights to Java would be that "IBM or Oracle buys rights to Java, further locks down the platform or entangles it in more Patents/IP."

2.23 Cizek testimony on April 2009 licensing talks with Google

Leo Cizek, Oracle Account Manager, testified that he discussed Java licensing with Google in April 2009:

"Q. After December 2005, did you have any other discussions with anyone from Google regarding Android?

A. Yes. In, I think, April of 2009, I had a discussion where the person from Google wanted to discuss Java Standard Edition. But I brought up the subject of Android, and we discussed that, as well.

Q. So what was the name of the person whom you spoke to, who worked for Google?

A. Martin Buccholz.

Q. And what was the reason that you found yourself speaking to Mr. Buccholz?

A. Mr. Buccholz had contacted a colleague of mine, indicating that he wanted to discuss with the correct person at Sun the possibility of Google's licensing the source code to Java Standard Edition so that they could get access to a particular type of support. Getting, like, advance notice on security bug fixes.

. . .

A. When I called Mr. Buccholz -- this was a conference call, by the way -- I had a colleague on that line with me, as well, a systems engineer from Sun. I explained that Sun would be very interested in looking into the possibility of doing a source license agreement covering Java SE and providing just the type of support that they were requesting. But I said that there would be something that would have to be fixed, first, which is the fact that regarding Android there was no commercial use license; and, as we understood it, Android was shipping an incompatible version of Java, commercially."

2.24 Cizek email of April 29, 2009

Leo Cizek, an Oracle employee, sent an internal email reporting on a conversation in which he informed Martin Buchholz, a Google software engineer, that Google's use of Java in Android was unacceptable: "I delivered the message that they have only two options: OpenJDK or Commercial Use, which would require compatibility. I also explained that using Java in the context of customer-facing applications is considered by Sun to be commercial use. I also explained that if they choose the commercial use/compatible option, it would have ramifications throughout Google, and I gave Android as an example. Martin replied: ‘The Android group did not use any Java code in developing Dalvik; they only used the Java specifications.’ . . . I replied that Sun’s position is that the spec license agrmts require that any s/w created from them which is for commercial use be compatible."

2.25 Catz testimony on May/June 2010 discussions with Google

Safra Catz, Oracle's CEO, testified as follows regarding discussions with Google:

"Q. Well, what did you do, if anything, before bringing this lawsuit against Google?

A. We reached out to Google a number of times trying to get this matter resolved with them. We met with them. You know, a number of us met with them at different times.

Q. Were you involved in any of those meetings?

A. Yeah. I was informed about the other meetings, but I was actually involved with one with Alan Eustace, Andy Rubin's boss at the time.

Q. Can you explain what it was you were trying to accomplish by meeting with Google -- approximately when were these meetings taking place?

A. Well, we actually acquired Sun in -- in January of 2010. And so after that the -- the meeting I went to Alan Eustace was almost two years ago now, so June of -- June of 2010 --

Q. And what were you trying to accomplish --

A. (Continuing) -- May maybe. May, June, something like that.

Q. And in these meetings around May, June, 2010, what was it that you were trying to accomplish by meeting with Google?

A. Well, we had really two objectives. One was to bring Android on into Java compatibility. That was very, very critical. The other part was to get Android licensed and paying for the intellectual property."

2.26 Kurian testimony on May-July 2010 discussions with Google

Thomas Kurian, Oracle EVP for Software Development, testified as follows:

"Q. With respect to the second item, Mr. Kurian, Mr. Kurian, what did you say to Google?

A. I specifically discussed -- we specifically discussed with Mr. Rubin that the Dalvik implementation and their implementation of Java needed to comply with the Java Standard specifications, which meant you had to implement the class libraries completely and also pass the TCK.

Q. Did Google accept that?

A. No."

2.27 Lindhom email of August 6, 2010 (the most famous "Lindholm email")

Tim Lindholm sent an email to Andy Rubin and others stating that "Larry and Sergei [sic]" asked him "to investigate what technical alternatives exist to Java for Android and Chrome." In the email, Lindholm writes that the alternatives "all suck," and that Google "need[s] to negotiate a license for Java under the terms we need."

3. Google Knowingly and Willfully Infringed Because of its Profit Motive and To Secure Its Dominance in the Mobile Search Market

3.1 Miner email of October 12, 2005

Rich Miner co-founder of Android and Google employee, wrote an email to Andy Rubin stating: "[i]t is widely believed by that if an open platform is not introduced in the next few years then Microsoft will own the programmable handset platform[.]"

3.2 Google Inc.'s Form 10-K for 2005

Google Inc.'s Form 10-K for the fiscal year ending December 31, 2005 noted:

• Google's business model of relying on search engine advertising from browsers used on personal computers was in jeopardy because "[t]he number of people who access the Internet through devices other than personal computers, including mobile telephones . . . , has increased dramatically in the past few years."

• "[I]f we are slow to develop products and technologies that are more compatible with non-PC communications devices, we will fail to capture a significant share of an increasingly important portion of the market for online services."

3.2 Bornstein email of April 13, 2006

In an internal Google email to Andy Rubin and Steve Horowitz, Dan Bornstein wrote: "We need to provide an alternative to MSFT [= Microsoft], and we need to do it in such a way as we don't fragment 3rd party developers. . . . Java has very little fragmentation, and it's adoptable. If we play our cards right, we can also leverage not only existing developers, but applications as well."

3.3 Android PowerPoint presentation dated November 2006

An Android PowerPoint presentation, dated November 2006, states:

• "Supporting Java is the best way to harness developers"

• "[There are] 6M Java developers worldwide."

• "Strategy: Leverage Java for its existing base of developers."

3.4 December 2008 Android presentation

December 2008 Android presentation discussed the growing mobile market and explained that "the trajectory for mobile search will converge with conventional computer based search." It further stated: "Why did Google invest in Android? . . . . Don't get locked out!"

3.5 Gundotra email of April 13, 2010

Vic Gundotra of Google emailed Jonathan Rosenberg of Google and copied Andy Rubin, stating: "Apple is going to make sure only they have a shot at mobile advertising. We need android to win more than ever."

3.6 Talking points slide of October 12, 2010

Jonathan Rosenberg's assistant forwards a "talking points" slide to Alan Eagle of Google stating that Android is a "critical asset" for the success of Google's 5 Business Units, each of which is a $10 billion opportunity for Google.

3.7 Google-internal notes of November 4-5, 2010

Internal Google notes from a Mobile Strategy Summit state that "if we miss the 'mobile window', we'll be out of business in 10 years."

4. Google Knowingly and Willfully Infringed Because It Had No Viable Technical Alternative

4.1 Rubin email (to Page) of October 11, 2005

Andy Rubin sent an email to Larry Page stating that "[i]f Sun doesn't want to work with us, we have two options: 1) Abandon our work . . . – or – 2) Do Java anyway and defend our decision, perhaps making enemies along the way[.] As you can see, the alternatives are sub-optimal[.]" The email further stated: "Android is building a Java OS. We are making Java central to our solution because a) Java, as a programming language, has some advantages because it's the #1 choice for mobile development b) There exists documentation and tools c) carriers require managed code d) Java has a suitable security framework[.]"

4.2 Swetland email of January 2, 2006

Brian Swetland of Google wrote an email to Mathias Agopian, also of Google, and copied Andy Rubin, stating that a primarily Java API "simplifies the application development story . . . reduces our development time… faster app development and debuggability." He further stated that Java was better than other technical alternatives, such as "C++, Intercal, etc" because:

• "Java is more accessable [sic] than C++. There are more Java programmers. There is more standardization in tools and libraries. Debugging is much simpler (especially for people who are not total rockstars – perhaps a lot of casual developers, etc)"

• "Java solves a lot of the portability issues C++ has"

• "Java does have a big win of being much more compact code than native arm/thumb code."

4.3 Desalvo "half-ass" email of June 1, 2006

Chris Desalvo, software engineer at Google, wrote an email to Andy Rubin stating: “"egarding Java class libraries[,] [o]urs are half-ass at best. We need another half of an ass."

4.4 Bourrillion chat message of November 14, 2007

Kevin Bourrillion, software engineer at Google, wrote a chat message to Bob Lee saying that Android had "take[n] [the] good stuff from java[.]"

4.5 Lindholm email of August 6, 2010 (the most famous "Lindholm email"

Tim Lindholm sent an email to Andy Rubin and others stating that "Larry and Sergei" asked him "to investigate what technical alternatives exist to Java for Android and Chrome." In the email, Lindholm writes that the alternatives "all suck."

5. Google Attempted to Conceal its Use of the Copyrighted Materials for as Long as Possible

5.1 Chen-Chu chat of November 4, 2007

In a November 4, 2007 chat between Jason Chen and Eric Chu, both of Google, Eric Chu wrote: "This Java stuff can be nothing or very serious. I do believe Sun is planning to come after us." He further wrote: "the only thing we need to scrub for at this stage is references to Java."

5.2 Bornstein email of November 7, 2007

In an internal Google email, Dan Bornstein directs a team to "[s]crub out a few more 'j's" from the Android code.

5.3 McFadden email of November 12, 2007

Andy McFadden, software engineer for Google, reported that his recent activities included: "Remov[ing] various incarnations of the 'J word' from the SDK."

5.4 Walker email of November 12, 2007

Amanda Walker, a Google software engineer, emailed Dan Morrill, also of Google, to ask him not to "publicly compare Android to J2ME or any other technology." She explained: "As innocent as that seems, unfortunately it's exactly one of things that it's vital that we not do. It doesn't even sound that innocent, actually--at a first guess, the fact that we're not using a 'real' JVM or J2ME at all may dim Sun's initial euphoria a bit . . . and if Sun decides to take potshots at Android, that would hugely complicate things. . . . I'm planning on just playing dumb and forwarding all questions back to the mother ship :-)."

5.5 Morrill instant message of November 14, 2007

In an instant message from Dan Morrill to Dan Bornstein, both of Google, Dan Morrill announced his intention to "do a sanity pass over the [Dalvik spec] docs" before they were released, because he would not "be surprised to find legally questionable uses of the j word."

5.6 Rubin email (to PR team) of November 16, 2007

After learning that a Google employee had stated publicly that Google had its "own APIs [and] a better flavor of Java[,]" Andy Rubin emailed the PR team to request that "only authorized speakers speak to the press" and emphasized that: "This is really important and a legal issue."

5.7 Miner email of November 18, 2007

After another Google employee was asked to do a tech interview relating to Android, Rich Miner, co-founder of Android and Google employee, wrote to Andy Rubin and others that he would "prefer to have" himself "or someone else from our team handle these calls if they [are] Android related[.]" He stated that "[t]here is lots of sensitivity around Android and Sun/Java[.]"

5.8 Burke email of November 21, 2007

David Burke, an engineering director at Google, described his recent presentation on Android to Andy Rubin, stating: "I was very conscious of the sensitivity around Java and was careful to sidestep any pointed questions in that direction (I definitely never said JVM or ‘the’ Java language, for instance)."

5.9 Rubin email of March 24, 2008

Andy Rubin wrote an internal Google email directing employees at the JavaOne conference booth to "answer direct developer questions about Android" and demonstrate Android on a "[o]ne-on-one only" basis. He instructed the employees to give demonstrations on a "one-on-one only" basis where the individual "know[s] exactly who . . . [he/she is] . . . talking to." He explicitly directed them not to "demonstrate to any sun employees or lawyers."

5.10 Bug-tracking system entry of May 12, 2008

A Google "Buganizer" entry list that Issue 1168987 is to "[r]emove j-word from everywhere." The notes to the entry state: "The problem is that we can't just find and replace java with dalvik. This has no functional impact but we need to make a call in terms of what extent we need to do this. Need feedback from arubin, hiroshi, and some combination of lawyers."

5.11 Gibson email of October 7, 2008

Ryan Gibson of Google wrote an internal Google email to Dan Bornstein, among others, noting that Dan had "stripped" "dirty words like 'Java' and 'J2ME' before SDK release."

5.12 Lindhom email of April 29, 2009

Tim Lindholm wrote an internal Google email about discussions with Sun about a partnership or support agreement. He stated that he wanted to avoid "inadvertently stir[ring] anything up for Android" and opined that Google should "step away" from the negotiating table with Sun "and only respond further if Sun chases after us."

5.13 Morrill email of September 28, 2010

Dan Morrill of Google sent an internal Google email discussing results of word search on Android code for the purposes of cleaning up that code. That word search included, "for obvious reasons: sun oracle* orcl Java jvm jdk jre Jcp jsr patent*" Dan Morrill stated: "Honestly I don’t think we can’t not scan for these. These represent ~50% of the total hits, so perhaps we can spotcheck this set, as we discussed."

5.14 Google-internal emails Of October 26-November 11, 2010

A group of Google employees sent various emails discussing scanning the Android code for references to "bad words" and finding that "biggest offenders are Java, License and Patent."

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+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|