APIs and most code is copyrightable, they are original works of authorship fixed in a tangible medium, all that is required by he Copyright Act of 1976. It doesn't look like either party in this case claimed the code was not eligible for copyright either
If they shouldn't be copyrightable because the world would be better off, interoperability between business is harmed, it is up to congress to change the law. Historically legislation like this harms smaller companies mostly, larger companies can better afford to deal with the requirement to license or the cost/work required to stick to fair use or litigate over it, so the larger companies that can afford to lobby to change the law aren't going to want them changed.
This case certainly sets precedent that API re-implementation can be fair use, not that it always is. Fair use is very fact specific, based on a four part test where having one part in favor can be fair use, and having three parts in your favor can still be infringement. A future case with products that would have a more substantial effect on the market of the original work, or had more of the original work reused than was strictly necessary could very well be infringement. With regards to "the amount and substantiality of the portion used" in this case less than 1% of the original code was copied just measuring the lines of code. Substantiality is harder to put a number on, but arguably it was only a small portion of the original product. This is a very low and for many other APIs a more substantial portion would need to be copied to be useful. The precedential value of this case is unclear without either the law changing, or further litigation.
How often does the API itself exceed the level of creativity of uncopyrightable plain lists of facts? It's not clear to me that it should be considered copyrightable on its own, especially with the fact that copyright explicitly do not cover functional elements. The declarations only instructs you on how to interact with the actual code, and AFAICT rarely add any creative height on top of what's in the main source code.
If presence and order of keywords was sufficient, such legal precedence would create collateral damage at levels that is beyond absurd - outside of software, this would extend to atypical calendar formats, plenty of paper forms, automatic telephone voice menus, map projections, and so much more. Calling it "destructive" wouldn't suffice. Entire industries would be leveled by uncooperative rent seekers that hold old copyrights.
The threshold of originality is extremely low for a work to be considered a work of authorship. From the linked decision, " a work is “original” if it is “independently created by the author” and “possesses at least some minimal degree of creativity.” Feist Publications, Inc. v. Rural Telephone Service Co., 499 U. S. 340, 345 (1991). The lines of declaring code in the Java platform readily satisfy this “extremely low” threshold. "
Paper forms are often protected by copyright, as long as they have creative non functional elements. And they are licensed much like stock photos in some industries.
There would be some APIs or code that only contain functional elements and aren't eligible for copyright protection, but in most cases there is a substantial amount that is not only functional.
Copyright protects works fixed in a physical media, not the underlying idea. Many people can create similar works based on the same underlying ideas. Like with a map projection a specific implementation can be protected by copyright. But the idea of a map projection where a constant bearing in the real world corresponds to a straight line on a map cannot be protected by copyright, someone else could create their own version that does the same thing without infringement.
Copyright only protects against copying, not against independent creation of the same work. With something like a calendar, or in some cases an API that only has a few creative elements, multiple people could make the same choices and create the exact same thing without there being any infringement.
Re forms: I did primarily mean rather simple ones (like say attendance forms), but there's a bigger argument here;
This type of API copyright would post likely not just mean the paper form is under copyright protection, but that the software to OCR scan it and parse it would also likewise be protected - as it is an ordered series of keywords with types, etc. It would then be a license infringement to parse forms without a license.
Independent creation is legal defense, not a cause for dismissal of a suit. You need to prove it - which becomes harder if they can argue you saw their work first and imitated theirs.
There's precedence where people have created their own works from scratch and held to be infringing because they mimicked an existing work too closely (like one case of a photo of a red London bus), and in civil copyright lawsuits the other copyright holder only needs to show its likely, which may reduce to showing you knew their work existed.
If they shouldn't be copyrightable because the world would be better off, interoperability between business is harmed, it is up to congress to change the law. Historically legislation like this harms smaller companies mostly, larger companies can better afford to deal with the requirement to license or the cost/work required to stick to fair use or litigate over it, so the larger companies that can afford to lobby to change the law aren't going to want them changed.
This case certainly sets precedent that API re-implementation can be fair use, not that it always is. Fair use is very fact specific, based on a four part test where having one part in favor can be fair use, and having three parts in your favor can still be infringement. A future case with products that would have a more substantial effect on the market of the original work, or had more of the original work reused than was strictly necessary could very well be infringement. With regards to "the amount and substantiality of the portion used" in this case less than 1% of the original code was copied just measuring the lines of code. Substantiality is harder to put a number on, but arguably it was only a small portion of the original product. This is a very low and for many other APIs a more substantial portion would need to be copied to be useful. The precedential value of this case is unclear without either the law changing, or further litigation.