Send a GET request to some_website.com/some_protocol to get back a jpg of a cat
I wrote it down, and thus it was "fixed in a tangible medium of expression". As I understand that requirement of the law that is all that is required.
If I just told you that verbally, and we did not write it down, record what I was saying via a mic, or anything else, then it would not be fixed. No one does protocols like that though.
What you have here is a particular description of a REST protocol that is fixed, and indeed, if it fulfills the other requirements of copyrightability, it could be copyrighted, and I wouldn't be allowed to, say, sell T-shirts with that sentence printed on them. But if you developed a protocol and I asked you what is the work that you have produced, that work wouldn't be that sentence, but the algorithm it describes.
The same applies to algorithms, BTW. If I write and publish an algorithm, it is possible that my paper and even the particular pseudocode I used is copyrighted, but that's not "the work" (of the algorithm) nor is it a part of it. That is why even though the paper is copyrighted, the algorithm itself is not, although it could perhaps be patented. As confusing as it may sound, in the US the situation is: the paper describing the algorithm is copyrighted, a program implementing the algorithm is copyrighted, the algorithm itself cannot be, but it can be patented.
Whether or not code APIs can be copyrighted, they are different from protocols just as programs are different from algorithms, as a certain fixed piece of text is certainly an important part of the work. That may not be a sufficient condition for copyright, but it is a necessary one.
If Oracle is right, copyright protects the "[not relevant to the case] GET [not relevant to the case] <base_url>/some_protocol [not relevant to the case]" and it would be copyright infringement.
Well really I'd probably need to have a few more APIs involved, such that I have a tree structure similar to classes, but the point stands.
All that this subdiscussion was discussing was whether or not REST APIs are fixed in a medium as required, they are.
No, because the fixed portions are too small to be copyrighted, and they're also not creative. Being a fixed expression is just one of many necessary conditions, not a sufficient one. Also, not every copying of a copyrighted work is an infringement.
> they are.
They most certainly are not. If you think REST protocols are like code APIs, you should be able to explain why algorithms are not copyrightable but programs are. The law already makes a distinction between those two, so you'll need to explain why that distinction does not apply for protocols vs. APIs.
> Being a fixed expression is just one of many necessary conditions
And yet it is the only one you raised, and the only one I responded to in this thread. You are moving the goal posts. If these posts were legal briefs the judge would say you have waived the rest of your arguments and I would have won (Waiving arguments being the legal equivalent to moving goalposts).
Because it is the difference between protocols and APIs, and why, regardless of the status of code APIs, protocols cannot be copyrighted. This is also the difference between programs and algorithms.
But you seem to have interpreted the necessary condition that a work must be fixed in order to be eligible for copyright as "any fixed portion of a work is copyrightable." This is untrue both because being fixed is necessary but insufficient for copyright, and because tiny portions of a work aren't works in themselves. Also, I have not claimed that anything that might be called an API and is fixed is necessarily copyrightable. I only said what is definitely not copyrighted. So no goalposts have been moved, you just misunderstood the necessary condition and my point: Protocols (like algorithms), unlike code APIs (and programs), aren't fixed, and so cannot be copyrighted regardless of anything else that may or may not be. That some tiny portions of a protocol might be fixed does not change the status of the work.
