Hacker News Reader

Comment by ABCLAW | Hacker News Reader

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.

View on HN

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.

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.

Where is the obvious factual inaccuracy?

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

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

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

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?

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.

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

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.

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.

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.

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.

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.

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

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.

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?

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

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

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.

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.

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.

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.

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

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.

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.

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

> 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 Java API definition.

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

I thought Google used the implementations!

They mostly used Apache Harmony's 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.

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.

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

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.

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.

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.

> 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

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.

> Dealt with previously - APIs are copyrightable

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

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

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.

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.

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

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.

That creates a circular argument.

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.

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

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

Reply on news.ycombinator.com