Live data from Hacker News

Google’s copying of the Java SE API was fair use [pdf]

supremecourt.gov

501–510 of 965 posts

Re: Google’s copying of the Java SE API was fair use [pdf]

#501

Earlier quoted context omitted.

It is fascinating that code is now being measured quantitatively. Number of "lines of code".

Now? I've personally heard quantities of code measured in "lines of code" (or, thousands of lines of code-- "K-LOCs") going back to the mid-90's. An acquaintance who worked for IBM in the 70's said it dates back at least that far (measuring developer productivity in the "K-LOCs" they produce).

https://www.youtube.com/watch?v=GqFYsvxHZOs&t=1205s

(start at 20:05 if timestamp fails).

Re: Google’s copying of the Java SE API was fair use [pdf]

#503

> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as…

So if Java had just bloated their code and those apis code footprint represented a larger % of the overall they’d be guilty? Or if Java trimmed a bunch of non essential packages into modules/extensions Google would be guilty It seems to me the judge is saying, “the house was full of 10 tons of jewelry but the robbers only took 10 pounds so that isn’t really stealing lol “

Now the jewelry stores will have to become smaller so that there will be 1-2 jewels per store. When something gets stolen, it'll be 50-100%.

Re: Google’s copying of the Java SE API was fair use [pdf]

#504

Honestly this stands contrary to almost every principle of fair use (transformative work of different character for the purpose of comment, parody etc.). Google took tons of APIs from a platform and implemented them into... a platform. If you think designing thousands of classes is not substantial that's a very different argument, different from fair use. Fair use means yes, APIs are copyrightable, but this is transf…

Is a restaurant menu copyrightable?

Recipes and menu listings are not. The artistic layout of the menu is.

Disclaimer: IANAL

Re: Google’s copying of the Java SE API was fair use [pdf]

#505

> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as…

So if Java had just bloated their code and those apis code footprint represented a larger % of the overall they’d be guilty? Or if Java trimmed a bunch of non essential packages into modules/extensions Google would be guilty It seems to me the judge is saying, “the house was full of 10 tons of jewelry but the robbers only took 10 pounds so that isn’t really stealing lol “

More like 10 million pages of books, Reading 10K pages does not mean one stole all the knowledge.

Re: Google’s copying of the Java SE API was fair use [pdf]

#506

For better or worse, the same arguments ( "API is copyrightable" ) is what was used in the past to prevent 98's Microsoft from doing embrace-extend-extinguish to Java with their "JavaVM with P/Invoke'd Win32 API". The idea in that case was that when you try to implement something identical to the Java language and standard library, it doesn't matter if you call it Java or "Visual J++"; you are still implementing Java…

I seem to remember that the 98 case was a trademark violation. Microsoft used the Java brand even though their implementation wasn't compliant (it was a derivative) - which was a big issue for Sun since one of the main point of Java is compatibility ("Write once, run everywhere"). Google however made sure to always be clear about "the Java Programming Language" or such safe phrase that makes clear that they're not th…

Correct. Microsoft could make J++ or whatever; they just couldn't call it Java.

The particular issue was that Microsoft was extending some of the Java language (and maybe com.sun?) classes. If you used any of their extensions, then you had code that could only be compiled with Microsoft's compilers, and you were locked in. (The "extend" phase, which is then leveraged for the "extinguish" phase.)

Re: Google’s copying of the Java SE API was fair use [pdf]

#507
post #485

> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as…

Can't this argument be used to copy the x86 interface and avoid paying license fees to either Intel or ARM for the instruction set?

The word on the street is that is primarily protected by patents, which explicitly protect against from scratch competing implementations, unlike copyright protection which only protects against verbatim copying of the original work.

On the plus side though, they only get 20 years of protection. x86-64 in it's original form should be up for grabs pretty soon here.

Re: Google’s copying of the Java SE API was fair use [pdf]

#508
post #70

While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use: > To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on…

I suppose Supreme court decision over this matter sets precedence for any future cases.

Re: Google’s copying of the Java SE API was fair use [pdf]

#509
A summary for those who don't want to read the entire thing:

This case was originally granted back in 2019. It was scheduled for oral argument in March 2020, but was postponed at the last moment until October because of the pandemic. Being postponed at the last moment, it was fully briefed well over a year ago, and the justices likely knew how they would rule in the case for a long time. (It's unclear how much of an impact oral argument actually has on influencing the decisions). That it took so long for a decision to come out--this is the last October hearing to get an opinion--strongly suggested to me that this would be a messy case with several overlapping concurring and dissenting briefs.

It is not. It is a simple 6-2 decision, with a single majority opinion and a single dissenting opinion. I'm reading between the lines here, but it seems pretty clear that Breyer (the majority opinion author) does not believe that APIs are copyrightable in the first place, but doesn't argue that point as he probably does not have enough other votes to agree with him. It's plausible that Breyer had a lengthy section on why APIs weren't copyrightable but that was pulled due to the other justices in the majority rejecting it. We can't know what the voting would break down as, but a 3-3-2 breakdown of "API is uncopyrightable; API is copyrightable, but this is fair use; API is copyrightable, this is not fair use" does not strike me as implausible. (There's not much in favor of this breakdown, note: that I lay it out like this is as much wishful thinking as anything else).

Thomas's dissent--I'll focus on that first--essentially makes two main arguments. The first is that API is copyrightable in its own right (Breyer's opinion assumes that it is for the fair use analysis but doesn't say that it is). The second argument is that Google's copying of the API cannot be fair use. A lot of that argument appears back-reasoned from "Google copied so much of the API and they made so much money off of it, how can it possibly be fair." In a broader sense, however, it's a different mode of fair use analysis than Breyer argues for. Thomas essentially views copyright as a property interest, and fair use is a narrow limitation on property interest. The API is an entity in and of itself here, so even though the API is a tiny fraction of both the original and reimplementing code, you need to look at the amount of the API itself that is being copied to judge how substantial a portion it is. Although when he turns to consider the impact that an independent implementation has on the market for the original, it's not the market of the API itself that matters but the market of the entire implementation.

Now going back to Breyer's opinion, he treats fair use rather differently. First, Breyer essentially invokes the idea that different kinds of copyrighted material deserve different amounts of protection. He draws a distinction between declaring and implementing code, and notes that since only declaring code is being copied, it pushes the factor analysis much more towards being fair use than otherwise. In contrast to Thomas, Breyer notes that commercial use isn't automatically non-fair use, and lists a few examples of where commercial use can indeed be fair use. Also, Breyer pushes hard against the idea of copyright being about property interests, noting that the Constitution expressly provides that copyright is for the progress of science and arts. Whereas Thomas places primacy on the importance of the effect of the market, Breyer instead contends that it's the least important factor here.

All the way back at oral argument, Thomas surprised me with the most insightful question: the fair use factors in the law are very explicitly a nonexhaustive list, so what other factors might exist to sway fair use analysis? At opinion time, Thomas is instead the one to declare that none other exist, while it's Breyer who rather strenuously comments that fair use analysis is not exhaustive, although he does not include any other factors in his analysis.

What's the overall impact, then? APIs may or may not be copyrightable--SCOTUS does not decide. But Breyer essentially suggests that APIs have at best "thin copyright"--a lot of their use may be inherently fair use (the same analysis Breyer does here can reasonably be copy-pasted for a lot of API reimplementation cases). What's more radical is the effect it has on fair use analysis. Breyer states that appeal courts have to reconsider fair use on appeals if juries find a use to be fair or not (that's an easy part of the opinion to miss). Breyer upends the traditional notion of how to balance fair use factors yet again. Essentially, he suggests that the analysis of fair use is dependent in large part on what kind of work is being copied, and the balancing is dependent on the kind of work. He also rejects a lot of the traditional emphasis on market or potential market analysis for fair use. This is somewhat disclaimed for wider application to non-code cases, but you can bet there is now going to be a lot of appeals surrounding fair use over the next few years.

Re: Google’s copying of the Java SE API was fair use [pdf]

#510

> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as…

Question from a layman: Does "interoperability" as a concept have any legal relevance here? Like focusing on programmer skills seems kind of beside the point, which is really for two pieces of software to be able to interoperate.

Yes, interoperability is relevant, because it affects the necessity of copying that particular code rather than making one's own substitute, which in turn affects fair use.

But Google's lawyers (inexplicably, in my opinion) failed to talk much about the fact that many Java libraries are interoperable between Android and Oracle Java, leaving the courts to think only in terms of full applications which are not interoperable. Thus the courts have treated this case as if the only benefit to Android's reuse of Java was programmer familiarity.

Thankfully, Google won anyway, so any defendant in a future case who can make a better interoperability argument will be in an even stronger position.

Edit: For example, in the Federal Circuit ruling that the Supreme Court just overruled, they complain: "Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google's interoperability argument confusing. [..Google] points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform." [1]

[1] http://www.cafc.uscourts.gov/sites/default/files/opinions-or...

Post reply on HN