Unpopular opinion: I feel Google should be punished for what they did to Java.
Maybe the mechanism being used is wrong, but Android bastardized Java and as an Android developer I feel real damage has been done to the health of the Java ecosystem by having billions of devices run fragmented Java-but-not-Java.
Google has started to make it right with the switch to openJDK and Desugar, but in a lot of ways it’s too little very late.
Quit shilling for your employer. No one takes this argument about a piece of technology (swing) that has not been relevant for over a decade and a half seriously. Look up the history of innovations that Java and in particular the hotspot JVM brought to the mainstream. Enough with this false narrative that java and the jvm sucked and was in decline and Google swooped in and saved it. Some of the creators of your beloved V8 and Go Lang were the very same folks who helped create the hotspot JVM. Google basically pulled a fast one by not buying a license and they knew the consequences even at the time this occurred.
Someone flagged the comment before I could post my response, but here it was (re: Google didn't save Java on the client):
Java on the server was not in decline, but Java on the desktop was declining, had declined. Applets were dead, very few success stories around Java Web Start. And the main three 'consumer' success stories for Java on the frontend were Limewire, Minecraft, and IntelliJ/Eclipse. As a consumer facing technology, Java was a complete failure. No sane person wanting to ship a commercial, consumer app to end users would consider Java as a first choice. I have been a Java developer from the day HotSpot Alpha was released, I say this as someone who loves the platform.
Personal Java failed. I worked for years on J2ME apps, Java on high end Nokia Phones, Java on Palm devices (Ghost VM), etc. All these platforms amounted to nada. Flash was far more widely used for front end user facing apps than Java. Ditto for Visual Basic.
The relevance of the Swing comment is the people complaining about the fragmentation of Java's write-once-run-anywhere promise, which was always more of a promise than a reality. If you want to make a viable mobile Java, you had to remove Swing, Java2D, CORBA, JMX, and a ton of other JDK libraries, which is exactly what Sun did with the various profiles as well. But once you do that, you have "fragmentation"
If Google had not produced Android, I can bet the leading platform today for mobile development that is not from Apple, would either be Xamarin based C#, or some scripting language like Lua or Python on top of a Linux widget toolkit. Java would not be in the mix at all. Or perhaps it would FlashMX sitting on top of Linux (ugh)
They made billions of people access and use technology. Java was just a tool to help them achieve it. Sorry, your complaint is not really making sense here
It’s like I have a brand that makes widgets and gives out the plans to our widgets.
Larry finds plans to one of my old widgets and builds it into his awesome product and millions of people learn how to use the old version of my widget.
But my old widget kind of sucks and I’ve been releasing new widgets that fix a lot of issues.
Millions of people are gnashing their teeth over the old widget but Larry won’t update which version of my widget, he’s occasionally using parts of my new widget blueprint so now he’s creating Frankensteins of my widget that don’t even have a version.
But they’re still my widgets, Larry calling them by my brand name, people are conflating them with my widget, people making tools for my widget now have two diverging targets. People are saying my widget sucks because of issues I fixed ages ago.
It almost reminds me of J++ in a way, but with more subtlety.
But isn't that the point? That Google uses the Java infrastructure, but when it comes down to licensing, it isn't Java anymore? Google made a business decision to not buy a license and time will tell if that was a good decision or not.
Android popularity (or demise) does have 0 impact on server-side Java. We don't share the toolset, we don't run the same JVMs etc. Call it Jiva if you like.
Google should go Kotlin way, it will be better for everybody.
Whaaa? I mean Java is undoubtedly more popular because of Android but it's not like it was hurting before. Sure, there aren't a lot of consumer-facing applications running Java but it's pretty much the standard on the enterprise side of things.
It seems to me that it's a good thing for Oracle. Oracle/Sun was never going to make any headway in the mobile space. It just wasn't going to happen. So, it wasn't a loss to them, because they had already lost that market.
But, with Android, Java got a boost that bled over to the server, and to a lesser extent, the desktop. It can be argued what the size of that boost was, and if it had any real impact (I would argue that it was not significant), but it was still a boost that they never would have had.
Anyway, that's the opinion of some random guy on the internet.
2006 - Jasper S20 with SavaJe OS gets presented at Java ONE
2006 - End of the year, SavaJe fails to gain another round of investment, in spite of the successful reception at Java ONE
2007 - April, Sun public announcement to buy SavaJe assets
2007 - November, Open Handset Alliance is created
2008 - November, HTC Dream gets released as the very first Android device. The initial architecture diagrams have a certain resemblance with SavaJe ones.
The OS that came to be Android started in 2003, was initially based in JavaScript, had lots of time to inspire on Java stacks after they pivoted to Java and were eventually bought by Google.
Only after SavaJe was no longer around, it became public what Google was up to regarding their mobile OS strategy.
Why are you comparing the date of SavaJe's being acquired, with the date of Android being actually released or gaining third party external hardware partners? Apples and apples would be Google's acquisition of Android in 2005 vs. Sun's acquisition of SavaJe's in 2007. And even then, Google acquired the actual devs too, whereas Sun only acquired the code and IP.
And Android is way more a rip off of Palm than SavaJe. All of the interesting things it does (the intent system, the capability based IPC, the battery friendly process lifecycle model, etc.) clearly descend from Palm (which isn't a surprise given that's where Dianne Hackborn cut her teeth).
J2ME was king on mobile devices in Europe (at least). Moreover, SUN had licencing fees from J2ME and if I remember correctly, you could not use Java on mobile devices without paying fee to SUN. So, it was their source of income and Google abused that. Just check interview (many times referenced here in comments) with James Gosling to see what the feelins on SUN side were. At that point, they were already underdogs compared to Google. This is all about greedy Google business behaviour and I think with Oracle they just got nice sparing partner to play legal war games with. SUN was too nice for them.
I’m don't agree with that, the big reason why what Google did was so vexing was the timing.
Java was just starting to get revitalized after a long period of stagnation. Java 7 was a big deal and for a long time Android devs were limited to a weird amalgamation of Java 6 and a few Java 7 features.
Then Java 8 came with lots of great Stream goodies (and a lot more) while Android devs are still forced do to make due with unofficial backports or cutting off most Android devices (API 24) is the first to support them natively.
Android development gets mindshare for Android, not Java. The speed of the transition from Java to Kotlin shows how antsy devs were to get away from Java.
There are interesting things happening with Java, and they’re all outside of Android
> Java was just starting to get revitalized after a long period of stagnation. Java 7 was a big deal and for a long time Android devs were limited to a weird amalgamation of Java 6 and a few Java 7 features.
Counterclaim: If it were not such a big legal hazzle, it would have been a lot more easy for Google to update to new Java versions fast on Android.
Just to give examples that look plausible to me: Because of the legal burden Google decided to implement their own version of the Java standard library based on Apache Harmony.
With every new version of Java coming there might be new legal pitfalls to consider and surely almost always the sword of Damocles that Oracle might consider the fact that Google implemented new Java features as a reason to extort more money from Google since they implemented additional copyrighted APIs.
Counter-counter-claim: No, it wouldn't, because Google screwed the pooch with their update mechanism. The reason people were faced with the decision of not using the new features, using unofficial backports, or cutting off older devices is because Google could not update their devices in a reasonable manner.
What is it with all these ignorant but highly opinionated folks seemingly astro turfing for Google? Java remains very strong on the server side and it hardly needs Android to "save" it.
Java was literally dying before Google released Android. It was just something you did if you were in university or working on a legacy system. Everyone was moving to Ruby, JavaScript, and C#.
Look again. The downward trend of Java was arrested and it stayed on a plateau when Android began becoming popular; then come 2015 they both came down together.
If we're using Google Trends as a proxy for what happened, then I'd say there's some truth to Android saving Java from its decline.
On the other hand, Java was on a decline before Android, and since then it's more popular than ever. Just think how many new developers have had to "learn Java" just so they can build Android apps.
I understand the fragmentation issue, but I think it's a minor one and the net benefit for the Java ecosystem was much larger.
Also, Oracle is simply in the wrong trying to copyright APIs, and it has gotten a lot of hate from developers over that + all the other things they've done to Sun's previous projects that also made developers hate them.
With its developer-hostile attitude, is it any wonder developers are no longer interested in having anything to do with Oracle?
> Oracle said its APIs are freely available to those who want to build applications for computers and mobile devices, but draws the line at anyone who wants to use them for a competing platform or to embed them in an electronic device.
This argument that Java was dying before the arrival of Android is super suspect. At best, you could say java was stuck in a rut between 6 and 7 (similar to c++ up until c++11), but it’s industry usage had not waned.
The court isn't going to care if what Google did was damaging to the Java ecosystem. They only care if Google broke copyright law. Also, all software stacks are fragmented. Consider the alternative - some kind of machine overlord dictatorship ;)
Java was only popular in the first place because people assumed it was a free-enough language that anyone could implement. Everyone assumed the TCK license was a technicality right up until Apache Harmony was (entirely unreasonably) denied one; most of the JCP members expressed shock and dismay at that.
That was the decision that lead to Android being "Java-but-not-Java". If they'd been granted a TCK license like they should've, they'd've implemented proper Java (confirmed by the TCK) and we'd be in exactly the same situation as if Google had used OpenJDK all along.
> real damage has been done to the health of the Java ecosystem by having billions of devices run fragmented Java-but-not-Java
Even 100% running with that, damaging an ecosystem isn't against the law. You could argue that Google damaged the Erlang ecosystem by not basing Android on Erlang. Ecosystems compete with each other all the time, and it's hard for one to grow without damaging another.
I didn’t say it’s against the law, or imply it. If anything I implied the opposite with the comment about the wrong mechanism.
Actually my mistake, I assumed that you mean copyright, if you mean all laws in general, I feel there’s probably a way for Oracle to litigate, similar to how J++ went down
Did I say they were? You’re patching into the use of the word feeling.
This just seems like a replay of J++. No one outside of Oracle or Google can determine the facts behind those statements you quoted, so the best outsiders like us can do is go based on “feelings” based on basic reasoning
Yeah, seems a little strange to ask a question like that after the court already ruled in their favor. Whether you like it or not, clearly they did have a case.
In this field "having a case" depends not so much on objective truth but on subjective narrative, having enough money to pay more lawyers for a longer time than the opponent, finding the right judge, making sure the jury is stuffed according to plan and more of such skullduggery. If it were about objective facts the case would have been over and done with in a month with a definite conclusion, either it being OK to use API's without licensing or it being a violation to do so. If the outcome were the latter there would have been some bickering over how much to pay for said violation, add another month for that.
Alas, this is not about objective truth and "having a case". It is the result of a free but regulated market being infected by a parasitic organism which has turned the regulator's defence mechanisms to its own purpose, the which being the extraction of as much value as feasible while keeping the host alive.
I’m not sure if I have the timeline correct but I thought Java was owned by Sun Microsystems at the time when they made these decisions. I’m sure they rightly assumed Sun Microsystems would never do this. It is sad to see what Oracle is doing with Sun Microsystem’s creation.
This is what Oracle does with every acquisition. You wring as much revenue out of a product as possible and when you cant get anymore you toss it aside and go acquire another product/company. This is what will happen to Netsuite which was recently acquired.
It is sad. When I was young, about 16-19, I had a friend who worked for Sun Microsystems and he was an amazing mentor, and maybe twice a year I got to meet some of his colleagues too. They embodied 'the hacker' spirit that I believe hacker news represents - long grey hair, very open minded, very friendly, and loved being passionate about tech discussions while keeping an open mind and a willingness to be wrong.
These people turned me into who I am today by showing me a form of non-vain, open, intellectual curiosity that I try and emulate - the persons age, race, gender, religion -- all irrelevant -- it was about the ideas. Though they would look down on you if you used the wrong editor (go vi!) but they would smile and show you the way.
I don’t mean to be overly negative, but I hope you recognize the irony in describing your image of a hacker as someone with long, grey hair, and proceeding to say that superficial traits like appearance don’t matter, only ideas.
I did notice that after submitting it, and made a mental note in correcting it in the future. It was more for comic effect / appeal to stereotype - but that failure is mine. I'm always learning :)
It is beyond sad. Oracle bought Sun exclusively to sue Google for its use of Java in Android. (I know someone involved in the lawsuits.) We really need to fix our patent system on the software side.
- Sun was fearful of MS's EEE approach (embrace, extend, exterminate) where MS took a thing, built their own, pushed their own tooling, added their own proprietary instruction, boom windows lock-in. So Sun basically made their contract: Java is free but only if you DO NOT introduce any new instructions, and implement a 100% compatible VM, nothing added or removed.
- Sun was making _some_ money out of mobile.
- Google introduced this pre-compiled java stuff. It used Java but compiled into binary. Sun was kind of excited. Java everywhere. Even though it violated the terms sun put out, sun was happy to get more java out there.
- Google / Sun had a more or less truce.
- Oracle bought sun. Sun didn't have much business left as Linux was obliterating their Unix business.
- Oracle saw the primary income from Sun as a lawsuit against google. And licensing on every Android phone period.
> they rightly assumed Sun Microsystems would never do this
Interestingly, the article includes a quote from a Sun Microsystems co-founder who agrees with Oracle's stance on this:
> Among Oracle’s supporters in the case is Sun co-founder Scott McNealy, who said Java was created to be a platform-neutral system where programmers could “write once, run anywhere.”
> Java “is the foundation upon which our digital world is built,” McNealy said in a filing with the court. “Google stole that foundation, used it to build Android, and destroyed Oracle’s market in the process.”
I'm worried if this is again going to pose serious problems in using open source stack and building profitable solutions. So, If I'm going to build something profitable using R and Tensorflow/Keras then someday I could be sued by the consortium or Microsoft that owns Revolution Analytics (that controls R) ?
R is GPL, so as long as you're complying with the GPL terms in your use of it or derivative works, you're fine. If you make your own API-compatible reimplementation of R that isn't covered under the GPL's permission grant, though, then you might have issues (this case will in part determine what kinds of issues).
Also, the copyrights for R are mainly held by the nonprofit R Foundation, not by Revolution Analytics: https://www.r-project.org/foundation/. An API case from R copyright holders would additionally be really messy because a huge portion of the APIs originate in Bell Labs S, which they don't own the copyright to. Though there might be some sleeper case where whoever now owns the original S copyright pops up and sues R users for having cloned S's API...
Why? At worst Google will pay a couple billion for losing API suit. Oracle's patent suit already went down the tube. And by the time Oracle wins Java will be even less relevant for both Google and Oracle. Considering Oracle's Java business is sinking. They already threw away JavaEE to Eclipse and Cloud infra is heading Go way.
So instead of being hobbled by Sun JDK design decisions they worked on Dalvik and Java like paraphernalia. And big success of Android is partially due to that.
Doubt it if they still want the JVM. Sure Java the language is gone, but Kotlin on the JVM relies on the very non-Oracle-approved Java stdlib implementations that are at the root of this suit. If you want to argue Kotlin Native + NDK, sure, but it is very young (though I like it and have used it myself).
Today, Google is using the Oracle-approved form. They already switched Android from Harmony to OpenJDK in a previous release.
Since then, this suit has been about (a) deciding whether Google is guilty of wrongdoing in the past, and (b) what the extent of the damages should be for that historical wrongdoing should be, if any.
The outcome here doesn't really have any impact on the future of Android (except if Google wanted to factor the suit into their decisionmaking for their own reasons).
> The outcome here doesn't really have any impact on the future of Android
While most of your point is true, I disagree with this part. Using lawyers to tackle companies that succeed with only parts of your technology may send a chilling effect towards future uses. Also, knowing that you are not allowed to partake certain independent directions in the stack you choose for your devices is a legitimate reason to fear the continued use of that stack. Some are OK to them (e.g. conforming to the GPL on Linux) and some may not be (e.g. not being able to write portions of the stdlib without dealing w/ OpenJDK stewardship). I don't think these are their own reasons as much as they would be the reasons used by anyone who fears technologies stewarded by litigious outfits.
So you cut my comment off right at the part where I've pre-emptively addressed your entire criticism, and then you write out a paragraph detailing this criticism anyway because your position is contained squarely within the very part of my comment that you chose to leave out?
You don't get to define "for their own reasons" to mean something else just so that you have a something to argue about. Doing something for one's "own reasons" means that the decision is theirs to make, in contrast to being legally compelled to act in a certain way. It doesn't mean acting in a way that nobody else would, nor acting in a way that nobody else would agree with.
Ah, I took "doesn't really have any impact" as "doesn't really have any practical impact" instead of "doesn't have any legal impact". I thought you were making a point about it being Google's personal reasons they might justify moving on as opposed to reasonable ones based on precedence of the decision.
No? It runs on the JVM and Kotlin/JVM links the Java standard library as part of its class path and compiler emits JVM bytecode, but that's not the issue here. I feel like people do not understand what this lawsuit is about. There's also a lot of technical people here reading the decision and making tech-minded assumptions about the business strategy. A far simpler solution than reconstructing the entire ecosystem would be to just switch off Dalvik VM and use the JVM.
The problem has nothing to do with using the Java API. It has everything to do with copying the OracleJDK API and implementation then building a secondary non-compliant JVM to run it. The OracleJDK (which is different from the OpenJDK) is not licensed in a way that allows copying.
>The problem has nothing to do with using the Java API. It has everything to do with copying the OracleJDK API and implementation then building a secondary non-compliant JVM to run it. The OracleJDK (which is different from the OpenJDK) is not licensed in a way that allows copying.
Um, no. The case has solely to do with the copyright of the SSO of 37 Java API's that Google used. This has nothing to do with their VM.
>In short Google fucked up big time.
On the contrary, the CAFC fucked up big time for allowing API interfaces to be copyrighted.
Actually, both parts were incorrect. This has nothing to do with implementation whatsoever. This copyright case is based solely on the SSO of 37 Java API interfaces and nothing else.
Oracle (Sun) paid probably hundreds of engineers to invent and maintain Java. As James Gosling says https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be... they gave away a lot but charged big companies to pay the expenses. Google should have paid that freaking licensing fee
Yeah, “stealing” an API and open source, building a successful mobile UI platform (unlike personal/embedded java and Sun’s own failed attempts at fragmentation) and contributing it free back to open source where it has been used as a base OS for thousands of new products from TVs to drones.
Regardless, the CAFC has ruled -- twice -- that APIs are subject to copyright. The Supremes are likely to deny cert again, so that stands as the law of the land. You steal someone's API, you pay a penalty. Don't like it? Write your Congressman.
This only stands as law of the land when the plaintiff manages to include a patent claim (even a weak one that later gets thrown out) to force the case under the Federal Circuit's jurisdiction, as happened here. They don't normally hear copyright cases.
While I'm sure more such patent claims will get bundled with API copyright claims in the future where a plaintiff can credibly manage that, it's not otherwise the law of the land.
(An aside: I think the Federal Circuit may have considered aspects of Ninth Circuit precedent in this ruling, as they're supposed to do for non-patent issues from the Ninth Circuit. Even they might rule differently in cases from other circuits, maybe just making it the law of cases they handle from the Ninth Circuit with significant persuasive impact on how they'd rule on cases from other circuits.)
Eventually a normal Ninth (or other) Circuit panel will rule on this. They're not bound by the CAFC ruling, though they will undoubtedly consider it. As soon as one circuit rules otherwise, that will create a circuit split.
Eventually, the Supreme Court will want to resolve that circuit split and will grant cert, either changing this bad precedent even for cases that go to the Federal Circuit or truly making it the law of the land.
A Supreme Court ruling on this would only affect the current Oracle v Google case if it happens before this case is fully finalized, given the doctrine of res judicata. But it would help future cases, including between these parties about a different topic, as well as between Oracle and other companies about the Java API.
With all of that said, contacting representatives in Congress and Senate to make explicit that APIs aren't copyrightable would still be great, as would narrowing the CAFC's jurisdictions to patent claims (and its otherwise specialized areas) or eliminating it entirely.
As I understand the CAFC to work, subject matter jurisdiction only applies to determining whether CAFC can rule on a case. Once they so rule, that ruling is precedent throughout the land -- irrespective of whether the topic of their ruling fell within their subject-matter jurisdiction.
> irrespective of whether the topic of their ruling fell within their subject-matter jurisdiction.
The opposite. Binding only within their subject-matter jurisdiction.
Which is good, because this ruling is so broad it's essentially trying to argue there's no such thing as fair use (because plagiarists arent protected by fair use, and all copyright infringers are plagiarists, and fair use is inherently copyright infringement, therefore...)
Please don't use the expression "contributing back" on a platform that Google rules with an iron fist. Not only is their draconian licensing contract kept secret, for fear that consumers might realize the sort of behavior Google is up to, but now Google is explicitly implementing block screens for installing the app store on an Android device that isn't adequately under Google's thumb. This isn't the behavior of a company who is "contributing back", it is the behavior of a company doubling down on controlling the industry.
All irrelevant. If I check out an open source project, expand it significantly, fix tons of bugs, increase performance, and commit the changes upstream, I have contributed back. The fact that I have built another product on top of that isn't 100% open source does not nullify the huge contributions of the former.
Chrome isn't open source. Chromium is. Chromium contains V8. V8 alone launched the huge nodejs community. In your mind, because Chrome isn't 100% open source, the fact that you can use pieces of it that are for tremendous benefit to the community doesn't count?
Handsets aren't the only thing Android is used for. Virtually every consumer product I see launch these days used some part of Android. TVs, smart speakers, IoT devices, thermostats, car entertainment systems, set top boxes, watches, and on and on. If someone wants to do a Kickstarter on a new piece of HW, the first thing that they're going to thing of is forking a chunk of AOSP, and to deny the immense value this has enabled for people building such devices is absurdly blind. Without ASOP, many of these projects wouldn't even exist.
Your positions are transparently hypocritical for someone who was a Windows Mobile fanboy, and rarely says a negative word about Apple or Microsoft's 100% proprietary platforms.
People in glass houses (or Google offices) should not throw stones. Also, I have a much longer history of criticizing Apple than Google, and give Microsoft significant flak on a regular basis for the way they've managed several aspects of Windows 10... including Mobile. I have no financial investment or implicit bias in any of these companies such as yourself.
I have no problem with proprietary software, I have a problem with proprietary software masquerading as open software and trying to use claims like "fair use" for something tightly controlled with secret arrangements and bullying the industry into compliance.
I would argue Android offers little benefit to the niches you detail, the only reason other Linux flavors don't make more sense is because they're taking advantage of the fact that they have to have Android developers anyways, because of app support. Android is not a good OS for smart devices, most of the bloat it shoves on top of Linux has little benefit to single-purpose hardware. I don't think Google gets to claim credit for the entire smart device market.
The proof is in the pudding. Prior to the introduction of Android, embedded Linux in consumer electronics was awful and many devices often selected Windows Embedded, QNX, etc. I worked on embedded Windows in automotive devices and know first hand how a) horrible it was (slow, buggy, insecure) and b) how horrible to Linux replacements were that tried to rig up a half functioning platform.
Most small companies do not have the skills to take vanilla Linux userspace, or even Debian or Ubuntu, and build out a polished mobile platform that they can shove into a thermostat or watch. The only semi-popular Linux attempts that succeeded in volume were HTML based like WebOS, which again, simply used a fork of an off the shelf complete platform mostly built by a corporation (e.g. WebKit)
You can argue all you want, but evidence suggests otherwise. Someone building a sealed, firmware for a device today that doesn't permit third party apps, still chooses AOSP as a base more often than not, and the reason they do so, is because there is huge value in the platform. Whether you like the design or not, whether you think it is bloated or not, people think that using AOSP to bootstrap their HW lowers their time to market or costs. And for those people, they are receiving value.
Do you oppose copyright on all software, i. e. source code, as well?
Because I could somewhat understand that sort of IP anarchism, although I wouldn't agree. But I'm having a hard time thinking about a coherent reasoning to see source code as copyrightable, yet deny the same to APIs.
Copyright applies to any creative endeavours that reach a certain level of breath and/or depth. Having been involved in a few library projects, I have witnessed quite a few where I would say the API was far more important, and sometimes took more work, than the underlying implementation.
Look, for example, at all the work done in standard-setting bodies: RFCs, WHATWG, etc. They are all licensed freely, yes. But the attachment of licenses to those documents implies an acknowledgement by the authors (and the community) that their work falls under copyright.
Yes, I (personally) oppose patent protection and copyright on software, and barring that, severe time limits, like say, 5 years. You really think an API should be protected from forking or reimplementation for A CENTURY? It's absurd, Oracle agrees with me (see link at bottom)
The entire PC industry was launched because clean room re-implementation of the API of the BIOS broke IBM's stranglehold. Is the world better without WINE? Without game or CPU emulators?
I am philosophically opposed to the idea of API copyrights especially. This is a corporate battle whose collateral damage is going to harm the entire industry.
It's funny how everyone loves forking, until tribalism kicks in, and then people start granting mulligans on philosophy just because of tribal positions on whichever company they don't like. Remember this? http://www.gordoni.com/software-patents/statements/oracle.st...
"Oracle Corporation opposes the patentability of software"
"A balance of fifty years protection for direct copying of code would continue to be provided by copyright law."
Funny how perspective changes if you perform a buyout of a struggling company's assets to use it to shakedown the market.
I was a huge C64/Amiga fan, but I honestly don't think it would have been Atari or Amiga, both companies were horribly managed. And the Mac was just horrifically overpriced for what you got. At the same time Apple was shipping a $2k non-multitasking, B&W, 128k computer with shitty graphics and sound, Commodore was shipping the Amiga 1000, with twice the memory, and a custom chipset that was not equaled until years later by VGA, or to be honest, SVGA, and at half the price of the Mac 128k.
IMHO, the Amiga 1000 was the 'iPhone' of personal computers, ridiculously better than the Mac and PC at its launch date, it was a step-function better than the Mac. But Commodore was a bungling, mismanaged company that flushed a great opportunity down the drain. It's like if you invented the iPhone, but didn't know how to sell it, market it, and get product market fit.
Commodore was vertically integrated like Apple of today, they had a stellar custom chip development team, and had revolutionary chips in the worlds (AAA and Hombre) that would have been like 3dfx, but in 1992, delivering a quantum leap in gfx and single-texturing 3d pipeline well before others.
I'm really bummed the company flushed it down the toilet and "Xerox PARC"'ed itself, by having a winning team of researchers and engineers, but not being able to make a business.
>Do you oppose copyright on all software, i. e. source code, as well?
That has nothing to do with anything. Copyright is a human construct. Somethings are decided to be copyrightable and somethings are not. Not every creative endeavor should be copyrighted, other should, and other should with major limitations. APIs were never copyrightable. Ever. The computing and programming industry developed with this assumption - in fact, it may not have ever developed if that wasn't the case. Why does this need to change now? And not even through a new law but rather court re-interpretation.
My point is that there should be some criteria that determine if something should fall under copyright. And I'm having a hard time finding such a set that contains source code but does not include a (sufficiently extensive) API.
You're just asserting tradition. Yet you are not addressing my examples that directly show precedent within the industry for recognising copyright for APIs.
As I undestand it, there is a principle that legal contracts themselves cannot be copyrighted, despite the fact that they might well be the result of a considerable amount of creative work. The underlying principle here is that the legal effect itself cannot be subject to exclusive ownership, and the only way to get the same legal effect is to have the same contract.
I believe APIs can be considered under an analogous principle - that is, the ability to interoperate with a set of existing code shouldn't be subject to exclusive ownership, and you can't interoperate with the same existing code without implementing the same API, so APIs should not be copyrightable. (This draws a distinction between the API itself and the underlying implementation of that API).
The first smartphones had only 128mb of RAM and very slow performance. To remain compatible means supporting Swing, Java2D, CORBA, and a ton of other non-optional APIs included in the JDK. This was not really technically feasible in 2007.
For decades, people had been producing Java forks which weren't compatible, Sun didn't do much about them, and even encouraged them. Their main idea was to charge for the TCK and the right to use the Java(tm). Remember Ghost and WabaVM for PalmOS? Remember Kaffe +Classpath?
I'd argue that the idea of write-once-run-anywhere with a one-size-fits-all UI layer from mobile to server is a pretty bad idea. Apple seems to understand this, which is why iOS differs from NextSTEP.
I wonder how the $$ Google might pay to Oracle compares to the $$ it is spending to move away from Java by building replacements (v8, Go, Dart, Flutter/Fuschia, etc.) that are all essentially "GC languages with a great runtime VM".
E.g. I can understand Oracle/Sun needing some amount of money for stewarding Java, as the teams required to build/maintain/QA/release the JVM were AFAIU in the hundreds, so not cheap. But "Java is free", so they didn't have a way for covering that cost from the majority of enterprise developers who were getting a free lunch, and instead relied on the J2ME licensing almost by accident/happenstance IMO.
So now, companies like Google are not "paying for hundreds of Oracle/Sun engineers to develop a platform/language/ecosystem", but instead "paying hundreds of internal engineers to develop (multiple) platforms/languages/ecosystems".
Which they can do, and still provide v8/Go/Dart/etc. "for free" because they have the luxury of paying for everything with ads, which Oracle/Sun didn't, which forced Oracle/Sun to commit the sin of asking for money.
Granted, don't want to be an Oracle/Sun apologist b/c they messed up in a lot of ways (stagnated the language/etc., don't have a great reputation, etc.) and the competition/iteration of the next-gen languages like Kotlin/TypeScript/Go/etc. is working out great.
Just interesting to think of the economic trade-off, e.g. if Oracle had been a little less controlling, and Google a little more willing to pay licensing/something, if the net effect would have been Java today being in a demonstrably stronger market position than it is.
And, either way, the rest of us are still being spoiled by so many free lunches: amazing tech (languages/libraries/frameworks/ecosystems) built by professional teams that we don't pay a dime for.
V8 has little to do with Oracle, fundamentally. V8 came about because they wanted a higher performance JS VM for their browser; the JVM was never in contention there.
Sure it does. Why did they want a higher performance JS VM for the browser? The language of choice to build interactive applications on the web before JS was really viable was Java.
A high performance JS VM means we don't need to use applets anymore.
And V8 was first released in 2008. Java applets were pretty much completely gone from the web by this point. The only competition on the web, from plugins, at that point was Flash (okay, Silverlight deserves a footnote, but little more).
> The language of choice to build interactive applications on the web before JS was really viable was Java.
I find this amusing. No one ever built anything meaningful client-side with Java. There's a reason Microsoft laughed off Java as "write once, debug many".
Um Eclipse? Netbeans? ArgoUML? (just out of top of my head).
Your statement would be true if you have said "anything meaningful client-side on the web with Java". On the web Java was restricted to Java applets and was never really in competition with JavaScript.
Not Flash? In my experience Java applets never got anywhere close to the level of adoption of Flash. I suppose it might've been different in corporate environments. I had Flash enabled in my browser long after I stopped using Java applets altogether, if only for video streaming.
Corporate environments were different (easy was to expose Java business program to user without hiring Web people), but the doom of Java in the browser was the whole applet concept and not the DOM integration that JavaScript had. It might have been quite a difference if the JVM could have controlled the webpage like JavaScript.
This is ignorant. The rise of Javascript had little to nothing to do with the fall of Java applets, which failed due to their own issues.
Java applets were already considered a dying tech when Google made their push to heavily-Javascript-dependent apps, and the performance requirements that led to.
Note also that despite the similar name, Javascript and Java have technically nothing to do with each other. It is a quirk of business history [1] that Netscape and Sun partnered to name Javascript as it is when Sun was first pushing Java as a web technology.
There was no DOM back in the early days of Javascript. The page was rendered in a single pass, you could inject text and markup via document.write() and anything "dynamic" was accomplished by reloading an IFRAME. Remember, these were the days when too many tables would crash your browser; I recall the early demos of Gecko showing deeply nested tables, and all styling was with font tags still.
Netscape was still trying to sell a browser, and they wanted a common language on the frontend and backend, so Javascript was also on Netscape Server.
I would be willing to contend that in the view of "Java applets are where the web is going" back then, the difficulty of communication between the applet and the enclosing page was something that needed some scripting glue and that JavaScript, from its inception, was to be that glue. It took about a year to get it working, but this was the initial goal of JavaScript.
In underlying code you are correct. But they both work in a C/C++ style. JavaScript has become a 'Write Once, Run Anywhere' foundation because of the web browser. Don't forget projects like NWJS (Node Webkit), Electron, Cordova/PhoneGap, Google Chrome Apps, NodeJS, and ClearScript(.NET).
All of these JavaScript implementations use the V8 JVM and can make desktop and command line application. Depending on security settings they can give partial to full system access to the underlying OS just like Java. If this ruling is upheld I would look for Oracle to float a trial balloon on newer JavaScript implementations and for stealing their Java's API's.
> And, either way, the rest of us are still being spoiled by so many free lunches: amazing tech (languages/libraries/frameworks/ecosystems) built by professional teams that we don't pay a dime for.
Don't those things realistically exist precisely because of a virtuous, continual cycle in the greater tech community of paying that free lunch forward?
Even the strictly free lunch use cases, where someone doesn't contribute time/money/effort back into the system, involve helping to popularize the whole and keeping it going; broadening it, spreading it, bringing more contributors in. Those people end up as popularizers/evangelists, which is a required ingredient for the virtuous cycle to keep going.
I think the part that gets lost in all of this is that Sun offered to license Java to Google previously for $100M. [1] Google turned that down and bypassed Sun because they didn't want to pay (or license). At the time, Sun was happy to see Java being used by Google, even without the license. Still, Google knew exactly what they were doing. [2] My point is, they did this to themselves and they knew what they were possibly getting into.
Call me naive, but is a company being happy with what you're doing to the tune of them even saying so (or representatives thereof) tantamount to an implicit contract? I know it's been argued in this case, but it strikes me as disingenuous at the least and fraudulent at the most to change your mind. Sure we don't mind Google bearing the brunt of this because they can, but how would we feel were a smaller company subject to this kind of bait and switch based on legalities?
Estoppel: This my be my new favorite word. I can imagine all kinds of scenarios for use (okay, I can imagine one) "You can try to renege on your promises, but I'll estop you, I'll estop you once & for all!"
This isn't a bait and switch based on legalities. If Oracle made representations to Google that they didn't mind them using their software, Google would be able to claim that Oracle is estopped from pursuing a claim due to the prior authorization they received.
What's being stated here is that Google's infringement improved Oracle's market position - that fact doesn't bar Oracle from pursuing their remedy against infringement. If you steal my software for making phones chirp every time you get a tweet and widely distribute it to the point that it becomes the de-facto standard in the tweet notification market, it doesn't magically mean that I don't get to come after you for stealing my tweet tech.
Here's the decision itself. Estopple is mentioned 0 times. This isn't because Google's legal team is braindead. It's because the argument that the Google's use was authorized following them walking away mid-licensing negotiation is insane. Google's defense is based on fair use.
http://www.cafc.uscourts.gov/sites/default/files/opinions-or...
If I hand you a bag of balls and say you're allowed to play with the purple and green balls inside, I haven't given you permission to play with any of the other balls.
In this case, the different balls are the different dismemberments/rights related to Java.
Sun defended Java with the trademark and the compatibility kit, not copyright on the API. It never occurred to anyone (as it shouldn't now) that there was copyright on the API.
[edit] Jonathan Schwartz: "The strategy was, we agree on these open APIs, then we compete on implementations."
I am not sure you are familiar with the entire case regarding Sun's public approval of Google's Java use. Oracle argued it was the CEO's personal blog, but the CEO definitely did give a form of "green light" depending upon your interpretation. It's a defense I feel like is easy to do against a large company that "should have known better", but would be considered unfair against a smaller company that was essentially given approval. I won't address the rest of your comment that is out of context since it's missing this important fact.
I'm familiar with the case. The comment isn't out of context; you (and other posters) need to recognize that IP rights are composite rights, like real estate.
In real estate, you can own a plot of land and provide others with permissions associated with the land; maybe they're allowed to walk over a path that runs through your land. That permission is not equivalent to all possible permissions associated with the land - although maybe some ancillary ones are implied in. Maybe people are allowed to bike over the path too, but they certainly aren't allowed to dump broken washing machines there.
Similarly, in IP I can grant you a set of rights related to my product without giving you ALL rights related to my product.
To use your own analogy it seems like we are only talking about one singular right. Making derivative work thereof. If not can you clarify your position?
But the thing is Google didn't use the Oracle Java engine. They implemented their own runtime environment that's mostly API compatible with Java (and getting further from that as the years go on).
This gets into really critical concerns around APIs. If commercial product A sucks and I'm in a shop where we made our own drop in replacement that implement's A's APIs .. then we open source that drop-in replacement and put it on Github so anyone can use it, are we no violating their copyright just by implementing their API?
This can set dangerous prescient when it comes to interoperability and reverse engineering.
Mobile Telecoms standards are written by 3GPP, all BTSs and handsets (and for that matter, interfaces like 'A') are standard, and controlled by 3GPP. I believe they are open.
I'd say it's patent law, not copyright law, that make the licences possible to enforce.
Most of the patents are the result of a lot of research and cleverness. Some of the patents are the equivalent of looking in another drawer if the first one did not contain what you are looking in.
It's a bit arbitrary that an API isn't protected when some bullshit patents are. There is clearly much thought in some of the java APIs.
I'd like to see shorter protection time for patents thought, especially in areas where there are very low investment costs, like software development.
In my experience the big hurdle is getting your device certified, not licensing issues. That's not really an IP issue however, it's just that uncertified devices might misbehave and create issues for other users.
> They implemented their own runtime environment that's mostly API compatible with Java (and getting further from that as the years go on).
That's not quite right - Google adopted Apache Harmony[1] (an open source project, and if you want to attribute an organisation responsible for Harmony's success - such as it was - it would be IBM). Apache Harmony would have been 100% API compatible with Java had Sun (and later Oracle) not refused to provide the Technology Compatibility Kit (TCK).
The Android runtimes (Dalvik, then ART) never had compatibility with Java bytecode, instead, Android build-tools use(d) Java bytecode as an intermediate pipeline step; the ultimate executable had 0% compatibility with the Java runtime.
I don't think that's quite right, either (though I could be wrong). IIRC, Android first was done based on Sun/Oracle Java. Then (and maybe even after the lawsuit started?), Google shifted to Harmony.
Are you perhaps referring to Android's very recent switch to GPL-licensed OpenJDK[1] from Harmony after the lawsuit? There was no GPL licensed (and certified) version of Java when the Android project kicked off - OpenJDK came into existance later. Also - Apache Harmony predated OpenJDK by a few years.
> The issue is can a public API be copyrighted. That is the scary issue.
In Roman Law there is the principle "In dubio pro reo" (https://en.wikipedia.org/wiki/In_dubio_pro_reo), which means that if there are doubts whether the culprit is guilty or not, he/she may not be convicted.
I feel like this probably is intended to apply in criminal cases and not civil. (And a copyright case like this would certainly be civil, and not criminal)
In the US, it at least seems that something similar does, in so far as we require a unanimous vote by the jury to convict someone in a criminal trial, but a simple majority for a civil.
I don't get why it's a scary issue or even controversial why an API would be subject copyright. An API, in my mind, is similar to design drawings or blueprints. Independently figuring out how to implement those drawings doesn't change the fact that you copied the design.
If you apply this view to all APIs, the computer revolution would never have happened. The PC was a clone of IBMs API. They fought this battle and lost and now we can argue about it on little handheld clones all day long.
In fact, IBM was so sure that the BIOS API could not be copyrighted they basically made their source public (in the manuals but NOT open source) so anyone reading the manuals to understand the BIOS was tainted and couldn't write a competitor. Compaq did a clean room setup to get around this.
>IBM was so sure that the BIOS API could not be copyrighted they basically made their source public
That is not how copyright works. You almost got it right with your comment "anyone reading the manuals to understand the BIOS was tainted and couldn't write a competitor."
Copyright protects against copying. It does not protect against independent development. Hence the clean room set up.
If the BIOS API was copyrightable, they would have had to do nothing and simply declare that they owned the copyright to the API and thus no clones. Since they couldn't do that, they had to go to the extra step.
That is simply incorrect. Copyright covers copying. It does not cover independent re-implementation. That is the point of clean-room re-implementation. It is not copying because--> clean room.
Silly Example: you design a phone book containing all the names and phone numbers of everyone in the city. To the extent that any subjective decisions were made in the design, it is a copyrighted work. I design a phone book. If I copy yours, it is a violation of your copyright. If I collate the underlying information and then make my own phone book it is not copying, even if it looks exactly the same.
No, you are not getting the point of the whole "copyright the API" thing this discussion is talking about. If I can copyright the API then it doesn't matter if you clean room or not since the API is copyright and I can sue the heck out of you no matter how you did your work. That is my point that you are missing. IBM didn't believe they could copyright the API so they took some additional measures. If they thought the API was copyrightable then Compaq would have gotten sued out of existence. This is what makes Oracle's assertion so scary for the computer industry.
Actually, you're not getting it. Copyright means I can't copy your work. If I arrive independently at the same thing, then I didn't copy your work and therefore didn't violate your copyright.
If I take your picture of a building and copy that's a copyright violation.
If I take a picture of a building from the exact same angle you did, that's not a copyright violation.
> If I arrive independently at the same thing, then I didn't copy your work and therefore didn't violate your copyright.
That's not how it works for copyright. Beyond that, how do you independently arrive at an API that you are trying to have an exact copy of? Photography is not programming. I cannot run a bunch of words through a program until it prints out some book I want and then say I arrived at it independently. You honestly need to read the copyright laws as you are missing some information.
[edit: the original premise of all this thread is IBM didn't try to copyright the BIOS API]
I suppose you could argue that black box reproduction is simply an elaborate form of copying. That's not relevant to this case because Google did simply just copy it.
Then why did you bring it up? My original post was about a situation where the creator of an API didn't believe it to be copyrightable and then made an attempt at protecting it a different way. Oracle believes they can copyright an API and almost everything in the industry was built with the belief that you cannot copyright an API.
Relevant portion "But one problem remained with their IBM-compatible machine. How would they recreate the IBM BIOS without breaching the copyright? Why did they need a compatible BIOS (basic input output system)? . . . Some companies, such as Eagle, copied the BIOS either by reading the IBM manual to understand which interrupt codes did what or by simply copying the hard-coded ROM chip that holds the BIOS. This breached the copyright that IBM had over the BIOS and so did not take IBM long to prevent such companies from selling more of those machines. However, there is a way to bypass these types of copyrights with the use of a “clean room”."
Your original post was about IBM not being able to copyright the PC Bios. Which is simply not true in any way shape or form.
No, no, no, that is not what I said. I was talking about the API of the BIOS. The BIOS source code is, of course, copyrightable. That is why IBM was able to make it very hard for people to copy it until folks did a proper clean room. Why would I go into detail about the counter measure if it was not copyrightable? That makes no sense.
Interesting edit to your original post. So their countermeasure was to try to taint everyone in the whole universe so a clean room reimplimentation would not be possible? Wow. Interesting interpretation.
That is not an interpretation, that was an actual strategy. They put enough information and source code into the documents that described its function to taint anyone who read the documentation. There are multiple sources (and I do believe some TV) on IBM's strategy. Compaq's Garry Stimac realized the problem when he read the manuals. A clean room strategy was setup.
You said:
>My original post was about a situation where the creator of an API didn't believe it to be copyrightable and then made an attempt at protecting it a different way.
What "different way" are we talking about here? IBM asserted their copyright quite forcefully against Eagle and shut them down.
The API of a BIOS is not the whole thing! It just specifies the interface by which the BIOS can be called by the OS.
For a crude analogy, consider the interface specification that most modern cars adhere to: there will be a steering wheel with a certain shape, size, and position relative to the driver's seat; there will be two or three pedals, with the accelerator on the right, the brake pedal to its left, and the clutch pedal, if present, to the left of the brake; etc. etc. None of this tells you whether the car runs on gasoline, diesel, CNG, or electricity, or whether the motor is in the back or the front, how many cylinders it has, etc. — all these are implementation details that do not usually affect the interface much.
The implementation of the BIOS — the code that actually performs its various functions — is clearly copyrightable, and always has been. But the API is just the specification of what those functions are and how they can be invoked. Imagine if one car manufacturer had been able to copyright the steering wheel and pedal arrangement that we're all familiar with!
That's true, but if you type and distribute a book that happens to match the latest Harry Potter, nobody - including the courts - will believe you independently came up with that exact sequence of words.
Similarly, if you copy the definitions of all functions/methods/classes/etc from one API, nobody will believe you independently came up with it.
It's hard to tell about APIs, since there's no caselaw, but the rule for texts is that the smaller they are, the more original they have to be to qualify for copyright protection - so conversely, the sheer length of a work makes it more likely to be protected even if it's not that original.
So "add(a, b) returning the sum of the two" is probably not copyrightable by itself, but a whole namespace full of functions might be.
No. But the court explicitly looked at that and said that there was enough creativity in the choice of what names to give methods and how to group methods that the Java API qualifies as a creative work (and I don't think anyone would really dispute that).
Replying to your comment below. I am not missing your point. I am merely pointing out that your point is incorrect as a matter of law. Copyright does not cover re-implementation. Copyright only covers copying. Your statement that IBM could sue company using a clean-room developed re-implementation of IMB's BIOS if IBM owned a copyright to their BIOS is incorrect as a matter of law.
> Copyright does not cover re-implementation. Copyright only covers copying.
Coypright covers derivative works of copyright-protected works, as well as literal copies. If APIs are copyrightable, there is a very good case to be made that a reimplementation of an API implementation (not an API that serves a similar function, but an actual reimplementation) is a derivative work of the API itself.
> However, the Oracle Google case is not about derivative works.
The Copyright Act, however, is; if APIs are protected by copyright, than making a derivative work of an API is an exclusive right of the copyright owner.
Which is a key reason why there is widespread concern about the CAFCs ruling on API copyright. (OTOH, Google losing on fair use at the CAFC makes it more likely that the API copyright issue gets to the Supreme Court in this case rather than a later one, so it might be a good thing for resolving that concern.)
No literal copying of text is required for something to be a derivative work. Transforming a work implementing an API into documentation describing the API would produce a derivative work of that API, if the API is protected by copyright. Transforming that documentation of the API into another implementation of that API would also produce another derived work of the API.
> Your statement that IBM could sue company using a clean-room developed re-implementation of IMB's BIOS if IBM owned a copyright to their BIOS is incorrect as a matter of law.
To the extent that it's relevant here, that appears to be untrue. This hinges on the fact that with an API, you have to match it exactly, and there's no reasonable way to argue that someone could sit down and do a clean room implementation of the Java APIs that perfectly matched all 3000 classes and all the public interfaces of all those classes.
You can do a clean room implementation of the Java Platform, but you can't do a clean room design of the Java APIs. The whole point you're trying to solve is to make something that's compatible with Java, and that requires knowing the Java APIs, i.e., it's not a clean room. If we extrapolate that back to IBM and clones, as long as the clone makers must come up with the same external API as the IBM BIOS, then this court would say that IBM absolutely could use copyright law to prohibit clones, because the clones would have to have copied the APIs -- not the code, but the names and types used in the APIs themselves, and IBM holds copyright to those names.
Clean-room reverse engineering produces an implementation that is not a derivative of the original implementation. But if the API itself is copyrightable as a separate work from the implementation, then you have to consider whether the API of the reverse engineered implementation is a derivative of the API of the original implementation. The answer to this question is rather obviously yes, since the reverse engineering process is all about separating the API from the implementation and copying only the former. Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable.
> Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable.
I disagree. However, I am not aware of any caselaw on this point. It is an interesting logical twist you have added, but I fail to see how it must be that way in view of the fact that copyright explicitly allows clean-room type reverse engineering.
> in view of the fact that copyright explicitly allows clean-room type reverse engineering.
The legal status of reverse engineering is not at all clear-cut. There are many nuances depending on the circumstances, and much of it is determined by case law rather than statute. There's no clear basis for you to make claims about how this new class of copyright (on APIs) will interact with reverse engineering. However, it is much simpler to state that if APIs are a work subject to copyright, then it must be possible to make derivative works of APIs that are also subject to copyright absent any explicit exception or fair use right.
Well of course it is possible to make derivatives of APIs that are also subject to copyright. My point is that it is also possible to make a clean room reimplimentation that is not a derivative work, which is much more valuable. Just don't copy is the lesson here.
> My point is that it is also possible to make a clean room reimplimentation that is not a derivative work,
You have not at all established this point. What makes you think that the API of a reverse engineered implementation is not tainted by the copyright of the original API? It's clear that clean room reverse engineering produces an independent implementation, but it also seems clear that such a technique does not prevent the structure, sequence and organization of the original API from strongly influencing the structure, sequence and organization of the reimplementation's API.
...I don't really see what the difference is. In both cases Google would end up with exactly the same API specification. There's no room for them to come up with an "original" API, because if the API they end up with is not an _exact copy_ of Oracle's, then software written for Oracle's Java implementation would not be compatible with Google's Java implementation (and vice-versa).
It is effectively impossible to take something as complex as the Java API, do black box testing, and come up with an exact copy. Google's API being slightly different is ultimately the point. The process yields a new original work even if it ends up being 99% the same as Oracle's API.
The 1% that's different being... what? Bugs? Like I said, any differences in Google's version of the API would, by definition, be interoperability problems that need to be corrected.
To make that more concrete: if Oracle's string concatenation function is called `String.concat` and Google's is called `String.append`, then code which calls `String.concat` isn't going to work with Google's implementation, and code which calls `String.append` isn't going to work with Oracle's implementation. It doesn't matter if the APIs are "similar" or not, they have to be _identical_ in order for code written for one system to be interoperable with the other.
The 1% will be things like String.methodNoOneUses or ObscureClass. Even if they aren't identical they will be close enough for 99.999% of the programs people write.
And once again, you'd end up in exactly this legal situation since the names are visible via reflection, but somehow aren't functional as viewed by the court.
That's one of the most important issues with this ruling; it effectively bans even black box reimplementations.
So bugs nobody files then? Why do you think this is a useful distinction. Either APIs aren't copyrightable or we should pass a law that says they aren't immediately.
APIs are copyrightable under a CAFC decision notionally applying 9th Circuit law in this case which the Supreme Court declined to review because, pending the resolution of other issues, they viewed it as not ripe for review. Since this is not within the CAFCs special subject-matter domain (patents or any of the other areas which bring a case within it's jurisdiction; this case is at CAFC because to once had patent claims even though they are no longer live), this ruling doesn't seem to be binding precedent on any lower court. So, it's “law” in only a very weak and tenuous sense.
It's neither express in the statute nor is it in case law binding on any court, because while CAFC decisions are nationally binding, that is only on the subject matter uniquely assigned to the CAFC, but that doesn't include copyright. Those are claims the CAFC decided under 9th Circuit case law in a case that is in its jurisdiction because it once had patent claims, even though those claims aren't active. Had the actual 9th Circuit ruled this way, it would be 9th Circuit case law, but the CAFC applying (notionally) 9th Circuit case law doesn't create new 9th Circuit case law. It doesn't even create precedent binding on future CAFC panels, even if those panels are themselves applying 9th Circuit case law. It is at most persuasive authority, rather than binding authority, in any future case, so it is only “law” in the sense that, e.g., scholarly treatises on the law are “law”.
So, barring this case being both heard and affirmed by the Supreme Court, this interpretation of copyright law, while potentially decisive in the outcome of the present case, isn't, substantially, law, so much as an idea of what the law might be.
Bugs are a red-herring to the discussion. Bugs doesn't get you out of copying. The question is: did you copy or not? Google argued "we certainly did copy but APIs can't be copyrighted." Which was not the law at the time they did the copying and is not the law now .
Except it is the law now and then that APIs aren't copyrightable according to the court that's generally supposed to handle such things, in this instance The US Court of Appeals for the Ninth Circuit. They've ruled plenty of times on the matter, and have developed decades of case law stating that implementing APIs is totally kosher. Sony v. Bleem is great example. There the appeals court ruled that not only could Bleem ship a PS1 emulator with reverse engineered APIs of the kernel (explicitly as a commercial venture even!), but they could port it to a competitor's game console (the Dreamcast), and use Sony's IP in screenshots.
But, because Oracle v. Google case had an ancillary patent question in an earlier appeal, the appeals are instead going to the Court of Appeals for the Federal Circuit. This court is really only supposed to answer patent questions. The CAFC can't set precedent in these matters, and overwhelmingly defers to the district courts' precedent. Bot for some reason they have chose to ignore all of that this time and make their own, fresh (and super weak) precedent that only applies to copyright cases with patent questions.
Eh, I wouldn't go that far. CAFC judges just tend to be appointed (at least a little) for how much of a hard on they have intellectual property rights in general. The whole circuit was setup pretty much only to do patent appeals for the most part. The judges probably just think of themselves as 'principled'. And they are technically allowed to do this, despite it being kind of a dick move.
>APIs aren't copyrightable according to the court that's generally supposed to handle such things, in this instance The US Court of Appeals for the Ninth Circuit
That is just not true. According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.
> According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.
The Federal Circuit has the right to hear and decide this particular case, but they do not have the right to establish binding precedent on lower courts or other appeals courts in matters of copyright law. This has been explained to you repeatedly.
So? The proper response would have been for Google to either pay the license or develop their own write once use anywhere software. Instead, the took the shortcut of copying someone's hard work.
By that logic WINE shouldn't be allowed to exist either, since it copies Windows' API.
Copying APIs is strictly necessary for interoperability. Allowing APIs to be copyrightable encourages monopolies by legally prohibiting newcomers' software from being compatible with their competition.
It'd be like if Microsoft were allowed to sue Google Docs and Libreoffice for making their software able to open Word documents. (Except in this case the "documents" are source code.)
I'm not sure how WINE works. But I just don't see that being the case. All WINE has to do is capture the API calls and transform them into a different WINE API call that ends up performing the same function and then proceed with zero copyright issues.
> All WINE has to do is capture the API calls and transform them into a different WINE API call that ends up performing the same function
How can it "capture" the calls without knowing what it's capturing? It has to know that there's a windows API function called "CreateWindowEx" that takes particular parameters, otherwise how could it possibly "translate" it? And the fact that CreateWindowEx takes particular parameters is precisely the API.
Of course the implementation of that API will be different in WINE, just as Google's implementations of the Java API are different from Sun's (aside from the 9-line rangeCheck which is a separate issue). In fact it would be fair to describe what Android does as "capture the API calls and transform them into a different Dalvik API call that ends up performing the same function".
> All WINE has to do is capture the [Windows] API calls
So... you're saying it needs to implement the Windows API? If APIs are copyrightable, then that's a violation of Microsoft's copyright. You've included a copy of Windows' API in WINE.
Unfortunately courts don't pay attention to your opinion. They only pay attention to grumpy old codgers who don't really understand technology or innovation. They only understand precendents or long ago useless decisions of previous courts and the pragmatism of someone raised on thoughts on computers and ideas of fairness from the 1950s.
People who reversed engineered the IBM BIOS had the API specification -- actually they had the entire source code. They didn't just fire random interrupts at the BIOS and see what it did. But what they did do was take that specification and describe it the detail necessary for completely fresh implementation.
Not true at all. It was a clean-room reverse engineering job. Yes, they could have looked at the API, but they did not. More specifically, they erected an information wall between those who had the API specification and those who did not, and used the results from those who did not.
One team looked at the API and source code and everything and used that to develop the specification for the "clean" team to implement. That's the point. Collectively they didn't start with nothing.
I don't see how the size of the spec has anything to do with it. It could be the standard height of doors or the standard interface/protocol between every sensor and smart component in a smart home.
What if I create my own smart home server that can be a drop in replacement for some commercial product using just what I've gather from their public API? Is that infringement, when the underlying implementation is entirely my own?
You can't copyright trivial work so the size of the spec matters.
It depends on how you create your server. If you go to their website, look at their API, and start typing identical code then that's not ok. It's pretty clearly copying. If you do black box testing and then write your own API that's fine. It's clearly not copying but a new original work.
Generally, anything can be copyrighted as long as it's sufficiently original. The phrase “I have abandoned my search for truth and am now looking for a good fantasy”, for example, is under copyright by Ashleigh Brilliant, who own a case against a t-shirt manufacturer using it.
It's more analogous to -- very analogous to -- the "clean room" BIOS clones that enabled the PC Clone industry to take off (and made IBM-compatible PCs actually affordable; before the clones took off, IBM's prices made Apple seem like a bargain).
Except Google did not do a clean room clone. They simply copied, thus violating the whole point of copyright. If they had developed their own API that simply used different names but was functionally identical, they would not have violated copyright. Copyright protects against copying. They didn't do that because they wanted to take advantage of the huge existing JAVA developer base who would easily be able to use the copied APIs to develop for Android. I.e., Google chose to copy and thus are liable for that choice.
AS has been covered elsewhere, an API is a functional description and not copyrightable, irrespective of what a specific court says. This specific court has had its rulings slapped about so much by the next higher court, it is a wonder that they haven't just packed up and gone home.
That is why telephone books and others things are not copyrightable. They are lists of facts. API's are lists of facts, a functional specification for use.
There are consequences if this stands and it will not be to our benefit as programmers, developers, designers, etc. Nor will it be to the benefit of society as a whole.
Telephone books are copyrightable. This is black letter law.
As said by the Supreme Court in Feist, "Notwithstanding a valid copyright, a subsequent compiler remains free to use the facts contained in another's publication to aid in preparing a competing work, so long as the competing work does not feature the same selection and arrangement,"
In other words, if it does feature the same selection and arrangement, it is a violation of copyright.
Your statement that APIs are not copyrightable is not true as well.
It depends on your meaning of functionally identical. In the hypothetical non-copied Android ecosystem, it could be functionally identical. In terms of interoperating with Java, no. But I fail to see the relevance of the latter point with respect to copyright. Copyright says: don't copy. If that unfortunately makes it difficult to leverage the existing Java developer base for your multi-corps next megaproject, too bad. Develop your own ecosystem.
Yes, but you can't copyright the technical structure - so the acoustically designed internal structure can be copied unless it's protected by IPR other than copyright (patent, industrial design rights, whatever). The external appearance, AIUI, is chosen primarily on artistic merit and so would be under copyright. Facets that are technical, how panels are adhered, how drainage works, they could be copied.
Using this as an analogy for the API would mean anything that was part of the technical implementation could be copied but inconsequential or artistic parts couldn't. This has been interpreted to mean that the actual code is "creative", so you'd have the framework of the code but not the non-essential parts that could be different and still allow the API to work.
It's scary because let's say you are competing with someone, so you decide to copy their API to make it easy for people to migrate over to your system rather than use their system. Now, instead of just doing that, you have to get a license to use the API. Otherwise, you are a copyright infringer.
Here is an example of a potential copyright infringer copying the API for another competing service. I'd hope they acquired a license for it, otherwise.
The API is less like the blueprints and more like the building code. This is perhaps a bad example as many building codes are copyrighted, but a lot of people find this as absurd as copywriting an API.
Building codes being copyrighted is fine. But if I want to make my own building code, but have all existing builders be able to easily transition, then I must necessirily be making a copy.
How is an API different than any other product specification? Why can't e.g. Panasonic sue other manufacturers for making an 18650 form factor battery cell? Why can't Ford license the form factor that every car uses for a gas nozzle? There's fundamentally not a way to create your own compatible implementation without using the same API.
Panasonic and Ford own copyrights on their CAD drawings for those items. So I can't just CTRL C and CTRL V and send them off to a manufacturer to get my own stuff made. I can, however, measure those things and create my own drawings without violating copyright because I am not reproducing the work.
Reflection means that you can, through automation, observe the complete set of public classes, methods, and fields in the java api without ever looking at docs. You can put together a script to do this in 15 minutes.
Design drawings is an implementation, not an API. Copying a drawing is like copy-pasting code from someone else.
Something akin to API in art would be style. If you allow style to be copyrightable, it would mean any apps following the Material Design style, for example, would infringe Google's copyright.
GNU/Linux is a partial (but incomplete, since no Linux distro is unix(tm) certified) a reimplementation of proprietary Unix, and with billion-dollar companies like Red Hat and IBM it's certainly a commercial endeavor at proprietary Unix's expense. It would seem to be an attractive target if a plaintiff like SCO could somehow move the case to the federal circuit (as none of the standard appeals courts have declared APIs copyrightable).
Reimplementation does not necessarily violate copyright. Copying does violate copyright (absent fair use). Like verbatim copying. Example, Google didn't have to use the “java.lang.Math.max(a,b)” header, but they did. They did copy because they wanted to leverage the existing Java developer base who would easily be able to develop for Android, without having to do the hard work of building their own ecosystem. Overall, Google copied the header structure for more than six-thousand methods.
Exactly. I don't see what you are disagreeing with. The point is that in order to leverage Java's developer base as quickly as possible they made it possible for Java developers to essentially develop for Android without needing to learn a new syntax for all the APIs they already knew. That is why they copied.
How many ways are there to define max? Surely AT&T should turn around and sue Oracle for lifting max(a, b) from stdlib. Or maybe SCO will rise from the grave and try it again.
I see the point, but that's "whataboutism." I also have no idea who owns the copyright (if anyone does) to stdlib APIs, and whether Oracle obtained license. Do you?
There's no doubt that if it is established that APIs are subject to copyright, then someone owns copyright to the C standard library APIs. It's not old enough for copyright to have expired, and nobody has ever released the APIs to the public domain (because nobody ever seriously thought that such a thing would be necessary). Establishing API copyright as a real thing without broad fair use rights would throw into doubt the copyright ownership of a large portion of all software ever written.
Code written for one will fail for the other, and negates the whole point of interoperability. Therefore the method signature should not be copyrightable
copyright has a fair use clause, which states that one can decompile software to produce a derivative for the purposes of interoperability. This then must assume that any apis being implemented has to both fall under copyright (otherwise, this law does not apply to api), but also means that the law allows for the use of the api for the purposes of interoperability (and therefore, you cannot claim to have the sole rights to an api).
That is exactly what reimplementation means in this context, creating a new implementation of an existing interface. And that is exactly what GNU Linux did. They copied a large number of system header files and created new libraries that implemented them. The copied a large number of command-line interfaces, and created executables that implement them. They extended them in the process, but the goal was to mostly preserve API compatibility.
>are we no violating their copyright just by implementing their API?
OpenJDK is GPL. If you comply with GPL, no. This is the problem, Google copied and did not comply with the GPL. Their other option was to pay Oracle/Sun a licensing fee for a commercial license. This is exactly the business model many GPL users follow. Ruling otherwise makes this business model invalid, but it also creates a double standard.
Consider a programming language where you program in types, like Idris. The case is more obvious here. The API is a program. The same applies to Java too, but that seems less obvious. The API is the program that produces compiler output.
Considering the pain that has been caused by Google deciding they needed to reinvent Java, and do so in a way that isn't really compatible with the new releases, I would say I'm ok with this.
Most third party commercial Java vendors, selling JDKs for embedded development also have their own VMs and AOT compilers, with variations better suited for their hardware.
SUN wasn't very happy about Google using Java without paying anything. IIRC SUN wanted Google to use J2ME and get some modest fees; instead Google decided to reimplement API, pissing off all top guys at SUN who publicly were OK with it (hoping they could negotiate some payment), but internally were boiling.
Sun was only incrementally better than Oracle in their approach to Java licensing. They already has one pyrrhic victory over Microsoft that birthed C#, .NET, and Microsoft's own VM. Failing to come to terms with Google means client Java runs on Android, and not even on a Java VM. Way to make your language technology relevant.
Google believed they could implement their own VM and get something cheaper (and/or better) than they would get by licensing one from Sun. That seems like a perfectly legitimate business decision for them to make. A clean-room reimplementation of an existing API had long been thought to be legally clear, going all the way back to Compaq reimplementing the IBM BIOS and starting the "IBM-compatible" competitive ecosystem that our whole industry is built on.
That's it. The VMs on the market at the time we're absolutely terrible for phones. John Carmack was commenting on how JavaME gave you worse performance than an original IBM PC, and HotSpot's strategies absolutely destroy battery life.
The whole subthread focusing on the Android VM is completely irrelevant. The entire argument at this point has to do with the inclusion of the Java APIs. Not even Oracle or the appeals court are harping on Google's custom VM.
Android does not have a Java VM, and it does not run Java bytecode. Dalvik bytecode is more compact, and more CPU efficient, and the more recent ART runtime is even more efficient and performant. But it isn't a JVM.
Just like all the vendors selling commercial JDKs for the embedded market.
They also offer customized versions fine tuned for their deployment scenarios, doing Java bytecode to either native (AOT) or their own proprietary bytecode format when generating the firmware image.
Or for example, IBM Java running on IBM i mainframe, where Java bytecodes used to be translated into the TIMI bytecodes, just like any other IBM i application.
The Dalvik and ART runtimes differ in that the do not run Java bytecodes. Every commercial embedded jvm, open source jvm, and me jvm I have seen all run Java bytecodes and you can use any toolchain that makes .jar files with these vms. Unless the translation you mention can happen at runtime, it isn't a jvm.
Copyright covers subjective work, not just "artistic" work. In the same sense that the choice of how to paginate a phone book and where to put the guidewords on each page is copywritable, yes APIs are copyrightable.
Once they admit to copying some of it, it throws the whole clean room process into doubt. I think the courts are working on the "where there's smoke there's fire" principle.
Google knew what they were doing and IMO they were right. I still don't think Google or anybody should have to ask for Oracle's permission for reimplementing a JVM (as long as it's done cleanly). You seem to put the blame on Google for not wanting to pay $100M at the time but what if instead it was a small startup who simply couldn't afford that cost?
I'm not worried about Google in the least, I am however concerned about the precedent this sets.
I'm not sure how that's relevant, if anything since the crux of the issue seems to be the "stealing" of the API the fact that there are incompatibilities should be in Google's favour? It's a bit odd to claim that somebody stole your API while at the same time complaining that they did not steal it well enough.
The original license for Java said you can create your own implementation just fine, so long as it was compatible with the others (or at least the benchmark one). By not doing that, Google violated the license.
"It's a bit odd to claim that somebody stole your API while at the same time complaining that they did not steal it well enough."
Not if what you want to avoid is people Embracing your API, Extending it with new special bits, and Extinguishing your version.
That's not all it said. The license had field-of-use restrictions, meaning you couldn't use your implementation for every purpose. The Apache Foundation published an open letter to Sun on that regard.
And specifically, use of a J2SE implementation in mobile devices may have been forbidden.
> what if instead it was a small startup who simply couldn't afford that cost?
Licensing costs can scale according to the customers business size and revenue. What is more concerning is that this may create precedent that API specs are copyrightable -- to the degree they are worth billions in damages.
Licensing costs are arbitrary. If you want to license some IP from me I can ask for a billion dollar for it. Or I can simply refuse to sell it. The point is that IMO Google or anybody else shouldn't have to ask for permission for cleanly reimplementing an API.
I think some people in this thread are minimizing the issue because they don't like Google but I think it's naive and short-sighted. It's not about Google or Oracle, it's about copyrighting APIs.
> I'm not worried about Google in the least, I am however concerned about the precedent this sets
It's legal precedential value is limited, because it was a copyright decision in the Court of Appeals for the Federal Circuit (CAFC).
The general principle for a precedent is that precedent for court X is set by the appeals court that hears appeals from X, and the appeals court that hears appeals from that appeals court, and so on.
So, for example, the district courts in the 9th Circuit (which covers the west coast tech companies) gets precedent from the Court of Appeals for the 9th Circuit, and from the Supreme Court. In particular, this is the appeals path for copyright cases.
The appeals path changes for a few special subjects. Patent appeals from all of the Federal district courts, for example, go to CAFC. So, in matters of patents, a district court in the 9th district would look to CAFC for patent precedent, not the 9th circuit appeals court.
Oracle sued Google for both copyright infringement and patent infringement. The parties were OK enough with the outcome of the patent part of the case that no one appealed that, but the copyright decision was appealed.
You might expect that this means the appeal would go to the appeals court for the 9th Circuit, because only copyright issues were being appealed, but that's not how it works. Where the appeal goes is decided by what was at issue in the original case, not by what was at issue in the appeal.
The rule is that if a case has both a special subject, such as patents, that points to CAFC, and other subjects, such as copyright, that point to the appeals court for the circuit the district court is in, the appeal goes to CAFC. CAFC handles the whole thing.
When CAFC gets a subject that normally does not come to them, but got there because it was attached to a case that also had a subject that does go to them, the rule is that they are supposed to follow the precedent of the appeals court for the circuit the district court is in. They don't set precedent in that district.
For example, if two companies sued over copyright in the 9th Circuit, with no other issues involved that would deflect the normal appeals path away from the 9th circuit's appeals court, the district could would look to that appeals court and the Supreme Court for precedent. CAFC opinions on copyright would at most be interesting opinions it might look to for insight, just like it might look to courts of appeals for other circuits, but only it's own circuit's appeals court and the Supreme Court would be precedent it has to actually follow.
PS: I think we'd be better off if CAFC just got the patent appeals. If a case has both copyright and patent issues, send patent appeals issues to CAFC and copyright appeals issues to the circuit's appeals court. At the trial level we merge cases that would normally be in different courts into one (e.g., if a case has both state and federal issues, it goes to federal court and the federal court handles the state issues).
That makes sense at trial court level because they involve examining witnesses, examining experts, and similar. If different issues were heard in different courts, many of those witnesses would have to go to multiple courts. It could be a major hardship on them. You'd want to hold them all in the same area, at near the same time, to minimize travel. That could be hard to schedule.
Appeals courts, on the other hand, just work off the transcript from the trial. The only people needed there are the lawyers arguing the case. The lawyers for appeals are usually more specialized than trial lawyers, so there are quite possibly different lawyers handling the different issues in the appeal.
It would not be much of a hardship, if any, for different issues to go to different appeals courts, as long as a little care is taken with scheduling.
Heck, it might even be less of a hardship. Imagine you are a copyright appeals lawyer in the 9th Circuit. Normally all your appeals court...
Haven't all of the patent issues been settled? So what's to stop a copyright troll from adding ancillary patent claims to be able to use the CAFC for the appeals process from now on.
> I think the part that gets lost in all of this is that Sun offered to license Java to Google previously for $100M. Google turned that down and bypassed Sun because they didn't want to pay (or license).
I'm not sure I follow - Google believed they didn't need a license, just like everyone who used Linux despite SCO offering to license Linux to them.
If Google needed a license, and Sun had not offered one, it would not make a difference; Google would still be liable for infringement. There's no abandonware or compulsory license provision in the laws for this. The question is whether Google needed a license, not whether Sun was willing to offer one and for what price.
There's no provision for compulsory licensing for copyright because it's not supposed to inhibit technical implementations. Patents do that, and it least in the UK the law includes compulsory licensing.
US copyright law doesn't do compulsory licensing for anything other than music recordings, and I believe it doesn't have compulsory patent licensing at all. I'm not sure there's a good rationale for this.
Whether or not they knew that someone would come along and sue them doesn't matter if the lawsuit is unjust.
Even if Oracle is correct, and even if APIs can be copyrighted, Google's intent still doesn't matter. The only thing that matters is whether or not they infringed.
I consider this to be a form of victim blaming. You should argue the case on its own merits, not posit that Google was "asking for it."
It wouldn't be victim blaming to criticize a company that is breached because they didn't take compsec seriously. They weren't a small company at the time and they knew this was a hazard.
Google had a responsibility to their shareholders and customers to do the right thing regardless of how stupid they thought the law was, and their attitude here was pretty arrogant. (To avoid beating up on Google, I should point out believing they could take on anything helped them do some work that changed the world for the better.)
Since the attitudes of parties involved in a case are often considered in judging the case, I think it's entirely fair to bring them up.
> It wouldn't be victim blaming to criticize a company that is breached because they didn't take compsec seriously.
If you then turned around and argued that the hacker somehow wasn't in the wrong because of the victim's attitude, yes it would be.
Victim blaming has nothing to do with someone's responsibility to others, and everything to do with taking a conversation about whether an attack is justified, and shifting that conversation to instead suggest "well, dumb people like that deserve to be taken advantage of."
Oracle contested that Google infringed their IP. "They should have known we were gonna sue them as soon as we smelled the money" is not compelling evidence for that claim.
Much in the same way, saying "Johny should have turned off his attitude and just given us the money" is not compelling justification for a mob hit.
When Google did that, Google was relying on controlling precedents in the 9th circuit saying that APIs are functional elements needed for interoperability and therefore are not copyrightable. The first judge that they saw agreed with them and it should have been an open and shut case.
It was Google's misfortune that through a quirk of the system the case wound up in the Federal Circuit, which has a history of creatively ignoring precedent to fashion new precedent that increases its own importance. (Which is how we have patents on all sorts of crap that the Supreme Court has ruled that we shouldn't.) And it was good lawyering on Oracle's part to throw every possible argument at the case, including the copyright arguments that they knew they should have lost.
It's also very standard enterprise thinking: Save 100 mio now, get a bigger bonus check, and worry about the consequences later. Maybe all consequences can be avoided even.
Sun didn't just license the rights to the Java IP, but as a supposed standard established by the JCP, a farce of a standardization body that never was.
Google probably had to use their implementation and J2ME was and still is a piece of shit.
Yes it was about cost, but the cost would have been far greater then the licensing price ;-)
I'm having flashbacks here, but what I remember at that time was concern that if Google paid Sun, they'd be setting a precedent that way. There was a sigh of relief when they didn't, at least from some, because, regardless of how much better of a company Sun was than post-Sun Oracle, people felt like it was overreaching.
So although you're correct that Google did this themselves, the alternative was fraught with problems also. Better to fight it and lose than implicitly accept the idea and pay.
This was all happening in the context of C#, which people seem to be forgetting about too. It's important to remember that the whole idea of copyrightable API was done under the argument that it was important to protect API integrity from forks. MS provided evidence of a desire to do this (as has Google to some extent since then) but then introduced C# instead.
Anyway, this is a mess because copyrightable API is ridiculous, but Google should have been more careful with cleanroom implementations.
I think the case was basically lost as soon as the court ruled that APIs are copyrightable. I still disagree with that decision, but once you've already arrived at that point then I think it's pretty hard to argue that Google's use of those APIs was fair use.
They did appeal, and the Supreme Court pretty much said they didn't want to look at this until a trial took place on the fair use question. Now that that's happened, I assume there will be another appeal to the Supreme Court.
I sure hope so. That decision definitely needs to be appealed. I very much hope it's overturned. (The industry has pretty much assumed - and acted - that APIs were not copyrightable, and that's worked out all right. Suddenly shifting to APIs being copyrightable is going to cause some change the rules under existing activity, in ways that it's hard yet to define the full scope of.)
But even if it's not, the decision needs to be appealed. Right now the situation is that APIs are copyrightable, but only for sure within one of the US Federal Court districts. In the other districts, they may be copyrightable. Or they may not be. If they aren't, then we have different law applying in different districts until the Supreme Court decides to resolve the issue. A Supreme Court decision now, one way or the other, would at least give resolution. (If they decide that APIs are copyrightable, then we'd have different law in the US and Europe, but at least it would be the same law everywhere in the US.)
[Edit: Apparently this isn't in a district court, it's in the Federal Circuit, which handles patent cases.]
When the Supreme Court was considering Google's petition to hear the case, the court asked the White House to voice an opinion—where by "White House administration", you mean the Solicitor General.
That's not "weird"; that's a normal part of the job.
That's not weird, either. What would have been weird is a finding that they're not copyrightable, given that it would have been completely at odds with the statutes and case law we have concerning copyright.
The point is, nuance matters. If you're physically attacked and defend yourself in a way where you end up killing the guy, you claim that your actions were justified. You don't go to court claiming that killing people is just not a problem.
Here's how this case should go:
0. Oracle sues Google for copyright infringement.
1. Courts find that the design of APIs is an expression resulting from substantial creative decisions far above the low bar we already have for precedent, and therefore they're copyrightable.
2. Google defends themselves on the claim that, creativity notwithstanding, merely implementing a public API should not subject an implementor to the consequences of copyright infringement, and that there are no damages owed here.
> What would have been weird is a finding that they're not copyrightable
Nothing weird with that. APIs are meta tools, not actual tools. That's what "I" in the name is for. They are interfaces for a reason. It makes perfect sense for interfaces to be non copyrightable. EU courts got it right:
Computer code itself can be copyrighted, but functional
characteristics—such as data formats and function names—
cannot be. "To accept that the functionality of a
computer program can be protected by copyright would
amount to making it possible to monopolise ideas, to the
detriment of technological progress and industrial
development
> And by every indication, we're right on track.
We are not, until Supreme Court will overturn the current ruling and will clear APIs from copyrightability for good.
> I'm done commenting further here.
Sure, you brought no arguments to defend the illogical position of APIs copyrightability anyway.
You're leaving out the step where the district court found that APIs aren't copyrightable, but the district court was overruled by an appeals court that normally has no right to rule on such matters and does not set binding precedent on such matters. If Oracle's now-dead patent claims hadn't been included in their original complaint, then the process you describe would likely have ended Oracle's case at step one with the Ninth Circuit upholding Alsup's ruling on API copyrightability.
First: No, I didn't leave anything out. Review the link I included in my last comment. Hold on to the Federal Circuit as a personal stick in your craw if you want, but I didn't leave it out.
Second: That's a stretch. To argue that the case would have stopped at the Ninth Circuit is to argue that because the Supreme Court denied Google's petition to reverse the Federal Circuit, then they would have denied Oracle's petition to reverse the Ninth Circuit. That's a junk argument.
> To argue that the case would have stopped at the Ninth Circuit is to argue that because the Supreme Court denied Google's petition to reverse the Federal Circuit, then they would have denied Oracle's petition to reverse the Ninth Circuit.
That's not the argument I'm making.
The Supreme Court had several procedural reasons for not granting Google's petition for certiorari: the Federal Circuit's decisions were not setting binding precedent outside of this particular case, and there were still issues to be decided by the lower courts that included avenues for Google to prevail, making it unnecessary for the Supreme Court to render a landmark decision on the matter of API copyright.
If the appeals had gone to the Ninth Circuit, Google's appeal would have stood a much better chance than it did before the Federal Circuit. A Ninth Circuit decision in the matter would have set a very important precedent, but a decision in favor of Google would not have created any obvious circuit split and wouldn't have upset the status quo of the software industry. On the other hand, a decision in favor of Oracle would potentially have consequences serious enough to be a priority issue for the Supreme Court whether or not it created a circuit split.
> A Ninth Circuit decision [...] in favor of Google would not have created any obvious circuit split and wouldn't have upset the status quo of the software industry.
Go on, finish the thought, and make your conclusion explicit. Because by any reasonable reading, you're suggesting that the Supreme Court would not have granted Oracle's petition if Google prevailed in the Ninth Circuit. And yet you start by saying that this isn't your argument. Be explicit.
> Apparently this isn't in a district court, it's in the Federal Circuit, which handles patent cases.
This is a very important nuance. As I understand it, for the issues in this case that are outside the Federal Circuit's usual jurisdiction (patents), the Federal Circuit was supposed to rule however the local circuit (Ninth) would have ruled. The Ninth Circuit probably wouldn't declare APIs copyrightable, but the Federal Circuit did.
However, the Federal Circuit doesn't establish binding precedent for the Ninth Circuit on non-patent issues. That's part of why the Supreme Court didn't take up this case, and why many of the amicus briefs recommended against the Supreme Court taking up the case. Google gets screwed, but that ruling didn't have cause an immediate upheaval of copyright law in the jurisdiction that includes Silicon Valley and Redmond. All that their decision really established was an incentive to include bullshit patent claims in any copyright suit that pertains to APIs, so that you can get your appeals heard by the Federal Circuit instead of your local circuit.
I honestly don't know if a jury is the right place to decide a copyright case. Essentially, we take an extremely complicated chunk of law, take twelve random people and explain the basics of it... and then ask them to decide on a super complicated edge case of it. Does this work well?
I would argue Google is likely to win a jury case over Oracle in most cases because Google, at least until very recently, has widely been viewed as a "good" company, and is one that is popular with the average user.
The CAFC is the appeals court for patents, which are not the same as copyrights. The local circuits handle copyright cases, except when there are also patent-related claims in the case.
So if you are a plaintiff in a copyright lawsuit and you want your appeals to get the pro-IP biased treatment from the CAFC instead of going to the local circuit, make sure to find a way to include a patent claim in your suit.
from TFA:
"Oracle claims Google was in such a rush in the mid-2000s to create an operating system for mobile devices that the company used key parts of copyrighted Java technology without paying royalties. "
If this is true, it certainly isnt happening again. Google dominates smartphones and could very easily decide to phase out java for go/rust, torpedoing whatever rent-seeking strategy Oracle had originally devised. What oracle is attempting to do is nothing short of what Microsoft tried to do with TomTom's implementation of FAT.
If BTRFS, percona, and maria are any indication its not the work that matters. Plenty of talented engineers are willing to devote their time and effort to avoiding Oracle. Quite frankly the Oracle Database has turned into a manacle for Ellison. Unable to prevent its inevitable loss to open source alternatives through NDA agreements that prohibit public release of independent Oracle performance tests, and unable to convince cloud-bound companies to continue forking out high dollar per-core licenses for it, The software exists as a 90s anachronism to the hubris of dotcom. Oracle Enterprise Linux was, for all its intentions, a flop, and after acquisition and rebranding MySQL is a withered husk compared to its open source counterparts.
> The software exists as a 90s anachronism to the hubris of dotcom.
The point is that in BigCo environments the norm still is "no one ever got fired for buying IBM and Oracle" and even if that were not true shitloads of enterprise crapware are bound to Oracle's offerings and that alone will secure revenue for Oracle for decades to come. Hell when I look at the average age of stuff in the banking and insurance sector I would not be surprised if Oracle is still going strong in a century.
"If this is true, it certainly isnt happening again. Google dominates smartphones and could very easily decide to phase out java for go/rust, torpedoing whatever rent-seeking strategy Oracle had originally devised."
Because wanting to be paid for one's work is "rent-seeking" now?
And no, Google really couldn't. There's a huge library of Android applications that are using Java technologies to make them. Google can't replace Java with go/rust/dart without throwing all that away. They would have to continue to provide support, which would continue to put them in violation.
> There is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform
Someone should appeal and bust their case that claims that APIs are copyrightable. And don't forget those who supported this crookedness - Microsoft.
It's been sent back to the lower court to determine damages. After that Google can appeal to the Supreme Court if they can find some grounds on which to do so, and then the Supreme Court will decide whether to hear it or not.
If I recall correctly, the Supreme Court declined to hear an appeal of the API copyright question until Google had lost on fair use. Well, Google has now lost on fair use. The Supreme Court may be willing to take the case now (that is, before going back to the lower court to determine damages).
OT: Thinking about API copyright I wonder how that is supposed to work in other programming languages e.g. Golang. Lets assume Google owns the copyright of the 'io.Writer' interface for the moment.
Is everybody who has implemented a struct with a Writer method which satisfies the 'io.Writer' interface and as oracle stated it 'who wants to use them for a competing platform or to embed them in an electronic device' now (hypothetical) at risk of being prosecuted because they infringe Googles copyright?
---
I am well aware that Google was the respondent in the Oracle vs. Google case.
The law doesn't work as a set of naive rules like "If API->You need a license" because human life is full of nuances that can never be fully captured in a set of rigid rules. I know that people are uncomfortable with this truth, because our systems of courts often appears to the casual observer as just a bunch of "elders" making subjective decisions. Hence "smart contracts" etc.
And while the criticism isn't completely wrong, the system as it exists in the US today is actually working quite well, with the professional ethos and rules of the court system being somewhat successful at overriding any individual judge's predilections.
Anyway, in your case the difference is obviously one of scope. Even in the original ruling that affirmed APIs to be subject to copyright, the judge ultimately dismissed the case because they considered Google's actions to fall under "fair use".
While this was now struck down on appeal, it is absolutely certain that copying a single method's signature would still be protected as fair use. Moreover, in the case you mention, a method such as File.write() would probably not fall under any copyright because there isn't much of any creativity involved.
While I understand your point, your argument has very little foundation. You are basically saying: "Everything works very well and if a judge decides something you should respect that, as he has good reason to judge it his way".
One thing I have a particular problem with is that even judges from the same country seem to come to different results on the same case. I know its not unusual but that underlines my point that just because some judge came to some verdict, it isn't necessarily true.
And if 'the system as it exists in the US today is actually working quite well', why does a company like Google with a lot of smart people will have to pay a fine which probably will be as valuable as the whole Java platform? In a system that actually works well, the smart people would have seen what was going to happen and different judges would come to the same result.
And that something as 'simple' as a single method interface doesn't require any creativity is just wrong. I am sure there are a lot of famous creator quotes about that, the first I was able to find is from Steve Jobs:
Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. [1]
In the case of Golang that would translate to: It is much harder to build a universal single method interface for all kinds of write operations opposed to specific write methods for different use-cases.
There's a difference between using an API and reimplementing one. Nobody's saying that you can get in copyright trouble for using an API. And to my knowledge, Go(lang) doesn't have the "embed in an electronic device" restriction that Java had.
If you tried to create a different implementation of Go that used the same API, whether you could get in trouble depends on Google's license. And then, if the license is against you, whether you do get in trouble would be at Google's discretion.
Note well: IANAL. Also, I'm still hoping that this "copyrighting the API" will be overturned at the Supreme Court, in which case this whole conversation is moot.
There are two next steps. One step is a retrial in the lower court, with fair use no longer a defense. The other is an appeal to the Supreme Court on whether an API can in fact be copyrighted.
If the Supreme Court appeal happens, it probably puts the lower court trial on hold. If Google wins the appeal, then (I think) there's no case left to try in the lower court.
I always wondered why Google didn't buy Sun when they had the chance?
This (Android's use of Java) has always been a risk for Google. Either in form of the lawsuit but in more general what Oracle (or someone else) would do with Java.
Anyways. I hope both companies are smart enough to settle this in a reasonable manner.
Good. Initially, I thought the API decision was a bad one, but now I think the courts got it right.
If you've ever wrestled long with getting a program to compile, you realize it's non-trivial to wrap your brain around complex types. The API is a language and the compiler is a runtime producing output. I can design my API in something like Java and return null from all the methods while I do it. The compiler will still produce expected results when I try to string bits of it together.
For most languages, this work is hard, because everything is a runtime error from the compiler. There are elegant and inelegant ways to solve certain problems. The API determines that. It is itself a creative endeavor.
Google was given the opportunity to license the API. They still can under GPL, but that means complying with GPL, which they evidently did not want to do. Ruling in favor of fair use here creates a vague double standard. Business models like that of MongoDB, who releases their code under GPL for open source projects and charges a license fee for private projects, would become questionable. "Well, you give it away already, so it's fair use to use it any way we like without paying you!"
There's the reverse of Wine now too with Microsoft's clean room (non-GPL2 and not currently open source at all) implementation of the Linux kernel kernel <-> userspace ABI.
642 comments
[ 4.4 ms ] story [ 333 ms ] threadNo Google is not going to pay billion dollars, not yet. Very clickbaity title.
The case originally had Oracle seeking 8.8b in damages. Oracle won the revival. Therefore Oracle won the revival of a billion dollar case.
The title does not state or imply that google will pay the full amount, only that the case is not dead.
I know, click bait is bad, but it really irks me that people on HN are so quick to pull the 'click-bait' card for no reason.
Would a different title really change anyone's interpretation of the article? I don't think so.
Now it's about legal phrases and licensing terms instead of common sense all over again.
Maybe the mechanism being used is wrong, but Android bastardized Java and as an Android developer I feel real damage has been done to the health of the Java ecosystem by having billions of devices run fragmented Java-but-not-Java.
Google has started to make it right with the switch to openJDK and Desugar, but in a lot of ways it’s too little very late.
Java on the server was not in decline, but Java on the desktop was declining, had declined. Applets were dead, very few success stories around Java Web Start. And the main three 'consumer' success stories for Java on the frontend were Limewire, Minecraft, and IntelliJ/Eclipse. As a consumer facing technology, Java was a complete failure. No sane person wanting to ship a commercial, consumer app to end users would consider Java as a first choice. I have been a Java developer from the day HotSpot Alpha was released, I say this as someone who loves the platform.
Personal Java failed. I worked for years on J2ME apps, Java on high end Nokia Phones, Java on Palm devices (Ghost VM), etc. All these platforms amounted to nada. Flash was far more widely used for front end user facing apps than Java. Ditto for Visual Basic.
The relevance of the Swing comment is the people complaining about the fragmentation of Java's write-once-run-anywhere promise, which was always more of a promise than a reality. If you want to make a viable mobile Java, you had to remove Swing, Java2D, CORBA, JMX, and a ton of other JDK libraries, which is exactly what Sun did with the various profiles as well. But once you do that, you have "fragmentation"
If Google had not produced Android, I can bet the leading platform today for mobile development that is not from Apple, would either be Xamarin based C#, or some scripting language like Lua or Python on top of a Linux widget toolkit. Java would not be in the mix at all. Or perhaps it would FlashMX sitting on top of Linux (ugh)
Larry finds plans to one of my old widgets and builds it into his awesome product and millions of people learn how to use the old version of my widget.
But my old widget kind of sucks and I’ve been releasing new widgets that fix a lot of issues.
Millions of people are gnashing their teeth over the old widget but Larry won’t update which version of my widget, he’s occasionally using parts of my new widget blueprint so now he’s creating Frankensteins of my widget that don’t even have a version.
But they’re still my widgets, Larry calling them by my brand name, people are conflating them with my widget, people making tools for my widget now have two diverging targets. People are saying my widget sucks because of issues I fixed ages ago.
It almost reminds me of J++ in a way, but with more subtlety.
Google should go Kotlin way, it will be better for everybody.
Perhaps, but is that a good thing if you're Oracle? Especially considering the fact that it's Google Java that's thriving and not Oracle Java.
But, with Android, Java got a boost that bled over to the server, and to a lesser extent, the desktop. It can be argued what the size of that boost was, and if it had any real impact (I would argue that it was not significant), but it was still a boost that they never would have had.
Anyway, that's the opinion of some random guy on the internet.
Around 2006, many companies were moving their server stacks from C++, considered old and stagnated, into Java application servers.
I took part in several such projects.
SavaJe OS was going to be the next generation when Android came into the scene.
Android first architecture diagrams look quite similar to the initial SavaJe OS presentations.
Sun buying SavaJe was pretty clearly a response to Android, so it's pretty disingenuous to say that Android killed SavaJe.
1999 - SavaJe is founded
2006 - Jasper S20 with SavaJe OS gets presented at Java ONE
2006 - End of the year, SavaJe fails to gain another round of investment, in spite of the successful reception at Java ONE
2007 - April, Sun public announcement to buy SavaJe assets
2007 - November, Open Handset Alliance is created
2008 - November, HTC Dream gets released as the very first Android device. The initial architecture diagrams have a certain resemblance with SavaJe ones.
The OS that came to be Android started in 2003, was initially based in JavaScript, had lots of time to inspire on Java stacks after they pivoted to Java and were eventually bought by Google.
Only after SavaJe was no longer around, it became public what Google was up to regarding their mobile OS strategy.
And Android is way more a rip off of Palm than SavaJe. All of the interesting things it does (the intent system, the capability based IPC, the battery friendly process lifecycle model, etc.) clearly descend from Palm (which isn't a surprise given that's where Dianne Hackborn cut her teeth).
Java was just starting to get revitalized after a long period of stagnation. Java 7 was a big deal and for a long time Android devs were limited to a weird amalgamation of Java 6 and a few Java 7 features.
Then Java 8 came with lots of great Stream goodies (and a lot more) while Android devs are still forced do to make due with unofficial backports or cutting off most Android devices (API 24) is the first to support them natively.
Android development gets mindshare for Android, not Java. The speed of the transition from Java to Kotlin shows how antsy devs were to get away from Java.
There are interesting things happening with Java, and they’re all outside of Android
Counterclaim: If it were not such a big legal hazzle, it would have been a lot more easy for Google to update to new Java versions fast on Android.
Apparently the risk was not so large they couldn’t do it if they’ve decided to now
From that you see that interest in Java is slowly declining since 2004, release of Android didn't even move it up a bit.
If we're using Google Trends as a proxy for what happened, then I'd say there's some truth to Android saving Java from its decline.
I understand the fragmentation issue, but I think it's a minor one and the net benefit for the Java ecosystem was much larger.
Also, Oracle is simply in the wrong trying to copyright APIs, and it has gotten a lot of hate from developers over that + all the other things they've done to Sun's previous projects that also made developers hate them.
With its developer-hostile attitude, is it any wonder developers are no longer interested in having anything to do with Oracle?
https://www.techrepublic.com/article/oracles-lack-of-develop...
Like what is this nonsense from the article:
> Oracle said its APIs are freely available to those who want to build applications for computers and mobile devices, but draws the line at anyone who wants to use them for a competing platform or to embed them in an electronic device.
That was the decision that lead to Android being "Java-but-not-Java". If they'd been granted a TCK license like they should've, they'd've implemented proper Java (confirmed by the TCK) and we'd be in exactly the same situation as if Google had used OpenJDK all along.
What functional changes accompanied Google's switch to OpenJDK? Doesn't Android still use its own incompatible VM?
Even 100% running with that, damaging an ecosystem isn't against the law. You could argue that Google damaged the Erlang ecosystem by not basing Android on Erlang. Ecosystems compete with each other all the time, and it's hard for one to grow without damaging another.
Actually my mistake, I assumed that you mean copyright, if you mean all laws in general, I feel there’s probably a way for Oracle to litigate, similar to how J++ went down
> I feel real damage has been done to the health of the Java ecosystem by having billions of devices run fragmented Java-but-not-Java
Your feelings are not a legal basis for punishment.
This just seems like a replay of J++. No one outside of Oracle or Google can determine the facts behind those statements you quoted, so the best outsiders like us can do is go based on “feelings” based on basic reasoning
Alas, this is not about objective truth and "having a case". It is the result of a free but regulated market being infected by a parasitic organism which has turned the regulator's defence mechanisms to its own purpose, the which being the extraction of as much value as feasible while keeping the host alive.
These people turned me into who I am today by showing me a form of non-vain, open, intellectual curiosity that I try and emulate - the persons age, race, gender, religion -- all irrelevant -- it was about the ideas. Though they would look down on you if you used the wrong editor (go vi!) but they would smile and show you the way.
While this might be true, it's worth noting that this is a copyright case and not a patent case.
I think MySQL had something to do with it too. Even if just to capture the mindshare of all the developers using it at the time.
Here is the latest Gosling interview on the subject.
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
- Java is created / owned by Sun.
- Sun was fearful of MS's EEE approach (embrace, extend, exterminate) where MS took a thing, built their own, pushed their own tooling, added their own proprietary instruction, boom windows lock-in. So Sun basically made their contract: Java is free but only if you DO NOT introduce any new instructions, and implement a 100% compatible VM, nothing added or removed.
- Sun was making _some_ money out of mobile.
- Google introduced this pre-compiled java stuff. It used Java but compiled into binary. Sun was kind of excited. Java everywhere. Even though it violated the terms sun put out, sun was happy to get more java out there.
- Google / Sun had a more or less truce.
- Oracle bought sun. Sun didn't have much business left as Linux was obliterating their Unix business.
- Oracle saw the primary income from Sun as a lawsuit against google. And licensing on every Android phone period.
And thus today.
Java belongs in a Foundation.
I think they see the Sun acquisition more as controlling the Cobol of the 21st century. Putting a stick in Google's eye is just icing on the cake.
They just didn't had enough money to sue and decided to make juice out of lemons.
Interestingly, the article includes a quote from a Sun Microsystems co-founder who agrees with Oracle's stance on this:
> Among Oracle’s supporters in the case is Sun co-founder Scott McNealy, who said Java was created to be a platform-neutral system where programmers could “write once, run anywhere.”
> Java “is the foundation upon which our digital world is built,” McNealy said in a filing with the court. “Google stole that foundation, used it to build Android, and destroyed Oracle’s market in the process.”
I think McNealy is taking rather too much credit for Java here. Yes, it's widely used. The foundation? The foundation? Hardly.
And yet Sun's CEO previously took the stand in support of Google.
On the other it's not about open source. If you're willing to license stuff in good faith you should be fine.
Also, the copyrights for R are mainly held by the nonprofit R Foundation, not by Revolution Analytics: https://www.r-project.org/foundation/. An API case from R copyright holders would additionally be really messy because a huge portion of the APIs originate in Bell Labs S, which they don't own the copyright to. Though there might be some sleeper case where whoever now owns the original S copyright pops up and sues R users for having cloned S's API...
So instead of being hobbled by Sun JDK design decisions they worked on Dalvik and Java like paraphernalia. And big success of Android is partially due to that.
Since then, this suit has been about (a) deciding whether Google is guilty of wrongdoing in the past, and (b) what the extent of the damages should be for that historical wrongdoing should be, if any.
The outcome here doesn't really have any impact on the future of Android (except if Google wanted to factor the suit into their decisionmaking for their own reasons).
While most of your point is true, I disagree with this part. Using lawyers to tackle companies that succeed with only parts of your technology may send a chilling effect towards future uses. Also, knowing that you are not allowed to partake certain independent directions in the stack you choose for your devices is a legitimate reason to fear the continued use of that stack. Some are OK to them (e.g. conforming to the GPL on Linux) and some may not be (e.g. not being able to write portions of the stdlib without dealing w/ OpenJDK stewardship). I don't think these are their own reasons as much as they would be the reasons used by anyone who fears technologies stewarded by litigious outfits.
> I don't think these are their own reasons as much as they would be the reasons used by anyone who fears technologies stewarded by litigious outfits.
The problem has nothing to do with using the Java API. It has everything to do with copying the OracleJDK API and implementation then building a secondary non-compliant JVM to run it. The OracleJDK (which is different from the OpenJDK) is not licensed in a way that allows copying.
I recommend folks read https://law.stackexchange.com/questions/8213/is-it-legal-to-... for a little background.
In short Google fucked up big time.
Um, no. The case has solely to do with the copyright of the SSO of 37 Java API's that Google used. This has nothing to do with their VM.
>In short Google fucked up big time.
On the contrary, the CAFC fucked up big time for allowing API interfaces to be copyrighted.
"It has everything to do with copying the OracleJDK API and implementation"
This only stands as law of the land when the plaintiff manages to include a patent claim (even a weak one that later gets thrown out) to force the case under the Federal Circuit's jurisdiction, as happened here. They don't normally hear copyright cases.
While I'm sure more such patent claims will get bundled with API copyright claims in the future where a plaintiff can credibly manage that, it's not otherwise the law of the land.
(An aside: I think the Federal Circuit may have considered aspects of Ninth Circuit precedent in this ruling, as they're supposed to do for non-patent issues from the Ninth Circuit. Even they might rule differently in cases from other circuits, maybe just making it the law of cases they handle from the Ninth Circuit with significant persuasive impact on how they'd rule on cases from other circuits.)
Eventually a normal Ninth (or other) Circuit panel will rule on this. They're not bound by the CAFC ruling, though they will undoubtedly consider it. As soon as one circuit rules otherwise, that will create a circuit split.
Eventually, the Supreme Court will want to resolve that circuit split and will grant cert, either changing this bad precedent even for cases that go to the Federal Circuit or truly making it the law of the land.
A Supreme Court ruling on this would only affect the current Oracle v Google case if it happens before this case is fully finalized, given the doctrine of res judicata. But it would help future cases, including between these parties about a different topic, as well as between Oracle and other companies about the Java API.
With all of that said, contacting representatives in Congress and Senate to make explicit that APIs aren't copyrightable would still be great, as would narrowing the CAFC's jurisdictions to patent claims (and its otherwise specialized areas) or eliminating it entirely.
The opposite. Binding only within their subject-matter jurisdiction.
Which is good, because this ruling is so broad it's essentially trying to argue there's no such thing as fair use (because plagiarists arent protected by fair use, and all copyright infringers are plagiarists, and fair use is inherently copyright infringement, therefore...)
https://arstechnica.com/gadgets/2018/03/google-starts-blocki...
The court didn't buy that Android was a gift to society worthy of fair use protection, and at this point, neither will anyone else.
Chrome isn't open source. Chromium is. Chromium contains V8. V8 alone launched the huge nodejs community. In your mind, because Chrome isn't 100% open source, the fact that you can use pieces of it that are for tremendous benefit to the community doesn't count?
Handsets aren't the only thing Android is used for. Virtually every consumer product I see launch these days used some part of Android. TVs, smart speakers, IoT devices, thermostats, car entertainment systems, set top boxes, watches, and on and on. If someone wants to do a Kickstarter on a new piece of HW, the first thing that they're going to thing of is forking a chunk of AOSP, and to deny the immense value this has enabled for people building such devices is absurdly blind. Without ASOP, many of these projects wouldn't even exist.
Your positions are transparently hypocritical for someone who was a Windows Mobile fanboy, and rarely says a negative word about Apple or Microsoft's 100% proprietary platforms.
I have no problem with proprietary software, I have a problem with proprietary software masquerading as open software and trying to use claims like "fair use" for something tightly controlled with secret arrangements and bullying the industry into compliance.
I would argue Android offers little benefit to the niches you detail, the only reason other Linux flavors don't make more sense is because they're taking advantage of the fact that they have to have Android developers anyways, because of app support. Android is not a good OS for smart devices, most of the bloat it shoves on top of Linux has little benefit to single-purpose hardware. I don't think Google gets to claim credit for the entire smart device market.
Most small companies do not have the skills to take vanilla Linux userspace, or even Debian or Ubuntu, and build out a polished mobile platform that they can shove into a thermostat or watch. The only semi-popular Linux attempts that succeeded in volume were HTML based like WebOS, which again, simply used a fork of an off the shelf complete platform mostly built by a corporation (e.g. WebKit)
You can argue all you want, but evidence suggests otherwise. Someone building a sealed, firmware for a device today that doesn't permit third party apps, still chooses AOSP as a base more often than not, and the reason they do so, is because there is huge value in the platform. Whether you like the design or not, whether you think it is bloated or not, people think that using AOSP to bootstrap their HW lowers their time to market or costs. And for those people, they are receiving value.
Because I could somewhat understand that sort of IP anarchism, although I wouldn't agree. But I'm having a hard time thinking about a coherent reasoning to see source code as copyrightable, yet deny the same to APIs.
Copyright applies to any creative endeavours that reach a certain level of breath and/or depth. Having been involved in a few library projects, I have witnessed quite a few where I would say the API was far more important, and sometimes took more work, than the underlying implementation.
Look, for example, at all the work done in standard-setting bodies: RFCs, WHATWG, etc. They are all licensed freely, yes. But the attachment of licenses to those documents implies an acknowledgement by the authors (and the community) that their work falls under copyright.
The entire PC industry was launched because clean room re-implementation of the API of the BIOS broke IBM's stranglehold. Is the world better without WINE? Without game or CPU emulators?
I am philosophically opposed to the idea of API copyrights especially. This is a corporate battle whose collateral damage is going to harm the entire industry.
It's funny how everyone loves forking, until tribalism kicks in, and then people start granting mulligans on philosophy just because of tribal positions on whichever company they don't like. Remember this? http://www.gordoni.com/software-patents/statements/oracle.st...
"Oracle Corporation opposes the patentability of software" "A balance of fifty years protection for direct copying of code would continue to be provided by copyright law."
Funny how perspective changes if you perform a buyout of a struggling company's assets to use it to shakedown the market.
IMHO, the Amiga 1000 was the 'iPhone' of personal computers, ridiculously better than the Mac and PC at its launch date, it was a step-function better than the Mac. But Commodore was a bungling, mismanaged company that flushed a great opportunity down the drain. It's like if you invented the iPhone, but didn't know how to sell it, market it, and get product market fit.
And even if not, surely there would be another brand to gladly take their place.
Commodore was vertically integrated like Apple of today, they had a stellar custom chip development team, and had revolutionary chips in the worlds (AAA and Hombre) that would have been like 3dfx, but in 1992, delivering a quantum leap in gfx and single-texturing 3d pipeline well before others.
I'm really bummed the company flushed it down the toilet and "Xerox PARC"'ed itself, by having a winning team of researchers and engineers, but not being able to make a business.
That has nothing to do with anything. Copyright is a human construct. Somethings are decided to be copyrightable and somethings are not. Not every creative endeavor should be copyrighted, other should, and other should with major limitations. APIs were never copyrightable. Ever. The computing and programming industry developed with this assumption - in fact, it may not have ever developed if that wasn't the case. Why does this need to change now? And not even through a new law but rather court re-interpretation.
You're just asserting tradition. Yet you are not addressing my examples that directly show precedent within the industry for recognising copyright for APIs.
I believe APIs can be considered under an analogous principle - that is, the ability to interoperate with a set of existing code shouldn't be subject to exclusive ownership, and you can't interoperate with the same existing code without implementing the same API, so APIs should not be copyrightable. (This draws a distinction between the API itself and the underlying implementation of that API).
http://patents.2012.apievangelist.com/2017/12/07/2012-08-23-...
For decades, people had been producing Java forks which weren't compatible, Sun didn't do much about them, and even encouraged them. Their main idea was to charge for the TCK and the right to use the Java(tm). Remember Ghost and WabaVM for PalmOS? Remember Kaffe +Classpath?
I'd argue that the idea of write-once-run-anywhere with a one-size-fits-all UI layer from mobile to server is a pretty bad idea. Apple seems to understand this, which is why iOS differs from NextSTEP.
E.g. I can understand Oracle/Sun needing some amount of money for stewarding Java, as the teams required to build/maintain/QA/release the JVM were AFAIU in the hundreds, so not cheap. But "Java is free", so they didn't have a way for covering that cost from the majority of enterprise developers who were getting a free lunch, and instead relied on the J2ME licensing almost by accident/happenstance IMO.
So now, companies like Google are not "paying for hundreds of Oracle/Sun engineers to develop a platform/language/ecosystem", but instead "paying hundreds of internal engineers to develop (multiple) platforms/languages/ecosystems".
Which they can do, and still provide v8/Go/Dart/etc. "for free" because they have the luxury of paying for everything with ads, which Oracle/Sun didn't, which forced Oracle/Sun to commit the sin of asking for money.
Granted, don't want to be an Oracle/Sun apologist b/c they messed up in a lot of ways (stagnated the language/etc., don't have a great reputation, etc.) and the competition/iteration of the next-gen languages like Kotlin/TypeScript/Go/etc. is working out great.
Just interesting to think of the economic trade-off, e.g. if Oracle had been a little less controlling, and Google a little more willing to pay licensing/something, if the net effect would have been Java today being in a demonstrably stronger market position than it is.
And, either way, the rest of us are still being spoiled by so many free lunches: amazing tech (languages/libraries/frameworks/ecosystems) built by professional teams that we don't pay a dime for.
A high performance JS VM means we don't need to use applets anymore.
https://www.javaworld.com/article/2076251/core-java/applets-...
(Note that the article is from 2000.)
Remember that Google was already doing AJAX in Gmail in 2004, years before V8.
I find this amusing. No one ever built anything meaningful client-side with Java. There's a reason Microsoft laughed off Java as "write once, debug many".
Your statement would be true if you have said "anything meaningful client-side on the web with Java". On the web Java was restricted to Java applets and was never really in competition with JavaScript.
Desktop is quite another story.
I do think Sun entertained Java superseding Javascript in the browser - it just didn't work out that way.
Both Microsoft and Apple made it difficult in different ways, and the "year of linux on the desktop" has yet to really come (no ChromeOS don't count)
Not a problem when everyone is using Windows and Netscape. It's as horrible as you'd think.
Java applets were already considered a dying tech when Google made their push to heavily-Javascript-dependent apps, and the performance requirements that led to.
Note also that despite the similar name, Javascript and Java have technically nothing to do with each other. It is a quirk of business history [1] that Netscape and Sun partnered to name Javascript as it is when Sun was first pushing Java as a web technology.
[1] https://en.wikipedia.org/wiki/JavaScript#Beginnings_at_Netsc...
Netscape was still trying to sell a browser, and they wanted a common language on the frontend and backend, so Javascript was also on Netscape Server.
It was possible to call JavaScript from a Java applet and method in a Java applet from JavaScript (on a web page).
This functionality can be seen in Java 2 (now known as Java 1.2) - http://www.oracle.com/technetwork/java/basics-137133.html .
https://en.wikipedia.org/wiki/Netscape_(web_browser)#Release... has JavaScript and Java as part of the same release for Netscape. The next release of Netscape Navigator (3.0) had LiveConnect version 1 ( http://web.mit.edu/javascript/src/mozilla/js/src/liveconnect... ) which was that cross language communication.
I would be willing to contend that in the view of "Java applets are where the web is going" back then, the difficulty of communication between the applet and the enclosing page was something that needed some scripting glue and that JavaScript, from its inception, was to be that glue. It took about a year to get it working, but this was the initial goal of JavaScript.
Actually, Java was already mostly dead for the public web when Chrome and V8 were being developed, it was more Flash that was the competition.
All of these JavaScript implementations use the V8 JVM and can make desktop and command line application. Depending on security settings they can give partial to full system access to the underlying OS just like Java. If this ruling is upheld I would look for Oracle to float a trial balloon on newer JavaScript implementations and for stealing their Java's API's.
V8 is not a JVM (Java Virtual Machine), but a virtual machine for Javascript.
V8 didn't come about because of the JVM, but it was done by the same guy who wrote the JVM.
Don't those things realistically exist precisely because of a virtuous, continual cycle in the greater tech community of paying that free lunch forward?
Even the strictly free lunch use cases, where someone doesn't contribute time/money/effort back into the system, involve helping to popularize the whole and keeping it going; broadening it, spreading it, bringing more contributors in. Those people end up as popularizers/evangelists, which is a required ingredient for the virtuous cycle to keep going.
[1] https://www.computerworld.com/article/2509401/technology-law...
[2] https://www.cnet.com/news/why-oracle-not-sun-sued-google-ove...
EDIT: Added the second reference and cleaned up thoughts. Included note regarded license as well as pay.
What's being stated here is that Google's infringement improved Oracle's market position - that fact doesn't bar Oracle from pursuing their remedy against infringement. If you steal my software for making phones chirp every time you get a tweet and widely distribute it to the point that it becomes the de-facto standard in the tweet notification market, it doesn't magically mean that I don't get to come after you for stealing my tweet tech.
Here's the decision itself. Estopple is mentioned 0 times. This isn't because Google's legal team is braindead. It's because the argument that the Google's use was authorized following them walking away mid-licensing negotiation is insane. Google's defense is based on fair use. http://www.cafc.uscourts.gov/sites/default/files/opinions-or...
https://arstechnica.com/tech-policy/2016/05/suns-jonathan-sc...
If I hand you a bag of balls and say you're allowed to play with the purple and green balls inside, I haven't given you permission to play with any of the other balls.
In this case, the different balls are the different dismemberments/rights related to Java.
[edit] Jonathan Schwartz: "The strategy was, we agree on these open APIs, then we compete on implementations."
Here's some old HN discussion on it: https://news.ycombinator.com/item?id=2806771
In real estate, you can own a plot of land and provide others with permissions associated with the land; maybe they're allowed to walk over a path that runs through your land. That permission is not equivalent to all possible permissions associated with the land - although maybe some ancillary ones are implied in. Maybe people are allowed to bike over the path too, but they certainly aren't allowed to dump broken washing machines there.
Similarly, in IP I can grant you a set of rights related to my product without giving you ALL rights related to my product.
Nothing was stolen (i.e. Oracle still has the software), it was an infringement of copyright (and perhaps patents).
This gets into really critical concerns around APIs. If commercial product A sucks and I'm in a shop where we made our own drop in replacement that implement's A's APIs .. then we open source that drop-in replacement and put it on Github so anyone can use it, are we no violating their copyright just by implementing their API?
This can set dangerous prescient when it comes to interoperability and reverse engineering.
Try to sell a device that comunicates with a e.g. BTS station without buying their licenses, to see how it ends.
For the rest there is the 3GPP patent platform.
Most of the patents are the result of a lot of research and cleverness. Some of the patents are the equivalent of looking in another drawer if the first one did not contain what you are looking in.
It's a bit arbitrary that an API isn't protected when some bullshit patents are. There is clearly much thought in some of the java APIs.
I'd like to see shorter protection time for patents thought, especially in areas where there are very low investment costs, like software development.
That's not quite right - Google adopted Apache Harmony[1] (an open source project, and if you want to attribute an organisation responsible for Harmony's success - such as it was - it would be IBM). Apache Harmony would have been 100% API compatible with Java had Sun (and later Oracle) not refused to provide the Technology Compatibility Kit (TCK).
The Android runtimes (Dalvik, then ART) never had compatibility with Java bytecode, instead, Android build-tools use(d) Java bytecode as an intermediate pipeline step; the ultimate executable had 0% compatibility with the Java runtime.
1. https://arstechnica.com/tech-policy/2016/01/android-n-switch...
That is certainly an issue if you reverse engineer anything. Google went out of their way to NOT reverse engineer it.
The issue is can a public API be copyrighted. That is the scary issue.
In Roman Law there is the principle "In dubio pro reo" (https://en.wikipedia.org/wiki/In_dubio_pro_reo), which means that if there are doubts whether the culprit is guilty or not, he/she may not be convicted.
In the US, it at least seems that something similar does, in so far as we require a unanimous vote by the jury to convict someone in a criminal trial, but a simple majority for a civil.
That is not how copyright works. You almost got it right with your comment "anyone reading the manuals to understand the BIOS was tainted and couldn't write a competitor."
Copyright protects against copying. It does not protect against independent development. Hence the clean room set up.
Silly Example: you design a phone book containing all the names and phone numbers of everyone in the city. To the extent that any subjective decisions were made in the design, it is a copyrighted work. I design a phone book. If I copy yours, it is a violation of your copyright. If I collate the underlying information and then make my own phone book it is not copying, even if it looks exactly the same.
If I take your picture of a building and copy that's a copyright violation.
If I take a picture of a building from the exact same angle you did, that's not a copyright violation.
That's not how it works for copyright. Beyond that, how do you independently arrive at an API that you are trying to have an exact copy of? Photography is not programming. I cannot run a bunch of words through a program until it prints out some book I want and then say I arrived at it independently. You honestly need to read the copyright laws as you are missing some information.
[edit: the original premise of all this thread is IBM didn't try to copyright the BIOS API]
Your original post was about IBM not being able to copyright the PC Bios. Which is simply not true in any way shape or form. https://www.allaboutcircuits.com/news/how-compaqs-clone-comp...
Relevant portion "But one problem remained with their IBM-compatible machine. How would they recreate the IBM BIOS without breaching the copyright? Why did they need a compatible BIOS (basic input output system)? . . . Some companies, such as Eagle, copied the BIOS either by reading the IBM manual to understand which interrupt codes did what or by simply copying the hard-coded ROM chip that holds the BIOS. This breached the copyright that IBM had over the BIOS and so did not take IBM long to prevent such companies from selling more of those machines. However, there is a way to bypass these types of copyrights with the use of a “clean room”."
No, no, no, that is not what I said. I was talking about the API of the BIOS. The BIOS source code is, of course, copyrightable. That is why IBM was able to make it very hard for people to copy it until folks did a proper clean room. Why would I go into detail about the counter measure if it was not copyrightable? That makes no sense.
What "different way" are we talking about here? IBM asserted their copyright quite forcefully against Eagle and shut them down.
Eagle directly copied the source code of the BIOS, they were not sued for copying the API.
The API of a BIOS is not the whole thing! It just specifies the interface by which the BIOS can be called by the OS.
For a crude analogy, consider the interface specification that most modern cars adhere to: there will be a steering wheel with a certain shape, size, and position relative to the driver's seat; there will be two or three pedals, with the accelerator on the right, the brake pedal to its left, and the clutch pedal, if present, to the left of the brake; etc. etc. None of this tells you whether the car runs on gasoline, diesel, CNG, or electricity, or whether the motor is in the back or the front, how many cylinders it has, etc. — all these are implementation details that do not usually affect the interface much.
The implementation of the BIOS — the code that actually performs its various functions — is clearly copyrightable, and always has been. But the API is just the specification of what those functions are and how they can be invoked. Imagine if one car manufacturer had been able to copyright the steering wheel and pedal arrangement that we're all familiar with!
Similarly, if you copy the definitions of all functions/methods/classes/etc from one API, nobody will believe you independently came up with it.
So "add(a, b) returning the sum of the two" is probably not copyrightable by itself, but a whole namespace full of functions might be.
Coypright covers derivative works of copyright-protected works, as well as literal copies. If APIs are copyrightable, there is a very good case to be made that a reimplementation of an API implementation (not an API that serves a similar function, but an actual reimplementation) is a derivative work of the API itself.
The Copyright Act, however, is; if APIs are protected by copyright, than making a derivative work of an API is an exclusive right of the copyright owner.
Which is a key reason why there is widespread concern about the CAFCs ruling on API copyright. (OTOH, Google losing on fair use at the CAFC makes it more likely that the API copyright issue gets to the Supreme Court in this case rather than a later one, so it might be a good thing for resolving that concern.)
No literal copying of text is required for something to be a derivative work. Transforming a work implementing an API into documentation describing the API would produce a derivative work of that API, if the API is protected by copyright. Transforming that documentation of the API into another implementation of that API would also produce another derived work of the API.
To the extent that it's relevant here, that appears to be untrue. This hinges on the fact that with an API, you have to match it exactly, and there's no reasonable way to argue that someone could sit down and do a clean room implementation of the Java APIs that perfectly matched all 3000 classes and all the public interfaces of all those classes.
You can do a clean room implementation of the Java Platform, but you can't do a clean room design of the Java APIs. The whole point you're trying to solve is to make something that's compatible with Java, and that requires knowing the Java APIs, i.e., it's not a clean room. If we extrapolate that back to IBM and clones, as long as the clone makers must come up with the same external API as the IBM BIOS, then this court would say that IBM absolutely could use copyright law to prohibit clones, because the clones would have to have copied the APIs -- not the code, but the names and types used in the APIs themselves, and IBM holds copyright to those names.
I disagree. However, I am not aware of any caselaw on this point. It is an interesting logical twist you have added, but I fail to see how it must be that way in view of the fact that copyright explicitly allows clean-room type reverse engineering.
The legal status of reverse engineering is not at all clear-cut. There are many nuances depending on the circumstances, and much of it is determined by case law rather than statute. There's no clear basis for you to make claims about how this new class of copyright (on APIs) will interact with reverse engineering. However, it is much simpler to state that if APIs are a work subject to copyright, then it must be possible to make derivative works of APIs that are also subject to copyright absent any explicit exception or fair use right.
You have not at all established this point. What makes you think that the API of a reverse engineered implementation is not tainted by the copyright of the original API? It's clear that clean room reverse engineering produces an independent implementation, but it also seems clear that such a technique does not prevent the structure, sequence and organization of the original API from strongly influencing the structure, sequence and organization of the reimplementation's API.
Blackbox testing -> API Specification -> Implementation
and
Copy API Specification -> Implementaton
In the first case, you will come up with something similar but ultimately original. In the second case you are blatantly copying someone else's work.
To make that more concrete: if Oracle's string concatenation function is called `String.concat` and Google's is called `String.append`, then code which calls `String.concat` isn't going to work with Google's implementation, and code which calls `String.append` isn't going to work with Oracle's implementation. It doesn't matter if the APIs are "similar" or not, they have to be _identical_ in order for code written for one system to be interoperable with the other.
That's one of the most important issues with this ruling; it effectively bans even black box reimplementations.
So, barring this case being both heard and affirmed by the Supreme Court, this interpretation of copyright law, while potentially decisive in the outcome of the present case, isn't, substantially, law, so much as an idea of what the law might be.
But, because Oracle v. Google case had an ancillary patent question in an earlier appeal, the appeals are instead going to the Court of Appeals for the Federal Circuit. This court is really only supposed to answer patent questions. The CAFC can't set precedent in these matters, and overwhelmingly defers to the district courts' precedent. Bot for some reason they have chose to ignore all of that this time and make their own, fresh (and super weak) precedent that only applies to copyright cases with patent questions.
That is just not true. According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.
The Federal Circuit has the right to hear and decide this particular case, but they do not have the right to establish binding precedent on lower courts or other appeals courts in matters of copyright law. This has been explained to you repeatedly.
Not all types of reverse engineering is considered copying. See IBM PC BIOS cases.
Copying APIs is strictly necessary for interoperability. Allowing APIs to be copyrightable encourages monopolies by legally prohibiting newcomers' software from being compatible with their competition.
It'd be like if Microsoft were allowed to sue Google Docs and Libreoffice for making their software able to open Word documents. (Except in this case the "documents" are source code.)
How can it "capture" the calls without knowing what it's capturing? It has to know that there's a windows API function called "CreateWindowEx" that takes particular parameters, otherwise how could it possibly "translate" it? And the fact that CreateWindowEx takes particular parameters is precisely the API.
Of course the implementation of that API will be different in WINE, just as Google's implementations of the Java API are different from Sun's (aside from the 9-line rangeCheck which is a separate issue). In fact it would be fair to describe what Android does as "capture the API calls and transform them into a different Dalvik API call that ends up performing the same function".
So... you're saying it needs to implement the Windows API? If APIs are copyrightable, then that's a violation of Microsoft's copyright. You've included a copy of Windows' API in WINE.
What if I create my own smart home server that can be a drop in replacement for some commercial product using just what I've gather from their public API? Is that infringement, when the underlying implementation is entirely my own?
It depends on how you create your server. If you go to their website, look at their API, and start typing identical code then that's not ok. It's pretty clearly copying. If you do black box testing and then write your own API that's fine. It's clearly not copying but a new original work.
That is why telephone books and others things are not copyrightable. They are lists of facts. API's are lists of facts, a functional specification for use.
There are consequences if this stands and it will not be to our benefit as programmers, developers, designers, etc. Nor will it be to the benefit of society as a whole.
In other words, if it does feature the same selection and arrangement, it is a violation of copyright.
Your statement that APIs are not copyrightable is not true as well.
Using this as an analogy for the API would mean anything that was part of the technical implementation could be copied but inconsequential or artistic parts couldn't. This has been interpreted to mean that the actual code is "creative", so you'd have the framework of the code but not the non-essential parts that could be different and still allow the API to work.
Take this as an example: https://docs.us-phoenix-1.oraclecloud.com/Content/Object/Tas...
Here is an example of a potential copyright infringer copying the API for another competing service. I'd hope they acquired a license for it, otherwise.
[0]: https://www.opengroup.org/openbrand/register/
https://en.wikipedia.org/wiki/Single_UNIX_Specification#Curr...
There's no doubt that if it is established that APIs are subject to copyright, then someone owns copyright to the C standard library APIs. It's not old enough for copyright to have expired, and nobody has ever released the APIs to the public domain (because nobody ever seriously thought that such a thing would be necessary). Establishing API copyright as a real thing without broad fair use rights would throw into doubt the copyright ownership of a large portion of all software ever written.
People shouldn't have to write shit code cause judges are tech illiterate.
OpenJDK is GPL. If you comply with GPL, no. This is the problem, Google copied and did not comply with the GPL. Their other option was to pay Oracle/Sun a licensing fee for a commercial license. This is exactly the business model many GPL users follow. Ruling otherwise makes this business model invalid, but it also creates a double standard.
Consider a programming language where you program in types, like Idris. The case is more obvious here. The API is a program. The same applies to Java too, but that seems less obvious. The API is the program that produces compiler output.
I thought the OpenJDK people needed certain concessions to release their VM under the GPL?
GPL users charge money for a license on the implementation, not on the API. Or do you know any charging a license for the API itself?
SQL standard and the respective certifications have to be payed for.
Before that, Oracle ripped off Chamberlin and Boyce's work. Which they should be able to do, because APIs shouldn't be copyright-able.
At least Oracle payed something back, unlike Google, ripped off Sun and then stepped on it on their dying breath.
If it wasn't for Oracle we would be stuck porting Java 6 to other languages.
Aicas, PTG, IBM, MicroEJ, ....
Big difference with Google?
They play by the rules.
Or they will be sued out of existence. Google? probably not. IBM tried Harmony play along with Apache but backed away after legal threats.
"In a closely watched 2014 decision in the dispute, the Federal Circuit said the APIs were entitled to copyright protection."
Apparently, header files (which were subject to much discussion in the case) are still a legal minefield.
Sometimes I forget what a corporate brainwash hackernews can be.
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...
That's it. The VMs on the market at the time we're absolutely terrible for phones. John Carmack was commenting on how JavaME gave you worse performance than an original IBM PC, and HotSpot's strategies absolutely destroy battery life.
There are OEMs selling commercial JDKs for embedded use, with their own VM, JIT and AOT compiler variations, and library extensions.
Contrary to Google, they always played by the rules.
Nokia and Sony-Ericsson flagship phones were quite good.
So one either swims or joins the graveyard of companies that tried to fight it.
I'd argue that it's next to impossible. OSes are a commodity now. Even Microsoft is coming around to that idea.
> tech unlawfully taken from other companies.
All of the previous caselaw said that this was fine.
Java still exists today thanks Oracle, not Google.
They also offer customized versions fine tuned for their deployment scenarios, doing Java bytecode to either native (AOT) or their own proprietary bytecode format when generating the firmware image.
Or for example, IBM Java running on IBM i mainframe, where Java bytecodes used to be translated into the TIMI bytecodes, just like any other IBM i application.
Firmware does not change during runtime.
When you create your own USB cable, or electric plug, you aren't copying the API specs, you're implementing them.
I'm not worried about Google in the least, I am however concerned about the precedent this sets.
The original license for Java said you can create your own implementation just fine, so long as it was compatible with the others (or at least the benchmark one). By not doing that, Google violated the license.
"It's a bit odd to claim that somebody stole your API while at the same time complaining that they did not steal it well enough."
Not if what you want to avoid is people Embracing your API, Extending it with new special bits, and Extinguishing your version.
And specifically, use of a J2SE implementation in mobile devices may have been forbidden.
Licensing costs can scale according to the customers business size and revenue. What is more concerning is that this may create precedent that API specs are copyrightable -- to the degree they are worth billions in damages.
I think some people in this thread are minimizing the issue because they don't like Google but I think it's naive and short-sighted. It's not about Google or Oracle, it's about copyrighting APIs.
It's legal precedential value is limited, because it was a copyright decision in the Court of Appeals for the Federal Circuit (CAFC).
The general principle for a precedent is that precedent for court X is set by the appeals court that hears appeals from X, and the appeals court that hears appeals from that appeals court, and so on.
So, for example, the district courts in the 9th Circuit (which covers the west coast tech companies) gets precedent from the Court of Appeals for the 9th Circuit, and from the Supreme Court. In particular, this is the appeals path for copyright cases.
The appeals path changes for a few special subjects. Patent appeals from all of the Federal district courts, for example, go to CAFC. So, in matters of patents, a district court in the 9th district would look to CAFC for patent precedent, not the 9th circuit appeals court.
Oracle sued Google for both copyright infringement and patent infringement. The parties were OK enough with the outcome of the patent part of the case that no one appealed that, but the copyright decision was appealed.
You might expect that this means the appeal would go to the appeals court for the 9th Circuit, because only copyright issues were being appealed, but that's not how it works. Where the appeal goes is decided by what was at issue in the original case, not by what was at issue in the appeal.
The rule is that if a case has both a special subject, such as patents, that points to CAFC, and other subjects, such as copyright, that point to the appeals court for the circuit the district court is in, the appeal goes to CAFC. CAFC handles the whole thing.
When CAFC gets a subject that normally does not come to them, but got there because it was attached to a case that also had a subject that does go to them, the rule is that they are supposed to follow the precedent of the appeals court for the circuit the district court is in. They don't set precedent in that district.
For example, if two companies sued over copyright in the 9th Circuit, with no other issues involved that would deflect the normal appeals path away from the 9th circuit's appeals court, the district could would look to that appeals court and the Supreme Court for precedent. CAFC opinions on copyright would at most be interesting opinions it might look to for insight, just like it might look to courts of appeals for other circuits, but only it's own circuit's appeals court and the Supreme Court would be precedent it has to actually follow.
PS: I think we'd be better off if CAFC just got the patent appeals. If a case has both copyright and patent issues, send patent appeals issues to CAFC and copyright appeals issues to the circuit's appeals court. At the trial level we merge cases that would normally be in different courts into one (e.g., if a case has both state and federal issues, it goes to federal court and the federal court handles the state issues).
That makes sense at trial court level because they involve examining witnesses, examining experts, and similar. If different issues were heard in different courts, many of those witnesses would have to go to multiple courts. It could be a major hardship on them. You'd want to hold them all in the same area, at near the same time, to minimize travel. That could be hard to schedule.
Appeals courts, on the other hand, just work off the transcript from the trial. The only people needed there are the lawyers arguing the case. The lawyers for appeals are usually more specialized than trial lawyers, so there are quite possibly different lawyers handling the different issues in the appeal.
It would not be much of a hardship, if any, for different issues to go to different appeals courts, as long as a little care is taken with scheduling.
Heck, it might even be less of a hardship. Imagine you are a copyright appeals lawyer in the 9th Circuit. Normally all your appeals court...
I'm not sure I follow - Google believed they didn't need a license, just like everyone who used Linux despite SCO offering to license Linux to them.
If Google needed a license, and Sun had not offered one, it would not make a difference; Google would still be liable for infringement. There's no abandonware or compulsory license provision in the laws for this. The question is whether Google needed a license, not whether Sun was willing to offer one and for what price.
Whether or not they knew that someone would come along and sue them doesn't matter if the lawsuit is unjust.
Even if Oracle is correct, and even if APIs can be copyrighted, Google's intent still doesn't matter. The only thing that matters is whether or not they infringed.
I consider this to be a form of victim blaming. You should argue the case on its own merits, not posit that Google was "asking for it."
Google had a responsibility to their shareholders and customers to do the right thing regardless of how stupid they thought the law was, and their attitude here was pretty arrogant. (To avoid beating up on Google, I should point out believing they could take on anything helped them do some work that changed the world for the better.)
Since the attitudes of parties involved in a case are often considered in judging the case, I think it's entirely fair to bring them up.
If you then turned around and argued that the hacker somehow wasn't in the wrong because of the victim's attitude, yes it would be.
Victim blaming has nothing to do with someone's responsibility to others, and everything to do with taking a conversation about whether an attack is justified, and shifting that conversation to instead suggest "well, dumb people like that deserve to be taken advantage of."
Oracle contested that Google infringed their IP. "They should have known we were gonna sue them as soon as we smelled the money" is not compelling evidence for that claim.
Much in the same way, saying "Johny should have turned off his attitude and just given us the money" is not compelling justification for a mob hit.
It was Google's misfortune that through a quirk of the system the case wound up in the Federal Circuit, which has a history of creatively ignoring precedent to fashion new precedent that increases its own importance. (Which is how we have patents on all sorts of crap that the Supreme Court has ruled that we shouldn't.) And it was good lawyering on Oracle's part to throw every possible argument at the case, including the copyright arguments that they knew they should have lost.
Google probably had to use their implementation and J2ME was and still is a piece of shit.
Yes it was about cost, but the cost would have been far greater then the licensing price ;-)
So although you're correct that Google did this themselves, the alternative was fraught with problems also. Better to fight it and lose than implicitly accept the idea and pay.
This was all happening in the context of C#, which people seem to be forgetting about too. It's important to remember that the whole idea of copyrightable API was done under the argument that it was important to protect API integrity from forks. MS provided evidence of a desire to do this (as has Google to some extent since then) but then introduced C# instead.
Anyway, this is a mess because copyrightable API is ridiculous, but Google should have been more careful with cleanroom implementations.
http://www.zdnet.com/article/the-worst-decision-google-ever-...
But even if it's not, the decision needs to be appealed. Right now the situation is that APIs are copyrightable, but only for sure within one of the US Federal Court districts. In the other districts, they may be copyrightable. Or they may not be. If they aren't, then we have different law applying in different districts until the Supreme Court decides to resolve the issue. A Supreme Court decision now, one way or the other, would at least give resolution. (If they decide that APIs are copyrightable, then we'd have different law in the US and Europe, but at least it would be the same law everywhere in the US.)
[Edit: Apparently this isn't in a district court, it's in the Federal Circuit, which handles patent cases.]
https://arstechnica.com/tech-policy/2015/05/white-house-side...
I wonder what will happen this time.
When the Supreme Court was considering Google's petition to hear the case, the court asked the White House to voice an opinion—where by "White House administration", you mean the Solicitor General.
That's not "weird"; that's a normal part of the job.
https://en.wikipedia.org/wiki/Solicitor_General_of_the_Unite...
The point is, nuance matters. If you're physically attacked and defend yourself in a way where you end up killing the guy, you claim that your actions were justified. You don't go to court claiming that killing people is just not a problem.
Here's how this case should go:
0. Oracle sues Google for copyright infringement.
1. Courts find that the design of APIs is an expression resulting from substantial creative decisions far above the low bar we already have for precedent, and therefore they're copyrightable.
2. Google defends themselves on the claim that, creativity notwithstanding, merely implementing a public API should not subject an implementor to the consequences of copyright infringement, and that there are no damages owed here.
And by every indication, we're right on track.
https://news.ycombinator.com/item?id=10949839
And it looks like you're moving the goalposts and shitting out two-second replies, anyway, so I'm done commenting further here.
Nothing weird with that. APIs are meta tools, not actual tools. That's what "I" in the name is for. They are interfaces for a reason. It makes perfect sense for interfaces to be non copyrightable. EU courts got it right:
> And by every indication, we're right on track.We are not, until Supreme Court will overturn the current ruling and will clear APIs from copyrightability for good.
> I'm done commenting further here.
Sure, you brought no arguments to defend the illogical position of APIs copyrightability anyway.
[...]
> And by every indication, we're right on track.
You're leaving out the step where the district court found that APIs aren't copyrightable, but the district court was overruled by an appeals court that normally has no right to rule on such matters and does not set binding precedent on such matters. If Oracle's now-dead patent claims hadn't been included in their original complaint, then the process you describe would likely have ended Oracle's case at step one with the Ninth Circuit upholding Alsup's ruling on API copyrightability.
Second: That's a stretch. To argue that the case would have stopped at the Ninth Circuit is to argue that because the Supreme Court denied Google's petition to reverse the Federal Circuit, then they would have denied Oracle's petition to reverse the Ninth Circuit. That's a junk argument.
That's not the argument I'm making.
The Supreme Court had several procedural reasons for not granting Google's petition for certiorari: the Federal Circuit's decisions were not setting binding precedent outside of this particular case, and there were still issues to be decided by the lower courts that included avenues for Google to prevail, making it unnecessary for the Supreme Court to render a landmark decision on the matter of API copyright.
If the appeals had gone to the Ninth Circuit, Google's appeal would have stood a much better chance than it did before the Federal Circuit. A Ninth Circuit decision in the matter would have set a very important precedent, but a decision in favor of Google would not have created any obvious circuit split and wouldn't have upset the status quo of the software industry. On the other hand, a decision in favor of Oracle would potentially have consequences serious enough to be a priority issue for the Supreme Court whether or not it created a circuit split.
Go on, finish the thought, and make your conclusion explicit. Because by any reasonable reading, you're suggesting that the Supreme Court would not have granted Oracle's petition if Google prevailed in the Ninth Circuit. And yet you start by saying that this isn't your argument. Be explicit.
This is a very important nuance. As I understand it, for the issues in this case that are outside the Federal Circuit's usual jurisdiction (patents), the Federal Circuit was supposed to rule however the local circuit (Ninth) would have ruled. The Ninth Circuit probably wouldn't declare APIs copyrightable, but the Federal Circuit did.
However, the Federal Circuit doesn't establish binding precedent for the Ninth Circuit on non-patent issues. That's part of why the Supreme Court didn't take up this case, and why many of the amicus briefs recommended against the Supreme Court taking up the case. Google gets screwed, but that ruling didn't have cause an immediate upheaval of copyright law in the jurisdiction that includes Silicon Valley and Redmond. All that their decision really established was an incentive to include bullshit patent claims in any copyright suit that pertains to APIs, so that you can get your appeals heard by the Federal Circuit instead of your local circuit.
I would argue Google is likely to win a jury case over Oracle in most cases because Google, at least until very recently, has widely been viewed as a "good" company, and is one that is popular with the average user.
I think that's their only business, by design. https://en.wikipedia.org/wiki/United_States_Court_of_Appeals...
So if you are a plaintiff in a copyright lawsuit and you want your appeals to get the pro-IP biased treatment from the CAFC instead of going to the local circuit, make sure to find a way to include a patent claim in your suit.
If this is true, it certainly isnt happening again. Google dominates smartphones and could very easily decide to phase out java for go/rust, torpedoing whatever rent-seeking strategy Oracle had originally devised. What oracle is attempting to do is nothing short of what Microsoft tried to do with TomTom's implementation of FAT.
If BTRFS, percona, and maria are any indication its not the work that matters. Plenty of talented engineers are willing to devote their time and effort to avoiding Oracle. Quite frankly the Oracle Database has turned into a manacle for Ellison. Unable to prevent its inevitable loss to open source alternatives through NDA agreements that prohibit public release of independent Oracle performance tests, and unable to convince cloud-bound companies to continue forking out high dollar per-core licenses for it, The software exists as a 90s anachronism to the hubris of dotcom. Oracle Enterprise Linux was, for all its intentions, a flop, and after acquisition and rebranding MySQL is a withered husk compared to its open source counterparts.
The point is that in BigCo environments the norm still is "no one ever got fired for buying IBM and Oracle" and even if that were not true shitloads of enterprise crapware are bound to Oracle's offerings and that alone will secure revenue for Oracle for decades to come. Hell when I look at the average age of stuff in the banking and insurance sector I would not be surprised if Oracle is still going strong in a century.
Because wanting to be paid for one's work is "rent-seeking" now?
And no, Google really couldn't. There's a huge library of Android applications that are using Java technologies to make them. Google can't replace Java with go/rust/dart without throwing all that away. They would have to continue to provide support, which would continue to put them in violation.
They will get damages for everything that has already happened if they win, which is more than zero, so they do have a clear profit motive.
Oracle gains nothing by having Android use Java so if they force Google to use something else it doesn't matter to them.
Someone should appeal and bust their case that claims that APIs are copyrightable. And don't forget those who supported this crookedness - Microsoft.
Is everybody who has implemented a struct with a Writer method which satisfies the 'io.Writer' interface and as oracle stated it 'who wants to use them for a competing platform or to embed them in an electronic device' now (hypothetical) at risk of being prosecuted because they infringe Googles copyright?
---
I am well aware that Google was the respondent in the Oracle vs. Google case.
The law doesn't work as a set of naive rules like "If API->You need a license" because human life is full of nuances that can never be fully captured in a set of rigid rules. I know that people are uncomfortable with this truth, because our systems of courts often appears to the casual observer as just a bunch of "elders" making subjective decisions. Hence "smart contracts" etc.
And while the criticism isn't completely wrong, the system as it exists in the US today is actually working quite well, with the professional ethos and rules of the court system being somewhat successful at overriding any individual judge's predilections.
Anyway, in your case the difference is obviously one of scope. Even in the original ruling that affirmed APIs to be subject to copyright, the judge ultimately dismissed the case because they considered Google's actions to fall under "fair use".
While this was now struck down on appeal, it is absolutely certain that copying a single method's signature would still be protected as fair use. Moreover, in the case you mention, a method such as File.write() would probably not fall under any copyright because there isn't much of any creativity involved.
One thing I have a particular problem with is that even judges from the same country seem to come to different results on the same case. I know its not unusual but that underlines my point that just because some judge came to some verdict, it isn't necessarily true.
And if 'the system as it exists in the US today is actually working quite well', why does a company like Google with a lot of smart people will have to pay a fine which probably will be as valuable as the whole Java platform? In a system that actually works well, the smart people would have seen what was going to happen and different judges would come to the same result.
And that something as 'simple' as a single method interface doesn't require any creativity is just wrong. I am sure there are a lot of famous creator quotes about that, the first I was able to find is from Steve Jobs:
In the case of Golang that would translate to: It is much harder to build a universal single method interface for all kinds of write operations opposed to specific write methods for different use-cases.[1]: https://www.goodreads.com/quotes/445279-simple-can-be-harder...
If you tried to create a different implementation of Go that used the same API, whether you could get in trouble depends on Google's license. And then, if the license is against you, whether you do get in trouble would be at Google's discretion.
Note well: IANAL. Also, I'm still hoping that this "copyrighting the API" will be overturned at the Supreme Court, in which case this whole conversation is moot.
This is the legal drama that never stops giving...
If the Supreme Court appeal happens, it probably puts the lower court trial on hold. If Google wins the appeal, then (I think) there's no case left to try in the lower court.
This (Android's use of Java) has always been a risk for Google. Either in form of the lawsuit but in more general what Oracle (or someone else) would do with Java.
Anyways. I hope both companies are smart enough to settle this in a reasonable manner.
Hey! Stop laughing!
If you've ever wrestled long with getting a program to compile, you realize it's non-trivial to wrap your brain around complex types. The API is a language and the compiler is a runtime producing output. I can design my API in something like Java and return null from all the methods while I do it. The compiler will still produce expected results when I try to string bits of it together.
For most languages, this work is hard, because everything is a runtime error from the compiler. There are elegant and inelegant ways to solve certain problems. The API determines that. It is itself a creative endeavor.
Google was given the opportunity to license the API. They still can under GPL, but that means complying with GPL, which they evidently did not want to do. Ruling in favor of fair use here creates a vague double standard. Business models like that of MongoDB, who releases their code under GPL for open source projects and charges a license fee for private projects, would become questionable. "Well, you give it away already, so it's fair use to use it any way we like without paying you!"
What about Linux? Linux copied the Unix syscall interface.
What about Wine?
Not true. Android has been exactly that since 2016. Harmony is dead (killed at the ASF, even), and Android is now using OpenJDK.