[pron]

> Would this apply to REST APIs too?

I wouldn't think so. REST APIs are just called APIs, but they're really communication protocols. As those don't have a fixed description (i.e. you can describe the same protocol in different words) -- unlike APIs -- they are not copyrightable.

For good or bad, APIs aren't just a description of how to do something. They are fixed. If you write down how files should be organized in a drawer, then that specific text might be copyrightable; the method itself isn't. APIs (though not protocols) are both a description and a fixed text.

[stdgy]

Perhaps I am missing your point, but aren't all APIs simply definitions that describe how to communicate to an underlying system?

An API, by itself (By definition of being an interface), does nothing. It's just a description of how one would ask the system to perform some function. It may be written in a way such that it describes what the system will do to produce a result. But that's merely descriptive, not functional.

[pron]

> aren't all APIs simply definitions

Isn't all text simply a description of something? But what can be copyrighted isn't the something, nor is it any description, but that particular text. A REST protocol isn't a specific text while an API is.

[stdgy]

All text is a description of something, but not all text is copyrightable. I would hold that an API is a textual definition of processes used to interact with a system. I don't think that kind of rote technical description is covered by copyright.

I guess I'm confused over what you refer to when you say REST protocol. I'm imagining a textual description of endpoints, arguments and expected return types. Just technical details. Maybe you're talking about the actual implementation?

[pron]

I didn't say all text was copyrightable; I said anything that isn't text -- or any other fixed form -- isn't. A REST protocol (i.e. a REST API) doesn't have a fixed form. You can describe the very same protocol using many different texts (i.e. documentation) -- something which you cannot do for an actual API, which is text. While each of those documentation texts may be copyrightable in itself (technical documentation is very much copyrightable), the REST protocol itself isn't. It is only a mechanism, whereas an API is indeed a mechanism, but it is also a text. Since it is a text, it might be copyrightable, and since a REST protocol isn't a fixed text -- it is certainly not.

[harshreality]

As far as I can tell, the fixed form of an API has only two purposes/aspects:

First, naming. The naming of things allows them to be used by programmers. You could replace every unique identifier with a random dictionary word and the API would still work, although nobody would want to use it.

Second, structure(/sequence/organization). The structure could be transformed arbitrarily with the constraint that the operational aspects continue to behave unchanged. The only possible impacts, then, are that one structure is easier to use than another, or performs better than another; those are functional (in the general sense, not in the programming sense) differences, therefore should not be copyrightable.

Not everything that is fixed is copyrightable. It has to have creative spark, and the creative spark cannot be in the service of functionality. (Arguably, if it's in the service of functionality it's not creative at all, even if it naïvely seems like it is, because such "creativity" is indistinguishable from advanced-enough soft-AI optimization methods, with either performance or A/B testing for usability as the metric)

[pron]

> Not everything that is fixed is copyrightable.

Right, but something that is not fixed -- like a REST protocol (aka "API"), which could be described by many different texts -- is not copyrightable even if APIs are. Being fixed isn't a sufficient condition, but it is a necessary one.

I'm not saying APIs should be copyrightable, just that their copyrightability (if they have it) doesn't transfer to REST protocols.

[BHSPitMonkey]

I think you're describing the client side of the API.

A way of looking at REST APIs in the context of this Oracle case would be to imagine a Stripe clone appearing with an identical API to Stripe's, to the point of being interoperable with existing Stripe client code/libraries. Could Stripe claim copyright over the way their API is designed in this situation? If Oracle gets its way, then perhaps.

[pron]

> Could Stripe claim copyright over the way their API is designed in this situation?

Oracle isn't trying to copyright the way their API is designed. They're trying to copyright the API. A REST protocol, unlike an API, isn't a text (or any fixed work). What isn't fixed can't be copyrighted, but it could possibly be patented (a way of doing something may be patented).

You can't copyright an idea, but you can copyright a text (or a photo, a video, or a recording). An API is a text; Stripe's protocol (or "API") isn't (though Stripe's specific documentation page describing their protocol is probably copyrighted).