Google Wins Java Copyright Case

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

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

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

Share post

Please check our Community Guidelines before commenting

Conversation 20 comments

  • crunchyfrog

    05 April, 2021 - 10:39 am

    <p>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?</p>

    • hrlngrv

      Premium Member
      05 April, 2021 - 8:23 pm

      <p><a href="https://www.thurrott.com/google/248827/google-wins-java-copyright-case#621707&quot; target="_blank"><em>In reply to crunchyfrog:</em></a></p><p>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&amp;T when C rose to prominence. On a different tack, irrelevant to anything released under GPL, BSD, MIT or similar open source licenses.</p><p>Aside from umpteen different BASIC variants and Java, are there any other proprietary programming languages or libraries in widespread use?</p>

  • bkkcanuck

    05 April, 2021 - 11:35 am

    <p>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). </p>

  • eric_rasmussen

    Premium Member
    05 April, 2021 - 11:48 am

    <p>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.</p><p><br></p><p>I'm glad this is finally settled and that the court understood the root of the issue.</p>

    • hrlngrv

      Premium Member
      05 April, 2021 - 8:08 pm

      <p><a href="https://www.thurrott.com/google/248827/google-wins-java-copyright-case#621714&quot; target="_blank" style="background-color: rgb(255, 255, 255);"><em>In reply to Eric_Rasmussen:</em></a></p><blockquote><span style="background-color: rgb(255, 255, 255);">I don't much care for Oracle as a company</span></blockquote><p>Larry Ellison is one of the few humans who makes Donald J Trump seem like a consummate gentleman.</p>

  • JerryH

    Premium Member
    05 April, 2021 - 12:57 pm

    <p>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.</p>

  • a_lurker

    05 April, 2021 - 1:15 pm

    <p>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. </p><p><br></p><p>But they did rule in favor Google on this one. </p>

  • ebraiter

    05 April, 2021 - 4:03 pm

    <p>Wow. Google won a big ruling for once.</p>

  • hrlngrv

    Premium Member
    05 April, 2021 - 7:45 pm

    <p>If you're going to write about SCOTUS decisions, you should include which justices concurred and dissented.</p><p>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).</p>

    • Paul Thurrott

      Premium Member
      06 April, 2021 - 8:40 am

      lol why?

      • hrlngrv

        Premium Member
        06 April, 2021 - 7:13 pm

        <p><a href="https://www.thurrott.com/google/248827/google-wins-java-copyright-case#621810&quot; target="_blank"><em>In reply to paul-thurrott:</em></a></p><p>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.</p><p>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.</p>

        • Paul Thurrott

          Premium Member
          07 April, 2021 - 8:47 am

          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.

    • bkkcanuck

      06 April, 2021 - 11:12 pm

      <blockquote><em><a href="#621755">In reply to hrlngrv:</a></em></blockquote><p>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</p><ul><li>the decision</li><li>the narrowness (i.e. 6-2 indicating the vote was not close)</li><li>the majority opinion and who wrote it</li><li>the minority opinion and who wrote it</li></ul>

  • hrlngrv

    Premium Member
    05 April, 2021 - 8:04 pm

    <p><a href="https://www.thurrott.com/google/248827/google-wins-java-copyright-case#621720&quot; target="_blank" style="background-color: rgb(255, 255, 255);"><em>In reply to proftheory:</em></a></p><p>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.</p><p>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.</p><p>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!</p>

    • wright_is

      Premium Member
      06 April, 2021 - 5:11 am

      <blockquote><em><a href="#621758">In reply to hrlngrv:</a></em></blockquote><p>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.</p><p>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.</p><p>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.</p><p>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.</p>

      • hrlngrv

        Premium Member
        06 April, 2021 - 4:53 pm

        <p><a href="https://www.thurrott.com/google/248827/google-wins-java-copyright-case#621774&quot; target="_blank"><em>In reply to wright_is:</em></a></p><p>I'm more familiar with Compaq than AMI.</p><p>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.</p><p>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.</p><p>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).</p><p>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 <strong><em>expanded</em></strong> 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.</p>

        • wright_is

          Premium Member
          07 April, 2021 - 2:59 am

          <blockquote><em><a href="#621886">In reply to hrlngrv:</a></em></blockquote><p>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.</p><p>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.</p>

  • wright_is

    Premium Member
    06 April, 2021 - 5:25 am

    <blockquote><em><a href="#621720">In reply to proftheory:</a></em></blockquote><p>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.</p>

    • behindmyscreen

      07 April, 2021 - 3:44 pm

      <blockquote><em><a href="#621775">In reply to wright_is:</a></em></blockquote><p>Right. Which is what Google did and why what Oracle was doing would bring the software development world crashing down if they won.</p>

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC