Live data from Hacker News

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

supremecourt.gov

231–240 of 965 posts

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

#231

Had the ruling gone in Oracle's favor I can imagine some greedy company trying to procedurally-generate every API and copyright them all similar to this project which tried to copyright all musical melodies: https://www.independent.co.uk/life-style/gadgets-and-tech/ne... In the case of the music project, it was for the protection of the community, but I can imagine such a system being used selfishly for software APIs…

Independent copyright when a work was independently created is a thing in most jurisdictions, as copyright covers copying and is not like patents in that regard.

However, that would indeed require a ton more work to prove that you did not copy any of the generated work and truly did create yours by yourself.

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

#232
I 100% agree that this is the right outcome. Any other outcome would be a nightmare for software developers and would inhibit the development of products.

But the dissent raises an interesting point. I think it shows how the crafting of legislation by people who are wholly ignorant of technology can create problems. While programmers recognize the difference between an API and it's implementation, Thomas makes the interesting point that the relevant legislation does not (page 4 of the dissent):

> Copyright law generally protects works of authorship. Patent law generally protects inventions or discoveries. A library of code straddles these two categories. It is highly functional like an invention; yet as a writing, it is also a work of authorship. Faced with something that could fit in either space, Congress chose copyright, and it included declaring code in that protection.

> The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright. See 17 U. S. C. §§109(b), 117, 506(a). And it defines “‘computer program’” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101. That definition clearly covers declaring code—sets of statements that indirectly perform computer functions by triggering prewritten implementing code.

While it clearly is in the Court's prerogative to interpret law, there seems to be a pretty good case that the court didn't provide an interpretation for a gap in the law, it instead fixed a law that didn't make sense.

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

#233

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

I'm glad about this outcome, because I agree the other outcome would have had a devastating effect on software development.

I also appreciate this fair use argument, especially when you point out the code in question was 0.4% of the entire API.

Still, I'll always struggle with the idea that "the amount and substantiality of the portion used" when copying an interface is comparable to copying an implementation. The interface is, intellectually, the substantially heavier, "bigger picture" component of the API than the implementation. In my view they are apples and oranges.

So, I'm glad this was the outcome. But I'll always feel like there was something wrong with Googe taking the Java SE interfaces and using them like they did, gratis.

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

#234
post #119

Earlier quoted context omitted.

They are using a modern JDK on Android. The standard library is literally OpenJDK, and the runtime is the excellent ART JVM, which has super-fast GC and tons of mobile-specific optimizations (like zygote space support and switching to a different GC when the app goes into the background). IMHO, you really don't want HotSpot on mobile. ART is good work.

I think he's just referring to a modern version of Java the language, not ART vs HotSpot. I don't think anyone really cares which runtime is running.

The runtime prevent the support for modern JVM features such as value types (see my comment above). Google might duplicate all that work (but how much late they will be before it divide the Java world? Switching to a unified jvm and improving it through collaboration is the way to go.

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

#235

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 the official thing.

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

#236

Earlier quoted context omitted.

I don't know why people are acting like this is some victory of open source I don't know that anybody is saying that Google did anything specifically Good or Just or Noble or anything. The celebratory aspect is more based on all the Bad Things that would have happened in the future if this decision had come down in favor of Oracle.

That's literally the next sentence that you intentionally omitted. And I've seen plenty of people paint Oracle as some evil boogeyman like this is some good vs evil struggle. Oracle wasn't trying to make Bad Things happen. They were seeking damages from a damaging situation, and if bad things had happened... I'd blame the patent trolls and judges that enable them. Their insanity continues regardless of the verdict af…

Oracle wasn't trying to make Bad Things happen.

I didn't say they were.

They were seeking damages from a damaging situation, and if bad things had happened... I'd blame the patent trolls and judges that enable them.

The issue at hand is about copyright not patents.

And note that I'm not saying that nothing bad can, or will, ever happen again. I'm just saying that the consequences of this decision coming down the other way would have been Very Bad, which makes the current decision a Very Good Thing in general.

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

#238
post #81

Earlier quoted context omitted.

Thomas's dissent explicitly points this out. Without diving into "are APIs copyrightable?", the majority are skipping what should have been evaluated first before saying if they were fair-use or not.

Why should it have been evaluated first? I understand the intuition you're getting at: logically, the first question could make the second irrelevant. But if the second question resolves the issue even when the first is construed in favor of the other party, what's the rationale for demanding the court focus on the first question?

IANAL, but I can imagine something like the following:

A. We decide this is fair use based on the small number of LOC used and call it a day

B. OR we can decide that APIs are not copyrightable even though they're self-evidently creative works because of the importance of interoperability based on something something related to Borland v. Lotus, a case that we couldn't agree on the last time it came up.

Hey folks. Let's do A.

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

#239
post #136

Earlier quoted context omitted.

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

I suppose it makes sense from the perspective of copyright law, which protects artifacts. After all, one could say the same for quoting from a famous literary work .."ha now they're valuing literature in terms of number of words of prose!"

The dissent clearly highlights the fallacy of the ruling, where it discussed the importance of the "heart" of the work, rather than the portion of exact lines copied.

Aka, that you could clone Harry Potter's plot, characters, and story while not copying each word of the book verbatim, and it still be a copy of Harry Potter.

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

#240
post #190

The comments on this case always seem a bit confused to me. APIs have been copyrightable (in the US) since 2014(or 15, not sure). This ruling only affects the fair use judgement, and makes no further statement on the question of copyright; meaning APIs are still subject to copyright.

The copyrightability of APIs goes back to the "structure, sequence, and organization" being copyrightable decision back in (checks Wikipedia) 1986. The application since then has been inconsistent. Essentially, there's a concept called "thin copyright" which recognizes that some copyrightable things only receive minimal protection. The canonical example here is a phone books--phone books are copyrightable, but they mostly contain non-copyrightable information (lists of phone numbers), so most copying will essentially be fair use or free.

Breyer's decision explicitly avoids deciding whether or not the SSO being copyrightable is good law, but it does essentially provide that it provides only thin copyright.

Post reply on HN