I agree, although I think that some of those are less critical issues. For me, the reason to be aware of the politics around APIs is that APIs - unlike librari

I agree, although I think that some of those are less critical issues. For me, the reason to be aware of the politics around APIs is that APIs - unlike libraries - imply an ongoing relationship. With a library, it is presumed (leaving aside the question of licensing, which is definitely political) that the decision about whether to use a library is purely technical: does it do the things we want it to do, with the correct level of performance, reliability and ease of use? You could imagine writing a test suite to determine definitive answers to these questions and, once answered, there would be no need to examine them again. An API gives you access to someone else's product, and that product will evolve. Some of those evolutions may cause your product to break. If you're a Windows application developer, you can count on a pretty strong guarantee from Microsoft that they won't break Windows APIs, which is why programs from the 90s still run on modern versions of Windows, even if this requires some complex engineering from Microsoft. There was no technical aspect of the Win32 API circa 1995 that guaranteed these things; the commitment to future support was entirely political in nature. The same applies to network-accessible APIs today. If your program achieves some result by invoking a statically-linked library, you can be certain that it will continue to work in the future purely on the basis of your technical knowledge. If you're relying on a third-party API, you cannot, and that's the distinction that the OP is asking us to take more seriously.