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…
Google’s copying of the Java SE API was fair use [pdf]
151–160 of 965 posts
Re: Google’s copying of the Java SE API was fair use [pdf]
#152While 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.
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]
#153Earlier 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.…
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]
#154From 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…
Re: Google’s copying of the Java SE API was fair use [pdf]
#155Earlier 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.
Re: Google’s copying of the Java SE API was fair use [pdf]
#156This 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.
This case involved copyright, not patents. Copyrights are separate from patents.
Re: Google’s copying of the Java SE API was fair use [pdf]
#157This 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.
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]
#158Re: Google’s copying of the Java SE API was fair use [pdf]
#159Earlier 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…
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".