Live data from Hacker News

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

supremecourt.gov

151–160 of 965 posts

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

#151
post #79
post #65

Earlier quoted context omitted.

They didn't establish a new test, they applied the existing 4 tests / factors and found that they indicated fair use. The first 2 or 3 pages contain a description of the 4 tests and how they were found to apply in this case.

Not entirely. Per my understanding, this is a fairly big shift: "The fair use question is a mixed question of fact and law. Reviewing courts should appropriately defer to the jury’s findings of underlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This approach does not violate the Seventh Amendment’s prohibition on courts reexamining fa…

Well, it sounds like it's still the same test; it's just deciding that fair use cases must be decided by judges, not by juries. Which, as you say, seems like a good decision.

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

#152
post #81
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…

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?

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

#153
post #89

Earlier quoted context omitted.

I don’t think it moots the point at all. * Google’s API copying can’t be fair use if they weren’t copyrightable in the first place. * If you do copy an API because of it’s beauty and not for either interoperability with software or interoperability with developers then it seems that you would run afoul of copyright.

If you do copy an API because of it’s beauty and not for either interoperability with software or interoperability with developers then it seems that you would run afoul of copyright. That's why I said it partly moots the issue, not completely . Yes, you could conceivably still run afoul of copyright in some cases, but at first blush, this seems like a precedent that will make it very unlikely that that would happen.…

> If you do copy an API because of it’s beauty and not for either interoperability with developers then it seems that you would run afoul of copyright.

So don't do that?

Why would you copy an API save to be inoperable?

If it's just to duplicate someone else's design, I think I'm okay with that potentially being a copyright violation.

What downside am I missing?

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

#154

From the dissent: > The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright... 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 function…

This argument is hard to swallow: > declaring code would satisfy the general test for copyrightability.. they are expressed in “words, numbers, or other verbal or numerical symbols It is common knowledge that mathematical formulae & equations, which are also expressed in words, numbers, and symbols, do not have copyright protection. > Copyright protection is therefore not available for... mathematical principles; for…

When you get down to it, copyright is a whole bunch of contradictory rules. Courts decide every time there is a new kind of work, whether it is copyrightable or not. Trying to divine whether something is copyrightable by analogy to other kinds of works is a hopeless endeavour.

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

#155
post #89

Earlier quoted context omitted.

True, but it's such a strong precedent in favor of copying API's being "fair use" that it at least partly moots the more general question of "are API's copyrightable in the first place." I think this was a good decision all in all. AIUI, the SCOTUS try to limit the scope of their decisions as much as possible, to avoid over-generalization.

I don’t think it moots the point at all. * Google’s API copying can’t be fair use if they weren’t copyrightable in the first place. * If you do copy an API because of it’s beauty and not for either interoperability with software or interoperability with developers then it seems that you would run afoul of copyright.

That... somehow seems fair? If what you are copying is the artistic expression and not the functionality, that seems like exactly the sort of thing copyright is supposed to be about.

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

#156

This is one of the most important legal decisions in the history of software. The US Supreme Court has basically just saved the whole software industry (and FOSS projects) from being wrecked by patent trolls.

s/patent trolls/copyright trolls/

This case involved copyright, not patents. Copyrights are separate from patents.

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

#157

This is one of the most important legal decisions in the history of software. The US Supreme Court has basically just saved the whole software industry (and FOSS projects) from being wrecked by patent trolls.

Good, now can we get a ruling that prevents Google, RedHat, Microsoft and others from wrecking FLOSS projects with their stifling influence?

Or prevent them from eradicating competing or even original projects by doing hostile rewrites or forks?

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

#159
post #79
post #65

Earlier quoted context omitted.

They didn't establish a new test, they applied the existing 4 tests / factors and found that they indicated fair use. The first 2 or 3 pages contain a description of the 4 tests and how they were found to apply in this case.

Not entirely. Per my understanding, this is a fairly big shift: "The fair use question is a mixed question of fact and law. Reviewing courts should appropriately defer to the jury’s findings of underlying facts, but the ultimate question whether those facts amount to a fair use is a legal question for judges to decide de novo. This approach does not violate the Seventh Amendment’s prohibition on courts reexamining fa…

That analysis is addressing an argument that the Supreme Court could not overturn the finding that it was not fair use. That argument was based on the Seventh Amendment's reexamination clause. The Supreme Court held that the reexamination clause did not prevent it from addressing this issue, because the question is a mixed question of law and fact, i.e., it's a legal conclusion based on evidentiary facts. The Supreme Court cannot re-examine the "underlying facts," but the Seventh Amendment does not preclude it from deciding, as a matter of law, whether those underlying facts constitute fair use.

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

#160

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

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).
Post reply on HN