back to article Your roadmap to the Google vs Oracle Java wars

The final lap nears in Oracle's epic seven year battle with Google over Java. It's reached the Federal Appeals Circuit, where Oracle is confident that three appeals judges with a strong track record of upholding IP will decide in its favour. In many ways, it's a surprise that Big Red didn't win ages ago, with the two warring …

  1. Anonymous Coward
    Anonymous Coward

    Oh dear...

    Oh come on. This is a tech site and you're creating another one-sided article claiming that APIs should be subject to copyright despite the years of understanding that they were fair game and something that has made interoperability a key aspect of modern computing, stopped proprietary lock in and formed the basis of the whole of Oracle's business (SQL).

    For APIs to be declared off limits could affect vast swathes of the IT industry and see lawsuits not seen since someone decided that adding the work "on a computer" allowed software to be patented.

    I won't even start on the inaccuracies in this opinion piece but I am at a loss as to understand why it is sooo one-sided. Yes I know about Andrew O's hatred of Google and over bias towards anything IP based, and in some cases I agree with him. But if anyone cares to actually look at the true history of this case and see defeat after defeat (Judge Alsup did actually know a thing or two about computer programming) by Oracle then it would be very hard to side with them, unless of course you get all your information from Foss Patents.

    I suggest starting at a site like Groklaw (unfortunately no longer available) and set yourself three days to read the actual history and judgments. Then make up your mind whether Oracle are being hard done by in this matter.

    1. Anonymous Coward
      Anonymous Coward

      Re: Oh dear...

      "Groklaw (unfortunately no longer available) "

      By that I meant no longer being maintained/updated but still available with most of the pertinent facts towards this case...

      1. Steve Davies 3 Silver badge

        Re: Groklaw

        Have an upvote from me for remembering that link.

        I suggest that people read PJ's last post http://www.groklaw.net/article.php?story=20130818120421175 and reflect on what little has changed in the almost 4 years since she signed off. Ok, it is not directly relevant to this case but to security of what we do on the internet in general.

        As the SCO case it still occassionaly popping its head up above the parapet after more than 14 years, I think that this one (Oracle vs Google) has a long way to go yet. The supremes will probably have to consider it and the implications if Oracle prevail.

        {the raft of tech companies leaving the USA will become a tusnami according to one article I read a few months ago}

        1. Anonymous Coward
          Anonymous Coward

          Re: Groklaw

          Groklaw was, and still is, an invaluable resource. It's unfortunate that it didn't continue, but as many of us wrote at the time. PJ was entirely within her rights to call it quits (that final post provides some compelling reasons for her decision). The contributions of Mark Webbink (former Red Hat counsel) in particular were always insightful and thought-provoking. No doubt that were Groklaw still live, the present article would have been subject to the usual thorough analysis that so many others received over the years.

    2. Anonymous Coward
      Anonymous Coward

      Re: Oh dear...

      "This is a tech site and you're creating another one-sided article claiming that APIs should be subject to copyright despite the years of understanding that they were fair game"

      Convention doesn't trump the law. This case will probably establish whether you can be sued for copyright infringement for making a "system" that is an incompatible subset of a larger "system" that you've copied the API from. That's what this case was originally about - Sun were arguing that Android's Java implementation is a system that uses a subset of the Java API, but is deliberately incompatible. Java can be considered a system with well defined boundaries, so this is different to the Unix case such as SCO versus IBM since the boundaries of an OS and its API are much wider and less well defined.

      1. Anonymous Coward
        Anonymous Coward

        Re: Oh dear...

        "That's what this case was originally about - Sun were arguing that Android's Java implementation is a system that uses a subset of the Java API, but is deliberately incompatible."

        That is absolutely and completely wrong. That is not what this case was originally about at all. Sun had nothing to do with bringing this case. The original case was more about patents than copyright and the copyright aspect was watered down so much that it has eventually come down to whether APIs are deemed to be fair use.

        If this requires being dealt 3 IP friendly judges to be able to give Oracle a win, then that sounds like there could be some skew in the judgement. How about three completely independent (with regards to IP) judges who do understand technology, the tech industry and programming making a judgement - would that not be fairer?

      2. hammarbtyp Silver badge

        Re: Oh dear...

        "Convention doesn't trump the law."

        No, but the question is whether copyright law is appropriate when dealing with API's, which although are technically "published", their purpose is far more extensive than just a paper representation.

        Copyright law concepts was written way back,and just was not designed for this. To be honest this is just another example where the way information is used, distributed and disseminated shows that current copyright law is not fit for purpose.

        The only people cheering for this judgement to come down on Oracles side, is the author, Oracle and IP lawyers. That's not a group that any sane person would want to be associated with

    3. NinjasFTW

      Re: Oh dear...

      lol as soon as I saw the title of the article, I knew who would be the author and what it would say before looking at it.

      At least he has stopped quoting Florian Muller!

      1. Steve Davies 3 Silver badge

        Re: Oh dear...

        At least he has stopped quoting Florian Muller!

        Wow, another blast from the past. The aforementioned Groklaw had more than a few run ins with Florian who at the time was revealed to be a paid-for shill (for Microsoft and others).

        Have an upvote

    4. Anonymous Coward
      Anonymous Coward

      Re: Oh dear...

      It's also clearly someone else's writing. As we don't use the term "bumper sticker" here in the UK.

      I wonder who at Oracle wrote this drivel? It suggests if they have to resort to this sort of FUD, then they must be thinking the appeal of the appeal of the appeal is a lost cause.

    5. Anonymous Coward
      Anonymous Coward

      Re: Oh dear...

      "For APIs to be declared off limits could affect vast swathes of the IT industry and see lawsuits not seen since someone decided that adding the work "on a computer" allowed software to be patented."

      If you think about how companies are bought by NPEs so that they can use their broad patents to try to forced a licence fee out of other companies (i.e. patent trolls) think about the effect of being able to buy a company so that you can do the same with copyright as the API has been implemented - even if the original company was fine and even encouraged interoperability with their product, unless it was a signed contract, possibly with a consideration also paid then there would be a whole new group of NPEs (Copyright trolls).

      The same way that patents have had their status devalued due to trolls, overall copyright could go the same way.

    6. somewhere

      Re: Oh dear...

      The author is either clueless about the law in the USA or is being willfully obtuse. Expect a win for Oracle at the Corrupt Federal Circuit, followed by another Supreme Court "How Stupid Are You People" judgment throwing out Oracle's win. There is not, and never was any question but that Oracle is the party in the wrong.

  2. Anonymous Coward
    Anonymous Coward

    And what about the fact that Sun for years were promoting Java as an "open" platform? What does "open" actually mean then, if not avoiding vendor lock-in?

    And yet, here Oracle are saying that if you use Java in any way - even if you completely re-implement the language and its run-time libraries from scratch (as Google did) - you need to licence it, and pay a share of your revenues to Oracle. That's about as proprietary as you can get.

    1. Anonymous Coward
      Anonymous Coward

      Sun's objection was that Android implemented an incomplete and incompatible Java-alike. They felt this was antithetical to Java's principle of being a cross platform environment and sued on this basis. As the copyright holder to the API they are legally entitled to sue, as the convention that API's can be copied is based on implementations being compatible. Google were clearly intending Android's Java implementation to be compatible to begin with, hence the discussion points on getting a license for the TCK (testing suite that checks conformance).

      1. hammarbtyp Silver badge

        Sun had no problem with this, until they were taken over by Oracle

        This is just another long line in money grabs from Oracle. After their initial failure to argue that the code had been copied, they have tried to expand the argument that API's were copyright-able, despite virtually the entire software industry being based on the fact API's were open.

        It is an interesting case, but this article is so one sided it would make you wonder why it has taken 7 years ti get to this point. Pity that the analysis has been done by the registers answer to Sean Hannity

      2. Anonymous Coward
        Anonymous Coward

        > Sun's objection was that Android implemented an incomplete and incompatible Java-alike. They felt this was antithetical to Java's principle of being a cross platform environment and sued on this basis.

        If I build something that implements only a subset of Java then I'm happy that I can't use the name "Java" to describe it.

        Did Google use the name "Java" anywhere in their marketing of Android? Is this a trademark infringement issue? No, I didn't think so.

        The question is, what exactly does Sun/Oracle permit you to do with the Java language and specs without paying them money?

        It seems to me that an "open platform" should allow a clean-room re-implementation, *and* for you to implement as little or as much as you like, or indeed to modify it in any way that you like - since it's your own work at this point. If that's not allowed, then I don't see in what way it can be described as "open".

        1. Anonymous Coward
          Anonymous Coward

          Had Sun behaved the way Oracle is, Java would have never enjoyed the market penetration it did. Instead, we would have probably seen a more accelerated effort to improve C++ and that's the language Google would have used for Android (unless they branched off and created Golang a lot sooner than they did).

        2. Ptol

          <quote>

          It seems to me that an "open platform" should allow a clean-room re-implementation, *and* for you to implement as little or as much as you like, or indeed to modify it in any way that you like

          </quote>

          What does "clean room re-implementation" re-implementation actually mean?.

          (a) Thinking about an abstract problem, then designing and implementing a new solution from first principles without reference to any existing solution?

          (b) Copying some lines of code, but not all of it.

          I can see that (b) could be covered under a "fair use" clause, but it cannot possibly be "clean room"

  3. Denarius Silver badge

    OTGH

    a mobile OS based on a BSD ? That may be fun. A solid OS being made smaller or a solid OS being made leaky as a colander for NSA et al. At least a BSD should hang less. Why not QNX ?

    1. Voland's right hand Silver badge

      Re: OTGH

      It is not the OS, it is the app runtime environment which is the issue here.

      You can run the Android java-like bits on top of any Unix-like OS with a minimal degree of porting.

    2. Mage Silver badge

      Re: OTGH

      iOS is sort of distantly related to BSD.

      However the OS is a separate issue to the Java like application execution environment.

      "Fuchsia, according to original Android kernel developer Brian Swetland, is mostly BSD."

      But what replaces Davik, or whatever is the execution engine for the Java like applications. It looks like Java when I'm writing an Android App.

      I'm confused as to what Google's plan B is?

      Ignore Oracle? Buy them? Wut?

      1. Richard Plinston

        Re: OTGH

        > But what replaces Davik, or whatever is the execution engine for the Java like applications.

        Dalvik has been replaced by ART for some time now, since 4.1.

        > I'm confused as to what Google's plan B is?

        They seem to be moving to Kotlin.

      2. Anonymous Coward
        Anonymous Coward

        iOS vs Fuschia

        iOS uses the Mach microkernel with a BSD runtime. I would guess that Google's "mostly BSD" means a similar strategy, but likely with a different/newer microkernel (Mach is pretty old, but its lineage stretches back to NeXT's first cube so it is obvious why Jobs made that the foundation of OS X and of course iOS which is basically a stripped down OS X)

    3. thames

      Re: OTGH

      The problem here isn't the OS itself, it's the user applications that are written in the Java language that are the problem. The apps that are written in other languages are not at issue. If you port the Java language apps to a new OS, you haven the identical problem. If you replace the Java language apps on Android, you've gotten rid of the Oracle problem.

      In other words, the problem isn't the Android OS, it's the apps written in the Java language (even though it's technically not "Java").

      Replacing the Android OS itself would be silly, as their are loads of simple apps written in Javascript (which has no relation to Java) and loads of complex games written in C++ which are unaffected by this.

      As for what Google's "plan B" might be in all this, the most straightforward one would be to replace the recommended programming language with one that doesn't duplicate any of the Java APIs. Since it's the Java library APIs and not the language itself that is in question, any language that runs on the JVM and calls the Java libraries could be equally problematic. That means that Kotlin, recently given official support from Google, could be in trouble until and unless the lawyers can give the standard library a good going over and assure everyone that there's nothing resembling Java APIs in there. Google Dart might be a safer alternative.

      Once Google have picked a new recommended language, they need to figure out what to do about the existing apps written in the Java language. Perhaps they could release a program that mechanically translates Java to another language. For those developers who don't want to do that, they could let those developers negotiate their own license directly with Oracle. I suspect that given that alternative, most developers would either choose to port to the new language (using the automated tools provided by Google) or withdraw the app from the app store (for apps that were not selling well anyway).

      For software developers in general though the message seems to be to avoid Java like the plague unless the customer insists on it, and in that case make sure the customer is the one bearing any and all risk (get that in writing).

      The above applies to mobile phones. If Oracle are successful however, I doubt they would stop there. Traditional server systems would be at risk when Oracle casts their eyes upon them looking for excuses to squeeze licensing fees out of everyone using the JVM in some way. Alternative languages which run on the JVM and use the standard Java libraries are an obvious target if they implement the library interfaces in a similar fashion.

      American software copyright law has something called "non-literal copying", whereby the judge decides that something looks sort of like something else, even if they're not actually identical. That means the fact that the function and parameter names and the syntax decoration aren't the same doesn't mean that it isn't a copy. That's why Google can't simply make the whole problem go away with a bunch of "sed" scripts.

      Third party trolls will have a field day as these newly created IP rights become the functional equivalent of new software patents. The fact that you wrote the software entirely yourself won't save you from copyright infringement claims, including claims of non-literal copying.

      In other words, if you're in the software business, be prepared to be royally screwed by Oracle if the case goes their way.

  4. Voland's right hand Silver badge

    The fair use finding dumbfounded many legal experts. Google had copied 600 classes, 6000 methods and 11,000 lines of Java to create Android.

    Business as usual in java land. When I have to write in it, I end up copying and rewriting on average 3-4 classes which are clearly half-baked, but some idiot has declared final. This is for a 5k line project (plugin in a larger system). 600 classes are LESS than the expected needed copy rate for a project of the size of Android.

    A large chunk of these 600 classes is gson, guava and the common underlying google code behind them.

    Let's look into those. You have abstractions which Sun once upon a time started and left decidedly half-baked like Futures. Despite the classes being utterly half-baked, their expansion was deliberately limited by liberal sprinkling of Finals here and there. So due to the way they are declared you have no choice but to re-implement them replicating 100% existing functionality (you have to comply with a defined interface), but building on top so people can use them. If you replicate something trivial like a basic wrapper class it is guaranteed to end up looking 99% the same even if you do not copy it. That is pretty well covered by copyright law (as in all the cases where judgments went against Lego). If there is only one form which satisfies the functional requirement, the copying argument simply does not fly.

    On top of that, the whole argument about "Google copied from us" goes out of the window as in Java 8 Oracle pinched a large section of Google's work - Futures, preconditions, etc and included them into the core libs (with some "Titanic deck-chair re-arrangement" [tm]). It also had to do exactly what Google did as well. It just comes with the territory and unfortunately there is no way to chop the fingers of all the idiots which make a LIBRARY class FINAL. And, trust me, there are LOADS of those. Even in Google.

    By the way, what Andrew missed in his shouting about 6000 methods is how many of them are accessors to a pre-defined interface. There is only ONE WAY to write them. My (very educated) guess is - 5500 or thereabouts.

    AFAIK the judge DID have some software engineering background so he clearly saw the same thing all of us see and told SnOracle to go suck asteroids through a microbore and do not complain about a NATURAL SIDE EFFECT of their language syntax. You cannot write in java unless you re-implement regularly trivial sh** just because some idiot has declared it immutable or out of scope for your project.

  5. Anonymous Coward
    Boffin

    Your roadmap to the Google vs Oracle Java wars

    "Prepare to turn left."

    ...

    "Take the next left, signposted Python."

    ...

    "You have reached your destination."

  6. ratfox Silver badge

    I disagree with most of the article, but most of all I disagree with the notion that Oracle has lost money over this.

    It should be clear to anybody that their precious language is vastly more used now than it ever has been before. The vast majority of smartphones run Java, and a good part of all this IoT crap runs a lite version of Android.

    Before Android, the idea of running Java on small devices had become so old a joke that it wasn't even funny any more. Android has made it a reality, by improving on the utter crap that Sun was peddling.

    1. Voland's right hand Silver badge

      Sour grapes of envy

      Ever heard of sour grapes of envy?

      Someone comes around and does with relative ease what you have failed to do for a decade. Everybody sees how badly you suck and everyone starts using what the new guy has done.

      All large projects in Java outside Sun use Guava Futures and Guava Collections. They are something that makes the half-baked antisocial interfaces concocted by Sun in their concurrency utils usable in the course of normal software development.

      I am not surprised about the sour grapes.

      By the way - a large chunk of the 600 classes in the lawsuit are classes Google had to re-implement as part of Guava because Sun did not just put half-baked implementations of interfaces in their libs. They declared a lot of that final so it could not be extended cleanly and easily.

      So doubly sore grapes too - showing not just how badly you suck, but also showing exactly what you have failed to deliver.

      By the way - I am no fan of Google. Guava, however, is clearly one of the places where credit should be were its due.

    2. Anonymous Coward
      Anonymous Coward

      Agree. Clearly this is Oracle just greenmailing Google... hoping Google just writes them a check to get rid of this frivolous lawsuit.

      Google doesn't give in on these issues though. Microsoft is running their own racket shaking down all of the Android OEMs over MSFT's supposed mobile patents (all of those Windows Mobile innovations apparently) which they were supposedly infringing upon. Another "take a license or get sued", "You have to pay for Windows even if you are not running Windows" shakedown. Everyone else paid. Google told them to go ahead and sue.... Microsoft went away.

  7. Richard Plinston

    Google had copied

    > Google had copied 600 classes, 6000 methods and 11,000 lines of Java

    No, Google did not copy classes and methods, it only copied names and parameters. The "and 11,000 lines" is misleading, it implies that they also copied and additional 11,000 lines when those lines are the ones containing the names and parameters required for interfacing - at less than 2 lines each.

    In any case I am not sure why Google is not using as a defence:

    """Sun released the complete source code of the Java Class Library under the GPL on May 8, 2007, ..."""

    1. thames

      Re: Google had copied

      @Richard Plinston - "In any case I am not sure why Google is not using as a defence:

      Sun released the complete source code of the Java Class Library under the GPL on May 8, 2007, ..."

      The problem is that Google didn't use the GPL version of the class libraries. They re-implemented their own because they wanted Apache or BSD licensed software. A license for software written by Sun doesn't apply to software written by Google. Google's long standing aversion to the GPL may have just bitten them on the arse.

      1. Anonymous Coward
        Anonymous Coward

        Re: Google had copied

        Right. Had Google gotten behind the GPL-licensed OpenJDK effort undoubtedly would have contributed technical improvements and accelerated its acceptance. But there was a problem of timing. By the time Sun announced OpenJDK in 2006, Android was already well on the way to release. Google had acquired Android the previous year, and probably would not have had the time to switch to the (as yet nonexistent) OpenJDK and still release Android to manufacturing in 2006. Having said that, there's no reason that Google, with its considerable resources, could not have shifted Android's architecture to an OpenJDK base after the latter's initial releases in 2007. Google management decided not to do that, just as they'd decided not to seek a license from Sun (as Red Hat *had* for its IcedTea implementation of the OpenJDK).

  8. wikkity

    Here we go again

    Spouting the same old nonsense that has been demonstrated to be incorrect so many times. There are that many flaws in this article it is unbelievable and I for can't be bothered pointing them out yet again.

  9. jacksmith21006

    "In many ways, it's a surprise that Big Red didn't win ages ago, "

    What? That would have been INSANE for Oracle to win. BTW, I hate being one of those guys but this article is simply terribly written and just very basic tech things completely wrong.

    Honestly it is so bad it is impossible to fix and would be far easier to start over. It should be pulled because there will be people reading that might not know better.

    I get tech is hard but just have someone with even the most basic tech knowledge look at your article next time.

  10. jacksmith21006

    "In many ways, it's a surprise that Big Red didn't win ages ago, "

    What?

    That would have been INSANE for Oracle to win. BTW, I hate being one of those guys but this article is simply terribly written and just very basic tech things completely wrong.

    Honestly it is so bad it is impossible to fix and would be far easier to start over. It should be pulled because there will be people reading that might not know better.

    I get tech is hard but just have someone with even the most basic tech knowledge look at your article next time.

    Edit: Just re-read the article trying to figure out what advice I could give to NOT create something so inaccurate again. I thought if you had someone that had even a basic understanding of tech could help.

    But it is clear in a couple of cases in your article where you talked to someone that does know and communicated it to you but since you have so little understanding of even basic tech your brain trying to paraphrase turned it into something completely inaccurate.

    I hate to say it that I think it is a lost cause and I honestly HATE being so harsh. But I all I have is

    ¯\_(ツ)_/¯

    Maybe get into another domain or go to school. Or there is some great online resources to learn technology.

  11. David Taylor 1

    Wtf

    Could you be a more transparent Oracle shill!?

  12. Anonymous Coward
    Anonymous Coward

    Yeah, this article does seem to basically be written by Oracle's lawyers. Biased.

  13. Bob Hoskins

    Don't use Java

    Problem solved.

  14. PlinkerTind

    Lot of work into API creation

    Come on, there is a lot of work in creating APIs too. You can create lot of classes that interact in many different and disparate ways, but how should they interact and work together? Interaction and usage is not trivial, but has to be considered well.

    Typically, an API should be orthogonal, and simple and not duplicate functionality. This requires thought and design. This design work is worth something, right? You should be getting paid for all that work, right? It is like mathematics, to design an axiom system takes many years. First the mathematical objects have some properties, and after many tries the mathematicians finally distill the functionality into some axioms - which takes many many years. For instance, in Euclidean geometry the mathematicians spent hundreds of years debating the parallel axiom - should it be included in the axioms or not? I.e. mathematicians talked about the minimal API for Euclidean geometry - that took hundreds of years and lot of hard work to nail the important stuff and getting rid of all the fluff and unnecessary stuff. An API (i.e. axiom system) is not trivial to design, ask any mathematician

    I mean, it is like creating a new wonderful dish, say, hamburger. After 100s of hours trying out different combinations, you settle down on a modern burger. The first burgers were meat + bread. Today, after 100s of years of evolution, the top quality burgers are much different, compare a Shake Schack burger to meat + bread - what a difference!! Sure, you can copy a Shake Shack burger easily today, but there have been lot of design and thought into Shake Shack burger. The same with API - it is easy to copy them when they are done - but on the way there were lot of trial and error. APIs define the classes, and you can design classes in other ways - but the Java classes are now "obvious". Back in time, it was not obvious at all.

    If I were to design a kernel and the ABI/API from scratch it would take me years. But now I can instead look up common practice and copy typical kernel ABI/API functionality and that would save me many years of research. The same with API. It is easy to copy, but to design them requires lot of hard work. And you should be paid for hard work, yes?

    1. somewhere

      Re: Lot of work into API creation

      Work yes. Patentable, clearly not.

  15. Anonymous Coward
    Anonymous Coward

    ITYM Shills

    Legal experts were not confounded by this clear-cut case of IP abuse. Only IP ideologues were.

  16. fredesmite Bronze badge
    Mushroom

    To be perfectly CLEAR

    Google stole existing code for their implementation without granted permission or paying for it. All this lawyer double speak is bullshit .

    1. Richard Plinston

      Re: To be perfectly CLEAR

      > Google stole existing code for their implementation without granted permission or paying for it. All this lawyer double speak is bullshit .

      Wrong. No _code_ was 'stolen', or even taken. A handful of code lines written by the same person that wrote them for Sun were found to be the same.

      What is the same between Sun/Oracle Java and Dalvik is class names and method names and parameters. This is not 'code' it is interface API and is required to be the same for compatibility. It is a tiny fraction of the source code and is 'fair use' as well as arguably being unprotectable.

      Permission was granted by Sun.

      It is like one book author suing another because they used the same headings: 'Introduction', 'Contents', 'Preface', 'Chapter1', 'Chapter 2', ..., 'Appendix', ...

  17. trisul

    Is API just code.

    The article skirts the issue, which is whether APIs need to be available to everyone by saying that APIs are copyrightable, so they are the same as the rest of the code. Legally, this may be so, but as tech people we cannot accept this argument.

    The whole basis for copyright law hinges on the constitutional requirement that it must "promote the progress of science and useful arts". It is clear to technology people that open APIs promote progress of science and useful arts much better than having APIs treated as the rest of the implementation. APIs are created for the sole purpose of isolating the copyrighted implementation from the open outside environment, they just cannot be considered the same.

    The problem is that copyright law is antiquated, not only does it fail to "promote the progress of science and useful arts", it is actually used to prevent the progress of science and useful arts, and is thus essentially unconstitutional. However, vested interests and technological ignorance by judges has prevented the concept of copyrights and patents to be correctly applied to the software industry. By "correctly", I mean in such a way that they "promote the progress of science and useful arts" instead of achieving the opposite effect.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020