Oracle Wins Revival of Billion-Dollar Case Against Google
bloomberg.com
bloomberg.com
There is a reason for this: if it were the rule that an appellate court could easily step in and second-guess how a jury weighs evidence, there would be little room for finality with jury verdicts because lawyers are very skilled (and become very tiresome) endlessly arguing why this or that fact is better than another and why a court should weigh things differently than the way a jury did.
In this case, the Federal Circuit Court did what amounted a wholesale second-guessing of what the jury concluded about the facts here.
I am not saying the issues were not complex and that it had absolutely no basis for coming to different conclusions.
But the zeal with which this particular court upholds IP absolutism is truly a marvel.
This is the court that gave us the frivolous patent bonanza dating back to 1990s by which "everything under the sun" became patentable and many suffered for years from the consequent harm.
So too with the way it is handling copyright law in this Oracle/Google dispute. Yes, by all means, let us protect the hell out of APIs and invite endless future litigation that ensures that easy connectivity in the computer world will no longer depend on engineers but on lawyers. And let us say that "no reasonable jury" could possibly conclude that copying even a tiny amount of code could possibly be "quantitatively insignificant" so as to shield the one doing the copying from claims of copyright infringement, all the better to ensure that future lawyers can conjure up infringement claims from all sorts of seemingly quantitatively trivial copying.
I deliberately exaggerate in how I characterize this decision knowing that it glosses over all sorts of fine points that are the subject of profound argument among lawyers. But I do so to capture the spirit of this decision and what decisions like this mean for computing generally.
Yes, a very broad theory of what is patentable can readily be defended in the name of protecting IP rights and lawyers can come up with endless arguments for why this should be so. So too can lawyers make convincing arguments for very broad theories of copyrightability and very narrow readings of fair use. In both cases, the law protecting IP gets an expansive reading.
Well, speaking as one who has tilled this soil for a long time and who very much supports and sees the need for strong support of IP rights, I can only say that the Federal Circuit Court has proven to be a largely counter-productive force in serving as a specialized court dealing with IP among federal courts. This ruling will do what its prior expansive reading of patent law did: it will set up a legal standard that invites lawyers and litigants to engage in endless second-guessing over copyright and fair use in areas of connectivity and inter-operability in the computing world and this in turn, as a standing invitation to litigate, cannot be good for future development.
Lawyers will never become obsolete until we no longer live in a society that obeys the rule of law.
The more common term is "necessary evil".
In the current world, I think it is more common to be seeking loopholes, weaknesses, and exploits instead.
Corporate law? Their job is keep us from getting sued.
Family law? If you're advocating that human perspective for the opposing party, are you failing your duty to your client?
Prosecutors? Not sure they have that discretion.
General legal services, probate, etc. Doesn't seem that applicable.
Intellectual Property? Human perspective? Unlikely, except maybe the "hard-working inventor" angle.
Defense attorneys? Sure. That could be a good angle - along with any possible opening to exploit.
I'd love for you to provide countering perspectives from your broader exposure.
They shouldn't be advocating the opposing party's human perspective in court, but they certainly should be doing it privately to the client. Things will usually work out better for them if they can reach an amicable compromise out of court rather than having to engage in protracted legal battles with their own family.
> Prosecutors? Not sure they have that discretion.
Prosecutors absolutely have that discretion. They don't have to take every case to court and they don't have to seek the harshest allowable punishment for every case they do take to court. They are supposed to be serving the public interest, not seeking to imprison as many people as possible.
In this day and age, there are far too many laws to both understand and be sure you are law abiding. Ignorance of the law is a given. Ignorance not being an excuse for something like murder makes sense because you should just know better, ignorance not being an excuse in possession of the feathers of a protected animal that you found on the ground should be valid even though this presents an insurmountable burden to prosecution: it shouldn't be possible that picking up feathers you find on the ground is a crime, but it is.
The sentence "a lawyer who represents himself has a fool for a client" should be an indictment of the legal system and not a jeer at the self-represented. Justice should be given to those who deserve it, not to those who manufacture it through technicalities. The fact that a lawyer is necessary to achieve justice implies you are not achieving justice but rather merely a bureaucratic victory.
This state just renders law into bureaucracy and divorces it from the concept of justice. The rule of law is only sensible insofar as it can achieve justice, not as its own end divorced of anything humanly meaningful.
I think the core problem is that this misinterpets the phrase "rule of law", which Google defines as "the restriction of the arbitrary exercise of power by subordinating it to well-defined and established laws."
If your lawyer's arguments, preparation, and skill matter, or if it matters whether you have a lawyer or not, then you are being subject to "arbitrary interpretation" of the legal landscape, rather than to well-defined and established (and understood) law.
Your /lawyer's/ actions affect the judgment, rather than just your actions.
In reality, "defining the spec" is the entire purpose of having a legal system in the first place. A nation is a machine that is evolving its own state. There's no outside "programmer" who can observe and define the entirety of the desired state. (Unless you believe in an active interested conception of God, perhaps.)
The legislators, lawyers, and judges who tell us what the law is, are part of society too--and that's why the law changes over time. It's supposed to change over time. The law constrains human behavior, but it also reflects human behavior, so the state of what's legal right now exists in a weird state of superposition between the two.
But, the fantasy that one is outside of, or separate from, society is a popular one--seen most clearly expressed in the libertarian creed, but popular in Silicon Valley too, at least from a business perspective. What do most tech companies want from the government? To stay the heck out of their business, stay far away, and don't bother me. That includes lawyers.
So you're going to get downvoted here, but I don't think that means you're wrong.
It indicates there is a large amount of incidental complexity.
Clearly, exterminating lawyers or deleting random files is not a workable solution. But we should invest in reducing the system to essential complexity. If we are successful, the symptoms will subside.
It's worse than that. They are supposed to be applying ninth circuit law, and they roundly haven't throughout the entire appeals.
They've made a complete mess of it. First in copyrightability, and now fair use. There are even ninth circuit judges who have spoken out about this.
Technically, this doesn't have any effect on 9th Circuit law because CAFC decisions applying (and I use that term loosely, here) a particular Circuit’s law do not form new binding precedent for courts in that circuit (or even precedent binding on the CAFC itself in future cases applying the same law.)
But, no, the Ninth Circuit can't intervene that way, though tension between Ninth Circuit precedent and a decision, even if non-binding on other courts, in the CAFC presents an issue similar to a conflict between circuits that would ordinarily seem to weigh in favor of the Supreme Court taking the case on appeal, since avoiding effectively having different systems of federsl law applied to different cases is one reason the Supreme Court exercised it's discretion to hear appeals. It seems certain that Google will appeal this.
People very often make the mistake of assuming two people with the same data will form the same opinion, and that where people disagree, it must be due to not understanding the data/etc.
In my experience, this is very wrong :)
I've met the ex-Chief Judge of the federal circuit, Randall Rader, a number of times (he also taught a class i took in law school at GWU).
He's definitely not stupid, is cognizant of how people view his decisions (he said "they loved me when i wrote nintendo vs. atari and hated me when i wrote other things"), and really did believe he is making things better.
Of course, i strongly disagree, but like i said, it's not like he doesn't understand the issues.
Just to get this straight, because I think I roughly know the legal system works in the US, from TV and movies, but then when I apply it to a real world case such as this, it seems too ridiculous for words: by "jury" you're actually referring to a group of about 10-12 randomly selected laymen with no background in law whatsoever, and even specifically selected to also have no background in the subject matter (because knowledge equals prejudice /s), and they get to decide on the outcome of a billion dollar case?
Fair use has four factors, lets see how it shook out:
1) Purpose and Character: Google tried to argue that because android is free that it isn't commercial. Bzzt. Nope. You don't need direct monetization to make something commercial.
Was it transformative? They verbatim copied shit. Google claimed it was transformative because they used it in smartphones, yo. No. You guys who think patents that slap "but use a computer to do it" onto the end of some existing process are bad? Google's trying to say the same thing per computer form factor.
2) Nature of the Copyrighted Work: Dealt with previously - APIs are copyrightable. Lots of people have an issue with this, but the previous opinions on that point are where you should go for material on that point.
3) Amount and Substantiality: Bad faith usage came out around neutral; wasn't a huge amount copied but it was important material, as admitted by Google themselves.
4) Effect on Work's Value: Direct evidence of market harm demonstrated by showing that Amazon leveraged Google's infringement to lower their license payment. Slam dunk.
Overall, I agree with the other posters indicating that once API copyrights were upheld that this was going to be a clear loser for Google. Maybe they'll get cert and have the supreme court take a look at this following the re-trial.
I don’t necessarily agree with the decision but I can see where they’re coming from.
Edit: And particularly there's tons of case law that this stuff isn't copyrightable, see Sony v. Bleem, where a company literally wrote an emulator of a PS1, and courts said that was fine. Even to straight up sell as a competing product, and for running on competitors machines.
Edit2: And the otherwise shitty DMCA even has explicit exemptions for software interoperability purposes.
There is a bit of a "intellectual property" slippy slope going on here. Whether or not something is useful or non-trivial is inconsequential.
You could design an engine to have an artistic structure. What you couldn't then do is stop anyone copying the functional parts of the engine and leaving out the purely artistic elements.
PS: I am not a lawyer. Above piece of knowledge is coming just from what I read, perhaps on HN during the previous ruling on the case.
At the time, though, I don't believe it was open source and OpenJDK originated as a cleanroom rewrite of it, and has since been integrated.
What if I named my function 015342342(String 123949)? How does that change anything?
Without endorsement, there is definitely a line between text in which one can be "creative" and numbers in copyright law as written.
The problem here isn't the line between creative and non-creative, the problem here is the introduction of copyright, a concept created for expressive works, into a field that consists of functional works. It should not be a surprise to anyone, not even lawyers, that this isn't going to "just work". The surprise to me is that it has taken this long for this foundational clash to start emerging at a big scale.
The choice of call name in an API are arbitrary, the reuse of those names to interface with that API is not a creative copy it's a technical requirement.
If I make a toothed belt to fit a pair of gears, that's not an artistic expression no matter the the tooth pitch is an exact duplicate of that on the gears. If the gear is purple and orange spots, in a distinctive pattern, and I make my belt the same pattern then that's a copyright issue.
If the API calls were like "thisIsTheSummerOfOurDiscoTents(banana)" - such that the names are sufficient to be individual works of art, and weren't following a technical function, then perhaps you have an argument that the API is a work of literature, or otherwise an artistic creation.
It just sounds like a wrong decision was previously made and should now be overturned.
The real key point is in the second half, though. Arguing over whether or not a particular micro-decision is "creative" is the entirely wrong track to be taking when we're discussing something that is functional, that performs some real task in a way that a movie or song simply does not. Why would we expect standards based on "creativity" to apply to that in any sensible way?
It's impossible for a collection of letters to be creative but for that collection of letters when represented numerically to be no longer creative. If I make up some BS for how there's a correspondence between these symbols and other symbols (1=alpha, 2=bravo, ...; or 1=sandwich, 2=wellington, ...) - then 1383() is just sandwichBiscuitAppleBiscuit(). Then it's clear the creative aspects of the program, API, or whatever, don't lie in the specific choice of tokens.
Would a judge agree that providing a dictionary/key that says an arbitrary name for each number (easy to do programmatically) makes a program creative that otherwise wouldn't be. It's clearly ridiculous. Not least because it would mean that duplicating a work that was compressed, or represented in binary, would then no longer be a tort, because apparently numerical representation would rule out a work from being creative.
And yeah, I guess that IBM could start suing everybody... this whole situation is so ridiculous.
Other forms of structured metadata use cross-party?
Or IBM could realize if they start doing that, it might show the insanity of the current law, and result in the law changing back to what it was and should be, API's not copyrightable.
Seems pretty straightforward.
There's nothing legally stopping you from doing the same; Disney does not own these stories.
They literally admit to having copied it.
All the hypotheticals trying to find the end of cleanroom dev in this case keep missing the point: They didn't do cleanroom dev. They admit to not having done it. Their defenses aren't organized around them doing it. So what's the furor about?
Alsup: "I have done, and still do, a significant amount of programming in other languages. I've written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There's no way you could say that was speeding them along to the marketplace. You're one of the best lawyers in America, how could you even make that kind of argument?"
David Boies (counsel for Oracle): "I want to come back to rangeCheck."
Alsup: "rangeCheck! All it does is make sure the numbers you're inputting are within a range, and gives them some sort of exceptional treatment. That witness, when he said a high school student could do it—"
Probably about the absurdity of being hit with potentially astronomical penalties for "copying" 9 lines of trivial code that's barely worth hitting ctrl-c for.
Obviously, common sense is - as always - distant from the pedantic nature of law and laywers, but just about anyone sane is gonna look at this and go "well that's just stupid".
IIRC, the literal copying of code was something for which the parties stipulated to $0 in damages; the potential liability is about copying the API, not the one trivial 9-line function.
So a Google employee was donating code to Oracle, and they sued them for it. It's absolutely shameful behaviour.
Obviously that sounds pretty crazy, but if it's true, it would at least be an approach that I could understand.
Uhhh. No. Just no. I don't think you understand the meaning of "clean room" in this context. In this context, clean room means that the person in the room is untainted by any copyrighted information full stop.
The problem I'm describing is that in this case the kind of thing you'd typically want to write in that documentation is exactly the signatures of methods, which would amount to copying the copyrighted material and would taint the whole clean room. I'm trying to think of a way you could even do clean room engineering if the signatures of methods are copyright information. The reimplement from usage examples is the only thing I can come up with.
These $9 Billion dollars will look great on Oracles bottom line. The mega-billions in possible lost trade and efficiency make me think this ruling gets reversed with a vengeance.
(And yes, I know: The overwhelming majority of the work was a clean room implementation, but not all. In retrospect, this was an unfortunate mistake by Google.)
In my entire career you could not copyright an API. There is good reason for this. If you wanted to do business with certain entities, the implementation had to be multisource. The new implementation had to come from a cleanroom, but in this case it came from open source (which seems equivalent). Therefore you have one judge making one decision that is an anomaly. It seems to me that a single judge should not be making a landmark decision.
This is the 2012 ruling: http://www.groklaw.net/pdf3/OraGoogle-1202.pdf
Alsup indicates that SSO isn't dead law, but finds that APIs aren't copyrightable because they are 'the only one way to write" things to get the key functionality. Copyright doesn't cover purely functional elements and since the expression and the function are the same, copyright bows out.
Note: I like Alsup, but this argument is based on obviously factually incorrect premises which are blown up on appeal.
Here's the appeal in 2014: http://www.cafc.uscourts.gov/sites/default/files/opinions-or...
They summarize the facts as follows: " And, the court informed the jury that Google conceded that it copied the declaring code used in the 37 packages verbatim. The court also instructed the jury that Google conceded copying the rangeCheck function and the eight decompiled security files, but that Google maintained that its use of those lines of code was de minimis. See Final Charge to the Jury (Phase One), Oracle Am., Inc. v. Google Inc., 3:10-cv3561 (N.D. Cal. Apr. 30, 2012), ECF No. 1018 at 14 (“With respect to the infringement issues concerning the rangeCheck and other similar files, Google agrees that the accused lines of code and comments came from the copyrighted material but contends that the amounts involved were so negligible as to be de minimis and thus should be excused.”). "
Ie: Google copied and admitted it copied. This isn't a cleanroom implementation.
For more details on why they found copyrightability, see the discussion starting on p.17. There's a lot in there, and having a discussion about it (or at least a proper one) requires people to look at the actual text.
Edit: Made the formatting better.
I read page 17 and it is clearly written by someone that doesn't understand software. My non-lawyer reading of the justification implies that polymorphism violates copyright law - which is an even deeper issue. This would destroy all modern software development. Yikes! I am now even more confused. Even Oracle would disagree with this point of view.
In your text, you are now making the argument that Google did not have a cleanroom implementation. This is a different discussion that should be on it's own thread.
Regarding your polymorphism point, you've got the cause and effect swapped. The LACK of polymorphism was the basis for Alsup saying APIs are uncopyrightable. Because there's only one way to do something, the words and the function are linked, and copyright does not protect function, ergo copyright wouldn't protect the word either. This line of reasoning doesn't flow in reverse - Polymorphism doesn't indicate that a work is copyrighted or subject to restrictions upon use, or that various safe harbour provisions/copyright exceptions do not apply.
2) There's no need for a separate discussion. I'm not making the argument; it's literally admitted by Google in the context of this case that they straight up copied chunks of code.
> We further find that the district court erred in focusing its merger analysis on the options available to Google at the time of copying. It is well-established that copyrightability and the scope of protectable activity are to be evaluated at the time of creation, not at the time of infringement.
The error is subtle, but crucial: when Sun/Oracle released their API, they gave rise to a new functionality: interoperability with whatever they just created. If someone wants to write a drop-in replacement, they have to read the declarations, copy them all, then write a conforming implementation.
Changing the order of those declarations would still be possible, but one would still have to start from the original files anyway. Assuming those were readable to begin with, any transformation would be a purely legal trick, so they can say "I didn't really copied it".
As far as I can tell the court either ignored or dismissed this interoperability issue. Agreeing with Oracle that Google could have renamed its function names, even though those names are part of the API they were conforming to (the `max` function is obviously part of the standard library), is ignorant at best, dishonest at worst.
I am not arguing that Google has an interoperability exemption. I am arguing that the API is not (or should not be) copyrightable in the first place, because any attempt at interoperability would instantly void it.
I would also argue that interoperability with the training of masses of developers is a thing. Saying it is not only strengthens the relevant network effects, which is bad for competition. I doubt that last one would hold up in court, but still. See how C++ became popular. Not quite compatible with C, but close enough to spur adoption.
And overall, it is very weird that Google's intent matters here. They should be judged on what they did, and maybe whether they did it on purpose. Why they did it should be no more than extenuating or aggravating circumstances.
The court specifically deals with this assertion and does not come to the conclusion that you do.
>And overall, it is very weird that Google's intent matters here.
No it isn't. This case was about Fair use, and intention matters for some of the test elements. A bunch of people think this case is about API copywritability. They're four years too late to complain.
I know. I did read their lengthy conclusion.
> A bunch of people think this case is about API copywritability.
Too bad it isn't. That ruling from 4 years ago is insane. And I recall people did complain at the time, did they not?
I just reread the document, and I think you are referring to page 36. I think Oracle is trying to get around the Sega vs Nintendo case which does protect the API. I believe the Oracle argument is tenuous since you still need to import the Math class to use it. If you don't import it, they you have to specify the Math class every time you use the method. Even if Oracle is correct, then it would mean the Math class is not in the API, it is an implementation detail. Then we are back to the discussion if an open source implementation is legitimate replacement for clean room implementation. Then this becomes an open source discussion and not an API discussion.
The whole Oracle discussion of API seems circular and might be a red herring. The real discussion is at the very end where Oracle says that Google only implemented a subset of the API and not the full API.
One function, rangechececk.
Which premises are you referring to? I am not a lawyer, but I am a programmer, and what you just paraphrased sounded obviously true (at least when "the functionality" means "replacing the old system", a.k.a. interoperability).
If this holds up, every programming language that was not originally produced under a suitable open source license will need to be dropped because all software written in those languages will be infringing an API copyright.
The case goes into discussing this directly, indicating that Google's cleanroom efforts give it evidence that it proceeded in good faith, but good faith alone does not intrinsically absolve you of admitted copying (which is an infringement) that's found elsewhere.
Now if you did an ACTUAL cleanroom and didn't take chunks that you thought were trivial, the argument to demonstrate infringement in the first place would need to be localized on the SSO level, where single-option design choices would again be exempted through the doctrine of merger, and we'd have a much different set of considerations.
As per the jury award to Oracle, you'll be happy to know they're going back to first instance to have another trial to determine the quantum. Maybe Oracle will get $1 again despite winning due precisely to the mitigating factors you've raised. Who knows. This case wasn't about that. It was about fair use.
It's hard to overstate how difficult it is to separate what you want the law to be from what it is. This is why people do so badly at representing themselves, and even lawyers have this problem.
Oh well. I hope some people found it useful.
There are two things in play here and they are NOT the same. The one the whole world cares about is weather APIs are copyrightable. Weather Google is guilty of copying part of Oracles implementation of the code behind the API is not relevant to API copyrightability. If you can't see the distinction you don't understand software or the real core of the case and should stop trolling. If you do see the distinction, why do you keep insisting on conflating the two?
Whether or not the supreme court agrees with the IPRs affirmed in this series of cases is another question entirely, but until that comes down, nothing has really changed.
Happy reading.
I don't understand how this is never brought up with regard to API copyright. API's are software, software has been deemed copyright-able, thus, API's are copyright-able.
Am I going crazy or missing something?
This is, essentially, the fallacy of division.
Interfaces to software have been rules non-copyrightable despite being an element of software and thr software itself being copyrightable; this is particularly the case for user interfaces (Lotus v. Borland is the landmark case here.)
There have been many comments from the legal community, including, IIRC, judges that sit on the 9th Circuit, that the Federal Circuit (which heard this case on appeal because of the patent claims in it) has misapplied binding Ninth Circuit precedent (which is supposed to control on coypright issues in this case because this came up from a district court under the 9th Circuit, and copyright law is not one of the areas where the Federal Circuit has exclusive subject matter jurisdiction.)
Which part of "let's find a small group of the least qualified people to decide on billion dollar cases" ever seemed like a good idea to anyone?
Then there's the judge, who has a background in law but NOT in programming.
Then there's the lawyers, who have a background in both (assuming the expensive lawyers G and O can afford), as well as years and years of practice influencing the decisions of small groups of laymen.
IANAL, but doesn't this contradict case law elsewhere?
> The Java API is a collection of “pre-written Java source code programs for common and more advanced computer functions.”
I'm not too familiar with Java, but I believe they are mistaking APIs for libraries there. Did Google infringe on the libraries or the actual API?
Like did Google actually infringe on what Oracle calls the "Java API" (but is actually a library), and are we all talking past each other when discussing "API copyrightability" when Google may have actually been found of infringing a library?
I think the CAFC may be just as confused about which one is which and on which it's ruling.
Additionally, how would this relate to the Java programming language being "free" and why would Google infringe on anything if it was free?
I don't know the actual details of Sun's licensing, though, but even from what Oracle is claiming now, it seems that Oracle's case is quite weak, and I don't see how its license specifically banned Google from doing whatever they think they did.
Finally, the CAFC's pro-patent rulings are almost always overturned by the Supreme Court, and if I believe they wouldn't even have gotten this case if Oracle hadn't also accused Oracle initially of patent infringement. If Oracle had only accused Google of copyright infringement, I think some other court would have gotten the case, maybe a court with less of a bad record in understanding IP law (going by Supreme Court's rulings at least). It's just a shame that Obama's pro-IP laws lawyers got in the way and convinced the Supreme Court to reject the case.
Was this a mistake or did Oracle actually accuse themselves of infringing their own patents?
Supposedly, both. They made an API with the same structure, names, etc. They also copied a nine-line function called rangeCheck.
Additionally, how would this relate to the Java programming language being "free" and why would Google infringe on anything if it was free?
"Free" is not a legal license. Google would have to start from the OpenJDK implementation, and be subject to its license, which they didn't.
1) AMD chips aren't free and the usage is totally for a commercial purpose.
2) ISAs are an API.
3) While the implementation is probably clean-room, it's still a total copy of the ISA structure and function call/return value.
4) Intel has been directly harmed by AMD competition, which results in them needing to be price competitive in certain markets.
So don't think of Java being in Android. The Android toolchain uses Java, but the Android runtime is not a Java runtime.
For one thing, this makes it different from Amazon using an Oracle Java runtime. But the total set of differences is deep and significant.
Google had little interest in expanding the reach of the Java platform—they wanted to attract Java developers to their “looks like Java, but isn’t” platform while benefiting from the years of work that went into the JDK.
I don’t necessarily think APIs should be copyrightable, but since they now are as a matter of law, I’m leaning towards Google’s actions constituting infringement.
While this may hit on our sense of fairness, it has no relation to legal "fair use". My political parody show owes no profits to the subjects of my derision, IoW.
The same could have been said of Visual J++ but Sun killed that opportunity before it could really flourish.
Bzzt. You really need to make a citation for that statement. Without it there is no point in considering your other 3. The case law around that issue is exactly Oracle vs Google.
The 2018 decision is not the same as the 2014 decision or the 2012 decision.
That Federal Circuit decision has not been reviewed by the Supreme Court, does not establish binding precedent outside the context of this case, and is widely seen by outsiders as being in error for not matching what the Ninth Circuit would have ruled.
It is incorrect to make any categorical statement that APIs are copyrightable. That question is still pending. All that's been settled is that this one case is being conducted under the assumption that APIs are copyrightable, until such time as the Supreme Court decides to review this issue.
The Supreme Court need not weigh in in order to make the law what it is.
-) Are Networking protocols copywritable ?
-) Are REST APIs copywritable ?
I am not sure if this is the way open source world should work.
This is ridiculous. An argument supporting a fair use defense in a copyright proceeding is a very different thing from a patentability argument. Google is not trying to claim patent rights to its Android API.
[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.
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.
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.
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 appearances are in the 9th Circuit, and you have a few cases going on there. Then some stupid mixed patent/copyright case comes along, and no you've got a case on the other side of the country to deal with.
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.
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.
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:
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
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.
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
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.
The theory is that instead of the legislature trying to think through all the corner cases ahead of time, they pass a somewhat vaguer act and leave the courts to sort out some test cases; then in a reasonable amount of time clarity is supposed to emerge.
But it's been 40 years since the world decided that it would "protect" computer programs as if they were literary works, and 30 years since most people thought that the question of API copyrightability was settled, and it turns out that we never got clarity at all.
Having judges trying to determine the question by deciding whether APIs are analogous to chapter titles or plot points in Harry Potter books is just ridiculous.
A. I don't like that APIs are copywrite-able.
B. I wish Google complied with the GPL anyway. I hate this anti-GPL sentiment that has been going around the last 10 years or so.
C. The android play store would probably go through a renaissance if all the apps had to be rewritten.
D. I don't trust Google, but I really really really don't like Oracle.
C. Not going to happen.
OpenJDK is.
They've done just that https://news.ycombinator.com/item?id=10803775
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...
Sun was fine with what Google was doing.
When Oracle purchased Sun, it gained the rights to Sun's intellectual property and decided that it had a case against Google.
http://www.zdnet.com/article/sun-ceo-explicitly-endorsed-jav...
No 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.
If this meets your definition of "very clickbaity" then where could you go to avoid click-bait?!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:
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]
[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.
1) was Sun making applets suck so bad, e.g. the JVM itself was too slow pre-JIT, classloading over the wire sucked, DOM interaction was hard (AFAIU/IIRC), etc.
I don't think any of these problems were fundamental to "put a VM in the browser", as conceptually Java & JS VMs aren't that different: the trade-offs JS/Brendan picked just worked better.
2) was Oracle being so lawsuit happy, as I think Dart could have been "just a faster/better browser-based JVM" (basically applets done right/with a great pre-JIT JVM) and not the combined "new language + new VM + new ecosystem", had Google felt comfortable using the Java language. It would have made a ton of sense, to reuse all their existing/internal Java tooling/knowledge/etc. But not with Oracle already breathing down their neck re Android.
Anyway, agreed it doesn't seem that way, but I think v8's success is actually more related to Sun/Oracle/Java's mistakes/missed opportunities than is initially apparent.
Not complaining, as we're in a great place now with v8/TypeScript/React Native being basically "the VM + type-safe language + framework that Java could have been", but with legitimately awesome features e.g. TS's type system, RN hot loading, etc.
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.
Hey! Stop laughing!
http://www.zdnet.com/article/the-worst-decision-google-ever-...
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.
I'm confused...
So far, the ruling only applies in the Federal Circuit. And you only get into the Federal Circuit when there is a patent aspect to the case. But a forum-shopping litigant could have a patent claim to the case, drop it part way through, and still wind up in the Federal Circuit on appeal (which, if I understand correctly, is exactly what happened in this case).
I agree, this is all stupid, but i'm asking this from the perspective of just finding examples to allow all parties to back off.
If that seems absurd, consider how few people were programming back then and how fundamental and basic the APIs were. It’s worse than the patent mess. At least patents expire in 20 years! Copyright for those 1970s APIs will belong to my heirs for 50 years after I die! (see the Mickey Mouse law [2]).
[1] https://en.m.wikipedia.org/wiki/9_track_tape
[2] https://www.google.com/search?q=mickey+mouse+copyright+law&i...
Would be an interesting idea if Google could compile JVM bytecode apps to run on .net VM. Of course JSV8 engine would be better, but is more difficult.
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.
Please anyone who's ever programmed anything; take a step back and tell me this is sane. Tell me there's not a billion cases like this out there waiting for a lawyer to unearth them.
However persuasive the step by step logic seems, it's the same step by step that paves the road to hell. If logic, reason and law bring us to this point then it's logic, reason and law that need to be carefully reexamined.
You could be the unwitting, unintending offendor by trivial API copying, entirely normal in your prior working experiences.
You could now be the person who has to inform senior staff that due to this decision, code your company owns as IPR is the subject of this kind of copying.
Think about it: If you discovered that any activity you did was now potentially valuable in a lawsuit to generate income, by what right do you not inform senior staff? What you feel about the lawsuit is distinct from your obligation as a company officer, regarding its status surely?
Does this revive the SCO linux case? Who owns the copyright for POSIX/UNIX system APIs?
What about cloud provider compatibility shims, e.g.: S3 reimplementations or Localstack?
I am left with nothing but more questions about the broadness of this decision.
I don’t even hate Java that much I just hate the Java is the only “serious programming language” attitude so common in this industry.
Is this really the best defense? The tag line is "write once, run anywhere" after all. I remember back in my CS days (mid/late 90s) when Java was first being pushed at my uni, the overly-enthusiastic vibe even back then was that Java would eventually be found everywhere, even in mundane devices like toasters and coffee machines.
Someone should appeal and bust their case that claims that APIs are copyrightable. And don't forget those who supported this crookedness - Microsoft.
I also hope Oracle burns to ground in a decade.
Oracle has payed for SQL. Google has not payed for Java.
In 1987, Oracle was already the largest database vendor and IBM's database business never recovered from that setback.
That said, I don't know if Oracle had some sort of licensing agreement with IBM during those early years. The question is what any such agreement would have looked like in light of the recent legal opinions on copyright.
IBM is doing pretty fine with DB 2 and Informix.
Greed has consequences and greed will be the undoing.
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"
So now the API names are all changed.
Basically, if API are copyrightable, whats the minimal change to not consider it a copy?
com.oracle.String/lowerCase
Could this become
com.google.String/lowerCase
So now the name is changed? Or does this all now becomes a case of any similarity can be sued and on a case by case basis courts will jusge if its too similar or not enough?
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.
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.
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.