When you're trying to compete with a huge incumbent you always have the Wine vs. Qt/GTK question, where you have to choose between compatibility and design freedom.
But even when you choose compatibility and reimplement the incumbent's API, you don't want to do it using their servers. What happens when they suddenly change the protocol they never promised not to change?
Their clients would have to be updated as well, so there would be an indefinite period of time where the unchanged protocol still works giving microG a chance to upgrade as well.
Google has all the data that makes it work + you would need to analyze all that data to end up with server that can take radio levels and output location. It's not as easy saying lets use our own servers.
If google were nefarious, they can secretly ship a new version that supports both versions of the protocol, wait weeks, months, or even years for it to become installed almost everywhere, and then silently remove support for the old version from their servers.
That would give microG zero time to prevent their software from working uninterrupted.
That sort of thing can happen for all sorts of legitimate reasons, it's not necessarily nefarious. For instance if the client side of the project is running ahead of the server side, rollout may begin with usage controlled by server-side variables. Once the servers are ready to go, usage may be ramped up much faster than software rollouts themselves happen.
Also IIRC the Google services are updated automatically in the background anyway by the Play Store app. So I guess rollouts can happen quite quick regardless.
OsmAnd appears to work fine on my phone, which as far as I know does not have any of Google's proprietary components currently installed (by way of a vanilla CopperheadOS install).
You need a location service provider, which can be fulfilled by GPS or network location. You don't need the fusion location provider, which is the proprietary one.
