Roberts: Let's say someone copies the headings in your brief and they copy the organization in your brief, which sections you put first and how you organize them. Would your argument say that's perfectly fine so long as they write their own text?
Google's lawyer didn't really have a great response to that. He said "no but computer programs are different" but really didn't provide a compelling argument for why.
Can designing an API be a different job from implementing a design? If so, then maybe the work product of the designer is copyrightable on its own.
meat.beef
.. BeefAndPotatos
.. BeefAndCabbage
fish.cod
.. CodWithPeas
.. CodWithChips
This is literally an exact representation of what an API looks like. You go to a recipe and you execute it expecting a result. And you get one, the implementation of it is up to the author of the book.
An API is more like a set of mechanical gears that just happen to be shaped a little like words. If I change the names of things in a table of contents to synonyms, I can still use it to find what I am looking for. If I change the names of things my implementation of an API, it no longer functions as an interface for the things that worked with it previously.
An API, despite looking like works, is not a literary expression of a process, it is a machine for executing the process itself, and its shape, is essential to its function.
Suppose then, than I publish the book explicitly as a replacement for the other book. Not as in "this is the same" but as in "if you find a reference to a chapter in the other book, you can also just look here". Would that be copyright infringement?
What happens if I do this to a technical document (think a 3gppp spec) where the TOC runs for 10 pages for a 300 page document, with headings nested 5 deep?
If this argument is valid, it means that APIs are not copyrightable, they are patentable, because copyright is only for expressions of ideas, not for machines; patents are what apply to machines. And Oracle has already lost on the question of patent infringement in this case (back in 2015, IIRC).
Processes, whether they're made up of abstract concepts or not are patentable[0]:
"Processes are patentable under the U.S. Patent Act if they meet certain criteria. A process patent is a form of utility patent that covers methods of changing the functionality or characteristics of a material during a particular use. The patent-holder is granted exclusive protections and rights to that process for 20 years.
When one patents a business method or, in some cases, a computer program, this is a form of patenting a process. It's now possible to patent subscription-based services, targeted advertising networks, online auction sites, portal sites, email systems, and even discussion forums.
As our society has evolved, intellectual property (IP) issues have evolved along with it. What constitutes IP these days is so much more than the newest machine or physical invention. Today we have genetically modified seeds, new strands of DNA, computer software, chemical formulae, and more. As these issues become more complex, patent law has to evolve to address new concerns. For example, one can now patent business models and software through the U.S. Patent and Trademark Office (USPTO)."
That is incorrect.
> . If I change the names of things in a table of contents to synonyms, I can still use it to find what I am looking for.
If I change the name to be something you cannot refer to, you cannot.
> If I change the names of things my implementation of an API, it no longer functions as an interface for the things that worked with it previously.
This is irrelevant to the API. The API does not make a guarantee about functionality. If I have an endpoint /foo and later /foo increments an internal counter by 1, the API remains unchanged. Documentation supplements and is not part of the API per se, which is an important distinction. The fact that Documentation and an API are being referred to in conjunction, was a failure that software will suffer for more than the lifetime of my children.
The only purpose of an API is providing mechanical access to functionality.