I noticed that comment too early on. Breyer's opinion comes pretty close to saying "it's at best 'thin copyright'" but the fact that it's explicitly disclaimed makes me think that this is to some extent a compromise position: rather than arguing about whether SSO is copyrightable and risk a bigger split, just concede it because the fair use is sufficient here.
That's exactly why fair use exists. A teacher showing a movie in class is fair use, editing a clip for memes is fair use, making backups is fair use. APIs are copyrightable, but independent implementations are fair use, this is an outright win IMO. SSO might or might not be copyrightable in all of these cases, but we have certainty with fair use for specific cases.
In deference to OP, the question was never "Are APIs copyrightable?" The question was is what Google did in taking header information and doing their own implementation fair use, and it's unquestionably good now that the SCOTUS said this is fair use. Make sure to actually do your own implementation though.
Sun/Oracle didn't want to fragment Java, they copyrighted the language spec, and provided the JVM under SCSL before GPL. Java isn't fragmented, Sun/Oracle got what they wanted.
When SCOTUS accepted the cert petition, it granted two questions: a) are APIs copyrightable and b) if they are, is Google's use fair. Breyer's opinion explicitly lays this out, but doesn't explore API copyrightability any further than "assume it is for this discussion."
Playing Kremlinology here, it feels like Breyer originally had an opinion that explained that APIs were not copyrightable, but sacrificed that section of the opinion to build a 6-2 majority. It's really weird that the opinions took so long to come out for how simple they end up being--why is this coming it in early April instead of early/mid February if it's written like this? My supposition is that there was a much more sharply divided court, running a 3-3-2 or 4-2-2 opinion, and by dropping the discussion of whether or not the APIs were copyrightable and instead saying "it's at best thin copyright" (i.e., it's copyrightable but good luck ever winning infringement) the opinions collapsed down into a more simple outcome. One thing's for sure: this is the case I'm most interested in finding out all the backroom discussions that went on here.
Thomas/Alito get wrong that computer programs are an expression in every form, not invention in any way. Patent law does this too I'd reckon. They then refuse to do the work it takes to determine fair use in this field, which Alsup (and this court) did very well. Open source code being copyright (or copyleft et al) fits in perfectly well with this fair use analysis.
From the market effect part of the opinion, it's Oracle who should be worried if they're different enough from AWS or maybe not if learning any widely-used API means it's a loss if not copied. The WINEs of the world should be safe, Microsoft was never going to bring Win32 or DirectX to Linux.
In my cursory readings about merger doctrine, it's been around for decades, but hasn't been widely adopted by courts, and the justices by little surprise couldn't agree (3-3 or 4-2). The open source lawyers love it, but that means little. Fair use is about as good as it was ever really going to get for the foreseeable future. The industry is just going to have to settle for this or maybe pool it's copyrights like OIN does for patents.
Ops, I meant to say s/APIs/software projects/ are copyrightable, as the question of copyrightable APIs within software projects was sidestepped by the court.
It's a lot easier to say what Google did was fair use than decide where to draw the line on where an API is in a software project and whether it is copyrightable or not.
