Live data from Hacker News

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

supremecourt.gov

481–490 of 965 posts

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

#481

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

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

Seems appropriate to create a burner account when you are this wrong and you know it. This is why many of us would like an easy ability to block greens.

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

#482

Earlier quoted context omitted.

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

I can recommend focusing on Justice Thomas' dissent, which contains a section related to this topic. I believe Justice Thomas agrees with your assessment, and he raises concern that the SCOTUS has essentially made APIs practically uncopyrightable (in that they will 100% of the time find that it's fair-use to use them). I actually disagree with him, but only in one sub-category: I think a SCOTUS ruling would be harder…

That’s a good thing. The ability to copy an API allows more competition, helps improve services as others provide similar functionality, and forces improvement because it becomes easier to migrate from one service to another.

One thing I do see happening is that sensitive and expensive to develop algorithm internals may be prevented from leaking into APIs. I, again, don’t see this as anything other than a win for devs. An API is fundamentally used to get stuff done, if a developer doesn’t need to know the implementation details I overall think this is a win for the developer using the API.

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

#483

Earlier quoted context omitted.

I don't think it's fair to compare a programming interface, which is more analogous to designing something like the plumbing architecture for a house, to a movie script, which is art. Yes, a well-written API can be considered art, but with the plumbing analogy, a "copy-cat" would just be making sure the same pipes are connected to the toilets in the same positions. What's going on under behind the dry-wall wouldn't m…

Bad analogy, architecture schematics are subject to copyright and you can't just take them and use them, either.

People can and do steal architectural patterns all the time for reuse in their own structures. Are your getting it wrong on purpose?

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

#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?

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

#486
post #459

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

> This judgment could have had devastating consequences and turned software development into a copyright nightmare. It’d sure have made the practice of taking someone else’s API and re-implementing the innards a lot more interesting: https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/s3co...

The WINE and ReactOS guys must be cheering!

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

#487
post #378

Earlier quoted context omitted.

I'm not sure why it's claimed they skirted the question... If I understand correctly, the Court answered the question when they issued bench instructions that APIs were to be considered copyrightable. Is the difference that there's no SCOTUS precedent on the issue because it wasn't addressed in this case? Because (IANAL but) I'd assume the bench direction is itself precedent... In that if another circuit court tried…

They did not say that APIs were copyrightable, they said that if "we assume, for argument's sake, that [APIs are] copyrightable, [...] the copying here at issue nonetheless constituted a fair use". From page 1 of the opinion, i.e. the actual ruling, which follows the "syllabus" in the pdf. The syllabus is basically just a summary. It's page 5 of the pdf.

I see; the difference is SCOTUS vs. circuit court of appeals precedent. I was referring to the decision of May 9, 2014 that overrulled the Alsup court assertion that APIs are not subject to copyright. But that decision was not from SCOTUS but from the appeals court for the circuit.

Current status, if I understand correctly, is that SCOTUS has not weighed in on whether APIs may be subject to copyright, and precedent in (Edit: Ninth Circuit) should be that they are to be considered copyrightable (and, I suppose, "no precedent in this circuit or from the Supreme Court" in all other circuits).

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

#488
post #354

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'm not sure the "API is copyrightable" argument was relevant in the Microsoft-Sun case. Keep in mind that case was settled privately. Since it was never decided in court, it's hard to say what the most relevant claims were, but I don't see Sun making much of the copyright claim. They had a licensing claim because they claimed Microsoft had licensed the Java trademark but was not implementing it fully according to th…

Good points. Though I thought the J++ naming was precisely to avoid the Java TM.

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

#489
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…

Making APIs copyrightable is a GOOD thing. It means they aren't patentable.

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

#490

> "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 wouldn't celebrate a victory yet. As is often the case, the court's choice of tests simply will serve as a blueprint for others on how to avoid themselves being caught in the same kind of result. Based on this court decision, it's apparently fair use to lift someone else's API and use it to jumpstart programmer familiarity with your product, if the author of the API previously tried to achieve success in that narro…

> IP holder companies will become even more common: they will be used to hold copyright to one API and license it out to customers

Not after this precedent, which says that APIs are free.

What will happen: Intel licensing the i86 instruction set will not be possible from now on, same for ARM.

Post reply on HN