As to factor number 2, the nature of the copyrighted work: For the last 20 years or so, courts have been backing away from the expansive approach of Whelan v. Jaslow and instead using a Computer Associates v. Altai "abstraction, filtration, comparison" analysis; in the end, courts typically hold that copyright protection for functional aspects of software is "thin." See, e.g., UC law professor (and MacArthur "genius grant" recipient) Pam Samuelson's 2013 review of the case law. [1]

From what I've read of the facts, number 3 -- the amount and substantiality of the portion used from the copyrighted work in relation to the work as a whole -- might have weighed heavily in Google's favor.

As to number 4, I didn't get a sense whether or not the evidence showed that Android has had a material adverse effect on the market for Java; that weighed heavily in the Supreme Court's thinking in the 2 Live Crew case.

[0] https://supreme.justia.com/cases/federal/us/510/569/case.htm...

[1] http://scholarlycommons.law.northwestern.edu/cgi/viewcontent...

"On cross-exam, a Google attorney brought up a graph from an internal presentation by Brenner showing "aggressive" and "conservative" estimates of what would happen to Java licensing revenue from 2007 to 2010. The graph's "aggressive" line showed a decline from around $140 million per year to about $105 million, and the "conservative" line showed a decline from the same starting point to around $50 million.

The graph was created before the launch of Android. Google's point was clear: Java was in decline, Android or no Android—and its executives and salespeople knew it."

It doesn't really matter what the numbers were though. They would have been higher had Google paid Sun for a Java license.

[0] http://arstechnica.com/tech-policy/2016/05/suns-head-of-java...

http://www.nolo.com/legal-encyclopedia/fair-use-what-transfo...

Samba never copied anything.

The interoperability argument was simple. Google wanted to use a language that was familiar to most and where developers could take existing code and port trivially. There are developer tools on the market that have done that for decades.

Davlik isn't drop-in compatible with the JVM anyway.

Oracle were never going to get away with that crap argument. To say that had Google copied all the APIs and created a compatible JVM that would have constituted fair use is laughable frankly.

Sun also open sourced Java which doesn't help them at all, and Oracle somewhat pathetically tried to backtrack on that.

That makes Oracle's win on the subject matter issue basically a pyrrhic victory for anyone looking to protect their APIs. They're protectable, but can't be protected in any realistic scenario.

The only sensible outcome. Had Oracle won we would have had years of court action in the developer software tools market until someone saw sense and simply ruled fair use in all cases. That may still happen.

And if you're in the camp that believes APIs should not be protected, this precedent--if it stands--means that you'll have to shoulder the expense of going to trial on the fair use issue before winning on the merits.

We'll have to get to a point where if court action is raised then it will automatically have to be thrown out. You can copyright APIs, but you can't tell others how they should be used.

Besides, how is the argument that Google effectively didn't copy enough at all consistent with the fair use factor regarding the amount of expression copied?

The trouble is that interoperability takes many forms and can't be shoved into a neat box like that.

What does that mean? What privileges would such a copyright provide? What could I do with the copyright that I couldn't do without?

What privileges would such a copyright provide?

In practice? None.

An API being used by a client and an API being copied by a competitor to be used by those same clients are two completely different situations.

Using API and the word 'copied' in the same sentence simply doesn't mean anything.

And that's about it.

According to this case, they did.

Unless you are arguing that network protocol compatibility is a different thing? It seems to me that there is a lot of overlap, since Samba relies on re implementing the same behavior as a Windows file server.

So.., if you implement an API in a different programming language, such that the text and structure is different, and yet the function remains the same... then have you not infringed any copyright?

To me an API, is just a formalization of declaring your intention to implement a particular functionality.

Nonetheless, I don't think the clean-roomness or otherwise of an implementation has an impact on this. Otherwise someone could copy music by listening to it and replaying it.

Like you said: the copyright is on the text, pattern and structure of the code. But it doesn't matter how it was replicated.

The trouble for doing that with Java APIs is the spec basically is the class declarations. You don't just need to "do the same thing" you need a tangible source file that has at least in part the same text.

Sane laws such as that automatically prevent issues such as this Java API dispute and also things such as the attempts to block interoperability for coffee machine "pods" by requiring a copyrighted magic string and using DMCA to prevent others from using it.

Please learn the difference between an API and a network protocol, else you end up looking foolish.

https://www.samba.org/ftp/tridge/misc/french_cafe.txt

I don't believe that the distinction is that clear at all. Hence my comment:

Unless you are arguing that network protocol compatibility is a different thing? It seems to me that there is a lot of overlap, since Samba relies on re implementing the same behavior as a Windows file server.

I think it is pretty easy to argue that the pattern of network calls needed to make calls (eg authentication) is an API.

Is a WSDL SOAP definition an API? I think most would say yes. A REST endpoint and the definition of how to use it? Why exactly is the definition of the HTTP protocol different to the definition of the REST endpoint?

IANAL, etc. Which seems important these days.

The API's that Samba uses to access that protocol are nothing like the Windows API calls (and are a completely independent implementation).

I'm just pointing out that it isn't at all clear to me that the strong distinction that software people see between APIs and protocols is as clear under law.

And of course Samba isn't built of WIN32 APIs, that's not what we're talking about.

I don't know if APIs should be subject to copyright or not. I certainly don't want them to be. But since APIs have been found copyrightable, it's hard to understand how this wasn't open and shut for Oracle.

It should be expected that when a district court and its jury have their hands tied by a bad appeals court decision, the outcome will look a bit odd. In many ways our system of case law functions like a body of software where patches can only add lines of code, not remove them. Convoluted solutions to work around previous mistakes end up practically set in stone and refactoring is at best a once in a lifetime opportunity.

> And if you're in the camp that believes APIs should not be protected, this precedent--if it stands--means that you'll have to shoulder the expense of going to trial on the fair use issue before winning on the merits.

worth remembering that since that decision was made by the Federal Circuit, it has no bearing on the rest of the court system when it comes to copyright. There is no place where "APIs are copyrightable" is binding precedent.

Any lawsuits that don't end up in the Federal Circuit (which pure copyright suits never do) will have to start from "are APIs copyrightable?" before having to make any sort of fair use defense.

It seems (based on this case) that you could make that happen by simply throwing in a patent claim, even if you'd get defeated on that point (which happened to Oracle). Not sure if that's a general rule one could exploit, or something that just happened in this case?

Starting from "Are APIs copyrightable" all over again? Great......... More legal fees, court time and nonsense.

"Under the first of the four § 107 factors, "the purpose and character of the use, including whether such use is of a commercial nature ... ," the enquiry focuses on whether the new work merely supersedes the objects of the original creation, or whether and to what extent it is "transformative," altering the original with new expression, meaning, or message. The more transformative the new work, the less will be the significance of other factors, like commercialism, that may weigh against a finding of fair use. "

Campbell v. Acuff-Rose Music, Inc. 510 U.S. 569 (1994)

I will simply point out, as i did in another comment, that the court of appeals in that case did in fact, claim that because 2 live crew took the heart of the old work, and made it the heart of the new work, that it was not transformative, and SCOTUS said that was wrong.

Disclaimer: I work for Oracle, though not on Java.

Didn't a jury just do exactly that? I realize Oracle must have an opinion contrary to the ruling else what's the point of an appeal, but will that really be the line of attack? We don't like the outcome, therefore we question whether the jury knew what they were doing?

Actually, that's pretty much exactly it. An appellate court is capable of ruling a jury finding as contrary to the weight of evidence. It's basically a mistrial ruling -- that the jury did not perform as required -- and therefore permits a retrial. It's a pretty rare occurrence, though.

EDIT: This seems to be a good review:

http://www.litigationandtrial.com/2012/04/articles/trial/con...

Specifically: "Rather, the role of the trial judge is to determine that notwithstanding all the facts, certain facts are so clearly of greater weight that to ignore them or to give them equal weight with all the facts is to deny justice."

So, the basic argument from Oracle could go something like, "The jury did not properly weight the fact that the copy was performed for commercial reasons and therefore cannot be fair use."

I can certainly see an argument here that certain facts, such as commercial use, were not properly considered by the jury. Commercial use is typically a very large factor in fair use, and should receive a correspondingly heavy weighting.

Also, remember that this would merely permit a retrial. It would not be an immediate ruling for Oracle, as one normally thinks of appeal decisions. It would be a big reset button on the whole process.

Good luck with that here.

There's a huge backlog of fair-use cases for them to base their decision on. I don't think it would be particularly difficult or nasty in this case, given that the ability to copyright APIs was a presumed fact during the trial. Also, the judges do not all need to agree; majority vote wins. So the moment they feel that further debate is unproductive, it's time to vote and move on.

It is going to have be be very clear and something that can be ruled on in a short space of time. There is no way you can argue at all that anything clear has been missed here, or argue in clear terms how things have been weighted.

Stuff like arguing that commercial reasons haven't been weighted properly is entirely subjective, because it depends on arguing how transformative use is - and that is what has happened here. The jury have already decided on that one. The 'backlog' of fair use cases will simply throw up the same subjective issues.

An application like that to a court is not going to impress any judge one iota. You can't just wander back into court and argue "The jury has been unreasonable" without some totally solid evidence. The jury also ruled unanimously, so it wasn't even close.

But the federal circuit could surprise us yet.

That's highly debatable - both the need for interoperability and the proprietary parts. Making the platform attractive to developers is a driving need making it interoperable is a byproduct of that. And Java was open sourced in 2007.

The GPL does not depend on copyrightable APIs, and says nothing about what Oracle is trying to argue. Linking to a library and merely using an API are two different things. The GPL depends on the former and says the latter is neither here nor there.

True in terms of the GPL as such, but the FSFs interpretation that the GPL applies to works that link, even dynamically, to a GPL covered work, which it holds to be derivative works, depends absolutely on the API presented by a library being a copyright-protected element (it also probably can't stand even then without an extremely narrow interpretation of "fair use".)

Instead the idea is that the code linking to GPL'ed code generates a new work during execution that's a derative of it AND the GPL'ed work, inheriting the copyleft license, requiring a compatible license on the linking code.

http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html

The code depends on copyrighted libraries, but, this has nothing to do with whether the method of calling a GPLed code library is itself copyrighted.

The primary argument is the simple question: is there two disconnected works or a single work with separate parts, parts that exist either for technical reason or for plain arbitrary reasons. Software that is dynamically linked can't be run without the dynamic library, is dependent on the library, and generally has no purpose if you try to use it without the library. If a judge/jury member will view the complete work as the software+library, then the method of linking the two together is irrelevant.

The "first" case of this was a patch to GCC. The patch would not have much purpose without GCC. A common sense approach would be that the working Objective-C compile had two parts, the patch provided by apple and the compile provided by the GNU project. RMS initial thought like most programmers that since patches seems like separate parts than it was separate and disconnected works. However, it was unclear so he asked a lawyer and thought that a judge would not view it like that. From there the dynamic linking guideline came to be and that is where current thinking has stayed. Nothing about API is needed for this, and GPL would still work tomorrow if someone created a third method to link software together as a single work.

A interesting future case would be a program that is dynamically linked to a library that exist under several different licenses. Such software would have a strong argument to be disconnected from their library, but they would still be incomplete and a judge would likely put a lot of weight on the developers intention rather than any technical aspects.

I mean, could you have a clause in a license that said "to distribute this work, you need to wear purple shoes on Mondays"? If so, why wouldn't you just be able to say "to distribute this work, you need to distribute works that link to it under the same license", as as arbitrary condition?

You don't need to abide by a copyright license if you aren't doing anything for which permission of the copyright holder is required in the law -- a copyright license is only needed to do things which would otherwise be prohibitd as within the exclusive purview of the copyright owner.

As the GPL isn't a sale contract that you must agree to as a precondition for receiving a copy of the software, when you receive a copy of GPL-covered software you can do anything you want with it as long as that isn't legally within the exclusive prerogative of the copyright owner (or contrary to the law for some other reason), and the GPL itself is irrelevant. The assertion by the FSF that particular uses of GPL-licensed software are constrained by the license is, therefore, necessarily an assertion that those uses are within the scope of the exclusive rights provided by copyright law.

Ah, that's what I was missing. When did they assert that the use by itself (with no redistribution) is constrained by the GPL? That seems to go directly against their FAQ:

  If I only make copies of a GPL-covered program and run them, without distributing or
  conveying them to others, what does the license require of me?

  Nothing. The GPL does not place any conditions on this activity.

The question at hand is whether you can impose these restrictions in the viral fashion of the GPL, e.g., on code I write that merely makes use of your APIs.

The way that the GPL attempts to enforce this is with copyright law, by not granting you the right to redistribute GPLed software unless you comply with it. By design, it doesn't restrict anything else about how you use the software.

(see the cite to campbell v. acuff rose, etc)

In fact, the precise argument y'all seem to make is disassembled in that case, because it's what the original court of appeals decision was in that case :

"The Court of Appeals reversed and remanded, holding that the commercial nature of the parody rendered it presumptively unfair under the first of four factors relevant under § 107; that, by taking the "heart" of the original and making it the "heart" of a new work, 2 Live Crew had, qualitatively, taken too much under the third § 107 factor; and that market harm for purposes of the fourth § 107 factor had been established by a presumption attaching to commercial uses."

They also explicitly said: " The statutory examples of permissible uses provide only general guidance. The four statutory factors are to be explored and weighed together in light of copyright's purpose of promoting science and the arts. Pp. 574-578."

Good. The CAFC ruling is indefensible, like most everything else that emanates from that court. If nothing else this ruling strikes me as a workaround for having an appeals court that is bought and paid for by special interests. For copyright and patents, the courts are so heavily stacked in favor of major rightsholders, and so abused by them, that for those who favor copyright reform it's probably well past the time to hope for rightful justice under the law and better to adopt a "victory at any cost" stance, much like our opponents (i.e. Oracle, etc.) already do.

If Google weasels out of liability because of some lame fair use defense that probably "technically" shouldn't pass muster, I can hardly give a damn given how often the law is twisted in the other direction already.

What recourse does Oracle have now? Didn't the Supreme Court decline to take this issue up last time round? Does that mean this case is closed?

One of the many things that makes fair use tricky is that the statutory factors aren't exclusive: 17 USC 107 just says that "the factors to be considered shall include" the 4 factors.

The letter of the law for fair use is often not all that helpful.

At the Circuit and Supreme Court level, expect Google to cross-appeal against the copyrightability issue again (the Ninth Circuit might well rule differently than the CAFC did applying -- in theory -- Ninth Circuit precedent, and in any case I think they'll need to do so at the Circuit level to keep the issue alive for the Supreme Court, which may week take the issue up on a final speak though it declined to do so on an interlocutory one.)

Sadly, it won't. Ars Technica has Oracle's general counsel saying "we plan to bring this case back to the Federal Circuit on appeal"

I wish Gunn v. Minton had been more expansive.

"Because this action included patent claims, we have jurisdiction pursuant to 28 U.S.C. § 1295(a)(1)"

...

"The jury found no patent infringement, and the patent claims are not at issue in this appeal. "

See Oracle America v. Google, Inc. (http://www.cafc.uscourts.gov/content/oracle-america-inc-v-go...)

The federal circuit will, in turn, pretend to apply ninth circuit law.

Your parent already answered that question (although I don't blame you for not noticing):

https://en.wikipedia.org/wiki/Judgment_notwithstanding_verdi...

I have seen this argument a lot but it doesn't make sense to me. Who says it has to be a drop-in replacement at the binary level to have interoperability value? The source-level interoperability is obviously valuable to developers, why ignore it?

I thought that since the court which ruled that APIs are copyrightable wasn't the court which would normally hear the appeal (due ot the patent issue) their ruling doesn't set a precedent?

1) Is incomplete. There should also be explicit mention of the creation and extension of open software ecosystems, which are of tremendous public benefit in both commercial and nonprofit forms. I guess this is partially covered by (4).