Google Wins Java Copyright Case

Posted on April 5, 2021 by Paul Thurrott in Dev, Google, Android with 18 Comments

The U.S. Supreme Court ruled today in Google v. Oracle and sided 6-2 with the online giant in determining that its copying of Java code constitutes fair use.

“We assume, for argument’s sake, that the material [Google copied] was copyrightable,” the ruling notes. “But we hold that the copying here at issue nonetheless constituted a fair use. Hence, Google’s copying did not violate the copyright law.”

Oracle acquired Sun Microsystems, the original owner of Java, in 2009, and cited the programming language as one of the firm’s key assets. But despite a pledge to “continue innovation and investment in Java technology for the benefit of customers and the Java community,” Oracle quickly turned on Google, whose Android mobile platform is arguably the biggest consumer of Java technology. It continued a lawsuit against the online giant that was first launched by Sun, alleging that Google “copy and pasted 11,000 lines of Java code” in creating Android.

Google admitted to this copying in 2016, but a series of court battles in the ensuing years muddied things. A federal jury decided in 2012 that software code is not protected by U.S. copyright laws, but that ruling was overturned two years later on appeal. Then, another jury found in 2016 that Google’s use of Java was legal under the fair use doctrine. That decision was likewise overturned on appeal, in 2018.

In January 2019, Google turned to the U.S. Supreme Court, and the Court agreed to hear the case the following November. The first filings were submitted in January 2020.

Google asked the Supreme Court to consider two questions: Whether the Java APIs it copied are copyrightable in the first place and whether Google’s use of those APIs in the creation of Android constituted fair use.

“A holding for Google on either question presented would dispense with Oracle’s copyright claims,” the Court notes in its ruling. “Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted. We shall ask instead whether Google’s use of part of that API was a ‘fair use.’ Unlike the [appellate court], we conclude that it was.”

I’m not sure that I’ve seen a court ruling with this much technical information since U.S. v. Microsoft in the late 1990s. It’s an interesting read if you’re curious about this case, and a good read if you’re concerned that the national discourse has devolved into sound bites and emojis.

Tagged with ,

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (18)

18 responses to “Google Wins Java Copyright Case”

  1. crunchyfrog

    Now that the JAVA lawsuit is apparently settled, what does this mean for the software industry in general? Will this ruling spill over into other "fair use" cases?

    • hrlngrv

      In reply to crunchyfrog:

      I just spent 15 minutes or so trying to search for other software fair use cases. There don't seem to be all that many. Perhaps unsurprising since anything using C's standard library would be unaffected due to the consent decree applying to AT&T when C rose to prominence. On a different tack, irrelevant to anything released under GPL, BSD, MIT or similar open source licenses.

      Aside from umpteen different BASIC variants and Java, are there any other proprietary programming languages or libraries in widespread use?

  2. wright_is

    In reply to proftheory:

    Yes, the calls couldn't be copyrighted, but the code behind them, which is why AMI and Compaq had to clean-room develop their own BIOSes.

  3. hrlngrv

    In reply to proftheory:

    I believe IBM did copyright the parts of the BIOS it wrote, but wasn't it under a consent decree for anticompetitive practices in the mainframe market at the time, so prohibited from limiting rights to reverse engineer its parts? OTOH, it licensed MS-DOS from MSFT, with the rights to rebrand it PC-DOS but not exclusively licensing it. Thus MSFT could license MSDOS.SYS to clone makers.

    With the advent of IBM's PS/2-Microchannel line in the late 1980s, all nicely patent-encumbered, the clone makers agreed on ISA then EISA and BIOS, and IBM's investment in Microchannel became as valuable as the latest patents in horse-drawn vehicles in the early 1900s.

    As someone who had the opportunity to use IBM PCs at work with one of the first Compaq Deskpros at home in the mid 1980s, I much preferred Compaq's implementation. The only downside was Compaq's own ANSI.SYS, which was crap compared to IBM's. (Maybe unfair to Compaq; the fault may have been MSFT's.) That became moot as soon as I discovered FANSI Console. The good old days!

    • wright_is

      In reply to hrlngrv:

      AMI and other companies clean-roomed the PC BIOS, creating their own versions that accepted the same calls, but the code was "100%" their own - it is possible that a chain of opcodes were the same or similar to IBM's, but they could prove that none of the engineers had had any access to an IBM PC to disassemble the original code.

      For the first few years of MS-DOS and PC-DOS, they were mutually incompatible, or at least the software needed to be re-compiled to work on the PCs that didn't have an IBM or IBM compatible BIOS, like those from ACT, Sirius, HP, DEC and several dozen other manufacturers. Even the disk formats were different. It was only after AMI and Compaq had clean-roomed the IBM BIOS that "IBM compatibles" started appearing - with more or less compatibility, early HP Vectras (HP's first attempt at an IBM "clone", after their HP 150 touchscreen series didn't really go anywhere) were "more-or-less" compatible, with some major applications, like Lotus 1-2-3, which used some IBM BIOS quirks for its copy protection, didn't run 100% smoothly; by the 2nd or 3rd generation, things had settled down enough that most software "just worked", regardless of who had made the IBM clone.

      At one point, I had an Act Apricot, a DEC Rainbow, an HP Vectra, an IBM PC XT, a Burroughs BTOS system, a DEC VT100 terminal and an Apple Mac on my desk, to cover the full gamut of systems that I needed to look after. About the only thing missing from my desk was an IBM 3270, thank God. I did bring in my Amiga from home, to show it off, running PC-DOS and Mac emulation in multi-tasking and copying data between the Mac and the PC.

      I managed to pare back the list of kit over time, the Rainbow could also run as a terminal, but you had to chose VT terminal mode or CPM/86 or MS-DOS (not PC-DOS compatible), for example and eventually I managed to wangle a copy of Reflections IV for DOS, so I could run terminal emulation directly on the Vectra, but the lack of multi-tasking made it a pain, when I was working on something in DOS and had to suddenly do a support call on the VAX or ICL mainframe, so the VT100 hung around longer than expected, until Windows 3 learnt some co-operative multi-tasking.

      • hrlngrv

        In reply to wright_is:

        I'm more familiar with Compaq than AMI.

        Maybe the Compaq engineers who developed Compaq's BIOS had no access to PCs, but it's a near certainty there were separate engineers in Compaq who were using IBM PCs and describing what happened with each BIOS call.

        By 1984, the year I bought a Compaq Deskpro, shrinkwrapped Lotus Development Corp software as well as the Lifeboat C compiler worked right out the shrinkwrap on my Deskpro. FWIW, my boss in my first fulltime job (startup, worst experience of my life) had a Compaq luggable he'd bought in 1983, and it ran WordStar and whatever the communication software which came with Hayes modems at the time right out of the shrinkwrap.

        Maybe separate versions for every clone maker was the case in 1981-2, but it had ceased being the case with the more successful clones by 1984. By 1986 (my second fulltime job), there were Panasonic and Olivetti clones which ran PC software out of the shrinkwrap (I used both kinds before I got an IBM PC XT, all work machines).

        Note: a lot of software back then, especially everything from Lotus Development Corp, included their own drivers for display hardware and printers, so didn't use the installed BIOS at all. There were separate drivers for IBM PCs with monochrome cards, Hercules cards, CGI cards, Compaq's dual mode (same video memory address range as CGI, but separate text and graphics modes). Lotus released new printer driver diskettes from time to time. Then there were all the shenanigans needed to use expanded memory cards which weren't part of MS-DOS until MS-DOS 5 IIRC in the early 1990s. 1980s software had to support expanded memory cards on their own with no help from MS-DOS at the time.

        • wright_is

          In reply to hrlngrv:

          That is the point of the clean room, you get a list of calls and possible results and, from that, you develop a new solution to stick to those rules, but you have never seen the code that produces those results, given those parameters.

          When I started in working for Plessey in 1987, they still had a mix of HP 125 (CP/M), HP 150 (MS-DOS, but not IBM compatible), HP Vectra (MS-DOS and 80% compatible), DEC Rainbows (CP/M 86 and MS-DOS, not IBM compatible) and IBM PCs. The later generations of Vectra were more compatible, but the first 286 based Vectra wasn't that compatible.

  4. hrlngrv

    If you're going to write about SCOTUS decisions, you should include which justices concurred and dissented.

    Breyer, Roberts, Sotomayor, Kagan, Gorsuch and Kavanaugh in the majority, Thomas and Alito dissenting, Barrett not taking part (presumably because she joined SCOTUS after it heard oral arguments).

    • bkkcanuck

      In reply to hrlngrv:

      The supreme court has already been politicized enough, we don't need to make it worse by having a row call on every decision. The furthest most I would think would be important is the

      • the decision
      • the narrowness (i.e. 6-2 indicating the vote was not close)
      • the majority opinion and who wrote it
      • the minority opinion and who wrote it
      • hrlngrv

        In reply to paul-thurrott:

        Any decision with Roberts in the majority is likely to be narrowly decided. This is an example. SCOTUS stipulated copyright applied, and ruled narrowly that Google's copying of what would be considered header files in C was fair use.

        That is, SCOTUS didn't rule on whether APIs could be copyrighted, only that if they could be, Google still didn't infringe Oracle's Java copyrights.

        • Paul Thurrott

          That's outside of the scope of my coverage, and I don't have any insight to offer there at all. A SCOTUS ruling is final and a win is a win. It's over. But I did cover the fact that they did not rule on whether software code COULD be copyrighted. That's definitely part of the story.
  5. ebraiter

    Wow. Google won a big ruling for once.

  6. a_lurker

    SCOTUS still screwed up. If using an API is fair use in one instance it is fair use in all instances. It also ducks the question of whether they are copyrightable in first place. API's by their nature are agreements between the caller and implementer about what parameters to pass and what the result will be.

    But they did rule in favor Google on this one.

  7. JerryH

    I understand the court usually does try to rule on the narrowest case they can, but this leaves Oracle open to sue others since Fair Use is only something a court is allowed to determine whereas flatly saying that an API can't be copyrighted would have prevented other suits. Good that Google won, but too bad that the court didn't take up the whole copyright on an API issue. This one will come back again at some point.

  8. eric_rasmussen

    This is a huge win! I don't much care for Oracle as a company, but my concern was the impact that a win for Oracle would have on software in general, especially when developing API-compatible tools and libraries.

    I'm glad this is finally settled and that the court understood the root of the issue.

  9. bkkcanuck

    Thank god! The earlier rulings were a disaster... Public interfaces should be considered fair use as it is important for compatibility and competition (private interfaces and code are the only parts that should be considered protected). The earlier rulings were a threat to what was considered the norm for most of the modern history of intellectual property (in the technology field).