A book about the API would be fair use if the copyright holder allowed it. For quite a long time, PeopleSoft had a policy of not allowing insiders to write books about PeopleSoft’s software; once it became ubiquitous, the policy changed. The software was only marketed to large businesses who had no interest in violating the licensing agreement for the software they licensed at considerable cost; no consultants or employees would want to risk being sued either. Was this a bad thing, that it was not made “free for the world” ? No, it never would have been developed if it could not have been successfully marketed and sold.
Header files are source code and are therefore copyrightable.
Source code is copyrightable.
All of JimRob’s source code is copyrightable. Source files, header files, all of it.
Say FR developed, for their own use in the development of the FR site, a library, mylib.so and a header file, mylib.h which is what they compile with their other source files to be able to call the functions in mylib.so - this is an API.
Say JimRob lets one of his friends publish a book about his API library because he is so proud of it; he grants his friend a license to include the header files in his book as long as he includes the complete listing; right in the listing of the header file is a copyright notice.
An appendix is then included in the book containing the complete listing of the header file used to link with the API library. No source for the library code, just the header source with all the function declarations, etc.
Now we’re mired in First Sale Doctrine, which is arguable as to whether JR would have lost control. But guess what, since the entire book itself is copyrighted by the author - a software developer who copies code out of it to use in their own software would be infringing at least on the copyright of the book’s author.
You could read all about it in the book and refer to the listing to understand all the explanations in the book, then write your own library - from scratch - that worked using the same ideas, algorithms, etc., and you would not be infringing. You didn’t copy the header file, you did your own thing that was similar.
You would be infringing, however, if you read the book then:
a) wrote your own version of the FR API library based on the header file, then
b) created your own mylib.h file on your computer and typed into it the full header file from the listing in the appendix in the book, then
c) distributed the library you made along with the header source you copied out of the book.
You would have copied part of the copyrighted work and distributed your copy without permission.
I’ve worked for a software company, as well as many clients and employers, writing custom source code for them. Never ever once did I ever dream of copying source code that I wrote or anyone else at the client wrote or any code that I saw while at the client, let alone copy the source code and actually using it in any situation other than for that client or employer.
The only time I’ve ever copied code out of a book and compiled it was Peter Norton’s Assembly language book from decades ago as a tutorial for myself when I was just starting to program. Which was exactly what the book was intended for; it was a complete example of an assembler program that would read and display disk blocks, as I recall. I did not make any distributions of the tutorial copy I created.
For the lazy, it may be tempting to copy stuff. And the opensource folks have so much effort tied up in Java-based things they’ve written. I knew it was turning yucky when the whole mountain of libraries started to be added on, it was just too tempting to use that stuff.
As far as patentability, I say, hogwash, software is nothing but math, essentially, which was always supposed to not be patentable. That being said, when other countries steal things, reverse engineer them then sell their own knockoffs, that ain’t right. The solutions start with not selling high tech things to them.
But copyright applies to all source code; header files are source code.
Think about it; if I simply don’t use headers and put all code in the .c files, redundantly declaring as needed in each one, the “can’t be copyrighted” argument is gone.
Years ago when I used cobol, assembler, scripts - they all have some sort of include, copybook, etc. They were all copyrighted. There is no “open season” on copying source code that happens to be in include files.
Whether source code is copyrightable has nothing to do with whether it declares a functions or defines them, what is copyrightable is source code, because it all is authored work; someone wrote it. I know there are all sorts of books describing the APIs out there, but google’s problem is that at the end of their development, since they wrote their libraries according to the header files - they need to violate the copyright on the header files in order to distribute the header files themselves. If the API was not under the same opensource agreement as the Java language itself, they should have not used the libraries, but made a new API of their own design - then they would not be using the header files. Google could have used similar ideas and concepts, just changed the structure to a significant degree by making fairly straightforward design choice changes, and changed all the names of things, and they would be completey ok on copyright. The only available recourse for Oracle would have been patents, because - like you say - ideas and concepts are not copyrightable. As long the APIs were either not patented, or the patents were designed around (not that difficult for anything but “exotic” algorithms which I doubt there were any), Google would have been good to go and the issue would never have gotten off the ground.
This is what Google has to say about your argument - they are responding to a question by the judge - likely the last brief of the trial. Note that they quote both relevant cases to their point and the copyright law relevant to the point. Your feelings aside - this is what the law says.
“Because aspects of a computer program that are functionally required for compatibility are not copyrightable, it does not matter what the defendant does with them. Even if the defendant’s product is not compatible with the plaintiff’s product, the plaintiff still cannot assert infringement based only on the copying of unprotected elements. “The protection established by the Copyright Act for original works of authorship does not extend to the ideas underlying a work or to the functional or factual aspects of the work.” Sega, 977 F.2d at 1524 (emphasis added) (citing 17 U.S.C. § 102(b)). A “party claiming infringement may place no reliance upon any similarity in expression resulting from unprotectable elements.” Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1446 (9th Cir. 1994) (quotation marks and citation omitted; emphasis in original). Thus, because the SSO of the 37 API packages is functionally required for compatibility, Google was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.”