A library is a promise you make to yourself: that you will keep it updated, that its transitive dependencies will not turn on you, that the native module it needs will still build on the next runtime. A service is a promise someone else makes to you. Neither is free; they age differently.
Where libraries age well
Pure computation with no external truth: a date library, a JSON parser, a template engine. Nothing about the world changes under them. Keep them few, keep them boring, and they will outlast the product.
Where they do not
Anything that encodes a fact that moves. Currency rates. Country tables. A provider's API shape. A PDF renderer that shells out to a binary. Sanctions lists. An OCR model. These are the dependencies that break in production on a Tuesday because the world changed, and a library cannot notice.
The arithmetic for a small team
A metered service moves the maintenance to the provider and prices it per call. A thousand free calls a month means a small product pays nothing until it is not small. One key and one wallet across the whole catalogue means adding a capability is a path, not a vendor. And a spec you can generate a client from means the integration is a build step you can rerun, not a fork you maintain.
The reference-data service is the clearest case: tens of millions of rows that every product needs and nobody wants to own, kept current in one place, free, GET only. The converters and verifiers are the same argument at one token a call.
Future-proofing is not choosing the library that will last. It is choosing which promises to make yourself and which to buy — and keeping the bought ones behind one door.