[sambeau]

  "declaring code and the structure, sequence, and organization of 
   the API packages are entitled to copyright protection." 

Would this apply to REST APIs too?

Someone needs to explain to them that that would be like being able to copyright how files are organised in a drawer, how books are organised on shelves in a Library, how a book is indexed, how departments in a company are named, how streets are numbered, how campus room numbers relate to floors and buildings, roads, flights, cashier tickets, ...

[HillRat]

[T]hat would be like being able to copyright ... how books are organised on shelves in a Library

Probably not the best example to give, since the Dewey Decimal System is actually a copyrighted product(http://cocatalog.loc.gov/cgi-bin/Pwebrecon.cgi?v1=11&ti=1,11...). Similar to how the AMA has copyrighted the ICD codes.

I do wonder if using identical function names, but different argument names, would be sufficient to escape infringement.

[russell_h]

I'm sure that would be found to be a derivative work.

The entire thing is derived from this doctrine: http://en.wikipedia.org/wiki/Structure,_sequence_and_organiz...

[abhorrence]

So speaking of how books are organized on the shelves at many libraries... http://en.wikipedia.org/wiki/Dewey_Decimal_Classification

[higherpurpose]

I think they did use that explanation at the Appeals Court, which was actually the one that didn't buy it and overturned Alsup's ruling:

https://www.techdirt.com/articles/20140509/10133727178/appea...

Mike's opinion today:

https://www.techdirt.com/articles/20150526/16550931121/obama...

[rayiner]

There is a museum in Philadelphia (the Barnes Foundation), which houses a collection meticulously arranged by Albert Barnes over the course of his life. I think that arrangement is itself a work of art entitled to copyright protection.

[AnthonyMouse]

What is that copyright protection supposed to look like?

There are clearly things that combine function and expression. Essentially all computer programs do this. But if the expressive part can be copyrighted and the functional part can't then the combined thing has to be separated into what can be copyrighted and what cannot.

The thing about APIs is that by their nature they're purely functional. There is no expressive component that can be extracted and changed without changing the function itself. Even the name is functional because that string of characters is what the compiler uses to match invocations of the function with its definition.

Try a mirror image analogy. First, a popular lock manufacturer encodes the mechanical specification for its lock cylinder as music, and it turns out to have a pleasing sound. When the sound hits the top 40 they can have all the music royalties, but that doesn't mean they can copyright the lock itself as an expression of the music.

Second, a popular lock manufacturer starts selling locks which will only open if the key blanks are encoded with a particular sequence of musical notes composed by a human artist, and asserts that such key blanks are copyrighted. It doesn't matter how expressive the music is when you play it on a piano, or whether it would be copyrightable if it was reproduced as sheet music rather than key blanks. If you specify it as an interface then it can't be copyrighted in that context because the functional interface demands that specific expression.

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

[fixermark]

I suspect a subset of that has, in fact, been tried (and the rest only hasn't been tried because of obvious prior art).