Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Google The Courts Oracle Programming Technology

Supreme Court Will Hear Long-Running Google and Oracle Copyright Lawsuit (cnbc.com) 60

An anonymous reader quotes a report from CNBC: The Supreme Court said on Friday that it will hear a dispute between tech giants Oracle and Google in a blockbuster case that could lead to billions of dollars in fines and shape copyright law in the internet era. The case concerns 11,500 lines of code that Google was accused of copying from Oracle's Java programming language. Google deployed the code in Android, now the most popular mobile operating system in the world. Oracle sued Google in 2010 alleging that the use of its code in Android violated copyright law.

Google won two victories in the lower courts but ultimately lost on appeal before the U.S. Court of Appeals for the Federal Circuit, which ruled last year for Oracle. Oracle has previously said it is entitled to $9 billion in damages, though no official penalty has been set. Java was developed by Sun Microsystems, which Oracle purchased in a deal valued at $7.4 billion that was completed in 2010. Underlying the legal issues in the case is a technical dispute over the nature of the code that Google used. Google has said that the code was essentially functional -- akin to copying the placement of keys on a QWERTY keyboard. Oracle maintains that the code, part of Java's application programming interface, or API, is a creative product, "like the chapter headings and topic sentences of an elaborate literary work." A number of high-profile tech firms urged the top court to take the case in order to side with Google.

This discussion has been archived. No new comments can be posted.

Supreme Court Will Hear Long-Running Google and Oracle Copyright Lawsuit

Comments Filter:
  • by mknewman ( 557587 ) on Friday November 15, 2019 @04:59PM (#59418262)
    I thought Java was coffee!
  • You mean, basically, everyone except for Oracle???

  • by alvinrod ( 889928 ) on Friday November 15, 2019 @05:13PM (#59418318)
    It's probably good that this will get settled definitively, but I'm a little bit worried about the outcome. The court doesn't always have a particularly good understanding of technology or the unseen ramifications of their rulings.

    If I had to bet money, I'd wager on the court finding against Oracle, but I don't think it's a slam dunk case by any means. So while I'm hopeful, I'm still apprehensive.
    • by ljw1004 ( 764174 )

      It's probably good that this will get settled definitively, but I'm a little bit worried about the outcome. The court doesn't always have a particularly good understanding of technology or the unseen ramifications of their rulings.

      The judge in "Oracle vs Google 2012 edition" knew coding as a hobbyist, and his knowledge informed his evaluations of the arguments.

      https://www.theverge.com/2017/... [theverge.com]

      Judge Alsup would like everyone to know that he doesn’t know Java. Not very well, anyway. He can, however, definitely code. He’s been coding in BASIC for decades, actually, writing programs for the fun of it: a program to play Bridge, written as a gift for his wife; an automatic solution for the board game Mastermind, which he is immensely fond of; and most ambitiously, a sprawling multifunctional program with a graphical interface that helps him with yet another of his many hobbies, ham radio.

    • The U.S. isn't the world. If the SCotUS decides in favor of Oracle, all the big companies will move their software development out of the U.S. They'll continue to sell/distribute it globally as before. In the U.S. either they won't sell it, or they'll negotiate licensing deals to sell it. The U.S. will become a backwater in global software development. Oracle will be vilified for costing the U.S. economy half a trillion dollars in software jobs. Eventually, either the SCotUS will realize they erred an
      • by jonwil ( 467024 )

        Even better, if Oracle wins IBM should sue them for violating the IBM copyright on SQL (which was invented by IBM and which is right at the core of Oracle's business)

  • Comment removed based on user account deletion
    • by Newander ( 255463 ) on Friday November 15, 2019 @05:52PM (#59418398)

      Not test code. Headers.

    • by stevew ( 4845 )

      You can find the gory details on groklaw.net. However - the 11K lines is bogus.

      What they got sued for was using the API definitions that are required to be able to simulate a Java environment. So as another poster said - HEADER files. The Header files have to have exactly the same names in exactly the same order...or it doesn't work.

      The analogy to a phone book (which can NOT be copyrighted) is actually spot on. The list of phone numbers/names is identical to the function calls and the arguments of the fun

  • Alphabet can perform a leveraged buyout of Oracle because their respective market caps of 920B and 185B respectively. In fact, Google can decrease Oracle's price by threatening to delist or blacklist its customers. Once Alphabet owns Oracle, it can scuttle Oracle's appeal to win a favorable precedent.

    • by gtall ( 79522 )

      You'd have to get Uncle Larry to give up his shares...not in his lifetime, he's taking them with him when he goes, no one else is worthy enough in his eyes to have them.

      • by tramp ( 68773 )
        I think that enough customers and other corporations would gladly let his share go with him but i do not think Uncle Larry has planned to go soon.
  • by dgatwood ( 11270 ) on Friday November 15, 2019 @05:34PM (#59418364) Homepage Journal

    This is a clear situation where two different circuits provided fundamentally contradictory guidance on whether APIs can be copyrighted, so certiorari should have been almost automatic. The irony, of course, is that in this situation, both opinions were in different parts of the same court case. That's pretty hilarious.

    The problem with allowing copyright on APIs is that it completely breaks the ability to write software. It is impossible to write software that targets any platform without using (and, in many cases, reimplementing) methods in the core API. The entire software industry would be violating copyright if we start treating APIs as being protected by copyright.

    So the software industry is a house of cards, built upon the assumption that APIs cannot be copyrighted. Approximately every programming language, every significant API, etc. is built, at least in part, on the design of, and the lessons learned from, other programming languages and APIs that came before them — including, incidentally, the Sun Java APIs in question. Sun basically copied the design of Apple's (NeXT's) Objective-C collection APIs, and adapted them to Java. So Oracle is suing for making an unauthorized derivative work of an API that is itself an unauthorized derivative work!

    We have the technology that we have, entirely because of that assumption, which mostly stems from the out-of-court settlement of UNIX System Laboratories, Inc. v. Berkeley Software Design, Inc., after a judge made it pretty clear that Novell (who at the time owned USL) would likely lose, because APIs are probably not copyrightable. Reversing twenty-seven years of informal precedent would be, IMO, catastrophic. I trust that the SCOTUS will do the sane thing, and not throw the entire industry under a bus.

    • by Kjella ( 173770 )

      If I'm playing the devil's advocate here I think they're running into the same issue as with natural language, words can't be copyrighted, phrases can't be copyrighted but poems and books can. Obviously it would be insanity if someone could copyright "add( a, b )" but I think the court is struggling with the idea that a huge set of carefully collected and curated APIs doesn't involve any creativity and is a purely functional work. Unfortunately unlike books where there's a gray area between plagiarizing and

      • But is the list of functions (and their inputs and outputs) really that creative? Is the list of chapters of a book copyrightable? Oracle says their API is like chapter headings and topic sentences, but that's not the meat and potatoes of "the work".
        • by cpurdy ( 4838085 )
          Anyone foolish enough to claim that API design is not creative has no real experience in software.

          In most cases, it is much, much more work to design good APIs than to write good implementations thereof.

          It is obvious that APIs must be copyrightable, in some form. It is also obvious that -- as APIs, for purpose of interoperability -- the use of APIs and the emulation of APIs cannot be viewed in the same manner as we viewed copying books 200 years ago.

          This is a topic that requires careful consideration,
      • The difference is that unlike natural language things like poems, if a programmer does not get the API exactly right, it doesn’t work. “It was the best of times, it was the shittiest of times” conveys the same idea as Dickens but is not exact. Changing one part of an API call makes it non-functional which is the opposite intent of the API.
        • The other difference is that the API is defined by the work. You can juggle the order of the statements in the headers, but the contents really have to be the same in order to achieve the same effect.

    • One of us doesn't understand what's happening.

      "The problem with allowing copyright on APIs is that it completely breaks the ability to write software"

      No. I can write Java using the official APIs, even if it turns out to be copyright protected.

      "It is impossible to write software that targets any platform without using ... methods in the core API."

      I assume you mean it's impossible to write and run Java without using core Java methods, which is true. But you can use the official Java API legally. Did you mea

      • by dgatwood ( 11270 )

        One of us doesn't understand what's happening.

        "The problem with allowing copyright on APIs is that it completely breaks the ability to write software"

        No. I can write Java using the official APIs, even if it turns out to be copyright protected.

        You can, but your work becomes a derivative work, which means that without the API author's permission, you don't own the code that you write against the API, and even with permission, you may or may not own the code. Such a change in the interpretation of copyright law would fundamentally change the way that we think about software publishing rights.

        "It is impossible to write software that targets any platform without using ... methods in the core API."

        I assume you mean it's impossible to write and run Java without using core Java methods, which is true. But you can use the official Java API legally. Did you mean it's impossible to take Java to your own system with the API intact?

        No, I mean that if you even so much as write a method call, your work is effectively a derivative of the method that you're calling, even when expressed in so

        • by cpurdy ( 4838085 )
          "No, I mean that if you even so much as write a method call, your work is effectively a derivative of the method that you're calling"

          This is a nonsensical claim. Words have meanings, and you are abusing that fundamental property.
          • by dgatwood ( 11270 )

            No, I'm really not. Show me a way to call a method that doesn't involve knowing its name and its parameter list, and I'll concede that you can write code that calls a method without being a derivative work of the method name and parameter list by extension.

            Go ahead. I'll wait.

            And no, knowing the address of the method in advance doesn't count, because the only way to know the address is to look it up by its name.

            • by cpurdy ( 4838085 )
              ... but that is not what the term means, in the legal use.

              Your ability to put together an English sentence is not sufficient to hide your ignorance.
              • by dgatwood ( 11270 )

                ... but that is not what the term means, in the legal use.

                Yes, it is. In legal terms, a derivative work is a work that incorporates part or all of another work. If the method name and signature (an API) are copyrightable, then any code either implementing that name/signature or incorporating the name/signature as part of a method call must be, by definition derivative works, because you're literally copying the name into the new work, and in some cases, the entire method signature (with the possible excep

                • by cpurdy ( 4838085 )

                  method name and signature (an API) [..] you're literally copying the name into the new work, and in some cases, the entire method signature

                  Strangely -- for /. -- the technical portion of your statement is correct for many languages; out of respect for that, I will attempt to respond constructively:

                  • If you are compiling against an API, then the license for the API will be applicable. For example, the GPL license will apply to the code linking to the GPL code, and the only enforce-ability of the GPL license
                  • by dgatwood ( 11270 )

                    For example, the GPL license will apply to the code linking to the GPL code, and the only enforce-ability of the GPL license is that the API is copyrightable. (If the API were not copyrightable, then anyone could link to GPL code without having to license their own code under the GPL. QED.)

                    That was historically not true, because static linking actually pulled the binary into the executable. And I've always had serious doubts about whether the linking-is-a-copyright-violation interpretation of the GPL would

                    • by cpurdy ( 4838085 )
                      You are certainly entitled to your own opinions on the value of APIs compared to the value of the code behind the APIs. As a developer of APIs used by many developers around the world, I understand just how creative and time-consuming that work is, and how important it is to protect that intellectual property on some level. To me, allowing someone to take entire APIs, without permission, and against the terms of the license, and then to re-implement them and sell or give that work away under a different lic
                    • by dgatwood ( 11270 )

                      To me, allowing someone to take entire APIs, without permission, and against the terms of the license, and then to re-implement them and sell or give that work away under a different license, is quite similar to allowing someone to take the notes and words of a song and to do their own "highly transformative" recording thereof, or to take the letters and order thereof in a book, and to do their own "highly transformative" printing thereof.

                      To me, it's more like writing a new book using the same section headi

                    • by cpurdy ( 4838085 )

                      To me, it's more like writing a new book using the same section headings and organization

                      I understand that you want that to be legal, but in the USA, even the table of contents of a book is protected by copyright. (I have read that this varies by country.)

                    • by dgatwood ( 11270 )

                      I understand that you want that to be legal, but in the USA, even the table of contents of a book is protected by copyright. (I have read that this varies by country.)

                      Fair enough. I probably should have said "Index" rather than ToC. It's a more accurate comparison, too.

      • Plenty of development will continue unaffected either way.

        Until IBM asserts API copyright on all clean room implementations of the PC BIOS.

      • by cpurdy ( 4838085 )
        "Copying the entirety of a language interface is the issue here, not learning from and improving on it."

        This ^ ^ ^

        Why people blindly give Google a free pass is mystifying to me.
    • APIs seem to be creative works unfortunately. Perhaps not all, but most do take some creative thinking in order to produce complete and working set. However, I do hope SCOTUS have enough understanding to rule that for greater good APIs should be exempt from copyright. However, there are examples where APIs were allowed to be burdened with royalties despite their universal interoperability (e.g. HDMI, a hardware "api").

      • by dgatwood ( 11270 )

        APIs seem to be creative works unfortunately. Perhaps not all, but most do take some creative thinking in order to produce complete and working set. However, I do hope SCOTUS have enough understanding to rule that for greater good APIs should be exempt from copyright.

        The thing is, creativity is not the only requirement for copyright protection. A work must, among other things, be nontrivial, sufficiently creative, and sufficiently original, and must not be purely utilitarian in nature. That last one is cr

        • Deserves to be modded up. I think 98% of all API's seem common, from IBM's POSIX, to TRS80 BASIC to APPLE2 etc. Now before that there was COBOL, FORTRAN and Borland products. As a CS I wrote Pcode interpreters and thought Java just a variation of sorts. IBM ZOS is rather interesting in that Paging, Sort and SAF API's predate everything in that they can be substituted in/out - same API, different methods. I have not seen this implemented elsewhere,although Digital VMS in code quality, thrashes Java. Were Or
  • by michaelcole ( 704646 ) on Friday November 15, 2019 @05:55PM (#59418406)
    It's ten years later, and we're still pretending these companies are not monopolies.
    • Who said anything that we are “pretending”? The question before SCOTUS (which is a fundamental one) is whether APIs can be copyrighted. It would not matter if was the parties were Mom and Pop’s Software vs Two Dudes Software. The only reason it has gone this long are both parties are corporations with deep pockets that can pay for lawyers for a decade.
  • by account_deleted ( 4530225 ) on Friday November 15, 2019 @06:29PM (#59418502)
    Comment removed based on user account deletion
  • I am all for abandoning copyright altogether, and where I live, I vote Pirate party. That being said, copyright does exist ATM, and greedy Google clearly stole Java language idea. manifested in API files, from Sun (now Oracle). Google was already giant corporation and could easily pay for using this _gigantic_ investment of Sun in Android OS, perhaps saving Sun in the process. Their greed prevented them of doing so. I can't really see how copying API files are any different then copying any other work. Ther
    • Google stole more than the API, they stole the implementation wholesale.
      They've been trying to sweep it under the rug for years, partly because of this suit, partly because Android on Java on half-broken Linux on half-broken Qualcomm is pure trash.

    • I am all for abandoning copyright altogether, and where I live, I vote Pirate party. That being said, copyright does exist ATM, and greedy Google clearly stole Java language idea.

      IBM had a competing implementation before Google did. So did Microsoft. Microsoft even made theirs incompatible and even they only had to either change the name or make it compatible. Gee, I wonder why Oracle didn't go after one of them?

      • by cpurdy ( 4838085 )
        "IBM had a competing implementation before Google did. So did Microsoft. Microsoft even made theirs incompatible and even they only had to either change the name or make it compatible. Gee, I wonder why Oracle didn't go after one of them?"

        IBM had a license to Java. They not only built their own Java implementation, but (as a term of the license), they had to pass all of the Java compatibility tests in order to call it Java.

        Microsoft had a license to Java. They not only built their own Java implementatio
  • You know, back in the day, we used to hold Core Wars sessions in the secure basement, and some wicked fast code it was.

    RGB isn't just called a wizard for nothing. In fact, she won almost all of them.

No spitting on the Bus! Thank you, The Mgt.

Working...