Hacker News Reader

Comment by rayiner | Hacker News Reader

These are the statutory fair use factors the jury was required to consider (17 U.S.C. 107):

(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;

(2) the nature of the copyrighted work;

(3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and

(4) the effect of the use upon the potential market for or value of the copyrighted work.

It's a somewhat surprising result, because two of the factors weigh heavily against Google (it's a commercial work, and was important to Android gaining developer market-share). Oracle's strategy going forward, both in post-trial motions and in any subsequent appeal, will be based on arguing that no rational jury could have applied these factors to the undisputed facts of the case and concluded that the fair use test was met.

It's also not a particularly satisfying result for anybody. If API's are copyrightable, then I can't think of a better case for protecting them than in this one, where Google created a commercial product for profit and there was no research or scientific motivation. It wasn't even really a case (like say, Samba) where copying was necessary to interoperate with a closed, proprietary system. Davlik isn't drop-in compatible with the JVM anyway.

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.

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.

View on HN

As to factor number 1, the purpose and character of the infringing use: In the 2 Live Crew / Pretty Woman case, the Supreme Court held that just because an infringing use is commercial, that doesn't automatically mean it's unfair (although it is indeed an important factor). [0]

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

Good point about factor #4. But (in light of dragonwriter's comment below): wasn't Sun making a play at getting JVM into peoples' phones before Android stole their thunder? Or am I misremembering the timing?

Oracle tried to argue that, with seemingly limited success. Bringing up SavaJe didn't help them. It clearly wasn't equivalent to Android in any way.

JavaME had existed for years. There were a few very good apps (Google Maps was great, as was the Facebook app). Given that even the cheapest phones included it I can't imagine Sun was making any money off it.

It was a major source of licensing revenue for Sun, and one of the main reasons why historically they had been reluctant to open source Java. They were making around $200M revenue from it in 2007, which was the major source of income for their software business.

I thought this part of an Ars Technica article[0] on the trial was pretty telling:

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

That's not relevant to fair use analysis. What's relevant to fair use analysis is if Java's market would have been bigger if Google neither bought a license nor produced Android. Obviously, any unlicensed use of a copyright protected work is going to reduce the caller of the protected work compared to the exact same behavior coupled with paying for a license, but that's not what the market effect factor is about.

You miss the case where Google had produced Android with a different platform (LLVM, Objective-C, or their own language). Since Java was in decline on mobile, it should have just entirely ripped Java from the mobile market.

I don't miss that case, I just don't believe it's the relevant one for fair use analysis. Though, if it were, that would weigh even more heavily in Google's favor.

Phones have had Java since 2001.

Google argued that feature phones only had Java ME, which only included a small subset of Java's APIs, in contrast to Android, which includes significantly more Java (SE) APIs, as well as Android-specific APIs. My layperson understanding of that argument was that their use of Java was transformative because feature phones running Java ME were completely different from Android smartphones.

Indeed, Google spent a lot of time making this case to the jury. I could be mistaken, but I fear this is going to be the basis of a reversal on appeal, because what "transformative" means is ultimately a matter of law (indeed, the word itself comes from a Supreme Court decision rather than the text of a law), and to me Android looks completely different from previous things considered "transformative":

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

When you look at Android and then look at previous phones with Java and apps on them it's hard to argue it isn't transformative. The difference between SavaJe and Android is night and day.

It wasn't even really a case (like say, Samba) where copying was necessary to interoperate with a closed, proprietary system.

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.

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.

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

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?

It's not, but Oracle had got themselves into a bind over the definition of 'interoperability'. They did indeed argue that Google hadn't copied enough, in so many words.

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

> You can copyright APIs, but you can't tell others how they should be used.

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

It is as ridiculous as it sounds. There is simply no case at all where API use cannot be sensibly argued as fair use. That's why you use an API in the first place........

What privileges would such a copyright provide?

In practice? None.

> There is simply no case at all where API use cannot be sensibly argued as fair use.

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.

Nope, they aren't, or at the very least, the difference between them is as to be indistinguishable. That's what the jury decided here.

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

I think you've just started to delve into the problem domain of copyright vs copyleft and why there are legal considerations when you allow people to access your software using an API.

Wave around a piece of legal paper with your name on it, if you file it with the copyright office.

And that's about it.

> Samba never copied anything.

According to this case, they did.

Nope. Not sure where you're getting that from.

Samba is API compatible with Windows file server.

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.

Copyright doesn't care about the software's behavior, just the text and structure of the code. Samba implemented CIFS without looking at or copying any Microsoft code.

This is such a key point and yet also quite confusing. Obviously copyright is not patents. Copyright is about preventing literal copying of someone's creation.

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.

That basically used to be true, but this trial was over the "sequence, structure, and organization" of the API.

How can you copy an API without looking at the original API? They might not have looked the implementation, but if the API itself is copyrighted, won't looking at it suffice to be infringement?

If there is one thing I've learnt for sure from all the random forum posts used in this trial, it is that "IANAL" is a good thing to say!

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.

Reverse engineering is not a defense against infringement if the subject of reverse engineering is copyright-protected.

It generally is. That's the whole point of clean-room reimplementation. You have one set of engineers that reverse engineers a product to develop a spec, and another set that implements the same functionality from the spec. That's kosher and has been upheld in several court cases.

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.

It kind of depends - in some jurisdictions, for example, interoperability requirements is a sufficient defense against copyright infringement, i.e., if you've built your product so that interoperating with it requires [re]using copyrighted parts, then it's okay to do so (up to the extent required for interoperability) even if you explicitly forbid it.

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.

Samba uses NO Windows APIs.

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

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

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

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.

A linearized network protocol is not an API. That distinction is very clear. Read the Microsoft protocol specs. They say nothing about API's used to send/receive the protocol - only how the protocol elements are encoded on the wire.

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

I don't disagree at all!

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.

It's not nearly as cut and dry as you're making it. Wiki of all places defines 'API' to be broad enough to include network wire protocols and endpoints. This trial was over "sequence, structure, and organization" rather than literal copying.

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

If you automatically throw out cases, what's the point of having a law enabling and encouraging those cases in the first place? Or maybe a better question is: what would legitimate infringement look like, if what Google did is fair use?

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.

Thus far, APIs have only been found copyrightable by the court that is specifically about patents. It's highly doubtful that any court capable of setting binding precedent on the matter will agree, especially to the same industry-destroying extent.

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.

> If API's are copyrightable

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

> Any lawsuits that don't end up in the Federal Circuit (which pure copyright suits never do) [...]

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?

This actually gets exploited all the time to get into the Federal Circuit's "arising under" jurisdiction :)

Fair point. I'm reminded why I don't get too familiar with US law in these cases.

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

Just has to happen once though.

It's always going to be tougher to get a no reasonable jury finding on a factor test like that than an element test. Implicit in a multi-factor test is that the weighing of the importance of the various factors with respect to each other is left to the trier of fact.

Errr, you didn't do factor one properly :)

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

Is Dalvik's use of the Java API transformative? My understanding of Cambell is that it's the Google Image Search scenario: where the thumbnail of the copyrighted work is fair use because it serves a totally different function than the original work.

So, i'm not going to express a precise legal view here (i am sadly too involved, i'm just going to stick to answering more general questions and pointing out what caselaw says), just pointing out your analysis of commerciality as the goal of the first factor is precisely what SCOTUS said not to do :)

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.

But function is not something to be assessed in isolation. The context is important too, as "the Java API" is not expression for expression's sake and has little intrinsic value. Google argued that they brought a system built originally for desktops and servers (the domain of JavaSE) to smartphones. Whether that's "transformative" is up to a jury.

If anyone is curious to see a summary of Oracle's claims to Google's copying not being fair use, the slides for their closing arguments are available at Ars Technica: http://arstechnica.com/tech-policy/2016/05/how-oracle-made-i...

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

Thanks. Quite apart from 'Java' having been open sourced, Schwartz also got up and told everyone this was all OK. Oracle really did face an uphill battle with that since it's nigh on impossible to take back.

And not to mention how difficult it would be to apply Oracle's logic to the innumerable applications that have modified a java version for their own use. I know this is argued in other posts on this thread, but just how in the world can Oracle justify FOSS and its implementation thereof a violation of copyright in these cases as well?

>Oracle's strategy going forward, both in post-trial motions and in any subsequent appeal, will be based on arguing that no jury could have applied these factors to the undisputed facts of the case and concluded that the fair use test was met.

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?

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

That's going to get messy. Very messy. It has to be crystal clear really for that to happen, but all you'd end up with is more debate on what parts have greater weight.

I don't see why it would necessarily get messy. Remember that appellate court does not accept new facts. The judges reviewing the case will do so based entirely on the facts found during the trial case and make a ruling. The only thing they would need to rule on is whether a particular fact was weighted properly by the jury. Remember, jury members are not expected to be experts of law; that's the judge's realm. So it's possible for them to misapply the law, and this process is a way to correct that.

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.

The only thing they would need to rule on is whether a particular fact was weighted properly by the jury.

Good luck with that here.

You are presenting a very cynical view of the justice system and judges without any reasoning backing your claim. "Good luck with that" is not really a valid debatable response.

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.

I'm presenting reality I'm afraid.

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.

And there's almost nothing crystal clear in US fair use law. I agree it seems inconceivable to argue that 'no reasonable jury' could have done just about _anything_ regarding a fair use determination. There are so few clear lines in the established law.

But the federal circuit could surprise us yet.

Thank you for the explanation!

> there was no driving need to interoperate with a proprietary one

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.

Given the fact that Java is open source and was open sourced in 2006, how does Oracle have a case? I'm asking legitimately not understanding how this even has a leg to stand on.

Google didn't base their implementation on OpenJDK, even if they had they didn't follow the terms in the GPL so (given it was copyrightable and not fair use) this wouldn't be a defence.

This is irrelevant. There was a ridiculous notion going around a while back that if Oracle lost then the GPL would become unenforceable.

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.

> The GPL does not depend on copyrightable APIs

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

This is not a much a question of the API as it is of the effect during execution. If the API would be considered to be what was protected then copyleft code can never be cloned in an interoperable manner under permissive licenses.

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.

Where the GPL is concerned the distinction between linking when code has been compiled and the API itself is very clear. Code is copyrightable, but headers and interfaces do not make something else a derivative work. Stallman agrees on this one:

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.

That is a very surface based interpretation of FSF stance on the subject. What I have heard from members of FSF board members is that the dynamic linking aspect of GPL is a simplified rule that a non-lawyer can use to identify when a derivative work is created.

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.

Why? A license is just a contract, no? Can't the clauses be arbitrary?

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?

> Why? A license is just a contract, no? Can't the clauses be arbitrary?

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.

The assertion by the FSF that particular uses of GPL-licensed software are constrained by the license

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.

http://www.gnu.org/licenses/gpl-faq.en.html#NoDistributionRe...

Sure, you can make arbitrary restrictions for how to distribute a work in a license.

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.

Open source is just a blanket term for a variety of different licenses with different limitations. Earlier court decisions didn't see the GPL license invalidating API copyrights. I guess a poor analogy is that you can use linux code all day long but the Linux trademark is not yours. Nor does Linus personally give you immunity from patents that code might infringe on.

As I see it, only factor 1 clearly weights against Google at all; the other factor you think applied presumably is #4, but Android gaining market is irrelevant to that. The value of or market for Java shrinking compared to what it would otherwise be is what factor 4 is about, and while Oracle no doubt argued this point, it's certainly not indisputable.

The supreme court has repeatedly stated that being commercial or not commercial is not the entire point, and the more transformative the use, the less it matters whether it is commercial or not.

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

I'll agree that I was too hasty in agreeing that factor 1 weighs against Google in my rush to make the case that factor 4 isn't a slam dunk.

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

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.

Would that be like Oracle arguing jury nullification? It seems that the case law on nullification is that the jury's verdict is the definition unless vacated by procedural error. Thoughts?

It's the opposite, in that instead of the jury overruling the judge on law (normally the province of the judge), the judge overrules the jury on the ultimate factual question of liability (normally the province of the jury). The required showing is accordingly exacting (though hardly impossible to meet in practice): no rational jury could have reached the same conclusion.

Do you know where to find the definition of rational that applies in these cases?

In a sense, in that you could view any post-verdict judgement contrary to the verdict as a ruling that the jury attempted nullification of the law where it lacks the power to do so (nullification is only a power juries can exercise to return criminal not-guilty verdicts, other than that, courts may set aside the jury verdict of no reasonable jury could find the facts necessary to the verdict returned on the evidence presented.)

Agreed, it sounds like by the letter of the law Google's use was not "fair use", if you grant the assumption that APIs are copyrightable in the first place.

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?

> it sounds like by the letter of the law Google's use was not "fair use"

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.

They've got post-verdict motions at the trial court, if that fails they can speak to the Circuit Court (I think this will go to the Ninth Circuit now rather than the Federal Circuit, but that may be incorrect.) If they fail their, they can petition to have the Supreme Court take up the case (their refusal to take up a different question in an interlocutory -- prior to final judgement -- appeal previously shouldn't be considered a strong signal of whether they would take the same or a different question on appeal of a final judgement.)

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

> I think this will go to the Ninth Circuit now rather than the Federal Circuit, but that may be incorrect.

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"

Yes, it will go back to the federal circuit because they interpret anything that once, ever, had patent claims in the complaint as arising under the patent laws of the united states.

I wish Gunn v. Minton had been more expansive.

Of course. They all want to get paid, and that's really what this is about from Oracle's perspective.

As Rayiner mentions, first they'll be a post-trial motion to vacate or overrule the jury verdict. Regardless of how those motions are decided the losing side will appeal to the Ninth Circuit. Only after a Ninth Circuit panel and perhaps en banc panel rules will one side or the other try for a cert petition to the Supreme Court.

Since Oracle hasn't dropped its patent claims from the complaint (despite the fact that they've already been defeated), doesn't Oracle get to bypass the 9th circuit and vault the case back to the CAFC?

Good point. That's a corner of the federal rules I'm not nearly familiar enough with to give you a confident answer.

It will return to the federal circuit. The patent issues were not even appealed to the federal circuit the first time.

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

I wonder whether this time the appeal will go to the Ninth Circuit, or whether instead it will return to the Federal Circuit?

> What recourse does Oracle have now

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

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

I wonder what would happen if they try the Supreme Court now.

Well they can't really 'try' the Supreme Court - the Court has to decide to take up the case. Oracle can't demand that they do so.

So, they can try, they just have an additional opportunity to fail that they wouldn't have at the Circuit Court level.

It wasn't even really a case (like say, Samba) where copying was necessary to interoperate with a closed, proprietary system. Davlik isn't drop-in compatible with the JVM anyway.

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?

> They're protectable, but can't be protected in any realistic scenario

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) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;

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

Who thinks APIs should be protectable? That's thought crime.

Oracle, Inc., and the Court of Appeals for the Federal Circuit, clearly.

Reply on news.ycombinator.com