Showing posts with label Sun Microsystems. Show all posts
Showing posts with label Sun Microsystems. Show all posts

Friday, December 8, 2017

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.

Share with other professionals via LinkedIn:


Monday, May 12, 2014

Refresher Q&A on Oracle v. Google after appellate ruling: this copyright case is NOT about $1 billion

This is my fourth post since Friday's Federal Circuit ruling that held 7,000 lines of concededly highly-creative Java API declaring code copyrightable. I reacted immediately to the decision and quoted the most important holdings; on Saturday I explained that this ruling was a spectacular comeback but not a surprise or novelty since the structure, sequence and organization (SSO) of computer programs has been copyrightable for almost a quarter-century; and on Google+ I showed that this blog, unlike any other online resource, was spot-on on five of the six most important smartphone IP decisions in the first half of 2014. (On this occasion, I would like to also give credit to Boston-based software and IP lawyer Lee Gesmer, who also discussed the possibility of Google losing this appeal ahead of the appellate hearing.)

Since some of the reporting reflects a fundamental misconception concerning what's at stake (by focusing on a billion-dollar damages claim that Oracle itself did not consider its first priority in the build-up to the 2012 trial) and given that I was one of a very few people not to lose track (out of sight, out of mind) of this case between the fundamentally flawed district court ruling and the appellate opinion, I thought this was the right time to provide a comprehensive, up-to-date Q&A. It is, however, too early to go into complete detail on the retrial. We'll cross the bridge when we get there. I'm happy to talk about it in very general terms already.

  1. Q: Do software developers and users in general, and Android app developers and users in particular, have to worry now that the pendulum has swung in Oracle's direction?
    A: No. No. No. The Federal Circuit has merely stated what has been the law for decades, and only the expressive aspects of Application Programming Interfaces (APIs) are copyrightable, not broader functional ideas. As for the Android-Java situation, we can rely on both companies' ability to resolve this situation in ways that make Android even stronger. Unlike Apple, Oracle is not waging a holy war against Android, but will be a big friend of Android once Google takes a license (the most likely outcome now). Android is the mobile Java platform now.

  2. Q: Is Oracle's copyright stronger than Apple's patents?
    A: Apple wants leverage over Google. Oracle now has it. But that is so only because Oracle's case, unlike Apple's patent assertions against Android, is truly about copying, not assertions of IP against independently-developed program code. In more than four years of Android litigation, Apple has not been able to show even one line of copied program code. Google never saw a need to negotiate a license with Apple before launching Android, but it was negotiating with Sun Microsystems about Java years ago, before it elected to infringe.

  3. Q: Could Google solve the problem by making another programming language, such as Go or Dart, the primary language for Android app development?
    A: It would have to change the API as opposed to replacing the programming language. The keywords and syntax of the Java programming language are free for everyone to use. This case is about the Application Programming Interfaces (APIs).

  4. Q: What are the next steps and how soon will the retrial take place?
    A: Google has already said it's considering its options. Given that Google will almost certainly request a rehearing (and potentially ask the Supreme Court to hear this case), a retrial is unlikely to happen this year, but the most likely year for this is 2015. A settlement may occur well ahead of a retrial, of course.

  5. Q: If and when the retrial takes place, who's going to prevail?
    A: In 2012, the jury was hung on "fair use" (it couldn't agree). After the Federal Circuit ruling, Oracle will be in far better shape than last time for procedural as well as substantive reasons.

  6. Q: Will the retrial be, in part, a billion-dollar damages trial?
    A: Oracle is seeking damages, but that's not the most important part, contrary to widespread misbelief. If Oracle was awarded a negligible monetary amount but an injunction, it would be in a better position to achieve its objectives (a license deal with Google) than if a jury awarded billions of dollars but the court denied an injunction.

  7. Q: What are the parties' business objectives in this dispute?
    A. Oracle once stated its intent to "bring Android back into the Java fold" by making Google comply with the Java rules the rest of the industry has accepted. Google seeks to defend the status quo: the use of Java material in Android without a license.

  8. Q: Does this litigation involve Google's rights to use certain Java code under an open source license?
    A: No. Google could have incorporated Java into Android on open source terms, but chose to eschew the GNU General Public License (GPL) because of its "copyleft" feature.

  9. Q: How do the parties' business models and intellectual property strategies with respect to software platforms compare?
    A: Google's approach to Android has amazing parallels to Oracle's approach to Java. The parties disagree only on how to deal with someone else's IP in a platform.

  10. Q: What ever happened to Oracle's patent assertions against Google?
    A: The district judge obligated Oracle to withdraw most of its patents. Two of the seven asserted patents were taken to trial and not found infringed. Oracle did not pursue those claims on appeal. Theoretically, patent assertions by Oracle against the Android ecosystem are still possible.

  11. Q: Is there a difference between U.S. and European law on software copyrightability?
    A: Copyright laws differ between jurisdictions, but commentators often overstate the scope of the opinion by the Court of Justice of the EU in SAS Institute v. World Programming, as I may explain in detail some other time.

1. Q: Do software developers and users in general, and Android app developers and users in particular, have to worry now that the pendulum has swung in Oracle's direction?
A: No, no, no. The Federal Circuit has merely stated what has been the law for decades, and only the expressive aspects of Application Programming Interfaces (APIs) are copyrightable, not broader functional ideas. As for the Android-Java situation, we can rely on both companies' ability to resolve this situation in ways that make Android even stronger. Unlike Apple, Oracle is not waging a holy war against Android, but will be a big friend of Android once Google takes a license (the most likely outcome now). Android is the mobile Java platform now.

Don't be fooled by the fear, uncertainty and doubt (FUD) strategies of those who are outraged that the Federal Circuit declined their invitation to misread long-standing statutory and Ninth Circuit law. They are now drumming up support for Google's very likely petition for a full-court review and Google's potential petition to the Supreme Court for writ of certiorari. They employed FUD tactics before (during the district court trial and after Oracle appealed), misleading some people to believe that anyone using an API to write apps for a platform would have to worry, which was never the issue. They still haven't come up with a better plan than FUD.

I'm an Android app developer and user myself and will now give you several reasons for which I believe Android will only become stronger if Google partners with Oracle. This doesn't mean to say that we app developers won't have to make some changes to our code if Google makes Android more Java-compatible as a result of all of this. I obviously can't guarantee you that this won't ever be necessary. I'm just saying that Android will continue to do well, and possibly even better, if Oracle becomes a strategic partner of Google's.

First, the Federal Circuit ruling is business as usual. In Johnson Controls, the Ninth Circuit decided back in 1989 that the structure, sequence and organization (SSO) of computer programs is copyrightable.

The sky isn't falling in the eyes of the software industry at large. Most major software companies, some directly and others through BSA | The Software Alliance, supported Oracle through amicus curiae briefs. Those companies have valuable software copyright holdings, but they also implemented other companies' Application Programming Interfaces (APIs) on various occasions. They are sophisticated enough to know that this cuts both ways, and they are comfortable with reasonable protection.

Google and its supporters argued that there was an industry expectation that APIs were not protected by copyright. Not only did the Oracle-supporting amicus briefs contradict that claim but the actual behavior of key players in the cloud computing space did so as well.

Second, some of the FUD (and the resulting panic) is based on inconsistent definitions of the term "API". Neither had Oracle submitted nor has the Federal Circuit ruled that "APIs" in the broadest sense of the term are protected by copyright. APIs have an abstract level, at which we're talking about broad ideas and concepts that can be protected only with patents, if at all. But they also have an expressive level: a creative SSO. Oracle's appeal was not about "APIs" in the broadest sense, but about a concededly highly-creative body of 7,000 lines of declaring code. It doesn't mean that minor, trivial subsets of that body, such as a definition of a function that determines the greater of two values, are copyrightable. Nor does it mean that Oracle's copyright in declaring code would prevent anyone from creating a Write-Once-Run-Anywhere (WORA) platform.

Third (and this is way more important than the third place suggests), if all you have is a hammer, everything looks like a nail, but there's a couple more tools available in this context. While something that isn't copyrightable is obviously free to use, non-copyrightability is not the only way to ensure free access. Fair use is also a powerful concept. I support Google on this one in connection with Google Books, but not its hijacking of Java (and I believe Oracle will prevail on this one on retrial, as I explain further below). In some other cases (for example, if someone just wanted to write programs for an existing platform), fair use would apply and result in free-of-charge access to APIs. That's why fair use is the better vehicle here: it depends on what someone does later with an API, while copyrightability must be determined based on what the original author created (before anyone could know what would be done later).

I'm not finished yet with the extremely important third point. Even if an implementer lost on fair use, it would not be the end of the story: if an antitrust argument of a dominant market position can be made, there is the possibility of a compulsory license on fair, reasonable and non-discriminatory (FRAND) terms. In fact, FRAND is mentioned in the Federal Circuit ruling. Without even a need to invoke antitrust law, Google could have received a license for a clean-room Java implementation on FRAND terms early on if it had decided to be fully compatible and to accept the other terms of such a FRAND license.

Fourth, the first three points were only about the law, but most of the time there won't be a legal controversy (not even outside the courts) in the first place because creators of APIs typically enable and encourage broad adoption since it's in their business interests. It's also in an API creator's business interest to enforce only reasonably. No one wants to scare their current ecosystem or behave in ways that make it hard to create and grow future ecosystems.

If Oracle keeps winning, Oracle and Google should ultimately reach a deal based on rational decisions on both sides. I can't predict their decisions, but these are extremely well-run companies. Oracle obviously has to seek impactful remedies because otherwise Google won't take a license. But it's not on a mission to destroy Android or anything like that. If Apple's patents were as strong as Steve Jobs mistakenly believed, it would definitely want to leverage them to regain market share from Android -- and Steve Jobs himself wanted "thermonuclear war" (according to his official biography) or a "holy war" on Google (according to an internal email). Apple has repeatedly taken the position in litigation that every Android device sold causes major harm to its business. That is not at all the case with Oracle once it has a deal in place with Google. Android is the only major mobile platform centered around Java, unlike iOS and Windows. Oracle apparently wants Google to become a good citizen of the Java ecosystem so as to reunite the Java community, and it wants to be compensated. However, I'm sure Oracle will take great care that Android emerge stronger, not weaker, from such a deal. I don't think Oracle will just maximize its piece of the cake: it will want Android to continue to grow.

2. Q: Is Oracle's copyright stronger than Apple's patents?
A: Apple wants leverage over Google. Oracle now has it. But that is so only because Oracle's case, unlike Apple's patent assertions against Android, is truly about copying, not assertions of IP against independently-developed program code. In more than four years of Android litigation, Apple has not been able to show even one line of copied program code. Google never saw a need to negotiate a license with Apple before launching Android, but it was negotiating with Sun Microsystems about Java years ago, before it elected to infringe.

As a strategic weapon, patents can be much more powerful than copyright. Copyright is narrow in scope. Patents are often not as broad as their owners claim (once there is a serious challenge to their validity, and claim construction by a court of law), but many software patents are indeed far broader than software copyright.

In the specific case of Oracle v. Google, it's not breadth that gives Oracle leverage (and the case has nothing to do with breadth of copyright, contrary to what some suggest). It's simply that Google has built Android in a way that the asserted Java API declaring code is a key building block. It elected to do so on a basis that the Federal Circuit found to constitute infringement (barring the affirmative defense of fair use, which is subject to a retrial). Now there's a million or so apps that make use of APIs Google (but not the Federal Circuit) thought were for the taking.

Look at it this way: the Great Wall of China is a huge building, but its existence is not a threat to your house. That's what software copyright is usually like: it's like real estate that belongs to someone else but that you don't have to worry about. Here, those Java APIs are like one wall of your house. If someone now argues that he owns that wall, then you're in trouble, not because of breadth but because you decided to use it.

Unlike in most software patent cases, the issue here is that the infringement occurred intentionally. Google knew that it was "perhaps making enemies along the way".

Of course, this infringement wouldn't really be an infringement -- or none that matters -- if Google had been right on copyrightability. But the Federal Circuit says it was not right, and after the appellate proceedings Google also faces a considerably steeper challenge with its "fair use" defense. The fact that Google took Java (as opposed to incidentally infringing a broad patent) gives Oracle a higher moral ground than, for example, Apple can claim. I also think Apple has a legitimate basis for enforcement, generally speaking. But Apple says "copying" when it means that others were inspired by the iPhone and independently developed creative imitations of certain features Apple was first to provide.

When Oracle complains about Google's use of Java, we're talking about actual, outright copying. In more than four years of Android litigation, Apple has not discovered a single line of program code stolen from iOS (it never claimed that there was, and due to differences in programming languages, the stolen code would have to be "translated" to other languages, but copyright also covers direct translations). Apple's infringement arguments were all based on abstract descriptions of functionality, not verbatim copying.

Google never negotiated with Apple or any other right holder I could think of before developing technologies for Android that later gave rise to IP infringement complaints. But it was negotiating with Sun Microsystems (which developed Java and was acquired by Oracle in 2010). And then decided to take its chances. That would have been acceptable if it had been in its right to do so. The district court cleared its behavior, and the Federal Circuit has reversed the district court ruling in part and remanded the rest.

In its disputes with Android device makers, Apple likes to argue (and this is not wrong in principle) that it shouldn't have to compete with products that infringe its own IP. Still, those competing products were developed independently. Apple is competing with what may sometimes involve implementations of its own ideas, but then those ideas are not necessarily patentable to the extent Apple believes (because of prior art). In Oracle's case, Java is simply unable to compete with Android, and Android includes what may be the most creative part of the Java codebase (as opposed to just another virtual machine-based platform).

I like Google a lot and find myself in agreement with it on many issues, but the Java thing must be rectified.

3. Q: Could Google solve the problem by making another programming language, such as Go or Dart, the primary language for Android app development?
A: It would have to change the API as opposed to replacing the programming language. The keywords and syntax of the Java programming language are free for everyone to use. This case is about the Application Programming Interfaces (APIs).

Just like the term "API" has divergent definitions, different understandings of what "Java" is (in the context of this dispute) also give rise to misunderstandings. The brevity of headlines and tweets compromises precision (that's also true of my headlines and tweets, of course).

If a tweet or headline says the appeals court allows Oracle to pursue claims over Java or held that Google infringed Java, it has nothing to do with the keywords and syntax of the programming language per se. Theoretically it would be possible to use all Java keywords and the Java syntax without implementing any API. One could start from scratch and write new APIs.

Google doesn't need to replace the Java keywords and syntax. If programming languages like Go or Dart used the same APIs, it would run into the same issues. As I said further above, copyright also covers translations of copyrightable material to other languages.

4. Q: What are the next steps and how soon will the retrial take place?
A: Google has already said it's considering its options. Given that Google will almost certainly request a rehearing (and potentially ask the Supreme Court to hear this case), a retrial is unlikely to happen this year, but the most likely year for this is 2015. A settlement may occur well ahead of a retrial, of course.

There are three things Google can do to pursue the cause of non-copyrightability. It can ask for a rehearing by the same panel of judges, an en banc rehearing (full-court review), or ask the Supreme Court to hear the matter (this is called a petition for writ of certiorari).

Petitions for a rehearing by the Federal Circuit often are requests for a panel rehearing and an en banc at the same time, though only one would be granted at most. Such petitions rarely succeed. In this case, the panel was unanimous. A rehearing by the same panel is a long shot to say the least. For an en banc the panel's unanimity also makes things harder, though not impossible. But it wouldn't be easy to convince the Federal Circuit, which doesn't deal with copyright cases too often, that this matter needs the attention of the entire appeals court. Even if a rehearing of some kind occurred, I doubt Google would get a better outcome.

Asking the Supreme Court for "cert" is something that Google could do, if only to further delay and create uncertainty while negotiating a settlement with Oracle. The Supreme Court does sometimes disagree with the Federal Circuit, but there really isn't any Supreme Court precedent that Google can claim the Federal Circuit decision was inconsistent with.

A company like Google that has to deal with many legal issues, including a number of very important ones, has to choose wisely the ones it wants to ask the Supreme Court to look at. Otherwise it would have to petition for cert every other month. I am absolutely convinced that Google would make a much smarter choice if it decided to play the Supreme Court card in connection with a couple of issues from the "Posner case" (Apple v. Motorola): injunctive relief over standard-essential patents, injunctive relief over non-SEPs, functional claiming, maybe also non-SEP damages. Considering (i) the importance of the issues to Google and its ecosystem (Samsung and other device makers), (ii) the fundamental conflict with Apple (and some other patent holders sharing Apple's related interests who aren't Google's best friends either), (iii) the fact that the Federal Circuit panel was divided in a way that very much invites a further appeal, and (iv) the fact that the Supreme Court may be more interested in, and more willing to support, Judge Posner's take on how to fix patent law (on what would definitely have nationwide impact) than Judge Alsup's wholesale adoption of Google's outlier non-copyrightability theory under Ninth Circuit law, I think the "Posner case" is a hands-down superior choice for a cert petition over the Oracle case, which Google could and should settle instead. Apple will never be part of the Android ecosystem (for as much as I like Steve Wozniak's suggestion that Apple, too, should build Android devices). Oracle will be a strategic partner. So Google should fight Apple and befriend Oracle.

Without a rehearing and a cert petition, I guess the Federal Circuit would issue a mandate to the district court in a matter of months, and the district court would then have to pick up the thread from 2012 and prepare a retrial. All in all, I guess the retrial is most likely to happen in 2015. But a cert petition could delay it (late 2015 or early 2016), and if the Supreme Court actually decided to hear the case, then 2016 becomes the most likely year for the retrial.

5. Q: If and when the retrial takes place, who's going to prevail?
A: In 2012, the jury was hung on "fair use" (it couldn't agree). After the Federal Circuit ruling, Oracle will be in far better shape than last time for procedural as well as substantive reasons.

Given that the retrial won't take place too quickly (though I guess Oracle will do all that it can to speed things up after the mandate issues), it's too early to discuss each and every detail of the "fair use" analysis in light of the appellate opinion. I've taken a clear position before (during the 2012 trial and between the appellate hearing and the appellate opinion): this is not a case of fair use. Hijacking can never be fair use, especially not transformative. I support Google on fair use in the Google Books context (where I was initially skeptical but after taking a closer look came down on its side). But not in connection with Java, where Android displaced mobile Java.

I do realize that many people now want to look at the "fair use" question again, given that it's the sole remaining defense for Google on remand. I've received requests on Twitter, for example.

I will probably do a whole series of posts on the fair use factors between now and the retrial. For the purposes of this Q&A, I am, however, prepared to explain in general terms why I think Oracle is in much better shape now.

I was much more accurate in my coverage of the 2012 trial than some others, who only appeared to have been accurate because the district judge erroneously agreed with them. But I admit that I was absolutely wrong on one thing: I thought the hung jury was due to a minority defending Google. Based on interviews with jurors after the trial, it turned out that it was actually just the jury foreman (who may have been smarter in this context than the rest of the jury) who declined to find in Google's favor. I have a high hit rate but it's not 100% and never will be.

But I'm optimistic I will be right next time and the fair use defense will fail. The Federal Circuit ruling has substantive and procedural implications, all of which will create a better factual and psychological basis for Oracle's efforts to overcome the fair use defense.

In substantive terms, the Federal Circuit made clear that Google stretches the envelope of "transformative" use, and suggested that any interoperability argument in the fair use context may have to be viewed on a package-by-package basis (37 packages are at issue). I will talk more about substantive aspects relevant to the fair use factors closer to the trial.

Google would have liked a retrial (which it ideally wanted to avoid in the first place) to be about infringement and fair use at the same time. But the Federal Circuit has directed the district court to reinstate the infringement findings and conduct further proceedings only with respect to fair use. This means the infringement finding (barring a successful fair use defense) is going to be law of the case. It's a safe assumption that there will be a fight over jury instructions, but those are not going to be great for Google in psychological terms because the law of the case is unfavorable now.

Google has also definitively lost its equitable defenses (it didn't appeal that loss). This means that on remand, Oracle will be able to seek exclusion of certain testimony and argument that was relevant to equitable estoppel and licensing-related defenses but will, arguably, be irrelevant to the narrow question of fair use. The Jonathan Schwartz testimony is one such example. It was really about equitable defenses and willfulness, but chances are that it influenced the jury in connection with fair use nonetheless. A stricter focus on the four fair use factors will benefit Oracle.

Both parties will optimize their fair use-related argument to the jury, and will likely get more time on fair use per se than last time. Knowing that the last jury, even though presumably due to some confusion and to jury instructions that were prejudicial to Oracle, nearly sided with Google, Oracle will presumably put a lot of effort into the fair use retrial.

With a view to further proceedings, whichever party loses the fair use retrial may appeal that one. On appeal they could raise issues with jury instructions, for example. But if Oracle prevails and then seeks an injunction, pressure on Google to take a license will grow.

6. Q: Will the retrial be, in part, a billion-dollar damages trial?
A: Oracle is seeking damages, but that's not the most important part, contrary to widespread misbelief. If Oracle was awarded a negligible monetary amount but an injunction, it would be in a better position to achieve its objectives (a license deal with Google) than if a jury awarded billions of dollars but the court denied an injunction.

I've already mentioned further above that various media reports mischaracterize this as a case that is about whether or not Oracle will get $1 billion. In January 2012, Oracle placed the emphasis more clearly than before (when it was already clear to me) on its push for an injunction. It is also seeking damages, and yes, these could amount to billions of dollars including willfulness enhancements. And if no injunction issued (which I think is hard to imagine here given the irreparable harm that has been caused), there would have to be postjudgment royalties, i.e., ongoing payments, which could also be substantial.

The biggest problem with a lot of the reporting is that it covers the trees instead of the forest. I recently stressed in connection with Apple v. Samsung II that, until the time of that post, mass media reports simply hadn't focused on the real issue in that dispute: workarounds. Apple can win all sorts of rulings, but as long as Samsung's products still look the same (or pretty much the same) to consumers, it won't slow down, much less stop the erosion of its global market share. In Oracle's case, monetary relief is definitely inadequate compensation for what Google did to Java. This is an injunction case much more so than a damages case, and the strategic value of an injunction far outweighs any damages claim the court would ever allow Oracle to present to a jury, even with willfulness enhancements (triple damages).

7. Q: What are the parties' business objectives in this dispute?
A: Oracle once stated its intent to "bring Android back into the Java fold" by making Google comply with the Java rules the rest of the industry has accepted. Google seeks to defend the status quo: the use of Java material in Android without a license.

Between the district court judgment and the appellate hearing, the two companies' CEOs blamed each other for the unresolved situation. In May 2013, Google CEO Larry Page said that a positive relationship wasn't possible because "money is more important to them than any kind of collaboration". Oracle didn't respond to that allegation, but in August 2013, Oracle CEO Larry Ellison reminded Google of its "Don't Be Evil" meme and said that "what they did [using Java in Android without a license] was absolutely evil". Mr. Ellison also called out Mr. Page on his personal responsibility.

There are disputes in which the only question is how much one party owes the other. If Oracle v. Google was one of those disputes that are only about money, I guess there would have been a settlement a long time ago. But this is really about two platforms: Java, which Oracle acquired as part of its $7 billion acquisition of Sun Microsystems, and Android, which lets programmers write apps in Java that generally won't run on Oracle's original Java. In January 2012, Oracle told the district court that it wanted "to bring Android back into the Java fold" (i.e., ensure true compatibility between Android and Java) and end "Google's lawless conduct". That allegation was based on the fact that Google was actually negotiating a Java license with Sun (before it was acquired by Oracle) and decided to go ahead and ship Android without a license. An order by the district court quoted the following October 2005 email by Android founder Andy Rubin:

"If Sun doesn't want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language - or - 2) Do Java anyway and defend our decision, perhaps making enemies along the way"

Google elected the second option, and by now Oracle has lost most of its Java business opportunity on mobile devices as a result of that. Java-based mobile platforms such as Blackberry and Nokia's Series 60 phones were extremely popular. By now, Android owns more than 80% of the worldwide smartphone market.

There are no signs of Oracle intending to cause harm to Android. Oracle's focus is on what it believes is best for Java, not on what is worst for Android. But Google wants to make its own rules. It's not just about whether Google would be willing to pay royalties (which it's not prepared to). For Google it's also about unrestricted autonomy. It wants to do with Java (and to Java) whatever it pleases. This, to Oracle, is fragmentation, which already had Sun worried back in 2007, shortly after Android was launched. It's of greater concern to Oracle what Google does with and to Java than whether and what it pays for using it (though that is also important).

After the Federal Circuit ruling it's really a risky game for Google to play if it still refuses to settle.

8. Q: Does this litigation involve Google's rights to use certain Java code under an open source license?
A: No. Google could have incorporated Java into Android on open source terms, but chose to eschew the GNU General Public License (GPL) because of its "copyleft" feature.

When Oracle filed this lawsuit in August 2010, it may have looked at first sight like a patent attack by a closed source software company on a piece of open source software. In its answer to the complaint, Google raised some open source issues that were presumably directed at the court of public opinion rather than the court of law. From the beginning Google has been playing the open source card, but it never had a formal defense based on its rights under the GNU General Public License (GPL), the free and open source software (FOSS) license under which Sun Microsystems published Java. In other words, Google put up an open source smokescreen and told an open source tale, but if you use software on open source terms and someone tries to prevent you from doing so, you raise a defense that says, "I am licensed under [whatever open source license] and I'm perfectly entitled to do what I'm doing!"

If Google had ever claimed in this litigation that Android's incorporation of Java was authorized under the GPL, this would have been inconsistent with its claim that it didn't use any copyrightable material (you can only license something, on whatever terms, if it's protected) and, far more importantly, a blatant violation of Rule 11 (truthful pleading standard) resulting in sanctions for Google and its counsel. The GPL affords you four freedoms: it allows you to use software without paying for it (freedom 0), to modify its source code as you please (freedom 1), to redistribute copies (freedom 2), and to distribute your modified versions to others (freedom 3). But once you exercise freedom 3, you're subjected to the copyleft rule: you must make your modified version available under the GPL. As a result, Google would have had to publish Android under the GPL. But it did not. Android builds on top of Linux, which is GPL'd, but Android itself is, according to Google, Apache-licensed. The Apache Software License 2.0 is a non-copyleft license and, therefore, absolutely incompatible with the GPL. You're lucky if you can run GPL and Apache software on top of each other (which can also raise complicated copyright and copyleft issues), but you certainly can't take GPL'd software, such as Linux, and release it under the Apache license.

As I'll discuss in more detail in the next section, Google seeks to exercise as much control over Android as possible. If Android had to be released under the GPL (and only under the GPL, or at least a compatible copyleft license), Google would have a hard time keeping a growing number of core Android components like its Mail and Map clients or even the new on-screen keyboard (again, more about that in the next section) closed -- and Google's hardware partners would have to release their proprietary enhancements such as Samsung's Touchwiz and HTC Sense under the GPL, which would run counter to their objective of differentiation because their competitors could then use the same code.

So there is no open source license-based defense. The closest thing to it that Google raised related to only a limited amount of code that it obtained under the Apache license. But that is also irrelevant. If I take software that I don't own and put it under an open source license without authorization, this still doesn't deprive the actual right holder of anything and, especially, doesn't allow third parties to use that software without a license from the actual right holder. Those third parties may, however, point to their reliance on what appeared to be an open source license in connection with the question of willfulness. Google never made that argument in connection with the program code that's really at issue (many thousands of lines of Java API declaring code): it obtained that one directly from Oracle's (Sun's) codebase, not indirectly through other parties or third-party open source projects.

9. Q: How do the parties' business models and intellectual property strategies with respect to software platforms compare?
A: Google's approach to Android has amazing parallels to Oracle's approach to Java. The parties disagree only on how to deal with someone else's IP in a platform.

It would be mistaken to believe that Google's Android business model is more permissive or more generous than Oracle's approach to Java. Let's face it: these two companies wouldn't be as wildly successful as they are if they acted like charities. Oracle acquired and has further invested in Java to make money with it; Google acquired and has further invested in Android to make money with it, too.

There are some differences, but there are also striking parallels. At the structural level (not getting into detail on how things are run), the Open Handset Alliance (OHA) is to Android what the Java Community Process (JCP) is to Java. Both Android and Java are available under open source licenses (Apache and GPL) as well as proprietary licenses. There are neat things that can be done and indeed have been done on an open source basis -- but both companies know that those seeking to make money with Android or Java will, not in all but in most cases, prefer a proprietary license.

Both companies also have in common that they fight fragmentation of their respective platforms.

The claim that Android is "free" and "open" is no longer taken seriously by anyone in this industry. If you're interested in a thorough, well-written debunking of that claim, I recommend this Ars Technica article entitled "Google's iron grip on Android: Controlling open source by any means necessary" (also, note what it says right below this headline: "Android is open--except for all the good parts"). Not even the current Android on-screen keyboard is open source...

If things had worked out differently between these two companies and they had developed Android together (or if they had co-developed Java, but it goes back to before Google was even founded), there wouldn't be a fundamental disagreement over what's desirable or undesirable with respect to a jointly-owned platform. However, Oracle has a tradition of respecting other companies' intellectual property rights (I can't remember any major IP infringement action against Oracle itself, obviously excluding what some acquisition target may have done prior to a takeover), while Google faces IP infringement allegations by major companies and organizations all the time. Google is defending itself very well so far, and that's positive for Android. But I sometimes feel it really likes to stretch the IP envelope...

In short, they don't disagree much on what each company wants to achieve with respect to its own platform, but they have a problem because of what Google wants to do with and to Oracle's platform.

10. Q: What ever happened to Oracle's patent assertions against Google?
A: The district judge obligated Oracle to withdraw most of its patents. Two of the seven asserted patents were taken to trial and not found infringed. Oracle did not pursue those claims on appeal. Theoretically, patent assertions by Oracle against the Android ecosystem are still possible.

Oracle originally asserted seven patents against Google, and at the early stages of this litigation it looked like more of a patent than copyright case simply because each patent was one "count" of the complaint, while copyright as a whole was only one more count. But item counting is never the proper methodology for establishing the relevance of issues in a case.

Oracle's patents-in-suit came under reexamination pressure. I must admit that I've lost track of those reexamination proceedings, but first Office actions are of rather limited relevance and even "final" Office actions tentatively "rejecting" a patent aren't truly final (as the examples of certain Apple patents such as the '381 rubber-banding patent -- key claims ultimately confirmed -- and the "Steve Jobs patent" -- all claims ultimately confirmed -- show). But Judge Alsup leveraged the state of affairs in those reexamination proceedings against Oracle, urging it to narrow its case for the jury lest the case would be stayed pending reexamination (i.e., for years).

In January 2012, Oracle proposed that the patent part of the case be severed and stayed in favor of a near-term copyright trial. This was the first public filing by Oracle in this entire litigation that demonstrated an unequivocal focus on copyright infringement issues.

Judge Alsup didn't adopt this proposal because he didn't want to have more than one Oracle v. Google trial. Oracle then had to withdraw most of its patents -- even with prejudice, which, by comparison, another (patentee-friendlier) federal judge in the same district, Judge Lucy Koh, did not require Apple and Samsung to do (they only had to withdraw patents without prejudice, allowing them to reassert them later). Ultimately, two patents were shown to the jury, which didn't find them infringed, though Google's own source code comments and file names clearly weighed against a finding of non-infringement with respect to one of them. The judge didn't overrule the jury, and Oracle is not pursuing those patents on appeal (one of them has expired and the other one was of relatively low commercial value).

Oracle's withdrawal with prejudice of five patents and abandonment of two other patents on appeal relates to Google, not to other parties, and even with respect to Google only to the patents-in-suit. Should any of those patents be confirmed at the end of reexamination (including appeals), Oracle would not be able to sue Google over them, but it could (and I have no idea whether it would want to do that) still sue Android device makers (even before the end of reexamination). It could also sue Google over other patents. Without speculating on the likelihood of this happening, I believe the successful appeal of the non-copyrightability holding makes copyright, not patents, an obvious priority for the further proceedings. I just wanted to point out that Oracle's preclusion with respect to patent assertions against Android isn't unlimited. That is another reason for which Google should settle.

11. Q: Is there a difference between U.S. and European law on software copyrightability?
A: Copyright laws differ between jurisdictions, but commentators often overstate the scope of the opinion by the Court of Justice of the EU in SAS Institute v. World Programming, as I may explain in detail some other time.

The district court appeared to take some potential interest in the European SAS Institute case, but its ruling has been reversed. This is not the time and place to go into details on SAS Institute. Suffice it to say that what it said was blown out of proportion by many people. Maybe I'll talk about it some more on some other occasion.

But Oracle v. Google could have worldwide effects. While the Federal Circuit opinion in Oracle v. Google isn't formal precedent for other jurisdictions, it will be interesting to see how judges outside the U.S. view software copyrightability. In principle, it would make sense in other jurisdictions as well to focus in a copyrightability analysis on how creative the original author was as opposed to whether concededly highly-creative declaring code later serves an interoperability purpose. There are similar concepts as fair use in other jurisdictions. There are compulsory licensing options in all jurisdictions to remedy extreme cases with the help of antitrust law. The Federal Circuit opinion may inspire non-U.S. courts as well to decline invitations to adopt "if all you have is a hammer" type positions and to address interoperability on a case-by-case basis (based on exactly how someone makes use of interoperability-related code).

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Share with other professionals via LinkedIn:


Saturday, May 10, 2014

In Java case, Federal Circuit just declined to hold massive body of creative stuff non-copyrightable

Within the context of the "smartphone IP wars", yesterday's appellate opinion in Oracle v. Google was spectacular. An unprecedented comeback. Oracle now has more legal leverage over Google than anyone else, such as Apple, has ever had, even at this stage, where things may still take a couple of years before an injunction issues (and, of course, there is some uncertainty remaining with "fair use", though the Federal Circuit made certain limits of that defense clear as well).

But "spectacular" doesn't mean "novel". Let's be clear about that. About two years ago I already wrote that "Oracle v. Google can't MAKE APIs copyrightable -- they HAVE BEEN for more than 20 years". In that post I referred to the Johnson Controls case, which the Federal Circuit also referenced several times in its decision.

This morning I read -- cursorily for the most part -- various comments, including reports on the decision by media that are usually nonjudgmental, and I felt that some people were living in a parallel universe. This includes some of the people who unjustly bashed me after the erroneous district court ruling in 2012 because they didn't realize I had been consistent on copyright in the interoperability context for a long time -- going back to 2004, in fact, in connection with Blizzard v. bnetd (a client-server DMCA case).

Now they can't bash me because I was simply right. So whom are they bashing? The Federal Circuit. They still believe Judge Alsup (whom I respect but nevertheless disagreed with on some issues, particularly copyrightability) got it right. There's all this glorification. Yes, based on what I read from him (his filings) and about him, I have no doubts that he's an interesting, in many ways impressive person. But that doesn't make him infallible. His position on copyrightability wasn't even original: he simply adopted everything Google's counsel told him. And now the Federal Circuit has agreed with Oracle on each copyrightability-related point.

One may dislike the fact that the Federal Circuit generally supports intellectual property protection, and maybe does to a greater extent than some other courts. That's OK. What's not OK is to vilify and disrespect that extremely competent court. The circuit judges deal with technical issues every day because their court hears all U.S. patent appeals from district court rulings. Day in and day out they rule on claim construction (interpreting patents), infringement and non-infringement theories, invalidity contentions (comparing patents to prior art). And the decision was reached unanimously by a panel of three judges -- not just one, such as in the district court. I wouldn't even want to claim that these judges are better than Judge Alsup because they serve on a higher court -- if Judge Alsup had been appointed to the Federal Circuit (which depends on many things besides someone's capabilities) and had served on it for a number of years, I have no doubt at all that he'd be a well-respected circuit judge by now. But it would be ridiculous to assume that circuit judges are inherently less smart than district judges.

Judge Alsup became extremely popular in tech media (as a side effect, most likely unintended) and activist circles by saying that he learned to program Java because of this case. I'm also a programmer (by the way, the U.S. patent application I filed this week includes roughly 100 pages, much more than the average patent application, of sample code I wrote in C#, which is very much like Java), so I, too, liked to hear that. But then he issued that erroneous non-copyrightability ruling, and when I read it, I must say with the greatest respect that it did not look to me like something written by a programmer (I'm not saying he didn't learn Java, just that the ruling didn't reflect the related knowledge). One key issue with it was that he conflated the freely-available Java programming language (commands/keywords) with the APIs. By contrast, the Federal Circuit showed how to get that part right. The circuit judges made a clear distinction in yesterday's decision between APIs that may arguably be needed to even implement the free programming language per se (maybe three of them, maybe a little more) and those that are not tantamount to programming language keywords. That is the degree of analytical precision and accuracy that I missed in the district court decision, and I found it in the Federal Circuit opinion. I, as a long-time programmer who wrote ten computer books while in high school, found nothing whatsoever in the Federal Circuit opinion that suggested a lack of understanding of software technologies. But all sorts of people out there now blame the Federal Circuit for not having understood the technical part. That is outrageous.

Let's now get to the real issue, which is the substance of the decision(s) at issue and not the competence of the decision-makers (which others chose to make a big issue in the public debate, without any factual support).

The next major fallacy on the part of those who criticize the appellate opinion is that they substitute their policy views for where the law (statutory law and applicable case law) stands. That's common. Software patent-eligibility is a context in which it's particularly extreme. Anybody with a modicum of knowledge and the ability to shut out ideology can see that U.S. statutory law on patent-eligibility is expansive and inclusive, so the only way to create restrictions is through new legislation. Nevertheless, one effort after the other (recently, CLS Bank) is made to persuade judges to legislate from the bench. And when judges provide minor clarifications that move the goal posts by a quarter of an inch, some people claim that they've been moved by a mile.

The Federal Circuit would have had to legislate from the bench to an extreme extent in order to concur with Google and its supporters. It declined to do what it's simply not supposed to do. It focused on its job, which is to interpret and apply the law as it stands. Isn't it absurd that people who have an important job to do and decide to do that job -- but refuse to do a job no one elected or appointed them for -- then get bashed? Maybe all three circuit judges should have said at the hearing that they learned Java for this case. No one could have proved the opposite, and some people might not criticize the circuit judges now. But they focus on their job. Not on PR stunts. Not on currying favor with activists. They deserve praise, not insults, for their focus on the real thing.

If the Federal Cicuit had affirmed the district court's non-copyrightability ruling in this case, it would have become the first appeals court in the U.S to hold a massive body of (highly) creative, original material not to be protected by copyright.

The people who say that this ruling makes new law are unable -- they don't even try -- to point to appellate decisions in the U.S. that held anything comparable to Java in both creativity and magnitude to be devoid of copyright protection.

Even before API copyrightability became an issue in Oracle v. Google (in the early stages of the dispute it was just known to the general public that the case involved a copyright infringement claim, but not what it related to other than one sample file Oracle provided relatively early on), I talked about it on this blog (in connection with Linux and other copyleft software, in early 2011), and I looked at a number of cases that are now mentioned in the Federal Circuit opinion and some additional ones that were addressed in various briefs and in the district court proceedings. There's no shortage of U.S. appellate case law that held some stuff non-copyrightable because obviously there were always some people who tried to expand the scope of copyrightability in unreasonable ways. But every single one of those non-copyrightability holdings by appellate courts relates to fact patterns that are easily distinguishable from the 7,000 lines of Java API declaring code that Google conceded was highly creative and that it also conceded it had literally copied. Yes, this is a real case of copying, unlike Apple v. Samsung II, where copying was just a red herring that Apple used, with very limited success in the end.

7,000 lines of concededly highly-creative material -- this involves a combination of a quantitative criterion and a qualitative one. You won't find that combination in any of those other cases except when -- and this is just about fair use, not copyrightability -- all that was allowed was intermediate copying (making a few copies for internal development purposes, such as reverse engineering).

There was Lotus v. Borland, about a spreadsheet menu structure that Google's counsel admitted (at the appellate hearing) was not comparable to the Java material because it was so much smaller and simpler. At any rate, the Supreme Court was divided over that one.

A long, long time ago there was Baker v. Selden, where someone wanted a book on an accounting method to result in a monopoly over that method. But owning copyright in a text is different from owning every application of what the text teaches.

In Feist v. Rural, it was made clear that "sweat of the brow" is not a criterion for copyrightability. A phone directory may take a lot of work to put together, but ultimately it's just real-world data -- not original stuff of the kind that Sun Microsystems' engineers created when they wrote those APIs.

In Sega v. Accolade, all that was allowed was a combination of intermediate copying for development purposes (unlike taking stuff and building it into a new product that is distributed, which is what Google did when it hijacked Java for Android) and the copying of 20-25 bytes of code that only served as an identification (like an internal password) that was necessary to make games run on a console. 20-25 bytes. Not 7,000 lines.

So you can find non-copyrightability holdings by U.S. appeals courts for

  • vast quantities of non-original stuff (telephone directories etc.),

  • tiny quantities of original stuff (20-25 bytes, for example), and

  • small quantities of low-creativity stuff (spreadsheet menu structure, and even that one was affirmed only by a divided Supreme Court).

Nothing like the Java APIs.

Both Sega and the subsequent Sony v. Connectix case -- fair use and not copyrightability cases -- did not establish an interoperability exception to copyrightablity, as the Federal Circuit clarified but Google's supporters still don't want to recognize. I already addressed that one two years ago. The problem with reading Sega (which Sony is based on) as holding anything related to compatibility to be non-copyrightable is that this is not even an obiter dictum. It's simply not stated at all unless one takes a few words out of context.

Unless we all want total chaos, there must be a reasonable standard for what is res judicata, an issue that a court actually decided. The standard for what is an obiter dictum (something mentioned beyond the actual decision but expressing an opinion) is lower, but the "interoperability exception" thing does not even meet a reasonable dictum standard if you and I agree that even something that someone claims was said incidentally in a decision must at least be said with a minimum degree of clarity and specificity.

In Sega, interoperability was considered a laudable goal. Yes, it is. That fact weighs in favor of fair use. In that case, it did. Rightly so. So if you only do a few intermediate copies for yourself and you copy 20-25 bytes (a mere identifier), and that's what it takes to bring more games to consumers for a platform they've purchased, that may be fine. In that case, it was. Rightly so. But the Ninth Circuit (the West Coast circuit) didn't say that anything relating to compatibility -- which would require some very complex line-drawing if it was the law (which it is not) -- is by definition non-copyrightable. Every piece of software (including Java, as Oracle never disputed) involves ideas and functionality of the non-copyrightable (perhaps patentable, but not copyrightable) kind. §102(b) of U.S. copyright law ensures that copyright protection does not extend to those ideas and functions, but the expression is protected. So the Ninth Circuit said that Sega's software involved such higher-level ideas and functions, it can't protect those with copyright, and it's fair use to make a few internal copies to research that non-copyrighted functionality, and the justification for research is (in this particular case) that interoperability is a laudable goal. It didn't refer to what kind of code it is: object code, source code; instructions or declarations; textual or binary. Undoubtedly, Sega's software, like anyone else's software including Oracle's software, embodies concepts that fall under §102(b). But it's not even a dictum, much less res judicata, without a minimum of specificity. If one doesn't specify what §102(b) relates to, then the broadest interpretation would simply deprive all software of copyright protection, which without a doubt none of the Ninth Circuit judges intended.

So there is neither any applicable case law in the U.S. that holds a Java API-like combination of quantity and quality (originality/creativity) of material non-copyrightable nor is there an interoperability exception to copyrightability in the Ninth Circuit.

The full Federal Circuit (a petition for an en banc review is a given) or the Supreme Court couldn't and wouldn't create such an exception either. Google and others who want this have to talk to Congress. They don't even seem to try this, presumably because they know it won't happen since the software industry is overwhelmingly on Oracle's side.

Then don't blame the Federal Circuit for doing its job. The Federal Circuit opinion is extremely well-reasoned and, as I said, reflects an accurate understanding of how programming languages and APIs work. Unfortunately, many of those who have commented on it and will comment on it going forward may not even have read it in the first place. They just don't like the 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+.

Share with other professionals via LinkedIn:


Friday, May 9, 2014

Oracle wins Android-Java copyright appeal: API code copyrightable, new trial on fair use

The most spectacular decision in the ongoing smartphone IP disputes has been handed down today by the United States Court of Appeals for the Federal Circuit: District Judge William Alsup has been overruled with respect to his erroneous determination that Oracle's Java API declaring code was not protected by copyright. Since the 2012 jury was hung with respect to "fair use", which means that neither party had prevailed on that defense, the case is now remanded to the United States District Court for the Northern District of California for a new trial on fair use and damages.

I disagreed with Judge Alsup on copyrightability all the way. I have been in favor of reasonable copyright protection for creative API-related material for more than ten years. Based on the official recording of the appellate hearing on December 4, 2013, I predicted this reversal of the non-copyrightability ruling and explained in another post why it was good news for software developers large and small. Reporters who attended the appellate hearing had also expected this outcome.

The Federal Circuit rejected Google's merely tactical cross-appeal relating to eight decompiled Java files (most of which were published by this blog before they showed up in any public court filing) and the nine-line "rangeCheck" routine.

Key holdings by the Federal Circuit:

  • The appeals court makes a clear distinction between the Java programming language (i.e., the commands/keywords that are free for everyone to use) and the APIs, and finds that only three of the Java APIs in question are basically part of the Java language, but "Google could have written its own API packages using the Java languages", which, as the opinion notes, "Google chose not to do".

  • "We are mindful that the application of copyright law in the computer context is often a difficult task. [...] On this record, however, we find that the district court failed to distinguish between the threshold question of what is copyrightable--which presents a low bar--and the scope of conduct that constitutes infringing activity. The court also erred by importing fair use principles, including interoperability concerns, into its copyrightability analysis."

  • "[W]e conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection."

  • This part is key for copyright law practitioners (I also mentioned this in my post-hearing commentary):

    "Although the parties agree that Oracle's API packages meet the originality requirement under Section 102(a), they disagree as to the proper interpretation and application of Section 102(b). For its part, Google suggests that there is a two-step copyrightability analysis, wherein Section 102(a) grants copyright protection to original works, while Section 102(b) takes it away if the work has a functional component. To the contrary, however, Congress emphasized that Section 102(b) 'in no way enlarges or contracts the scope of copyright protection' and that its 'purpose is to restate . . . that the basic dichotomy between expression and idea remains unchanged.'"

  • This part is pretty damning for the district court:

    "Oracle asserts that all of the trial court's conclusions regarding copyrightability are erroneous. Oracle argues that its Java API packages are entitled to protection under the Copyright Act because they are expressive and could have been written and organized in any number of ways to achieve the same functions. Specifically, Oracle argues that the district court erred when it: (1) concluded that each line of declaring code is uncopyrightable because the idea and expression have merged; (2) found the declaring code uncopyrightable because it employs short phrases; (3) found all aspects of the SSO devoid of protection as a 'method of operation' under 17 U.S.C. § 102(b); and (4) invoked Google's 'interoperability' concerns in the copyrightability analysis. For the reasons explained below, we agree with Oracle on each point."

    Each point. Wow.

  • The Federal Circuit disagrees with the district court and Google (the district court had basically just adopted Google's fundamentally flawed non-copyrightability argument, which is why it just got overruled) on the point in time at which the theory of a "merger" (of idea and expression) has to be determined. Google argued that it had only one way to write those API declarations -- but that's because it chose to be similar to Java in certain (and not all) respects. But this way Google limited its own choice. It could have create completely new APIs for Android. The question in a copyright case is, however, not whether the copyist had choices. It's whether the creator of the copied material had options. And Sun's engineers (Java was developed by Sun, which was acquired by Oracle in 2010) had plenty of choices. The Java APIs were and are creative and original. And that's why they are protected. Otherwise something could be protected by copyright when it's written and then lose copyright protection later because someone choose to copy -- that would be absurd.

  • A very common misconception in the API copyrightability context is that many people think the short names used in declaring code (mostly method and variable names) render that code uncopyrightable. But it's not the short names per se that are covered by copyright. The Federal Circuit clarifies this:

    "By analogy, the opening of Charles Dickens' A Tale of Two Cities is nothing but a string of short phrases. Yet no one could contend that this portion of Dickens' work is unworthy of copyright protection because it can be broken into those shorter constituent components. The question is not whether a short phrase or series of short phrases can be extracted from the work, but whether the manner in which they are used or strung together exhibits creativity."

    To me this has always been clear. Any creative work can be broken up into small parts that are not copyrightable on their own. For example, a copyrightable composition consists of single notes, but no note on its own is copyrightable. This blog post here is copyrightable as a whole, and so are many smaller parts of it on their own, but that doesn't mean that every word or short phrase in it is covered by copyright.

  • It's very important that the Federal Circuit agreed with Oracle and disagreed with Google on the applicability of the Lotus v. Borland ruling on menu structures in the Ninth Circuit (the West Coast circuit). According to the appeals court, Lotus is at odds with Ninth Circuit law.

  • "If we were to accept the district court's suggestion that a computer program is uncopyrightable simply because it 'carr[ies] out pre-assigned functions,' no computer program is protectable. That result contradicts Congress's express intent to provide copyright protection to computer programs, as well as binding Ninth Circuit case law finding computer programs copyrightable, despite their utilitarian or functional purpose. Though the trial court did add the caveat that it 'does not hold that the structure, sequence and organization of all computer programs may be stolen,' [...], it is hard to see how its method of operation analysis could lead to any other conclusion."

    This means the Federal Circuit agrees with former U.S. copyright chief Ralph Oman who warned in his amicus curiae brief that the district court ruling "eviscerates" copyright protection for computer software.

  • "Google's Interoperability Arguments are Irrelevant to Copyrightability"

    That's the headline of the section in which the Federal Circuit holds that the district court made a mistake by applying the Sony and Sega cases (see my commentary on those cases from two years ago), which were fair use cases in the Ninth Circuit that involved interoperability considerations, to the question of copyrightability. If you read the post I just linked to and compare it to the Federal Circuit opinion, you'll see that the appeals court's view of those cases is very similar to mine. Here's my favorite quote from that part of the ruling:

    "We disagree with Google's suggestion that Sony and Sega created an 'interoperability exception' to copyrightability."

  • "given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google's interoperability argument confusing. [...] The compatibility Google sought to foster was not with Oracle's Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue."

  • A goodie for FRAND friends:

    "Notably, even when a patented method or system becomes an acknowledged industry standard with acquiescence of the patent owner, any permissible use generally requires payment of a reasonable royalty, which Google refused to do here."

  • With respect to fair use, Oracle would have liked a "hole in one" here with the Federal Circuit reversing the non-copyrightability finding and resolving the "fair use" question as a matter of law. But the circuit judges found that "due respect for the limit of [their] appellate function requires that [they] remand the fair use question for a new trial". They do express sympathy for various of Oracle's arguments against Google's fair use defense, and they do indicate that Google stretched the meaning of fair use (for example, "Google overstates what activities can be deemed transformative under a correct application of the law"). But the Federal Circuit concluded that some factual questions remain to be resolved on remand. In particular, now that it has been clarified that interoperability is not relevant to the copyrightability analysis, it may still play a role in connection with fair use. But the Federal Circuit opinion suggests that interoperability may play a role for only a limited number of Java API packages. The retrial is going to be all about fair use, and it will be interesting, but Oracle is in reasonably good shape based on the Federal Circuit opinion, which will limit Google's arguments in the retrial.

  • The Federal Circuit rejects Google's and the district court's suggestion that Oracle was basically using copyright law instead of relying on patent protection. The Federal Circuit is the U.S. patent court -- it hears all U.S. patent appeals from district court decisions. And its opinion clearly supports that software can be protected by copyright law and patent law at the same time (with different aspects being protected by the different types of intellectual property rights, of course):

    "Until either the Supreme Court or Congress tells us otherwise, we are bound to respect the Ninth Circuit's decision to afford software programs protection under the copyright laws. We thus decline any invitation to declare that protection of software programs should be the domain of patent law, and only patent law."

It's a given that Google, given the high stakes, will ask for an en banc rehearing. But since the panel was not divided at all, I doubt that a full-court review would lead to a different result. This appellate opinion is extremely convincing. Google can, of course, try to appeal this case to the Supreme Court. Maybe it will bring a petition for writ of certiorari. But such a petition should be denied because the Federal Circuit ruling is absolutely consistent with Supreme Court law. In any event it will take some more time before a mandate issues to the district court. And then there will be further proceedings, which I look forward to. Or there may not be further proceedings if Google recognizes that Oracle is now on the winning track, and finally takes the license it was already negotiating years ago. That would be the most reasonable outcome.

BusinessInsider quotes Oracle's statement on today's decision (and has asked Google for comment as well, which it received later and which I disagree with).

This reversal-in-part is a huge win for Oracle and its appellate counsel, a team of Orrick Herrington & Sutcliffe lawyers led by Joshua Rosenkranz and Mark Davies. Mr. Rosenkranz has previously been dubbed the "Defibrillator" for reviving lawsuits on appeal after losses in district court. He did it again. (He was also very successful on Apple's behalf in two Motorola cases, the "Posner appeal" and Apple's appeal of the ITC's dismissal of its complaint against Motorola.)

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Share with other professionals via LinkedIn:


Tuesday, May 28, 2013

Google says Java APIs lost copyrightability like Aspirin lost trademark protection over time

This afternoon by Eastern Time the public version of Google's brief in the cross-appeal of a district court's Oracle v. Google Android/Java copyright ruling finally became available. The brief itself had already been filed on Thursday. It's considerably longer than Oracle's opening brief (counting from "Introduction" to the date of filing, Oracle's brief consisted of 14,702 words, while Google's brief has 17,488 words -- 19% more). Here's the 100-page filing (this post continues below the document):

Google Brief in Oracle's Copyright Appeal

I've identified one argument in Google's brief that raises an interesting issue, and I'm really curious to see Oracle's response to that one in its reply brief. Google says that Oracle can't now, on appeal, claim copyrightability for anything other than the structure, sequence and organization (SSO) of the Java APIs, which is how the case was put before the jury, allegedly without Oracle objecting to it. Google says Oracle can't argue now that the 7,000 lines in question are copyrightable ("Oracle does not get a second bite at the apple if its SSO claim fails"). This is a potential obstacle. Oracle may or may not have to overcome (if the SSO of the asserted APIs is found copyrightable, that issue won't be reached). But most of what Google says in its defense of Judge Alsup's ruling, which a former U.S. copyright chief says "eviscerates" protection for software, is simply besides the point if the appeals court disagreed with Google in only three ways:

  1. Google raises arguments in the copyrightability context that may be more appropriate, if at all, in the "fair use" context or perhaps a compulsory-licensing context under antitrust law. The example I mentioned in the headline of this post is typical:

    "[T]o the extent that merger occurs because a program element becomes an industry standard, the loss of intellectual-property protection over time is nothing new. The same issue arises when a formerly distinctive trademark like 'Aspirin' or 'Thermos' eventually becomes a descriptive, generic designation that competitors 'must be free to use if they are to be able to enter the market.'"

    It's quite a leap to apply this logic from trademark law to copyright law, and last time I checked Oracle didn't assert the Java trademark against Google.

    Many of Google's key arguments in the copyrightability context will be irrelevant if the Federal Circuit determines that what's copyrightable is copyrightable, and always will be, for substantive reasons.

  2. Google's lawyers' favorite word is "dictated" as in "dictated by an external factor" or "dictated by the function to be performed". That's a cornerstone of Google's anti-copyrightability argument: functional elements must be filtrated out regardless of how original or creative they are, and Google continues to claim that interoperability is a reason for denying copyrightability. In addition to the previous point (separating fair use and compulsory-licensing questions from copyrightability), the whole notion of 7,000 lines of API definitions being "dictated" makes no sense whatsoever if the appeals court determines that what matters for copyrightability is the creative freedom Oracle/Sun enjoyed when originally creating Java -- as opposed to the freedom Google enjoyed after it decided that it wanted to attract many Java programmers to Android.

  3. Google's brief relies (not only, but primarily) on three cases with respect to copyrightability: Sega v. Accolade, Sony v. Connectix, and Lotus v. Borland. Google has a problem if the Federal Circuit, unlike Judge Alsup, finds them inapposite because Sega and Sony are fair use cases that don't provide any detailed copyrightability analysis that would help decide the Android/Java case, and because Lotus was about a menu structure (very small and simple compared to the Java APIs).

Seriously, if the appeals court viewed the above three items the way I described (and would consider correct), then there wouldn't be much left of Google's appellate argument with respect to copyrightability. And Google recognizes in its brief that the Federal Circuit might side with Oracle on copyrightability, in which case it at least wants a second jury trial on "fair use", which it then also wants to become a retrial of API copyright infringement:

"if the Court reverses the copyrightability judgment, it should direct the district court on remand to retry Google's fair-use defense (as well as the inseparable issue of infringement)."

This may be a useful reminder to all those who, even in recent months, erroneously wrote in articles and commentary that Oracle had lost in district court on two grounds, copyrightability and "fair use" -- in reality, "fair use" was simply not resolved because the jury was hung, and once Oracle prevails on copyrightability, it will have to be resolved somehow: by the appeals court, by the district court, or by another jury. As long as Oracle hasn't prevailed on this count, it can't get an enforcement ruling, but as long as Google hasn't prevailed on it either, this particular defense hasn't succeeded.

This case is far from over, and Google has to deal not only with Oracle's opening brief but also some highly informative and persuasive amicus curiae briefs (overview of amici, former U.S. copyright chief's warning against eviscerating protection for software, Sun founder's submission explanatory filing by academics regarding API creativity, filings by organizations representing creatives).

After this bird's-eye view on Google's argument I'm also going to quote and comment on a few more passages:

  • "The Java Application Programming Interface ('API') is not a work of imaginative fiction."

    This is an allusion to the Ann Droid/Harry Potter analogy in Oracle's opening brief. Google's brief also mentions Harry Potter in a couple of contexts, claiming that fictional works are different. I don't think Oracle denied differences at the creative level, but Oracle's Harry Potter analogy is mostly about the commercial implications of plagiarism (at least that's the way I understood it).

  • "[Harry Potter's] chapter headings and topic sentences exist entirely for communicative and aesthetic purposes--not to 'bring about a certain result' when used in a computer."

    If everything that brings about a certain result when used in a computer were excluded from copyrightability, no software would ever receive protection.

  • "Oracle accuses the district court of practicing 'software exceptionalism'--discriminating against software by granting it less protection than other works. But it is Oracle that seeks an exception here by asking the Court to excuse the Java API from the normal rule of 'thin' protection for functional works."

    I would agree with Google on this one if, for example, Oracle claimed that a single function definition like for the "max" function should be copyrightable. In that case, copyright trolls would give programmers far more headache than patent trolls because software copyright would then be as broad as the broadest patents, or even broader. But Oracle only argues that thousands of lines of API definitions aren't for the taking. In my view, even "thin" protection has scope for this.

  • This is how Google states its cross-appeal issue, the eight decompiled test files and nine lines of rangeCheck code:

    "Was Google's use of eight decompiled test files and nine lines of rangeCheck code de minimis and thus non-infringing when compared to the 2.8 million lines of code in the class libraries of the registered Java 2 SE version 5.0 platform?"

    I'm not going to defend the rangeCheck decision, and frankly, I don't care about it too much. As for the eight test files, I believe those are protected, and the comparison to the overall number of lines of code is problematic: if a huge computer program had, say, 28 million lines of code (not 2.8 million), does this mean that one could copy 80 files from it? Or wouldn't it make more sense to look at what's copied and determine whether it's copyrightable in its own right?

  • Google argues that Sun had to make Java freely available because "Sun and its collaborators, including Oracle, recognized that they could not accomplish these goals by creating another proprietary platform, which Microsoft would dwarf". Whatever Sun's motives, strategies and competitive challenges were, the primary question in this appeal is copyrightability, which is unrelated to it, and even "fair use" is different. This here is perhaps relevant to equitable defenses, and the jury verdict didn't work out well for Google in that regard.

  • Google quotes from the district court's ruling the holding that "there is no bright line between the language and the API". Let's assume for the sake of the argument that there is no bright line. This still doesn't mean that any arbitrarily-chosen number of APIs is for the taking. It would have to be shown for each copied API why it really constitutes part of the Java language.

  • On page 14 Google's brief cites the declaration for the "max" method:

    public static int max(int arg1, int arg2)

    Google then says "[t]he 'max' method is just one of many", but the majority of Java API functions are quite different from "max" in terms of the freedom Java's creators enjoyed when designing the Java APIs. Considering that a group of academics had filed an amicus brief explaining in connection with the task of drawing a circle how an API could provide different functions having the same effect, I was surprised that Google would base its appellate argument on an exceptionally simple function like "max". If I were a Federal Circuit judge and read this, I would really wonder why they don't counter what those computer science professors wrote about creative choices in API design. It looks like Google doesn't think it can win the debate if one also looks at more interesting functions than "max". But I doubt that the appeals court is going to base its decision only on a function like "max".

  • Here's a passage that I think highlights very well the conflation of copyrightability and "fair use" arguments that is typical of Google's brief:

    "The district court committed no clear error in finding that the command structure of 37 Java API packages is functionally necessary (1) to achieve compatibility with programs written in the Java Programming Language and (2) to access, control, and use the Java class libraries."

    This is the second one of the three points I listed further above on which the appeals court might disagree with Google, in which case there wouldn't be much left of its anti-copyrightability argument. If the relevant point in time for copyrightability is when Sun created Java, then the alleged needs to achieve compatibility (didn't Apple make the iPhone a huge success without being Java-compatible?) and to access, control and use Java class libraries don't matter because they're Google's problem and didn't constrain the creativity of Java's creators.

  • "Oracle and its amici also argue that interoperability is 'all or nothing': to achieve it, Google must implement all 166 Java packages and Android must run all existing Java programs."

    I'd like to know what Google would do if, for example, Samsung decided to depart from the Android standard and used some of the APIs but mostly different ones. In that event Google might suddenly become a fervent supporter of API copyrightability -- or at least regret its stance in the Oracle case.

Later this week, or early next week, we'll see some filings by amici curiae supporting Google. I will discuss those filings as well.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Share with other professionals via LinkedIn: