What about the legal arguments made makes a distinction between "code" and "REST" APIs like you're doing? I've been reading the decisions and haven't seen anything like that.

Me neither and I even used ctrl-f. It seems the impact could taint anything loosly called an API. I make an API that is loosly linked to three competing API around then same data. Some of this leads to each of us suing the others.

Anyone can sue anyone over anything right now. The whole purpose of the court system is not to blindly apply any ruling to any other loosely coupled event, especially over the use of borrowed words, but to focus on the nuances and peculiarities of each case laid in front of it. That's what the courts are for, and why human judges and juries pass judgment rather than algorithms.

The legal arguments in any case pertain only to that case, but it is a necessary condition for a work to be covered by copyright is that it "fixed in a tangible medium of expression"[1], i.e. that there is some fixed text (or a picture, or an audio or video recording) that is the work (although once it exists, derivatives are also protected). This is true for a code API, but not for a protocol.

[1]: https://www.law.cornell.edu/wex/fixed_in_a_tangible_medium_o...

The moment your REST API includes any kind of validating schema, that will be the copyrightable "code API".

That schema could be copyrighted, but not equivalent ones, because the protocol isn't its schema. That's like saying that an algorithm can be "fixed" by writing a program that performs it, but if you do that, only the program (and its derivations) are protected, not the algorithm (the algorithms can be patented but not copyrighted). A program (including its code API) is a piece of text, and then its derivations are covered. A protocol, like an algorithm, is an idea that could be made into a piece of text, but the US copyright code explicitly states that that idea itself is not copyrighted.

For example, you and I could go to a sporting event and write down a description of it. Both of our descriptions are copyrighted, and any derivation of mine or yours are protected, but your description is not a violation of mine and vice versa, and neither is any other description by someone who saw the event but didn't derive her description from mine or yours.

Similarly for software, BTW. If you look at what a program does and then write a new program that does the same thing -- that's not copyright infringement, as you didn't derive your program from the fixed work of the original.

This whole case is about the "Structure, Sequence, and Organization" of the API. It's the abstract collection of API entry points, not any specific implementations. Yes, it's openly in conflict of previous definitions of copyright.

Yet again, I am not talking about whether code API is copyrighted or not; I'm just saying that regardless of the ruling, protocols aren't copyrighted. I said nothing about a particular implementation, but a code API, unlike a REST protocol, is a fixed expression. If that fixed expression is copyrighted, then what the copyright protects is a whole other discussion. Harry Potter is a fixed expression, but once applied, its copyright doesn't protect just a particular sequence of words, but various derivations of it as well (like translations). As to whether or not what this case is about is "in conflict with previous definitions of copyright," I have no opinion of the matter.

Yet again, the distinction you're making isn't one rooted in these rulings. The combo of striking down de minimus and entertaining that APIs can have copyright applies equally to REST, unless you can come up with a way for a server to not have the endpoint string literals in their code.

What you're describing is "how it should be", not the current state of the world.

Why would the distinction be rooted in the ruling? If there are, say, three conditions for copyrightability, and a work satisfies the first to but the third is unclear, then why would the ruling in that particular case even mention works that don't satisfy the first condition?

> applies equally to REST

Nope. This is a case about a verbatim copy of about two hundred pages of text (11,500 lines). There are interesting legal questions about whether or not the text is copyrighted (because software copyright is more limited than some other forms of copyright), but REST protocols aren't a fixed piece of text to begin with. They are just not works that copyright law deals with.

> unless you can come up with a way for a server to not have the endpoint string literals in their code.

There is no problem with string literals. None of the words in Harry Potter is copyrighted, and most books, or program with string literals, containing all of them don't infringe on Harry Potter's copyright.

How do you define, implement, or use a REST endpoint, without verbatim using the endpoint names?

And the length of the verbatim copying doesn't matter, because these same ruling are rejecting de minimus claims.

Like please look up the legal rulings here. They're using different tests than you normally see with copyright. You're spreading a lot of misinformation here.

https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...

> How do you define, implement, or use a REST endpoint, without verbatim using the endpoint names?

You can use names verbatim. You can write a book with the names "Harry" and "Ron" and even "Dumbledore" without violating Harry Potter's copyright. In fact, if you take Harry Potter, translate it to French and change all the names so that not a single word is copied verbatim, that is a copyright violation. But regardless of what you copy, in order for a work to be protected by copyright at all, it must be some fixed piece of text (or an image, or an audio/video recording). REST protocols aren't.

> They're using different tests than you normally see with copyright. You're spreading a lot of misinformation here.

I'm not talking about this case, but about why this case doesn't apply -- whatever the result -- to REST protocols. What you linked to is about the following: Once a work is protected by copyright, what kind of derivations are disallowed? For example, Harry Potter is copyrighted, but I don't make a verbatim copy but a French translation. Is that protected or not? What about basic plot lines? But any such discussions are irrelevant to algorithms and protocols, which are not copyrightable works to begin with. There is also a question about code APIs, because there are other necessary conditions for copyright, but there's no question about protocols, as they don't satisfy the first condition -- there is no fixed work at all. Anyone who says this could affect protocols is spreading misinformation. Whether code APIs are copyrighted or not, protocols, like algorithms, aren't.

> You can use names verbatim.

If this ruling passes the Supreme Court, you can't anymore in the context of software. That's the whole point of what has people up in arms. These points of copyright are left to the courts, and they can change the rules if they see fit.

I really don't understand your outright refusal to read the ruling or even the damn wiki page.

I won't be responding to you anymore until you make a good faith effort.

> If this ruling passes the Supreme Court, you can't anymore in the context of software.

This is simply and totally untrue; it is nothing but uninformed panic. If you think otherwise, please point me to what makes you think that. In any event, a protocol is not a copyrightable work regardless of the result of this case, for reasons that have nothing at all to do with the discussion about the copyrightability of code APIs. Code APIs satisfy the basic necessary conditions for copyright, and there is debate over more nuanced ones. Protocols, like REST APIs, don't even satisfy the first requirement of copyright law -- they are not a work fixed in any tangible medium -- so they are completely irrelevant. Again, programs are copyrighted, algorithms are not -- even if the algorithms contain some fixed strings in them. If you don't understand that distinction, there is really no point in going further.

> I really don't understand your outright refusal to read the ruling or even the damn wiki page.

I have read pretty much everything written about this case, and the actual rulings. But understanding the basic tenets of copyright law is necessary in order to make sense of what you read.

The question of SSO is, once a work is copyrighted, is its SSO protected similarly to translation? For example, Harry Potter is copyrighted; if I copy the basic structure from Harry Potter is that an infringement? That's the subject of the discussion, which takes as a given that software is copyrighted. In the case of protocols -- like in the case of algorithms -- there is no work from the perspective of copyright law, so questions of what transformations of the work could constitute infringement are irrelevant.

I think that many people don't understand that copyright works like a two-stage process. First there needs to be a work satisfying some requirement to which copyright applies; second, once such a work exists, different kinds of deriving other works from it are determined to be infringing or not. This court case is about the second part, as it is recognized that software is a copyrighted work, and all discussions about the second step (like SSO) are under the assumption that the first step is OK. Protocols and algorithms don't even pass the first step, so any discusssion about the second does not concern them.

Example: I decide to to cleanroom reimplement Google's search REST API. Google hits me with a lawsuit for violating the SSO of the REST API as implemented by the Google Web Services executable and source.

Any protocol worth protecting will have a tangible expression they can point to whether it be code or documentation. The need for a tangible expression doesn't make a practical difference in the de facto copyright of the REST API.

You keep using literary examples even though SSO treats software differently. I will be ignoring any literary allusions from now on, please use actual case law about software.

> Google hits me with a lawsuit for violating the SSO of the REST API as implemented by the Google Web Services executable and source.

No, it doesn't work like that, just as if you implement an algorithm that's at the core of another program (without deriving your code from that other program) you don't infringe on the other program's copyright.

> Any protocol worth protecting will have a tangible expression they can point to whether it be code or documentation.

I don't know how to explain it any better than I have, so I'll mention yet again that your point applies to algorithms, and yet they are not copyrightable.

If you have a paper describing an algorithm, the paper is copyrighted, but the algorithm it describes is not. If you copy or translate the paper you may be in violation of its copyright; if you implement the algorithm described -- you are not. Same goes for recipe books, by the way. If you copy the recipe you could be in violation; if you implement it -- i.e. cook according to it -- you are not.

That the program is a fixed expression that manifests the algorithm or protocol is irrelevant. You are not allowed to infringe on the program's copyright, but the protocol or algorithm it describes are not copyrighted to begin with.

> please use actual case law about software.

Protocols are not software. SSO is irrelevant to them. Their relationship to software is the same as that of algorithms to software, and SSO doesn't apply to algorithms either, because they are not copyrighted works.

Any argument you'd like to make why this case has any bearing on protocols would also need to be compatible with the fact that programs are copyrighted while algorithms are not. If you make an argument that would also cover algorithms you can know you've made a wrong turn somewhere.

Neither my example nor the facts of Oracle v Google are dependent on copying of algorithms due to both being clean room reimplementations with the minimum verbatim copying needed for API compatibility.

Since you obviously aren't interested in a good faith discussion that doesn't involve you adding strawmen, I shall bid you good day.

I think you intentionally misunderstand my point or we're completely talking past each other. This case isn't about protocols just as much as it isn't about algorithms. The only relationship between this case and protocols is that in recent years some have taken to calling them APIs. No matter what the result of this case is, it will have no effect on protocols, just as it will have no effect on algorithms, or on bananas. From the perspective of copyright laws, these things are completely different categories, no matter what mental connections you can draw between them. I only bring up algorithm to help you understand that even though algorithms and programs have a similar relationship to that between protocols and code APIs, copyright law is not concerned with algorithms although it is with programs, so that same connection between protocols and code APIs is equally irrelevant to copyright law. But if you're not able to understand why programs are copyrighted but not algorithms, you won't be able to understand why code APIs could possibly be copyrighted but definitely not protocols.

> if you're not able to understand why programs are copyrighted but not algorithms, you won't be able to understand why code APIs could possibly be copyrighted but definitely not protocols.

The lack of copyright protection for algorithms was never in question here until you started bringing it up.

I said good day.

Protocols aren't copyrighted regardless of whether code APIs are for the same reason algorithms are not copyrighted even though programs are. Any argument you make that if APIs are copyrighted then so are protocols would also lead you to conclude that since programs are copyrighted, then so are algorithms. The latter is untrue, and so is the former.

For example, you said above that a program implementing a protocol becomes its fixed expression, and so every implementation of the protocol would violate that program's copyright. Well, that same argument can be applied to incorrectly conclude that algorithms are copyrighted as well. Same goes for an argument about certain fixed strings. I've explained directly why those arguments don't work, but if you don't understand the explanation, perhaps seeing that your argument would also apply for algorithms make you realize you've made a bad turn somewhere. To claim that this case affects protocols you'll need an argument that cannot be used to claim algorithms are copyrighted, too. If it can be -- it's a wrong argument.

> Same goes for an argument about certain fixed strings.

The fact that you don't see the difference between copying an abstract idea like an algorithm compared to literal copying of the names necessary for the structure, sequence, and organization of the API belies your ignorance wrt to copyright.

One involves no "this piece of the original is listed here in the reimplementation, verbatim" and the other does.

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.

Do you understand SSO arguments?

> The fact that you don't see the difference between copying an abstract idea like an algorithm compared to literal copying of the names

An algorithm can contain literal names and you're allowed to copy them. You need to understand that what you're allowed to copy or not is the second step after having established that the work under discussion is a fixed expression (and satisfies all other necessary conditions).

> necessary for the structure, sequence, and organization of the API belies your ignorance wrt to copyright.

SSO applies after it's established that a work is a copyrighted fixed expression -- it's the second step; it does not, and cannot, establish that things that are not works are. The SSO of a non-copyrightable thing, like an algorithm or a protocol is not protected.

> One involves no "this piece of the original is listed here in the reimplementation, verbatim" and the other does.

What you're allowed to copy or not of a copyrighted work is irrelevant to what you're allowed to copy, or not, of a non-copyrighted work. You are allowed to copy, verbatim, anything that's copyable from non-copyrighted works.

For example, if I tell you an original story at a bar, the story is not copyrighted. Therefore, you are clearly allowed to repeat it verbatim, write it down etc. It's not that copying verbatim, SSO, translations of anything is not allowed; it's that doing those things for copyrighted works might not be allowed. The action matters only after the work is determined to be copyrighted. Another example: distributing photos of copyrighted images might be an infringement. Your face, if you show it in public, isn't a copyrighted work. Do you think that "the SSO argument" states that the SSO of your face is protected?

> Do you understand SSO arguments?

Yeah, but clearly you don't. SSO, like translation, is one of the kinds of protected derivations of a copyrighted work. It is not used to define what is or isn't a work. Protocols are not copyrighted, and so their translation and SSO are not protected. Programs are copyrighted works, and so the argument goes that their SSO is protected.

Once more, two steps: first, is it a work that satisfies the necessary conditions for copyright (yes for programs, no for algorithms/protocols); second, if the first part holds, what kinds of copies and derivations are allowed (SSO, translation, verbatim copies of small parts etc)?

You don't need to concern yourself with SSO or verbatim copies until you've established that the work is copyrighted. If it's not -- like in the case of an algorithm or a protocol -- the argument is completely irrelevant.

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

I think you're confusing the "fixed text" requirement with the question of whether the Java language constrains the declaration of an API to a unique textual representation. The latter is more or less true, but the declaration that the compiler ingests isn't the only way to describe a Java API in writing.

The two things are completely separate, but having a fixed expression is a necessary requirement. If I go to a sporting event and describe it in an article, then my article is copyrighted, and derivations of it are protected (translations etc.). But there could also be other people who wrote different original articles describing the same event, each of them is copyrighted, but none a derivation of the other or of mine. But the fact that all of those articles are different descriptions of the same match doesn't mean they're not all copyrighted, and that their derivations aren't protected. Each of those articles is a fixed expression, but the game itself isn't.

There's obviously code implementing the REST protocol that's copywritten.

How is a rest api document any less tangible than a source code document?

What piece of text that is the REST protocol?

Here is a simple REST protocol:

    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.

They are the same thing. In time this should become apparent to you.

A story I tell you in a bar and a written story may seem like the same thing to you, but one of them is copyrighted and the other isn't. A feature that may seem incidental to you is an essential one to copyright law. To copyright law it matter a great deal exactly how some expression is made, and how it is fixed to some recording medium. In particular, it requires that there exists some particular piece of text that can be called the work. This just doesn't exist for a protocol (there are many original texts that could describe the protocol), but it does exist for a code API.

How is there a difference here between "code APIs" and "rest APIs"? Both are simply interfaces which allow two pieces of code to talk to each other, the only difference is the protocol used (HTTP vs the platform's ABI)

Because copyright law doesn't care just about the purpose of a creative work, but also about its precise form and medium of expression. Why? That's a whole other discussion.