Live data from Hacker News

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

supremecourt.gov

611–620 of 965 posts

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

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

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?

The main influence of the Supreme Court is in setting precedent. In the absence of a ruling from the Supreme Court, the previous ruling from the Court of Appeals for the Federal Circuit is binding precedent on the whole country that APIs are copyrightable. That means that the most important precedents set in this case are still an issue for the software industry.

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

#612

Earlier quoted context omitted.

> That said, this case does establish a precedent that if your copying of an API is primarily for purposes of matching an interface so that developers can reimplement it, you're in fair use territory: >> Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment. It's even weaker than you think. It was im…

The dissent point out “non-competing” is a bit of a stretch as this affected contracts oracle had.

The dissent really made me think that, as the law stands, Google is in the wrong here, and what everyone is really trying to do is figure out how to allow copying / reimplementing APIs since that probably makes business / programming / innovation easier.

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

#613

I love how the Us supreme court judgements are written using low level terminology that most anyone can understand with little prior knowledge. Some countries use legal and complicated jargon that its hard to follow.

Supreme Court decisions are the next-best thing to black-letter law. It is important to clarify what the law has been decided to be, once and for all. Lower-court rulings have no shortage of legal jargon and terms of art with meanings that conflict with everyday meanings of those same words, because they're just part of the sausage making that is drafting and interpretation of the law. SCOTUS rulings can have these too, as the other responder indicated, but there's just fewer of them (and more clarifying language where necessary) because again, a SCOTUS ruling is a proclamation to the people, once and for all, of what the law has been settled to be.

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

#614
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.

Yeah, but Thomas said "The majority can not square it's fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable". Which is obviously false. A fair use analysis can -only- take place if the assumption is the code is copyrightable; if the majority had first decided the code was not copyrightable, fair use is immaterial. Thomas' argument, if followed, would either have led to this same…

If you read the whole dissent, it makes sense. He's saying that the fair-use analysis the majority used would render any kind of declaring code de facto not copyrightable, since the majority is essentially saying that the traits of declaring code make any implementation of it fair-use by default.

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

#615
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.

What does that even mean?

Algorithms and logical constructs like computer code aren't patentable under US law if that's what you're talking about.

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

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

The bigger story is Justice Thomas is saying Big Tech needs to be regulated like utilities.

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

#617

Earlier quoted context omitted.

and Amazon could talk to Oracle who "borrwed" the S3 API for their cloud storage.

S3 explicitly changed their license to allow copying the S3 API. I forget the year, ~2010? I was working an S3 at the time and it was a strongly debated decision. Google’s initial launch of their cloud storage copied not just the S3 API, but also the error codes.

I think the point is that if this case had gone the other way this kind of open licensing would happen a lot less. Companies would be obliged to enforce API copyright to protect themselves from loss of copyright (share holder value)

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

#618
post #556

Earlier quoted context omitted.

Had Justice Thomas' opinion prevailed, most everything within POSIX was originally copyright by AT&T USL as part of System V, and would be owned by the current holders of that intellectual property. Anyone using fork(), stat(), open(), or other basic parts of the UNIX development environment would be in violation. Those copyrights were purchased by Novell at some point, and I believe ended up with Attachmate. One wou…

> That is truly a nightmare scenario. Absolutely, but courts are supposed to interpret the law, not rule whichever way avoids nightmare scenarios. The risk of going too far in that direction (and this is by no means the first case in which SCOTUS c̶l̶e̶a̶r̶l̶y̶ may have rationalized a decision for pragmatic reasons) is that it makes the court more corruptible. I am glad the majority ruled this way, because I agree th…

If it reaches SCOTUS, it means the law is already ambiguous the way its written and that no one interpretation is obviously the correct one.

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

#619
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.

I'm not buying it. What you patent is a bunch of text that is clearly copyrightable.

If you patent a method how to organize APIs, that would be perfectly reasonable. In fact we have a bunch of patents like that for networking stuff.

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

#620
post #555
post #523

Hopefully this is a crack in the armor of the x86 monopoly - after all what is an instruction set but an "API for processors"? The novelty is in how you implement the instruction set , not the actual API that says "this instruction takes A and adds it to B", that is purely a matter of compatibility.

Who would willingly make a new x86 design these days? I would think this would crack ARM's control over their instruction set though. I can't imagine it'd be worth re-implementing literally the entire thing from scratch though when ARM will willingly sell you IP blocks, as opposed to Intel or ARM which will certainly not.

Zhaoxin Semiconductor, for one. Hygon licensed AMD's architecture as a starting point for their own stuff for another.

You're not going to find a lot in the west due to the patent issues (why follow that path when you're doomed to be sued into the ground), but there clearly is a desire to pursue x86 as an ISA (as opposed to going with ARM).

Post reply on HN