It was a little more nuance than that. Oracle was hoping SCOTUS would rule that API Structure, sequence and organization are copyrightable - the court sidestepped that question altogether by ruling that if APIs are copyrightable[1], the case fell under fair use. So the pre-existing case law holds (broadly, it's still fine to re-implement APIs - like s3 - for compatibility since SCOTUS chose not to weigh in on it in Google v. Oracle).

1. Breyer's majority statement presupposes API's are copyrightable, without declaring it or offering any kind of test on whats acceptable.

> So the pre-existing case law holds (broadly, it's still fine to re-implement APIs - like s3 - for compatibility since SCOTUS chose not to weigh in on it in Google v. Oracle).

There is no clear preexisting national case law on API copyrightability, and it is unclear how other, more general, case law would apply to APIs categorically (or even if it would apply a categorical copyrightable-or-not rule), so, no, its not “ok”, its indeterminant.

You are right there is no single national case that clearly ruled in either way, but the status quo is that it's de facto ok. Adjacent case law made white room reverse engineering & API re-implementation "ok" de jure, which is why most storage vendors - including very large ones - are confident enough to implement the S3 protocol without securing a license from Amazon first.

Edit: none of the large companies (except Oracle) are foolish enough to pursue a rule that declares APIs as falling under copyright because they all do it. In Google v. Oracle, Microsoft files briefs support both sides after seemingly changing their mind. In lower courts, they submitted an amicus brief supporting Oracle, then when it got to SCOTUS, they filed one supporting Google, stating how disastrous it would be to the entire industry.