SoylentNews is people
SoylentNews
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
(Score: 3, Interesting) by VortexCortex on Tuesday June 30 2015, @04:00AM
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: 4, Funny) by turgid on Tuesday June 30 2015, @07:44AM
Go on, give us a look at your metacompiler, please! I'll be your best friend...
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].