Hacker News new | past | comments | ask | show | jobs | submit login
Oracle Wins Revival of Billion-Dollar Case Against Google (bloomberg.com)
778 points by uptown on Mar 27, 2018 | hide | past | web | favorite | 615 comments



Appellate courts do not lightly overturn jury verdicts using highly fact-specific reviews of evidence. There is a reason they call a jury a "trier of fact".

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.


"In this case, the Federal Circuit Court did what amounted a wholesale second-guessing of what the jury concluded about the facts here."

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.


For someone who is very much on the outside of understanding this situation, if you think you know enough to comment on it overall, would you say that they are mishandling it due to generally misunderstanding the gravity of the verdicts they are handing out or is it more to do with not precisely understanding the technology, what goes into creating such technology, how technology is propagated and improved, and how that diaspora of code and information winds up becoming the open or closed source "fabric" of what we know as computing today?


They just think the ninth circuit is wrong. They are reasonably well informed, they just disagree.

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 :)


Thank you. I can totally understand that. I appreciate it.


Of course.

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.


Can the Ninth Circuit itself petition the Supreme Court to intervene and stop the Federal Circuit from making a hash of Ninth Circuit law?


> Can the Ninth Circuit itself petition the Supreme Court to intervene and stop the Federal Circuit from making a hash of Ninth Circuit law?

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.


If anyone wants more background on where the Federal Circuit came from and why it has caused so many problems, check this out: https://arstechnica.com/tech-policy/2012/09/how-a-rogue-appe...


> Appellate courts do not lightly overturn jury verdicts using highly fact-specific reviews of evidence. There is a reason they call a jury a "trier of fact".

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?


[cynical comment] Do you think the court is trying to guarantee jobs for lawyers?


It's worse than that, they're trying to guarantee profits for companies. Even though this is two titans fighting it out, the only people who benefit from an ultra strict copyright regime will be the people that can afford to fight it out in court. Everyone except people that hold shares in large companies will lose out.


As a shareholder in large companies I’m not sure I even benefit. The legal departments are going to have to have a bigger budget to deal with this, and new IP is going to be costlier to develop / buy / defend.


That lawyers exist is a good thing. It means we have a human, nuanced perspective on the finer points and interpretation of the law, which in Western civilization reigns supreme over all other things.

Lawyers will never become obsolete until we no longer live in a society that obeys the rule of law.


You're going to get downvoted because you're posting this in a forum of largely programmers, many of whom believe that every problem is essentially a programming problem, and that the law could be computer code if only the spec were well-enough defined.

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.


I dislike large numbers of lawyers for the same reason I dislike large amounts of code.

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.


I strongly disagree.

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.


> That lawyers exist is a good thing.

The more common term is "necessary evil".


In an ideal world, lawyers would be advocates seeking to provide a nuanced, human perspective.

In the current world, I think it is more common to be seeking loopholes, weaknesses, and exploits instead.


I can see how a person that only knows about law what they read in the headlines could come to that conclusion, but painting lawyers with a broad brush as you have is no more of a generalization than me saying that every Facebook employee is devoid of morals and ethics.


Which lawyers in what context do you see providing that nuanced human perspective?

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.


> Family law? If you're advocating that human perspective for the opposing party, are you failing your duty to your client?

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.


Every single point in this post is a broad-brush generalization perpetuated by media stereotypes.


And by limited personal interactions in professional capacities.

I'd love for you to provide countering perspectives from your broader exposure.


Lawyers are essentially social hackers trying to find weaknesses in IP laws and exploiting them for massive profit. It’s essentially court warfare


> Lawyers will never become obsolete until we no longer live in a society that obeys the rule of law.

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.


It may be helpful for readers to look at the actual meat and potatoes of the decision itself. I recommend jumping in at Page 27 of the decision so that they can see how the fair use factors were evaluated in this case: http://www.cafc.uscourts.gov/sites/default/files/opinions-or...

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.


RE> Nature of the Copyrighted Work: Dealt with previously

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.


There's a lot of similar responses regarding the API copyright issue. APIs have been 'subject to copyright' for 4 years, since the 2014 decision in this case. Lets see some key details:

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.


Why have you chosen to mingle the verbatim copying of function implementations (range check) with the API definition copying? You say google "admitted it" which is a loaded term and you use that to say "This isn't a cleanroom implementation". Google conceded the direct copying of one function implementation and thought it not relevant - IIRC the jury awarded Oracle $1 for that. The rest of the function implementation ARE clean room implementation, and the API definitions are claimed by most of the industry to not be copyrightable.

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.


I didn't choose to mingle those things. That's just plain what the facts are. I get that you don't like them, but that's tough beans.

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.


>> I didn't choose to mingle those things. That's just plain what the facts are. I get that you don't like them, but that's tough beans.

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?


You've been pointed towards resources that answer all of the issues you've raised, but you haven't read them. Suffice it to say, the decisions do not agree that Google's behavior here is not relevant in determining how to deal with the copyright issue.

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 get that you don't like them, but that's tough beans."

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.


Yep. There is a ton of layperson misinformation in this thread motivated by how people 'feel' about certain issues without actually reading the decisions or understanding the tests in question. There are laypeople literally getting angry at me that the court didn't say what they think is right.

Oh well. I hope some people found it useful.


Love your work. Makes sense, thanks.


It was quite helpful, thanks for all your comments.


Hi ABCLAW,

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.


1) Judges aren't computer scientists, and LOTS of IP cases read very poorly as a result. This is a structural issue with how judges are educated within court rooms regarding the facts surrounding the disputes in question - but let's just accept it as an unfortunate cost to adjudicating the way we do.

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.


I have just read from page 17 to 33. I expected a load of bullcrap, but ended up with only one nugget, page 31:

> 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.


Google specifically decided not to use 'interoperability' as a functional objective constraining their code design because there was a wall of evidence against that interpretation. There's a comprehensive write-up elsewhere in this thread about it.


I have read it, and I disagree.

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.


>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.

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.


> The court specifically deals with this assertion and does not come to the conclusion that you do.

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?


Hi ABCLAW,

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.


You aren't using the same definition of polymorphism as maire is. In the context of software, polymorphism is the practice of having an interface, one side of which has multiple alternatives which do different things.


> 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.

One function, rangechececk.


Which Alsup publicly admonished Oracle's counsel for trying to make a big deal out of it.


> this argument is based on obviously factually incorrect premises

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).


And this jury, that made the decision about APIs being copyrightable (in the US), that made this into "a clear loser for Google" in 2014 were also a dozen randomly selected laymen with no background in law nor programming?

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.


Where is the obvious factual inaccuracy?


How does this not apply, in any way: https://en.wikipedia.org/wiki/Software_copyright#History_of_...

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?


> 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.

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.)


Many commentators on this thread are desperate to come to the opposite conclusion despite the clear case law on this question.


Because it has some pretty wide ranging effects on our industry, mostly negative (in my opinion). Though wishes and hopes don’t change court decisions, of course.


If API are copyrightable how do clean room implementations work? It seems IBM could sue the clone makers for the BIOS API if that's the case.


That was already decided back in 2014 (Oracle v Google): the jury concluded that Google did infringe Oracle's copyrights, but they deadlocked on Google's fair use defense.

And yeah, I guess that IBM could start suing everybody... this whole situation is so ridiculous.


Does that mean all the cloud providers who are copying S3's API for object storage are violating some copyright?


That is what the new law established by that case seems to suggest...


I'm sure Amazon would love that to be true and force any competitor to beg for licensing.


After all, the sole purpose of such reimplementations would be to take business away from Amazon.


what about things like aftermarket car parts? 3rd party phone cases?


Lego-peg compatible toys made by other producers?

Other forms of structured metadata use cross-party?


Yes, IBM can start suing them with some substantial chance of victory under the new law established by these cases. It's fucked.

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.


Google didn't do a clean room implementation, so it's difficult to speculate what this decision might indicate for some other case involving a clean room implementation.

(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.)


if that happened today, they might, but until three years ago, APIs were not copyrightable. Or at least not thought to be by most developers.


I think because there are no identifiers. The BIOS API is: fill registers with these values, run this interrupt. That's different from openFileWithName(String fileName).


What? No those are the same thing. Why is an API suddenly not copyrightable if its 0x51234 offset 5 bits, vs human readable text? That is nonsense. Numbers and words should not be treated differently.

What if I named my function 015342342(String 123949)? How does that change anything?


Copyright has a creativity requirement. I can easily see a court ruling that 0x51234 bit 5 is not creative whereas SetBrickMode(true) has a spark of creativity in that it could have been named multiple things.

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 number sequence to word differentiation you make is specious - you may not consider it creative but there's a creative spark in choice of a number, or choice of a location in memory that leads to choice of a number, etc., as you later intimate that creativity is technically lead.

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 key word in first bit of my post is "court". I think standing in front of a judge and explaining that your choice of 1,383,929,380 is "creative" is, well, something you're welcome to try.

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?


Judges aren't fools (but some can be persuaded to be!).

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.


The thing is, any program that calls "SetBrickMode()" HAS to use that name. Nobody has ever claimed programs require the consent of the API creator under copyright law to use the API. EVER prior to this. And then once a bunch of software is created using the API (presumably without need of the copyright holder) someone else doing an alternative implementation for that software to run on has no choice but to use the same naming convention for those programs to run.


You can choose different interrupt numbers as well.


This line of 'concern' has been running through the courts since the mid 80s. This isn't anything new. The cases themselves discuss the jurisprudence on either side, as well as the tests used to determine the magnitude of creativity and similarity as between software products.


openFileWithName is a mnemonic that a software developer uses and which a machine translates into a literal location at compile time.


You actually do a clean room implementation rather than copying chunks of your competitor's work and then pretending it's allowed under fair use?

Seems pretty straightforward.


Google did clean room implementation of almost all functions. They copied 9 lines of implementation code verbatim - out of thousands of lines. It does raise a question in my mind as to how that one function got copies, but it's also possible that it was re-implemented and happened to be done exactly the same without looking at the original - I honestly don't know but Google conceded it was a duplicate either way. 9 Lines. Not a wholesale infringement - seems pretty straightforward.


Those 9 lines got copied because the function was going to get donated to openjdk anyway, so it would be stupid to rewrite a simple 9 line function that it used as that would be pointless duplication after it was merged.

So a Google employee was donating code to Oracle, and they sued them for it. It's absolutely shameful behaviour.


>It does raise a question in my mind as to how that one function got copies, but it's also possible that it was re-implemented and happened to be done exactly the same without looking at the original

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?


Oracle's counsel was publicly admonished by Alsup for even trying to push that argument.

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—"


> So what's the furor about?

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".


> 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.

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.


That statement is at odds to APIs being copyrightable. If the API itself can't be used then how exactly is a clean room implementation of that API supposed to avoid the copyright issues of implementing the API?


I'm trying to understand here - is the idea that if they had put a bunch of developers who had never seen the API that they were implementing (normal clean rooms allow documentation, but api documentation is pretty much the signatures and that pretty much is the material we're talking about being copyrighted), provided the clean room engineers only with example code that used the apis and that they had to make work then they would most likely not have a problem, even if the resulting code had blocks that were character-for-character identical (since interfaces likely would come out identical to those they needed to be interoperable with)?

Obviously that sounds pretty crazy, but if it's true, it would at least be an approach that I could understand.


>normal clean rooms allow documentation

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.


Yes, and the normal way you do this is by having some people (who can be tainted) write a bunch of documentation. Then the documentation gets passed to the people working in the 'clean room' who then implement based on that documentation.

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.


Not a lawyer, and I agree with your overall point, but I think usage examples are as tainted as the raw API.If the API is copyrighted with no fair use exemption for interop, why would that protection not extend to the API usage which contain the same information? "void IFoo.bar()" and "myFoo.bar() // returns void" are pretty similar and equally as "infringing" IMO.

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.


Cool. So if I just make a Mickey Mouse cartoon from scratch I should be good.


Or a film about Snow White, Pinocchio, Rapunzel, Sleeping Beauty etc.


Sure. If you managed to actually do that. Of course courts are free to infer as to the unlikelihood of that.


Disney's whole strategy was taking public domain works like those and making cartoon versions.

There's nothing legally stopping you from doing the same; Disney does not own these stories.


> 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.

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.


Strictly speaking, Java isn't used in Android. There is no JVM in Android, and there never was. It doesn't run Java bytecode. Java ends where dex translates Java bytecode. In recent version of Android, there's another layer where Dalvik bytecode is compiled to the target architecture.

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.


It also erodes Google’s claims of fair use. Leveraging the Java language and APIs benefited Google much more than it benefited the Java ecosystem at large. Almost anything that targets Java can now be used on Android, but the reverse is not true. The sharing largely flows one way.

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.


> The sharing largely flows one way.

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.


"Benefitting the ecosystem" doesn't bear on fair use at all, but if it did, one could point to Android driving a revival of Java generally, and dragging client-end Java coding out of a coma and into prominence.

The same could have been said of Visual J++ but Sun killed that opportunity before it could really flourish.


IMHO, if API's are copywritable, consider the equivalents :

-) Are Networking protocols copywritable ?

-) Are REST APIs copywritable ?

I am not sure if this is the way open source world should work.


What exactly was 'copied' by Google? Was it actual code directly copied or just the general design / APIs that were mirrored by their Android Java playform?


The court has made the point now that literally just the class and method names are subject to copyright.


Devil’s advocate here... the method signatures, the layout of the classes, what inherits from what, what bits are private vs public, are all pretty non-trivial. Moreover it’s where a lot of the subjective decision making happens, whereas the actual implementations are straightforward once you know what the method signatures should be.

I don’t necessarily agree with the decision but I can see where they’re coming from.


Triviality isn't the determining factor of what's copyrightable.

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.


In Sony v. Bleem they used blackbox testing and created their own original code from that. If Google had done the sam they would have been fine.


Because of Java's reflection, a black box approach would have given you the same API names that are being discussed here.


Not necessarily. You don't have to "look" at the reflection.


You do to be API compliant.


Bleem did not copy. An emulator is not necessarily a copy.


I think it's important to remember what copyright is meant to protect -- expressions of ideas. You can't copyright the structure of an engine in a car. You can't copyright medicine.

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 can't copyright the structure of an engine in a car. //

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.


What's reallly non trivial is getting developers to uptake a new APi they are unfamiliar with.


Isn't Java open source? (Does this not include the APIs that are part of it?)


When it comes to Oracle, it doesn't matter. There's a reason MySQL was forked into MariaDB basically the second Oracle bought it.


Open-source does not mean there are no restrictions. AFAIK, Java's open-source license did include some provisions that Google violated.

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.


OpenJDK is presently under GPL 2, with the "classpath exception" at the end: http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/LICEN...

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.


I thought Google used the implementations!


I thought one of the main issues was that there was only one natural implementation of many API functions. Like when you assign students a coding question, you will see many answers come back identical even though no one cheated.


Even then, there were only a couple trivial places that saw literal copying. The code that checks for array out of bounds was the main one.


They mostly used Apache Harmony's implementations.


The Java API definition.


[flagged]


If they stole Java then you have stolen all the words in your comment.


From the ruling:

> 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.


Did Google infringe on the libraries or the actual API?

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.


> if Oracle hadn't also accused Oracle initially of patent infringement.

Was this a mistake or did Oracle actually accuse themselves of infringing their own patents?


That sounds like something Oracle might actually do.


The case had some patent infringement accusations, some patents were thrown before the lawsuit started and others were considered not infringed


> Dealt with previously - APIs are copyrightable

IANAL, but doesn't this contradict case law elsewhere?


No


>> Dealt with previously - APIs are copyrightable.

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.


But Oracle vs. Google is the citation. Google previously won based on Fair Use. By definition, that court considered APIs to be copyrightable. If they weren't, the case would have been adjudicated on those grounds instead of the provisions of copyright law that govern fair use.


The district court found APIs to not be copyrightable. The Federal Circuit disagreed, and ordered the district court to hold a trial under the assumption that APIs are copyrightable—that's when Google's fair use defense became necessary.

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.


> That Federal Circuit decision has not been reviewed by the Supreme Court, does not establish binding precedent outside the context of this case,

The Supreme Court need not weigh in in order to make the law what it is.


Sure. Honest question: is it law now? As of March 2018? What need to happen for API copyright to become law, if the answer to that is “not yet”?


The CAFC can't set precedent on this matter.


The law is what it is by definition, but when what the law is is in dispute, the Supreme Court is what resolves it.


That creates a circular argument.


Bzzt. They're cited. By me. In this thread.

The 2018 decision is not the same as the 2014 decision or the 2012 decision.


Bing Bing Bing Bing. Everyone, read this last sentence. It is correct.


So then theoretically, Intel could sue AMD for supporting their x86 ISA?

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.


AMD has a long-standing cross licensing agreement with Intel regarding x86


Isn't that for patent infringement? EDIT: nope it explicitly covers the ISA, too


Don’t they cross license because AMD does need permission to reproduce an ISA?


isn't that just for patent infringement? EDIT: nope it explicitly covers the ISA, too


I think the part that gets lost in all of this is that Sun offered to license Java to Google previously for $100M. [1] Google turned that down and bypassed Sun because they didn't want to pay (or license). At the time, Sun was happy to see Java being used by Google, even without the license. Still, Google knew exactly what they were doing. [2] My point is, they did this to themselves and they knew what they were possibly getting into.

[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.


But the thing is Google didn't use the Oracle Java engine. They implemented their own runtime environment that's mostly API compatible with Java (and getting further from that as the years go on).

This gets into really critical concerns around APIs. If commercial product A sucks and I'm in a shop where we made our own drop in replacement that implement's A's APIs .. then we open source that drop-in replacement and put it on Github so anyone can use it, are we no violating their copyright just by implementing their API?

This can set dangerous prescient when it comes to interoperability and reverse engineering.


And yet Oracle ships an S3 compatibility API: https://docs.us-phoenix-1.oraclecloud.com/Content/Object/Tas...


Hell, Oracle got started by cloning the SQL API.


Which they payed for, unlike Google has done with Java.

SQL standard and the respective certifications have to be payed for.


The ANSI/ISO standards came out nearly a decade after Oracle's DB was released.

Before that, Oracle ripped off Chamberlin and Boyce's work. Which they should be able to do, because APIs shouldn't be copyright-able.


And how do you think standards get written, out of thin air?

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.


Most of the folklore seems to point to the ANSI/ISO work being done by IBM.


Does anyone actually use the Oracle Cloud? From my attempts, it's only full of misery and broken tech.


Oracle increasingly resembles the old CA. A huge licensing portfolio company with some tech/r&d on the side where good software goes to die.


So you're saying it's an Oracle product?


It's called brand recognition.


It's growing rapidly in Enterprise IT on all all three fronts IAAS, PAAS, SAAS.


Do you know something nobody else does? Because the news seems to indicate that its growth has been slowing for a year now, which is not good news in a rapidly growing market. https://finance.yahoo.com/news/oracle-apos-cloud-growth-disa...


> reverse engineering

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.


I don't get why it's a scary issue or even controversial why an API would be subject copyright. An API, in my mind, is similar to design drawings or blueprints. Independently figuring out how to implement those drawings doesn't change the fact that you copied the design.


If you apply this view to all APIs, the computer revolution would never have happened. The PC was a clone of IBMs API. They fought this battle and lost and now we can argue about it on little handheld clones all day long.


In fact, IBM was so sure that the BIOS API could not be copyrighted they basically made their source public (in the manuals but NOT open source) so anyone reading the manuals to understand the BIOS was tainted and couldn't write a competitor. Compaq did a clean room setup to get around this.


>IBM was so sure that the BIOS API could not be copyrighted they basically made their source public

That is not how copyright works. You almost got it right with your comment "anyone reading the manuals to understand the BIOS was tainted and couldn't write a competitor."

Copyright protects against copying. It does not protect against independent development. Hence the clean room set up.


If the BIOS API was copyrightable, they would have had to do nothing and simply declare that they owned the copyright to the API and thus no clones. Since they couldn't do that, they had to go to the extra step.


Replying to your comment below. I am not missing your point. I am merely pointing out that your point is incorrect as a matter of law. Copyright does not cover re-implementation. Copyright only covers copying. Your statement that IBM could sue company using a clean-room developed re-implementation of IMB's BIOS if IBM owned a copyright to their BIOS is incorrect as a matter of law.


> Your statement that IBM could sue company using a clean-room developed re-implementation of IMB's BIOS if IBM owned a copyright to their BIOS is incorrect as a matter of law.

To the extent that it's relevant here, that appears to be untrue. This hinges on the fact that with an API, you have to match it exactly, and there's no reasonable way to argue that someone could sit down and do a clean room implementation of the Java APIs that perfectly matched all 3000 classes and all the public interfaces of all those classes.

You can do a clean room implementation of the Java Platform, but you can't do a clean room design of the Java APIs. The whole point you're trying to solve is to make something that's compatible with Java, and that requires knowing the Java APIs, i.e., it's not a clean room. If we extrapolate that back to IBM and clones, as long as the clone makers must come up with the same external API as the IBM BIOS, then this court would say that IBM absolutely could use copyright law to prohibit clones, because the clones would have to have copied the APIs -- not the code, but the names and types used in the APIs themselves, and IBM holds copyright to those names.


> Copyright does not cover re-implementation. Copyright only covers copying.

Coypright covers derivative works of copyright-protected works, as well as literal copies. If APIs are copyrightable, there is a very good case to be made that a reimplementation of an API implementation (not an API that serves a similar function, but an actual reimplementation) is a derivative work of the API itself.


An interesting argument. However, the Oracle Google case is not about derivative works. Google admitted to copying.


> However, the Oracle Google case is not about derivative works.

The Copyright Act, however, is; if APIs are protected by copyright, than making a derivative work of an API is an exclusive right of the copyright owner.

Which is a key reason why there is widespread concern about the CAFCs ruling on API copyright. (OTOH, Google losing on fair use at the CAFC makes it more likely that the API copyright issue gets to the Supreme Court in this case rather than a later one, so it might be a good thing for resolving that concern.)


Clean room reimplimentation is not considered a derivative work. Derivative works requires actually copying (and then derivatizing).


> Derivative works requires actually copying

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.


Clean-room reverse engineering produces an implementation that is not a derivative of the original implementation. But if the API itself is copyrightable as a separate work from the implementation, then you have to consider whether the API of the reverse engineered implementation is a derivative of the API of the original implementation. The answer to this question is rather obviously yes, since the reverse engineering process is all about separating the API from the implementation and copying only the former. Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable.


> Clean-room reverse engineering is only useful in a world where APIs aren't copyrightable.

I disagree. However, I am not aware of any caselaw on this point. It is an interesting logical twist you have added, but I fail to see how it must be that way in view of the fact that copyright explicitly allows clean-room type reverse engineering.


> in view of the fact that copyright explicitly allows clean-room type reverse engineering.

The legal status of reverse engineering is not at all clear-cut. There are many nuances depending on the circumstances, and much of it is determined by case law rather than statute. There's no clear basis for you to make claims about how this new class of copyright (on APIs) will interact with reverse engineering. However, it is much simpler to state that if APIs are a work subject to copyright, then it must be possible to make derivative works of APIs that are also subject to copyright absent any explicit exception or fair use right.


Well of course it is possible to make derivatives of APIs that are also subject to copyright. My point is that it is also possible to make a clean room reimplimentation that is not a derivative work, which is much more valuable. Just don't copy is the lesson here.


> My point is that it is also possible to make a clean room reimplimentation that is not a derivative work,

You have not at all established this point. What makes you think that the API of a reverse engineered implementation is not tainted by the copyright of the original API? It's clear that clean room reverse engineering produces an independent implementation, but it also seems clear that such a technique does not prevent the structure, sequence and organization of the original API from strongly influencing the structure, sequence and organization of the reimplementation's API.


That is simply incorrect. Copyright covers copying. It does not cover independent re-implementation. That is the point of clean-room re-implementation. It is not copying because--> clean room.

Silly Example: you design a phone book containing all the names and phone numbers of everyone in the city. To the extent that any subjective decisions were made in the design, it is a copyrighted work. I design a phone book. If I copy yours, it is a violation of your copyright. If I collate the underlying information and then make my own phone book it is not copying, even if it looks exactly the same.


No, you are not getting the point of the whole "copyright the API" thing this discussion is talking about. If I can copyright the API then it doesn't matter if you clean room or not since the API is copyright and I can sue the heck out of you no matter how you did your work. That is my point that you are missing. IBM didn't believe they could copyright the API so they took some additional measures. If they thought the API was copyrightable then Compaq would have gotten sued out of existence. This is what makes Oracle's assertion so scary for the computer industry.


Actually, you're not getting it. Copyright means I can't copy your work. If I arrive independently at the same thing, then I didn't copy your work and therefore didn't violate your copyright.

If I take your picture of a building and copy that's a copyright violation.

If I take a picture of a building from the exact same angle you did, that's not a copyright violation.


That's true, but if you type and distribute a book that happens to match the latest Harry Potter, nobody - including the courts - will believe you independently came up with that exact sequence of words.

Similarly, if you copy the definitions of all functions/methods/classes/etc from one API, nobody will believe you independently came up with it.


Even if the methods and functions are so basic as to not have variations?


It's hard to tell about APIs, since there's no caselaw, but the rule for texts is that the smaller they are, the more original they have to be to qualify for copyright protection - so conversely, the sheer length of a work makes it more likely to be protected even if it's not that original.

So "add(a, b) returning the sum of the two" is probably not copyrightable by itself, but a whole namespace full of functions might be.


No. But the court explicitly looked at that and said that there was enough creativity in the choice of what names to give methods and how to group methods that the Java API qualifies as a creative work (and I don't think anyone would really dispute that).


> If I arrive independently at the same thing, then I didn't copy your work and therefore didn't violate your copyright.

That's not how it works for copyright. Beyond that, how do you independently arrive at an API that you are trying to have an exact copy of? Photography is not programming. I cannot run a bunch of words through a program until it prints out some book I want and then say I arrived at it independently. You honestly need to read the copyright laws as you are missing some information.

[edit: the original premise of all this thread is IBM didn't try to copyright the BIOS API]


I suppose you could argue that black box reproduction is simply an elaborate form of copying. That's not relevant to this case because Google did simply just copy it.


Then why did you bring it up? My original post was about a situation where the creator of an API didn't believe it to be copyrightable and then made an attempt at protecting it a different way. Oracle believes they can copyright an API and almost everything in the industry was built with the belief that you cannot copyright an API.


>My original post was about a situation where the creator of an API didn't believe it to be copyrightable

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”."


You don't seem to understand what an API is.

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!


Your original post was about IBM not being able to copyright the PC Bios. Which is simply not true in any way shape or form.

No, no, no, that is not what I said. I was talking about the API of the BIOS. The BIOS source code is, of course, copyrightable. That is why IBM was able to make it very hard for people to copy it until folks did a proper clean room. Why would I go into detail about the counter measure if it was not copyrightable? That makes no sense.


Interesting edit to your original post. So their countermeasure was to try to taint everyone in the whole universe so a clean room reimplimentation would not be possible? Wow. Interesting interpretation.


That is not an interpretation, that was an actual strategy. They put enough information and source code into the documents that described its function to taint anyone who read the documentation. There are multiple sources (and I do believe some TV) on IBM's strategy. Compaq's Garry Stimac realized the problem when he read the manuals. A clean room strategy was setup.


You said: >My original post was about a situation where the creator of an API didn't believe it to be copyrightable and then made an attempt at protecting it a different way.

What "different way" are we talking about here? IBM asserted their copyright quite forcefully against Eagle and shut them down.


You really need to read ScottBurson's commen https://news.ycombinator.com/item?id=16693994 because you don't seem to understand the difference between an API and source code.

Eagle directly copied the source code of the BIOS, they were not sued for copying the API.


There's a fundamental difference between:

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.


...I don't really see what the difference is. In both cases Google would end up with exactly the same API specification. There's no room for them to come up with an "original" API, because if the API they end up with is not an _exact copy_ of Oracle's, then software written for Oracle's Java implementation would not be compatible with Google's Java implementation (and vice-versa).


So? The proper response would have been for Google to either pay the license or develop their own write once use anywhere software. Instead, the took the shortcut of copying someone's hard work.


By that logic WINE shouldn't be allowed to exist either, since it copies Windows' API.

Copying APIs is strictly necessary for interoperability. Allowing APIs to be copyrightable encourages monopolies by legally prohibiting newcomers' software from being compatible with their competition.

It'd be like if Microsoft were allowed to sue Google Docs and Libreoffice for making their software able to open Word documents. (Except in this case the "documents" are source code.)


I'm not sure how WINE works. But I just don't see that being the case. All WINE has to do is capture the API calls and transform them into a different WINE API call that ends up performing the same function and then proceed with zero copyright issues.


> All WINE has to do is capture the API calls and transform them into a different WINE API call that ends up performing the same function

How can it "capture" the calls without knowing what it's capturing? It has to know that there's a windows API function called "CreateWindowEx" that takes particular parameters, otherwise how could it possibly "translate" it? And the fact that CreateWindowEx takes particular parameters is precisely the API.

Of course the implementation of that API will be different in WINE, just as Google's implementations of the Java API are different from Sun's (aside from the 9-line rangeCheck which is a separate issue). In fact it would be fair to describe what Android does as "capture the API calls and transform them into a different Dalvik API call that ends up performing the same function".


> All WINE has to do is capture the [Windows] API calls

So... you're saying it needs to implement the Windows API? If APIs are copyrightable, then that's a violation of Microsoft's copyright. You've included a copy of Windows' API in WINE.


Interoperability trumps copyright IMHO.


Unfortunately courts don't pay attention to your opinion. They only pay attention to grumpy old codgers who don't really understand technology or innovation. They only understand precendents or long ago useless decisions of previous courts and the pragmatism of someone raised on thoughts on computers and ideas of fairness from the 1950s.


It is effectively impossible to take something as complex as the Java API, do black box testing, and come up with an exact copy. Google's API being slightly different is ultimately the point. The process yields a new original work even if it ends up being 99% the same as Oracle's API.


The 1% that's different being... what? Bugs? Like I said, any differences in Google's version of the API would, by definition, be interoperability problems that need to be corrected.

To make that more concrete: if Oracle's string concatenation function is called `String.concat` and Google's is called `String.append`, then code which calls `String.concat` isn't going to work with Google's implementation, and code which calls `String.append` isn't going to work with Oracle's implementation. It doesn't matter if the APIs are "similar" or not, they have to be _identical_ in order for code written for one system to be interoperable with the other.


The 1% will be things like String.methodNoOneUses or ObscureClass. Even if they aren't identical they will be close enough for 99.999% of the programs people write.


So bugs nobody files then? Why do you think this is a useful distinction. Either APIs aren't copyrightable or we should pass a law that says they aren't immediately.


[flagged]


APIs are copyrightable under a CAFC decision notionally applying 9th Circuit law in this case which the Supreme Court declined to review because, pending the resolution of other issues, they viewed it as not ripe for review. Since this is not within the CAFCs special subject-matter domain (patents or any of the other areas which bring a case within it's jurisdiction; this case is at CAFC because to once had patent claims even though they are no longer live), this ruling doesn't seem to be binding precedent on any lower court. So, it's “law” in only a very weak and tenuous sense.


Well, I would love to hear about a circuit court case that says otherwise. Seriously, I have no idea, but I do not believe such exists.


Basically it's not the law yet and may never be the law.


Uhh. No. At least under any interpretation I know about what the law "is."


It's neither express in the statute nor is it in case law binding on any court, because while CAFC decisions are nationally binding, that is only on the subject matter uniquely assigned to the CAFC, but that doesn't include copyright. Those are claims the CAFC decided under 9th Circuit case law in a case that is in its jurisdiction because it once had patent claims, even though those claims aren't active. Had the actual 9th Circuit ruled this way, it would be 9th Circuit case law, but the CAFC applying (notionally) 9th Circuit case law doesn't create new 9th Circuit case law. It doesn't even create precedent binding on future CAFC panels, even if those panels are themselves applying 9th Circuit case law. It is at most persuasive authority, rather than binding authority, in any future case, so it is only “law” in the sense that, e.g., scholarly treatises on the law are “law”.

So, barring this case being both heard and affirmed by the Supreme Court, this interpretation of copyright law, while potentially decisive in the outcome of the present case, isn't, substantially, law, so much as an idea of what the law might be.


Bugs are a red-herring to the discussion. Bugs doesn't get you out of copying. The question is: did you copy or not? Google argued "we certainly did copy but APIs can't be copyrighted." Which was not the law at the time they did the copying and is not the law now .


Except it is the law now and then that APIs aren't copyrightable according to the court that's generally supposed to handle such things, in this instance The US Court of Appeals for the Ninth Circuit. They've ruled plenty of times on the matter, and have developed decades of case law stating that implementing APIs is totally kosher. Sony v. Bleem is great example. There the appeals court ruled that not only could Bleem ship a PS1 emulator with reverse engineered APIs of the kernel (explicitly as a commercial venture even!), but they could port it to a competitor's game console (the Dreamcast), and use Sony's IP in screenshots.

But, because Oracle v. Google case had an ancillary patent question in an earlier appeal, the appeals are instead going to the Court of Appeals for the Federal Circuit. This court is really only supposed to answer patent questions. The CAFC can't set precedent in these matters, and overwhelmingly defers to the district courts' precedent. Bot for some reason they have chose to ignore all of that this time and make their own, fresh (and super weak) precedent that only applies to copyright cases with patent questions.


I bet if one looks hard enough he would find links between these judges and moneyed interests tracing back to Oracle.


Eh, I wouldn't go that far. CAFC judges just tend to be appointed (at least a little) for how much of a hard on they have intellectual property rights in general. The whole circuit was setup pretty much only to do patent appeals for the most part. The judges probably just think of themselves as 'principled'. And they are technically allowed to do this, despite it being kind of a dick move.


>APIs aren't copyrightable according to the court that's generally supposed to handle such things, in this instance The US Court of Appeals for the Ninth Circuit

That is just not true. According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.


> According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.

The Federal Circuit has the right to hear and decide this particular case, but they do not have the right to establish binding precedent on lower courts or other appeals courts in matters of copyright law. This has been explained to you repeatedly.


>not only could Bleem ship a PS1 emulator with reverse engineered APIs of the kernel

Not all types of reverse engineering is considered copying. See IBM PC BIOS cases.


There weren't "IBM PC cases". All of that work was based on Apple v. Franklin, a 9th circuit case that held that APIs aren't protected by copyright.


How do you propose they do this black box testing?


Write code, run it through the compiler and create specifications based on what you observe.


And once again, you'd end up in exactly this legal situation since the names are visible via reflection, but somehow aren't functional as viewed by the court.

That's one of the most important issues with this ruling; it effectively bans even black box reimplementations.


It is not copyrights problem that obeying the law might be difficult.


People who reversed engineered the IBM BIOS had the API specification -- actually they had the entire source code. They didn't just fire random interrupts at the BIOS and see what it did. But what they did do was take that specification and describe it the detail necessary for completely fresh implementation.


Not true at all. It was a clean-room reverse engineering job. Yes, they could have looked at the API, but they did not. More specifically, they erected an information wall between those who had the API specification and those who did not, and used the results from those who did not.


One team looked at the API and source code and everything and used that to develop the specification for the "clean" team to implement. That's the point. Collectively they didn't start with nothing.


To me it's more like copyrighting the standard height of a door.


It's more analogous to -- very analogous to -- the "clean room" BIOS clones that enabled the PC Clone industry to take off (and made IBM-compatible PCs actually affordable; before the clones took off, IBM's prices made Apple seem like a bargain).


Atari and Amiga prices were quite competitive, offering much more than those early expensive PCs.


Except Google did not do a clean room clone. They simply copied, thus violating the whole point of copyright. If they had developed their own API that simply used different names but was functionally identical, they would not have violated copyright. Copyright protects against copying. They didn't do that because they wanted to take advantage of the huge existing JAVA developer base who would easily be able to use the copied APIs to develop for Android. I.e., Google chose to copy and thus are liable for that choice.


AS has been covered elsewhere, an API is a functional description and not copyrightable, irrespective of what a specific court says. This specific court has had its rulings slapped about so much by the next higher court, it is a wonder that they haven't just packed up and gone home.

That is why telephone books and others things are not copyrightable. They are lists of facts. API's are lists of facts, a functional specification for use.

There are consequences if this stands and it will not be to our benefit as programmers, developers, designers, etc. Nor will it be to the benefit of society as a whole.


Telephone books are copyrightable. This is black letter law. As said by the Supreme Court in Feist, "Notwithstanding a valid copyright, a subsequent compiler remains free to use the facts contained in another's publication to aid in preparing a competing work, so long as the competing work does not feature the same selection and arrangement,"

In other words, if it does feature the same selection and arrangement, it is a violation of copyright.

Your statement that APIs are not copyrightable is not true as well.


Where can I go copyright my phone number? I want to make those marketers pay a royalty for even storing my number.


An api with different names isn’t functionally identical, at least not without some sort of very weird indirection.


It depends on your meaning of functionally identical. In the hypothetical non-copied Android ecosystem, it could be functionally identical. In terms of interoperating with Java, no. But I fail to see the relevance of the latter point with respect to copyright. Copyright says: don't copy. If that unfortunately makes it difficult to leverage the existing Java developer base for your multi-corps next megaproject, too bad. Develop your own ecosystem.


The Java API is hundreds of classes and thousands of methods. It is far beyond something as simple as the height of a door.


I don't see how the size of the spec has anything to do with it. It could be the standard height of doors or the standard interface/protocol between every sensor and smart component in a smart home.

What if I create my own smart home server that can be a drop in replacement for some commercial product using just what I've gather from their public API? Is that infringement, when the underlying implementation is entirely my own?


You can't copyright trivial work so the size of the spec matters.

It depends on how you create your server. If you go to their website, look at their API, and start typing identical code then that's not ok. It's pretty clearly copying. If you do black box testing and then write your own API that's fine. It's clearly not copying but a new original work.


And what criteria should be used to tell when an API is complex enough to be copyright-able?


Generally, anything can be copyrighted as long as it's sufficiently original. The phrase “I have abandoned my search for truth and am now looking for a good fantasy”, for example, is under copyright by Ashleigh Brilliant, who own a case against a t-shirt manufacturer using it.


It's scary because let's say you are competing with someone, so you decide to copy their API to make it easy for people to migrate over to your system rather than use their system. Now, instead of just doing that, you have to get a license to use the API. Otherwise, you are a copyright infringer.

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.


How is an API different than any other product specification? Why can't e.g. Panasonic sue other manufacturers for making an 18650 form factor battery cell? Why can't Ford license the form factor that every car uses for a gas nozzle? There's fundamentally not a way to create your own compatible implementation without using the same API.


Panasonic and Ford own copyrights on their CAD drawings for those items. So I can't just CTRL C and CTRL V and send them off to a manufacturer to get my own stuff made. I can, however, measure those things and create my own drawings without violating copyright because I am not reproducing the work.


So google could've looked at all existing Java source code, and infer the api? But the resulting output is indistinguishable from just copying.


Reflection means that you can, through automation, observe the complete set of public classes, methods, and fields in the java api without ever looking at docs. You can put together a script to do this in 15 minutes.


Design drawings is an implementation, not an API. Copying a drawing is like copy-pasting code from someone else. Something akin to API in art would be style. If you allow style to be copyrightable, it would mean any apps following the Material Design style, for example, would infringe Google's copyright.


The API is less like the blueprints and more like the building code. This is perhaps a bad example as many building codes are copyrighted, but a lot of people find this as absurd as copywriting an API.


Building codes being copyrighted is fine. But if I want to make my own building code, but have all existing builders be able to easily transition, then I must necessirily be making a copy.


Can you copyright the architecture of a building? Like can you copyright the opera house so that no one else can build something similar or a copy?


Yes, but you can't copyright the technical structure - so the acoustically designed internal structure can be copied unless it's protected by IPR other than copyright (patent, industrial design rights, whatever). The external appearance, AIUI, is chosen primarily on artistic merit and so would be under copyright. Facets that are technical, how panels are adhered, how drainage works, they could be copied.

Using this as an analogy for the API would mean anything that was part of the technical implementation could be copied but inconsequential or artistic parts couldn't. This has been interpreted to mean that the actual code is "creative", so you'd have the framework of the code but not the non-essential parts that could be different and still allow the API to work.


> The issue is can a public API be copyrighted. That is the scary issue.

In Roman Law there is the principle "In dubio pro reo" (https://en.wikipedia.org/wiki/In_dubio_pro_reo), which means that if there are doubts whether the culprit is guilty or not, he/she may not be convicted.


I feel like this probably is intended to apply in criminal cases and not civil. (And a copyright case like this would certainly be civil, and not criminal)

In the US, it at least seems that something similar does, in so far as we require a unanimous vote by the jury to convict someone in a criminal trial, but a simple majority for a civil.



> They implemented their own runtime environment that's mostly API compatible with Java (and getting further from that as the years go on).

That's not quite right - Google adopted Apache Harmony[1] (an open source project, and if you want to attribute an organisation responsible for Harmony's success - such as it was - it would be IBM). Apache Harmony would have been 100% API compatible with Java had Sun (and later Oracle) not refused to provide the Technology Compatibility Kit (TCK).

The Android runtimes (Dalvik, then ART) never had compatibility with Java bytecode, instead, Android build-tools use(d) Java bytecode as an intermediate pipeline step; the ultimate executable had 0% compatibility with the Java runtime.


I don't think that's quite right, either (though I could be wrong). IIRC, Android first was done based on Sun/Oracle Java. Then (and maybe even after the lawsuit started?), Google shifted to Harmony.


Are you perhaps referring to Android's very recent switch to GPL-licensed OpenJDK[1] from Harmony after the lawsuit? There was no GPL licensed (and certified) version of Java when the Android project kicked off - OpenJDK came into existance later. Also - Apache Harmony predated OpenJDK by a few years.

1. https://arstechnica.com/tech-policy/2016/01/android-n-switch...


Yes, that's what I meant.


GNU/Linux is a partial (but incomplete, since no Linux distro is unix(tm) certified) a reimplementation of proprietary Unix, and with billion-dollar companies like Red Hat and IBM it's certainly a commercial endeavor at proprietary Unix's expense. It would seem to be an attractive target if a plaintiff like SCO could somehow move the case to the federal circuit (as none of the standard appeals courts have declared APIs copyrightable).


Reimplementation does not necessarily violate copyright. Copying does violate copyright (absent fair use). Like verbatim copying. Example, Google didn't have to use the “java.lang.Math.max(a,b)” header, but they did. They did copy because they wanted to leverage the existing Java developer base who would easily be able to develop for Android, without having to do the hard work of building their own ecosystem. Overall, Google copied the header structure for more than six-thousand methods.


That is exactly what reimplementation means in this context, creating a new implementation of an existing interface. And that is exactly what GNU Linux did. They copied a large number of system header files and created new libraries that implemented them. The copied a large number of command-line interfaces, and created executables that implement them. They extended them in the process, but the goal was to mostly preserve API compatibility.


How many ways are there to define max? Surely AT&T should turn around and sue Oracle for lifting max(a, b) from stdlib. Or maybe SCO will rise from the grave and try it again.


An infinite number of ways. Call it max(b,a) [i.e., reverse the order of b and a inputs]. But Google didn't do any of that. They copied.


The previous remark's point was that Java copied many C functions, inventions largely of AT&T and BSD.


I see the point, but that's "whataboutism." I also have no idea who owns the copyright (if anyone does) to stdlib APIs, and whether Oracle obtained license. Do you?


> (if anyone does)

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.


You could call it max(b,a) but that would be fucking stupid.

People shouldn't have to write shit code cause judges are tech illiterate.


And just how is max(a,b) good code and max(b,a) bad code?


Because the alphabet goes a, b, c, not b, a, c. The lexical ordering is uniquely privileged both when reading and writing.


Code written for one will fail for the other, and negates the whole point of interoperability. Therefore the method signature should not be copyrightable


Beware interpreting copyright law with the assumption that interoperability is relevant. The law doesn't care.


copyright has a fair use clause, which states that one can decompile software to produce a derivative for the purposes of interoperability. This then must assume that any apis being implemented has to both fall under copyright (otherwise, this law does not apply to api), but also means that the law allows for the use of the api for the purposes of interoperability (and therefore, you cannot claim to have the sole rights to an api).


Beware interpreting interoperability as a form of fair use. I wish we could make that assumption, but I don't think it's warranted.


Copyright exists to protect artistic expression, not functionality. Functionality is protected by patents.


Exactly. I don't see what you are disagreeing with. The point is that in order to leverage Java's developer base as quickly as possible they made it possible for Java developers to essentially develop for Android without needing to learn a new syntax for all the APIs they already knew. That is why they copied.


Afaik there are several certified GNU/Linux derivatives.


I'm not seeing any [0]. Care to name one?

[0]: https://www.opengroup.org/openbrand/register/



Both EulerOS and Inspur K-UX are Linux.


Seems like it’s really just an excercise in lawfare. The underlying legal “principle” is flexible.


Is this akin to React vs. Preact? Same API, entirely different codebase. Allows me to drop in a replacement if Facebook does a stupid.


It does sound similar


Key line from the article:

"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.


Considering the pain that has been caused by Google deciding they needed to reinvent Java, and do so in a way that isn't really compatible with the new releases, I would say I'm ok with this.


So you're OK with causing massive problems to anyone trying to provide alternatives to proprietary APIs just to stick it to Google?


Judges don't decide what's fair or ethical, they determine how disputed action intercedes with law.


I'm not commenting on the judge's decision, I'm commenting on s73v3r_'s position.


Most third party commercial Java vendors, selling JDKs for embedded development also have their own VMs and AOT compilers, with variations better suited for their hardware.

Aicas, PTG, IBM, MicroEJ, ....

Big difference with Google?

They play by the rules.


The rules as Oracle (and this ruling) sees them. Google and others disagree with Oracle about what the rules are or should be.


Interestingly, Microsoft briefed in support of Google this round in contrast with the copyrightability round.


> 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.


All telecommunication companies, Nokia, Motorola, Alcatel-Lucent, .... have their network elements APIs copyrighted and pattented.

Try to sell a device that comunicates with a e.g. BTS station without buying their licenses, to see how it ends.


In my experience the big hurdle is getting your device certified, not licensing issues. That's not really an IP issue however, it's just that uncertified devices might misbehave and create issues for other users.


Mobile Telecoms standards are written by 3GPP, all BTSs and handsets (and for that matter, interfaces like 'A') are standard, and controlled by 3GPP. I believe they are open.


Not they belong to the companies and some of them are available under FRAND licensing.

For the rest there is the 3GPP patent platform.


I'd say it's patent law, not copyright law, that make the licences possible to enforce.

Most of the patents are the result of a lot of research and cleverness. Some of the patents are the equivalent of looking in another drawer if the first one did not contain what you are looking in.

It's a bit arbitrary that an API isn't protected when some bullshit patents are. There is clearly much thought in some of the java APIs.

I'd like to see shorter protection time for patents thought, especially in areas where there are very low investment costs, like software development.


>are we no violating their copyright just by implementing their API?

OpenJDK is GPL. If you comply with GPL, no. This is the problem, Google copied and did not comply with the GPL. Their other option was to pay Oracle/Sun a licensing fee for a commercial license. This is exactly the business model many GPL users follow. Ruling otherwise makes this business model invalid, but it also creates a double standard.

Consider a programming language where you program in types, like Idris. The case is more obvious here. The API is a program. The same applies to Java too, but that seems less obvious. The API is the program that produces compiler output.


Huh .. so why doesn't Google just release their Android Java runtime under the GPL? Seems like an easy win all the way around?

I thought the OpenJDK people needed certain concessions to release their VM under the GPL?


Supposedly, they are switching to OpenJDK. But that doesn't erase their past infringement.


This is exactly the business model many GPL users follow.

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?


When Google did that, Google was relying on controlling precedents in the 9th circuit saying that APIs are functional elements needed for interoperability and therefore are not copyrightable. The first judge that they saw agreed with them and it should have been an open and shut case.

It was Google's misfortune that through a quirk of the system the case wound up in the Federal Circuit, which has a history of creatively ignoring precedent to fashion new precedent that increases its own importance. (Which is how we have patents on all sorts of crap that the Supreme Court has ruled that we shouldn't.) And it was good lawyering on Oracle's part to throw every possible argument at the case, including the copyright arguments that they knew they should have lost.


Google believed they could implement their own VM and get something cheaper (and/or better) than they would get by licensing one from Sun. That seems like a perfectly legitimate business decision for them to make. A clean-room reimplementation of an existing API had long been thought to be legally clear, going all the way back to Compaq reimplementing the IBM BIOS and starting the "IBM-compatible" competitive ecosystem that our whole industry is built on.


> better

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.


Except that wasn't the only approach available.

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.


The whole subthread focusing on the Android VM is completely irrelevant. The entire argument at this point has to do with the inclusion of the Java APIs. Not even Oracle or the appeals court are harping on Google's custom VM.


The VM is used as an excuse by Google supporters why they should get excused to help drive Sun into the floor.

Java still exists today thanks Oracle, not Google.


Android does not have a Java VM, and it does not run Java bytecode. Dalvik bytecode is more compact, and more CPU efficient, and the more recent ART runtime is even more efficient and performant. But it isn't a JVM.


Just like all the vendors selling commercial JDKs for the embedded market.

They also offer customized versions fine tuned for their deployment scenarios, doing Java bytecode to either native (AOT) or their own proprietary bytecode format when generating the firmware image.

Or for example, IBM Java running on IBM i mainframe, where Java bytecodes used to be translated into the TIMI bytecodes, just like any other IBM i application.


The Dalvik and ART runtimes differ in that the do not run Java bytecodes. Every commercial embedded jvm, open source jvm, and me jvm I have seen all run Java bytecodes and you can use any toolchain that makes .jar files with these vms. Unless the translation you mention can happen at runtime, it isn't a jvm.


It happens at deployment time, as mentioned.

Firmware does not change during runtime.


In 2008, none were as good as Dalvik for the use case.


That's the story Google likes to sell.

Nokia and Sony-Ericsson flagship phones were quite good.


No they weren't, I developed for them.


Me too, alumni from that little company located in Espoo.


I hope that little company does not come under pressure to make Android phones.


It is hard to compete against a free beer OS originally developed with tech unlawfully taken from other companies.

So one either swims or joins the graveyard of companies that tried to fight it.


> It is hard to compete against a free beer OS

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.


I was third party. Maybe your close association is blinding you.


Google did not do a clean-room reimplementation. They copied. This is not disputed by Google.


They copied literally a handful of lines of code that an intern could have written in a few hours.


But they didn't just write their own APIs. They copied them. Thousands of them.


Copying an API is what software developers call "implementing an API"

When you create your own USB cable, or electric plug, you aren't copying the API specs, you're implementing them.


Once they admit to copying some of it, it throws the whole clean room process into doubt. I think the courts are working on the "where there's smoke there's fire" principle.


IYO did they copy an artistic work?


Copyright covers subjective work, not just "artistic" work. In the same sense that the choice of how to paginate a phone book and where to put the guidewords on each page is copywritable, yes APIs are copyrightable.


Google knew what they were doing and IMO they were right. I still don't think Google or anybody should have to ask for Oracle's permission for reimplementing a JVM (as long as it's done cleanly). You seem to put the blame on Google for not wanting to pay $100M at the time but what if instead it was a small startup who simply couldn't afford that cost?

I'm not worried about Google in the least, I am however concerned about the precedent this sets.


> what if instead it was a small startup who simply couldn't afford that cost?

Licensing costs can scale according to the customers business size and revenue. What is more concerning is that this may create precedent that API specs are copyrightable -- to the degree they are worth billions in damages.


Licensing costs are arbitrary. If you want to license some IP from me I can ask for a billion dollar for it. Or I can simply refuse to sell it. The point is that IMO Google or anybody else shouldn't have to ask for permission for cleanly reimplementing an API.

I think some people in this thread are minimizing the issue because they don't like Google but I think it's naive and short-sighted. It's not about Google or Oracle, it's about copyrighting APIs.


> I'm not worried about Google in the least, I am however concerned about the precedent this sets

It's legal precedential value is limited, because it was a copyright decision in the Court of Appeals for the Federal Circuit (CAFC).

The general principle for a precedent is that precedent for court X is set by the appeals court that hears appeals from X, and the appeals court that hears appeals from that appeals court, and so on.

So, for example, the district courts in the 9th Circuit (which covers the west coast tech companies) gets precedent from the Court of Appeals for the 9th Circuit, and from the Supreme Court. In particular, this is the appeals path for copyright cases.

The appeals path changes for a few special subjects. Patent appeals from all of the Federal district courts, for example, go to CAFC. So, in matters of patents, a district court in the 9th district would look to CAFC for patent precedent, not the 9th circuit appeals court.

Oracle sued Google for both copyright infringement and patent infringement. The parties were OK enough with the outcome of the patent part of the case that no one appealed that, but the copyright decision was appealed.

You might expect that this means the appeal would go to the appeals court for the 9th Circuit, because only copyright issues were being appealed, but that's not how it works. Where the appeal goes is decided by what was at issue in the original case, not by what was at issue in the appeal.

The rule is that if a case has both a special subject, such as patents, that points to CAFC, and other subjects, such as copyright, that point to the appeals court for the circuit the district court is in, the appeal goes to CAFC. CAFC handles the whole thing.

When CAFC gets a subject that normally does not come to them, but got there because it was attached to a case that also had a subject that does go to them, the rule is that they are supposed to follow the precedent of the appeals court for the circuit the district court is in. They don't set precedent in that district.

For example, if two companies sued over copyright in the 9th Circuit, with no other issues involved that would deflect the normal appeals path away from the 9th circuit's appeals court, the district could would look to that appeals court and the Supreme Court for precedent. CAFC opinions on copyright would at most be interesting opinions it might look to for insight, just like it might look to courts of appeals for other circuits, but only it's own circuit's appeals court and the Supreme Court would be precedent it has to actually follow.

PS: I think we'd be better off if CAFC just got the patent appeals. If a case has both copyright and patent issues, send patent appeals issues to CAFC and copyright appeals issues to the circuit's appeals court. At the trial level we merge cases that would normally be in different courts into one (e.g., if a case has both state and federal issues, it goes to federal court and the federal court handles the state issues).

That makes sense at trial court level because they involve examining witnesses, examining experts, and similar. If different issues were heard in different courts, many of those witnesses would have to go to multiple courts. It could be a major hardship on them. You'd want to hold them all in the same area, at near the same time, to minimize travel. That could be hard to schedule.

Appeals courts, on the other hand, just work off the transcript from the trial. The only people needed there are the lawyers arguing the case. The lawyers for appeals are usually more specialized than trial lawyers, so there are quite possibly different lawyers handling the different issues in the appeal.

It would not be much of a hardship, if any, for different issues to go to different appeals courts, as long as a little care is taken with scheduling.

Heck, it might even be less of a hardship. Imagine you are a copyright appeals lawyer in the 9th Circuit. Normally all your appeals court 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.


Haven't all of the patent issues been settled? So what's to stop a copyright troll from adding ancillary patent claims to be able to use the CAFC for the appeals process from now on.


But, and this is the big but, they did it in such a way as not to be compatible with the Oracle one.


I'm not sure how that's relevant, if anything since the crux of the issue seems to be the "stealing" of the API the fact that there are incompatibilities should be in Google's favour? It's a bit odd to claim that somebody stole your API while at the same time complaining that they did not steal it well enough.


"I'm not sure how that's relevant"

The original license for Java said you can create your own implementation just fine, so long as it was compatible with the others (or at least the benchmark one). By not doing that, Google violated the license.

"It's a bit odd to claim that somebody stole your API while at the same time complaining that they did not steal it well enough."

Not if what you want to avoid is people Embracing your API, Extending it with new special bits, and Extinguishing your version.


That's not all it said. The license had field-of-use restrictions, meaning you couldn't use your implementation for every purpose. The Apache Foundation published an open letter to Sun on that regard.

And specifically, use of a J2SE implementation in mobile devices may have been forbidden.


> I think the part that gets lost in all of this is that Sun offered to license Java to Google previously for $100M. Google turned that down and bypassed Sun because they didn't want to pay (or license).

I'm not sure I follow - Google believed they didn't need a license, just like everyone who used Linux despite SCO offering to license Linux to them.

If Google needed a license, and Sun had not offered one, it would not make a difference; Google would still be liable for infringement. There's no abandonware or compulsory license provision in the laws for this. The question is whether Google needed a license, not whether Sun was willing to offer one and for what price.


There's no provision for compulsory licensing for copyright because it's not supposed to inhibit technical implementations. Patents do that, and it least in the UK the law includes compulsory licensing.


US copyright law doesn't do compulsory licensing for anything other than music recordings, and I believe it doesn't have compulsory patent licensing at all. I'm not sure there's a good rationale for this.


> My point is, they did this to themselves

Whether or not they knew that someone would come along and sue them doesn't matter if the lawsuit is unjust.

Even if Oracle is correct, and even if APIs can be copyrighted, Google's intent still doesn't matter. The only thing that matters is whether or not they infringed.

I consider this to be a form of victim blaming. You should argue the case on its own merits, not posit that Google was "asking for it."


It wouldn't be victim blaming to criticize a company that is breached because they didn't take compsec seriously. They weren't a small company at the time and they knew this was a hazard.

Google had a responsibility to their shareholders and customers to do the right thing regardless of how stupid they thought the law was, and their attitude here was pretty arrogant. (To avoid beating up on Google, I should point out believing they could take on anything helped them do some work that changed the world for the better.)

Since the attitudes of parties involved in a case are often considered in judging the case, I think it's entirely fair to bring them up.


> It wouldn't be victim blaming to criticize a company that is breached because they didn't take compsec seriously.

If you then turned around and argued that the hacker somehow wasn't in the wrong because of the victim's attitude, yes it would be.

Victim blaming has nothing to do with someone's responsibility to others, and everything to do with taking a conversation about whether an attack is justified, and shifting that conversation to instead suggest "well, dumb people like that deserve to be taken advantage of."

Oracle contested that Google infringed their IP. "They should have known we were gonna sue them as soon as we smelled the money" is not compelling evidence for that claim.

Much in the same way, saying "Johny should have turned off his attitude and just given us the money" is not compelling justification for a mob hit.


Call me naive, but is a company being happy with what you're doing to the tune of them even saying so (or representatives thereof) tantamount to an implicit contract? I know it's been argued in this case, but it strikes me as disingenuous at the least and fraudulent at the most to change your mind. Sure we don't mind Google bearing the brunt of this because they can, but how would we feel were a smaller company subject to this kind of bait and switch based on legalities?


It's not a contract, but there are other mechanism in the law to give effect to this intuition: https://en.wikipedia.org/wiki/Estoppel


Estoppel: This my be my new favorite word. I can imagine all kinds of scenarios for use (okay, I can imagine one) "You can try to renege on your promises, but I'll estop you, I'll estop you once & for all!"


This isn't a bait and switch based on legalities. If Oracle made representations to Google that they didn't mind them using their software, Google would be able to claim that Oracle is estopped from pursuing a claim due to the prior authorization they received.

What's being stated here is that Google's infringement improved Oracle's market position - that fact doesn't bar Oracle from pursuing their remedy against infringement. If you steal my software for making phones chirp every time you get a tweet and widely distribute it to the point that it becomes the de-facto standard in the tweet notification market, it doesn't magically mean that I don't get to come after you for stealing my tweet tech.

Here's the decision itself. Estopple is mentioned 0 times. This isn't because Google's legal team is braindead. It's because the argument that the Google's use was authorized following them walking away mid-licensing negotiation is insane. Google's defense is based on fair use. http://www.cafc.uscourts.gov/sites/default/files/opinions-or...


I am not sure you are familiar with the entire case regarding Sun's public approval of Google's Java use. Oracle argued it was the CEO's personal blog, but the CEO definitely did give a form of "green light" depending upon your interpretation. It's a defense I feel like is easy to do against a large company that "should have known better", but would be considered unfair against a smaller company that was essentially given approval. I won't address the rest of your comment that is out of context since it's missing this important fact.

Here's some old HN discussion on it: https://news.ycombinator.com/item?id=2806771


I'm familiar with the case. The comment isn't out of context; you (and other posters) need to recognize that IP rights are composite rights, like real estate.

In real estate, you can own a plot of land and provide others with permissions associated with the land; maybe they're allowed to walk over a path that runs through your land. That permission is not equivalent to all possible permissions associated with the land - although maybe some ancillary ones are implied in. Maybe people are allowed to bike over the path too, but they certainly aren't allowed to dump broken washing machines there.

Similarly, in IP I can grant you a set of rights related to my product without giving you ALL rights related to my product.


To use your own analogy it seems like we are only talking about one singular right. Making derivative work thereof. If not can you clarify your position?


They did make those representations, and Google did claim that.

https://arstechnica.com/tech-policy/2016/05/suns-jonathan-sc...


No, they didn't.

If I hand you a bag of balls and say you're allowed to play with the purple and green balls inside, I haven't given you permission to play with any of the other balls.

In this case, the different balls are the different dismemberments/rights related to Java.


Sun defended Java with the trademark and the compatibility kit, not copyright on the API. It never occurred to anyone (as it shouldn't now) that there was copyright on the API.

[edit] Jonathan Schwartz: "The strategy was, we agree on these open APIs, then we compete on implementations."


> If you steal my software

Nothing was stolen (i.e. Oracle still has the software), it was an infringement of copyright (and perhaps patents).


That licence would have more restrictions in both the short and long term than just the upfront cost.


I'm having flashbacks here, but what I remember at that time was concern that if Google paid Sun, they'd be setting a precedent that way. There was a sigh of relief when they didn't, at least from some, because, regardless of how much better of a company Sun was than post-Sun Oracle, people felt like it was overreaching.

So although you're correct that Google did this themselves, the alternative was fraught with problems also. Better to fight it and lose than implicitly accept the idea and pay.

This was all happening in the context of C#, which people seem to be forgetting about too. It's important to remember that the whole idea of copyrightable API was done under the argument that it was important to protect API integrity from forks. MS provided evidence of a desire to do this (as has Google to some extent since then) but then introduced C# instead.

Anyway, this is a mess because copyrightable API is ridiculous, but Google should have been more careful with cleanroom implementations.


It's also very standard enterprise thinking: Save 100 mio now, get a bigger bonus check, and worry about the consequences later. Maybe all consequences can be avoided even.


To complement that, here is the most recent Gosling´s interview at Triangulation about how Google screw Sun and was aware of their monetary situation.

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...


Well, first Sun treated Apache like shit over Harmony issue which had such big role in popularizing Java. Later Sun was was on receiving side.


SUN wasn't very happy about Google using Java without paying anything. IIRC SUN wanted Google to use J2ME and get some modest fees; instead Google decided to reimplement API, pissing off all top guys at SUN who publicly were OK with it (hoping they could negotiate some payment), but internally were boiling.


I don't think J2ME was suitable for googles usage regardless of price. Unsuitable tech is unsuitable if someone pays YOU 100M


Sure, I also found it funny back then, but that was what SUN management was thinking...


Sun was only incrementally better than Oracle in their approach to Java licensing. They already has one pyrrhic victory over Microsoft that birthed C#, .NET, and Microsoft's own VM. Failing to come to terms with Google means client Java runs on Android, and not even on a Java VM. Way to make your language technology relevant.


Sun didn't just license the rights to the Java IP, but as a supposed standard established by the JCP, a farce of a standardization body that never was.

Google probably had to use their implementation and J2ME was and still is a piece of shit.

Yes it was about cost, but the cost would have been far greater then the licensing price ;-)


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: