> > So far you've given no examples as to why you think that literal copying of SSO of a clean room code library reimplementation isn't equivalent to literal copying of SSO of a clean room REST server reimplementation.
A reimplementation of a protocol will, by definition, have another implementation that has SSO copyright over the API.
> A reimplementation of a protocol will, by definition, have another implementation that has SSO copyright over the API.
Same for an algorithm.
What you're saying now is this: forget the protocol, which isn't a copyrighted work, let's look at some program that implement the protocol. If you reimplement you will violate the program's copyright. It doesn't work like that because your reimplementation isn't derived from that program. You probably don't even have any direct access to the program's executable, let alone its source. Think of two reporters covering some news event. The news event itself isn't copyrighted, but each article is. Still, because they're both reporting the same event, they will have the same quotes. Still, they're not infringing on each other because their source wasn't the other article but something (the event) which isn't copyrightable. If your source is something that isn't copyrighted, you can copy it even if some copyrighted work copies it as well.
And again, your argument would work to explain why implementing an algorithm is a copyright violation. It isn't, so you can know your argument is wrong.
How does your argument allow for a clean room developed code library to be infringing on what it re-implements based on the SSO copyright of the API names?
First, I am not making any argument whatsoever about the copyrightability of code APIs, only that no matter what their status is, protocols cannot be copyrighted. Second, software source code is certainly copyrighted work (and that's why discussions of SSO are relevant in the first place), and if you're referring to Android, both sides agree that Google copied 11,500 lines of text -- about 200 pages -- verbatim from that work. Whether or not, despite the copyrightability of software, that copying is an infringement depends on much more nuanced portions of copyright law. You may want to read the court papers or even the Wikipedia entry on that case if you want to be certain on the matters of fact.
The 11,500 lines are just what's necessary for API compatibility. 'public class String' 'import java.lang.Object', etc. Both sides also agree that this was totally clean roomed. The verbatim copying here is just the SSO of the API.
That's the interesting subject of this case. But the fact is that 200 pages of a copyrighted work were copied, and there is an interesting legal question as to whether that copying does, indeed, constitute copyright infringement (i.e. whether it's protected and, if so, whether it's fair use). That Google intentionally did not try or want to achieve compatibility is another important detail that the court focused on, as well as the fact that they did all that for commercial purposes (here we're actually seeing that copyright has three stages: 1. determine whether the work is of a nature and form that is copyrighted. 2. determine what kinds of copying are protected. 3. determine whether protected copying was fair use.)
None of this, however, is relevant to discussions of works that are not copyrighted in the first place, as they do not even satisfy the most basic necessary conditions, like algorithms and protocols, of which REST "APIs" are instances. The case is about stages 2 and 3; they fail at stage 1. Partial, translated, complete, verbatim etc. copies of non-copyrighted works is outside the bounds of copyright law, and have nothing whatsoever to do with this case.
A reimplementation of a protocol will, by definition, have another implementation that has SSO copyright over the API.