Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday June 29 2015, @11:51PM   Printer-friendly
from the grab-some-popcorn dept.

TheVerge is reporting the Supreme Court has declined to hear the long-running Google, Inc. v. Oracle America, Inc. case concerning copyright over the Java APIs. This is an important case, because it sets precedent if publicly documented software APIs can be copyrighted. This has relevance throughout the FOSS community, from Wine (reimplementing the Windows API) to Octave (reimplementing the MATLAB API).

A brief history of events: The original decision, handed down in 2012 in district court, found strongly against Oracle that APIs were not protected by copyright. Oracle appealed, and the Federal Circuit Court of Appeals reversed the district court decision, finding the "structure, sequence and organization" of an API was copyrightable.

Google petitioned SCOTUS to hear the case. The Court seemed unsure, and requested the input of the Solicitor General (Donald Verrilli, appointed by Barack Obama). Mr. Verrilli replied with a brief instructing SCOTUS not to hear the case. Today, SCOTUS officially declined to hear arguments.

By declining to hear arguments SCOTUS defers to the appeals court ruling: APIs are copyrightable. Google may still have a defense under the Fair Use doctrine, but now all other users of APIs will have to prove Fair Use if a suit is brought. There is no option to overturn this precedent save a new case working through the courts. Soylentils, what will the effects of this decision be? Have you used or reverse-engineered code from public APIs in your own work?


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Nerdfest on Tuesday June 30 2015, @12:14AM

    by Nerdfest (80) on Tuesday June 30 2015, @12:14AM (#203091)

    Basically, far fewer jobs in the US for developers, and many more for lawyers. Thanks Oracle!

    • (Score: 5, Insightful) by kaszz on Tuesday June 30 2015, @12:34AM

      by kaszz (4211) on Tuesday June 30 2015, @12:34AM (#203103) Journal

      Yeah avoid the USA,, oh wait the trans Atlantic trade deal. The sue party may begin!

      So if you are a developer that wish to use an API of a company based in USA, keep out of that country. Bonus point for no compromised hardware-software by law, no really nasty letters, sue happy lawyers etc.

      • (Score: 3, Informative) by PartTimeZombie on Tuesday June 30 2015, @01:13AM

        by PartTimeZombie (4827) on Tuesday June 30 2015, @01:13AM (#203118)

        There's also a Trans Pacific Trade deal. It'll be pretty much the same thing I suspect.

        • (Score: 4, Insightful) by kaszz on Tuesday June 30 2015, @01:17AM

          by kaszz (4211) on Tuesday June 30 2015, @01:17AM (#203120) Journal

          Yeah, Trans sea reach of corporate bullying.

  • (Score: 5, Informative) by takyon on Tuesday June 30 2015, @12:28AM

    by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Tuesday June 30 2015, @12:28AM (#203100) Journal

    This is an important case, because it sets precedent if publicly documented software APIs can be copyrighted. This has relevance throughout the FOSS community, from Wine (reimplementing the Windows API) to Octave (reimplementing the MATLAB API)... There is no option to overturn this precedent save a new case working through the courts.

    https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court-refuses-review-oracle-v-google-api-copyright-decision [eff.org]

    Today’s decision doesn’t mean that Oracle has won the lawsuit. The case will now return to the district court for a trial on Google’s fair use defense. Both the Federal Circuit opinion and a brief by the U.S. Solicitor General recognized that Google was entitled to a trial on that defense. However, fair use shouldn’t be the only defense to API copyrightability. Fair use is a complex and potentially expensive defense to develop and litigate. While Google has the financial resources to take that defense to trial, few start-ups have the ability to do so. The Federal Circuit’s decision thus could deter new companies from competing with a large, litigious competitor by using the latter’s APIs. Hopefully other courts will decline to follow the Federal Circuit’s unwise opinion, which fortunately isn’t binding on the other appeals courts.

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    • (Score: 3, Interesting) by Non Sequor on Tuesday June 30 2015, @01:12AM

      by Non Sequor (1005) on Tuesday June 30 2015, @01:12AM (#203117) Journal

      I tend to try to play devil's advocate in these things and try to understand them in non-"the sky is falling" terms, but I really can't get a clear feel for what the scope of this is going to be and it seems like it has bad implications.

      --
      Write your congressman. Tell him he sucks.
      • (Score: 0) by Anonymous Coward on Tuesday June 30 2015, @01:36AM

        by Anonymous Coward on Tuesday June 30 2015, @01:36AM (#203126)

        Furthermore there is zero up-side to a ruling like this. Copyrighting an API does not provide an incentive to create the API in the first place, the API is just a means to the end goal of creating software that does something.

      • (Score: 3, Insightful) by frojack on Tuesday June 30 2015, @02:20AM

        by frojack (1554) on Tuesday June 30 2015, @02:20AM (#203144) Journal

        This is a case that would never have happened had Google just wanted to USE the APIs.

        Where ORACLE got the undies in a knot was that Google really wanted to build a replacement for the JVMs that Oracle was selling which was to be compatible at the API level, so zero code change would be needed.

        I've done this same thing while moving code from one compiler to another. Write a subroutine that mimics Compiler A's api but calls the comparable api from Compiler B, (or my own). Anybody who has managed large code bases for more than a couple years has been through this kind of migration a few times, with APIs, File Access routines, Databases, etc. Its far cheaper to make a simple function map routine than it is to dig through mountains of code of various vintage. Sometimes you can write code munging software to go fix every instance of the original API invocations when the approve approach can't be done. (Hell I wrote an engine for that as well). But most big conversion projects try to keep the API invocations in place, because every line you touch is a line you may break.

        In fact the original developers of the APIs in question, who were with SUN at the time have no problem with the Google's plan, and said so on many occasions.

        Its not an insurmountable problem. Its just a huge annoyance. Chances are just a minor munge on the API text with a code pre-processor to insert or re-order API elements is all that is needed. Maybe there should be a huge push to get all such APIs into the public domain with a non-retractable dedication.

        --
        No, you are mistaken. I've always had this sig.
        • (Score: 3, Insightful) by Anonymous Coward on Tuesday June 30 2015, @02:38AM

          by Anonymous Coward on Tuesday June 30 2015, @02:38AM (#203148)

          push to get ... into the public domain

          "Public domain"? What's that? You mean that mythical thing that copyright was supposed to enrich but has instead been used to mercilessly rape and pillage our culture?

    • (Score: 0) by Anonymous Coward on Tuesday June 30 2015, @01:27AM

      by Anonymous Coward on Tuesday June 30 2015, @01:27AM (#203122)

      Armed with this ruling, SCO might've had a case, were it not for the fact that Novell actually owned the System V API (d'oh!) and that many parts of the Unix were either open source'd or allowed to be standardized between the mid 1970's and early 2000's.

  • (Score: 5, Insightful) by stormwyrm on Tuesday June 30 2015, @02:12AM

    by stormwyrm (717) on Tuesday June 30 2015, @02:12AM (#203142) Journal

    It would be one thing if this were a law, in which case you could sue the Attorney General in their ex officio capacity to get the law declared invalid for whatever reason. But this is a specific interpretation of the law. I suppose now we can look forward to computer science research getting stifled in the United States thanks to SCOTUS's inaction here, and perhaps the centre of computer innovation will move elsewhere to avoid a legal climate where simply implementing an API can get you sued.

    I wonder if Google will begin to deprecate Java for Android development in favour of some other language like Go. I'd welcome that, being reminded daily why Java is not my favourite language as I develop an Android app.

    --
    Numquam ponenda est pluralitas sine necessitate.
    • (Score: 4, Insightful) by jcross on Tuesday June 30 2015, @02:54AM

      by jcross (4009) on Tuesday June 30 2015, @02:54AM (#203155)

      On the other hand, what might happen is that the smarter companies will realize that getting people to use their APIs is a good way to stay relevant, and locking them down just ensures that eventually they'll be completely overtaken, instead of merely having open source projects take pieces of an expanding pie.

      For example, if Octave were forced to break its compatibility with MATLAB, it very well might come up with a better implementation of a better API, and instead of acting as a free training environment for MATLAB skills, it would grow its own market that MATLAB would get no benefit from. In the case of Java there's a hell of a lot of code out there, I know, so it's not going away for a long time, but having it be in the foundation of Android means its star is hitched to an extremely relevant and growing market segment, and I'm guessing that's a win for the Java ecosystem as a whole.

      I guess what I'm saying is that open APIs are eventually going to dominate, because they allow more innovation from more players, and that's generally good for end users. The smarter companies will realize this and explicitly use open licenses, while the dumb companies like Oracle will buy good tech developed elsewhere and slowly, over the course of decades perhaps, they'll run it into the ground with their greed, sloth, and incompetence. The sky isn't falling, folks; the cooperators will win in the end.

      • (Score: 2) by jcross on Tuesday June 30 2015, @03:01AM

        by jcross (4009) on Tuesday June 30 2015, @03:01AM (#203158)

        There's actually yet another reason open APIs will win. Say I'm a big enterprise writing software for the long haul, and I'm considering Java. Now I have to consider what would happen if for some reason Oracle decided to stop updating the JVM, or if it went bankrupt and the copyright fell into the hands of some even nastier lawyers. Do I really want to take that risk with my very expensive code-base, or might I rather use something where I know I'll always have some options? The days when you could count on companies like Oracle or IBM to be rock solid for ages are numbered...

        • (Score: 3, Interesting) by VortexCortex on Tuesday June 30 2015, @04:00AM

          by VortexCortex (4067) on Tuesday June 30 2015, @04:00AM (#203175)

          In today's landscape where a free software C API gives you just as much if not more cross platform compatibility than Java can promise (both are write once, test everywhere, esp. with hardware virtualization), the choice is even more slanted away from proprietary APIs. Really, can any CTO look investors in the eye after tying the company to the whims of a 3rd party proprietary vendor's API and say they have the company's best interest at heart? In the short-term, perhaps the argument can be made that migration is more expensive than sticking with the vendor lock-in platform, but there can be absolutely no long term strategy so long as the company's future now rests on the 3rd party platform's whims and success. All new projects will be creating an internal "platform abstraction layer" (as all of mine have always had: FUCK relying on ANY API and/or proprietary language's library bindings). All existing projects should be moving towards adoption of either fully FLOSS API underpinnings or the company's own abstraction layer. You don't even have to be worried about your current platform itself to make this decision since it's the only logical way to ensure your application logic will be cross platform and portable to any future platform.

          More marketshare = more money; So, any way you look at it. This is potentially both a good thing and bad thing for the software industry. Bad: In the near term companies will have to spend money as they start creating and writing to abstraction layer APIs. Good: in the long term this means there will be less friction when making software cross platform (because the OS and API are fucking irrelevant, they're just ways my software gets to talk to the damn hardware). People don't buy OSs anymore. No one gives a flying fuck about the API or OS under the hood, they just care about which "apps" will run on the platform they have. This means it'll be cross platform programs or bust -- why start creating a new program today that's needlessly tied to a proprietary API rather than a cross platform, more future proof API and getting a larger potential market share for free? Any who pick less money (proprietary API) than more money (open / abstracted API) for the same input work is a fool that doesn't deserve to make such decisions. For existing projects the question is more complicated, but for anything new, it's a no-brainer: Public Domain / Open / Standardized API or nothing.

          The ruling sucks for me even though my meta language can compile to native machine code, C or Java bytecode, since the runtime API must call Java APIs when targeting the JVM even if the source code has no mention of the Java API and only uses my abstracted meta-language API. It's actually not that big of a deal though, since many of my customers have been opting out of unnecessary JVM overhead for native binaries or C output (then compiling the "intermediary" on w/ opts for the specific hardware). Once you're selling labor as open source code there's no benefit to releasing as compiled bytecode for a less efficient proprietary VM which would obfuscate "proprietary" sources -- the customers really can sudo apt-get install build-essentials && make as part of the installation process. Point being: The advantage of the JVM is out the window now that we have hardware virtualization and free native C/C++ compilers.

          What would be really sweet is if some BSDs sued Linuxes for copying the headers essentially required for POSIX compliance (the US Armed forces used to be a big stickler for POSIX compliance, until MS started whining about not being able to win bids). I wouldn't care since my platform abstraction layer allows each deployment platform to have a different API without my main codebase changing a single line of code. If I get sued over any specific API called by my abstraction layer I'll just drop support, inform my customers they'll be on binary paths from now on, and help that platform die. Bring it on Dinosaurs who didn't anticpate this shite coming a decade ago. My metacompliers and FLOSS will eat your lunch, proprietary APIs or not. If any OS (such as Windows) decides that I can't call their API without a license fee, then I'll drop them -- They're only 12% of my customers anyway, it'll be less work for me to drop support.

  • (Score: 3, Informative) by GungnirSniper on Tuesday June 30 2015, @02:17AM

    by GungnirSniper (1671) on Tuesday June 30 2015, @02:17AM (#203143) Journal

    The Solicitor General does not get to instruct the Supreme Court on things. It's an Amicus Brief which is a legal opinion or advice, rather than an order as the summary seems to imply.

  • (Score: -1, Offtopic) by Anonymous Coward on Tuesday June 30 2015, @03:53AM

    by Anonymous Coward on Tuesday June 30 2015, @03:53AM (#203173)

    There you go.

  • (Score: 5, Interesting) by curunir_wolf on Tuesday June 30 2015, @04:26AM

    by curunir_wolf (4772) on Tuesday June 30 2015, @04:26AM (#203181)

    Did anybody else read Verrilli's opinion? It's awful. He clearly did not bother to learn anything about what an API actually is. The whole thing is rather ignorant.

    He completely dismisses the comparison to Lotus based on nothing but his idiotic opinion that it's harder for a spreadsheet user to learn a new set of menus than it is for a programmer to learn a new API. What kind of logic is that? Moron.

    --
    I am a crackpot
    • (Score: 4, Insightful) by lentilla on Tuesday June 30 2015, @06:49AM

      by lentilla (1770) on Tuesday June 30 2015, @06:49AM (#203206)

      it's harder for a spreadsheet user to learn a new set of menus than it is for a programmer to learn a new API. What kind of logic is that?

      Illogical as it may be, there's more than a grain of truth. A (competent) programmer will probably grumble a bit when forced to learn a new API. The average spreadsheet user is likely to stare at the new spreadsheet menus blankly until someone holds their hand and shows them where to click. And shows them again later that day, and the next day, and so on...

      • (Score: 0) by Anonymous Coward on Tuesday June 30 2015, @07:12AM

        by Anonymous Coward on Tuesday June 30 2015, @07:12AM (#203210)
        The average spreadsheet user is likely to stare at the new spreadsheet menus blankly until someone holds their hand and shows them where to click. And shows them again later that day, and the next day, and so on...

        Until the boss decides that they're incompetent at their job and tells them that they're fired. If it's your job to push spreadsheets then you better damn well learn it, just as if it's your job to program in some API.

  • (Score: 0) by Anonymous Coward on Tuesday June 30 2015, @09:45AM

    by Anonymous Coward on Tuesday June 30 2015, @09:45AM (#203258)

    These people are off the rails lately...

    • (Score: 1, Informative) by Anonymous Coward on Tuesday June 30 2015, @01:14PM

      by Anonymous Coward on Tuesday June 30 2015, @01:14PM (#203290)

      I know, right...? Especially Scalia is sounding more and more like he's in touch with reality less and less...

  • (Score: 2) by Hairyfeet on Tuesday June 30 2015, @12:04PM

    by Hairyfeet (75) <{bassbeast1968} {at} {gmail.com}> on Tuesday June 30 2015, @12:04PM (#203277) Journal

    I know some in the FOSS community (for reasons unknown, after all with each release on Android Google puts more and more behind the Playwall [arstechnica.com] and they have flat out refused to allow GPL V3 pretty much anywhere) but AFAIK MSFT has never tried to sue Wine or Crossover for that matter, in fact if they wanted access to the source they could simply license the APIs (as Xandros did with Exchange) and likewise MATLAB has never tried suing Octave.

    Nope the only one this affects is GOOG and I would argue its a bad decision for one simple reason...there is absolutely ZERO difference between this and what MSFT tried to do in the 90s with MS Java! In BOTH cases you have a company in a position of dominance (MSFT with desktops, GOOG with mobile) taking somebody else's product (ironically the same product) and "pulling a EEE" and making just enough changes to make it incompatible with the original and give THEM ultimately control over the product. Because hey why would I write for Java when GOOG Java....err I mean "Dalvik" is on the biggest platform on the planet?

    Now you watch the incredible gymnastics that will be put on display as the fanboys jump through flaming logic hoops to explain why its perfectly okay for GOOG to do the same dirty trick MSFT was busted for in the 90s because...reasons. I'm sorry but I said MSFT was dirty and deserved to get smacked for that bullshit then and GOOG deserves the exact same treatment NOW. If they want to design their own language, without ripping anybody off? Go right ahead, not like they don't have the money and talent to do so....but that is the rotting elephant in the room, isn't it? They chose to copy Java on purpose so they could leverage the years of experienced programming talent while changing just enough that doing so wouldn't be also giving an advantage to the one they are copying.....hmmm, now why does that seem so familiar [wikipedia.org] I wonder?

    --
    ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
    • (Score: 4, Interesting) by stormreaver on Tuesday June 30 2015, @06:10PM

      by stormreaver (5101) on Tuesday June 30 2015, @06:10PM (#203408)

      there is absolutely ZERO difference between this and what MSFT tried to do in the 90s with MS Java!

      There is absolutely ZERO similarity between this and what MSFT tried to do in the 90s with MS Java. The former implemented some commonly used API's for a completely different product, while the latter claimed to be offering something it clearly wasn't. Google never tried to pass Android off as Java, while Microsoft very much tried to pretend that J++ was a Java-compliant product.

      It's very straight forward, with no gymnastics required.

      • (Score: 2) by Hairyfeet on Tuesday June 30 2015, @10:07PM

        by Hairyfeet (75) <{bassbeast1968} {at} {gmail.com}> on Tuesday June 30 2015, @10:07PM (#203530) Journal

        So if MSFT would have just named it "coffee" it would have been okay, is THAT your position? So GOOG or some other large corp could just take Linux and make it proprietary, because "hey this isn't 'Linux' its LOONIX, its a totally different thing!"....NOW do you see why your position is a dumb? Because if it all comes down to the name then any company with market dominance can simply take anything they want and the ones that actually invented the thing? Yeah fuck off peasant, we're the 800 pound gorilla!

        --
        ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
        • (Score: 2) by stormreaver on Wednesday July 01 2015, @05:35PM

          by stormreaver (5101) on Wednesday July 01 2015, @05:35PM (#203851)

          So if MSFT would have just named it "coffee" it would have been okay...?

          You're omitting, either wilfully or just ignorantly, some important details. Microsoft licensed Java from SUN under contract, a part of which said that the Java trademark could only be used by fully conformant implementations. Microsoft certified that J++ was fully conformant, while making it very much not so. That was a breach of its contract with SUN, a breach of copyright, and was an intentionally deceptive act by Microsoft intended to dilute the value of Java in an effort to protect Microsoft's operating system monopoly.

          Google reimplemented 37 Java packages using its own code for the sole purpose of compatibility and interoperability with the large existing body of Java code. Hopefully, that makes things clearer for you.

          Linux offers Iced Tea, a rebranding of Java, which is perfectly legitimate under the GPL (which is the license under which Java is distributed). And yes, the same could be done for Linux; as long as the result was released under the GPL.

          • (Score: 2) by Hairyfeet on Saturday July 04 2015, @11:53AM

            by Hairyfeet (75) <{bassbeast1968} {at} {gmail.com}> on Saturday July 04 2015, @11:53AM (#204993) Journal

            And YOU sir are omitting, either willfully or just ignorantly, some important details. Google attempted to buy licenses for Java, there are plenty of emails where they make it clear that they believed they were on seriously thin ice without a license and then just decided to say fuck it and copy it.

            So I'm sorry, come up with as many logic hoops as you like because there is zero difference between what MSFT tried and what GOOG did, the only difference? GOOG got away with it. BOTH took Java, BOTH made just enough changes to make sure "their" version was not compliant (which is called 'EEE', embrace, extend, extinguish, which wadda ya know,has been exactly what has happened to Java since Android) and BOTH used their market dominance in one area (desktops for 1, search the other) to muscle out the competitor.

            the only difference is the DoJ is so bought off that Brin and Paige could drop drawers and tell the DoJ to kiss their ass and the only response would be an inquiry on what lipstick they would prefer. The best part? Google is about to get the last laugh as they finish pulling a EEE on FOSS [arstechnica.com] which I'm gonna LMAO when all those that supported this "FOSS friendly" company finds out they supported the creation of the next TiVo, LOL. They are gonna fuck FOSS just like they fucked Oracle, just you watch. MSFT's only mistake was not buying off the DoJ before they tried to steal Java.

            --
            ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
            • (Score: 2) by stormreaver on Monday July 06 2015, @12:59AM

              by stormreaver (5101) on Monday July 06 2015, @12:59AM (#205437)

              Google attempted to buy licenses for Java, there are plenty of emails where they make it clear that they believed they were on seriously thin ice without a license and then just decided to say fuck it and copy it.

              Google was examining all its options, with licensing Java being one of them. Google decided that the licensing option was too restrictive, so created their own implementation of the needed API's (which, before this case, was generally considered to be legally acceptable).

    • (Score: 3, Interesting) by kurenai.tsubasa on Tuesday June 30 2015, @08:15PM

      by kurenai.tsubasa (5227) on Tuesday June 30 2015, @08:15PM (#203478) Journal

      You seem to be conflating Dalvik and the Playwall, but your overall criticism of the state of Android from the perspective of extricating Google from the OS is spot-on. However, there's more to Java than “apping app appers” (as whoever likes to post at random).

      I've been dabbling with server-side Java the past few years (mostly Apache alternatives to Hibernate/Jersey/etc) with the rationale that if Oracle went full retard, there would always be Iced Tea [classpath.org]. My Gentoo box at home has Iced Tea instead of Oracle Java and it works just fine.

      Everyone thinks Android and applets when Java comes up, but the open source ecosystem for server-side stuff is a cornucopia. I'm not necessarily a fan of Java as a language, but the ecosystem sold me on it.

      This situation is fairly disturbing. I never would have thought that an API would be copyrightable. Well, they're going fuller retard than I believed was possible. Crank the retardation to 11!

      If re-implementing the Java APIs turns out not to be fair use, the real shame will be losing the ability to legally run Iced Tea, and along with that, some very good libraries will suddenly be dead to me.

      Perhaps it's time to polish up on C++. C++11 may actually be usable! (Well, not that C++ wasn't, but I'm loving the auto keyword and user-defined types. I'm sure there's plenty of unexpected-ness there to hang myself. Just need to wrap my head around the semantics of C++ lambdas.)

  • (Score: 0) by Anonymous Coward on Tuesday June 30 2015, @12:33PM

    by Anonymous Coward on Tuesday June 30 2015, @12:33PM (#203278)

    Torture them to death if they sue you.

    Ignore this ruling like you ignore software patents.