Keep in mind that, depending on your perspective, FlightGear has a very liberal license (GPL) and that the nature of the GPL also means that recipient of GPL'ed contents must also follow the GPL - which is basically a no-go for any commercial/proprietary entity. And furthermore, while public domain imagery/contents would obviously be fine, continually fetching GBs of identical images over and over again by FlightGear clients would almost certainly be an annoyance, if not even a service violation. Which is to say, even just a handful of FlightGear clients connected over MP, participating in a virtual MP event, could bring down most public services to their knees.
In other words, other service users (free or paid) would almost certainly be affected by a handful of fgfs clients fetching imagery for hours.
Thus, it's generally not a safe assumption that people/companies will gladly provide such services, even if the underlying data/tiles/imagery is available free of cost, that does not mean that serving/distributing such data can be offered for free.
So you have the license of the data itself, but also the service cost associated with making the data available.
Note that this also is the issue that affects FlightGear scenery as a whole (terrasync hosting), but also fgdata hosting (git specifically).
So people really need to work out a solution that addresses both issues, even if these are currently not yet perceived to be real issues, they are likely to become very relevant over time, especially the very instant you start providing a solution that's of interest to the MP/terrasync community.
That is one of the reasons why I mentioned the scenario, where standard reverse proxies would be set up by volunteers in the FlightGear community, there also also proxy server implementations specifically for WMTS/WMS - the corresponding URLs could be pre-configured in fgdata space, so that we'd host our own network of GIS "mirrors" without actually violating any TOS, while ensuring that the actual services would only ever get to see requests that have not been previously made.
Besides, this is also a scheme that's basically in use with other tools/services, including other flight simulators. And such a scheme could also be sufficiently generic in nature, so that it might actually be of interest to the parties providing the actual geoservice - so that such FlightGear proxies/geoserver mirrors could also be used by other projects.
Simply expecting that they're going to tolerate possibly hundreds of GBs of requests per week, is unlikely to be viable in the mid-term.
The other issue being one of adding an implicit dependency, i.e. requiring 3rd party services for a more or less vital component of the sim.
Thus, even if you could get a written statement to approve such use, that would not necessarily solve all potential problems magically.