Remove mapbox-specific code

[petrsloup]

This PR remove the mapbox-specific portions of the code:

• "Telemetry" event sending to mapbox (data collection)
• Concept of access token
• "Edit this map", which sends feedback to mapbox

The most notable change is the "removal" of /src/utils/mapbox.js, which contains the following warning:

/***** START WARNING - IF YOU USE THIS CODE WITH MAPBOX MAPPING APIS, REMOVAL OR
* MODIFICATION OF THE FOLLOWING CODE VIOLATES THE MAPBOX TERMS OF SERVICE  ******
* The following code is used to access Mapbox's Mapping APIs. Removal or modification
* of this code when used with Mapbox's Mapping APIs can result in higher fees and/or
* termination of your account with Mapbox.
*
* Under the Mapbox Terms of Service, you may not use this code to access Mapbox
* Mapping APIs other than through Mapbox SDKs.
*
* The Mapping APIs documentation is available at https://docs.mapbox.com/api/maps/#maps
* and the Mapbox Terms of Service are available at https://www.mapbox.com/tos/
******************************************************************************/

But after this change, the maplibre-gl-js cannot be easily used with mapbox data (the mapbox:// urls will not work any more), so we should be okay. Maybe @nyurik has more insight into this ?

I've tested this a little (it works with styles from MapTiler Cloud API -- vector tiles/raster tiles/DEM/sprites/fonts, so everything should be loading okay). But I wasn't able to run the full test suite at the moment.

Please add commits to this branch if you find any more mapbox-specific pieces of code.

[snickell]

@petrsloup one key question here is if we want to merge this before or after our "most compatible possible with mapbox-gl-js" initial release, on the one hand, it will necessarily break mapbox URLs etc.

Another question is: Are we sure we want to completely disable mapbox? It might make sense for many of our users to continue being mapbox customers, but using a free sofware way to access mapbox features? Probably not, but worth thinking briefly about.

[lseelenbinder]

I would say we want to ship this after the initial version (v1.13).

[markgis]

Our user case would be that we would use our own tile layers, but there are cases for using the mapbox layers especially for quick proof of concepts and tests?

Do you envisage the getting started docs to use MapTiler or Mapzen or another vector tile service instead of Mapbox?

[kylebarron]

I'm not in favor of this change. Given what I've read above

• This code is only activated when you use a Mapbox-specific tileset (i.e. mapbox://...)
• This is a breaking change because once you remove this code, users can no longer use MapLibre with Mapbox data, because this would break their TOS.

I think backwards compatibility should be a high priority for a while, or we risk fracturing the community even further. This change seems to be inconsistent with the stated desire

we don't plan to move fast and break things, especially API compatibility

It seems to me that removing the ability to use Mapbox data services breaks compatibility, and if people can avoid triggering this code by self-hosting data, it should be moot.

Edit:

But after this change, the maplibre-gl-js cannot be easily used with mapbox data (the mapbox:// urls will not work any more)

In my understanding, this change implies that it cannot be used at all with any Mapbox services without breaking their TOS.

[nyurik]

I think we should introduce absolute minimum changes in our first official release, doing only what is the minimum required from the legal perspective. I suspect this just means rebranding, without any changes to the API (my understanding is that API compatibility is an exception to trademark law, but IANAL). The only possible exception is to disable telemetry to Mapbox if only non-Mapbox data sources are used. Last I checked the telemetry is not being sent for non-MB sources already, but we should make sure.

Going forward, I would prefer our users to have the option to use Mapbox data sources if they so choose, but we clearly cannot guarantee that if users use MapLibre code with Mapbox data, they won't violate Mapbox's terms of service.

Lastly, I think it would make sense to rename mapbox namespace/functions in the API itself in the next major release, except for those related to Mapbox's-specific services (if any), and introduce a separate "wrapper" project as described in #9 so that users can continue using original APIs as is if they so choose.

[curran]

Closes #6

[curran]

The style changes don't really make sense, as the underlying component that generates the DOM elements with class .mapboxgl-ctrl-attrib haven't been touched.

Also probably we'd want to make it possible to interface with Mapbox APIs via maplibre-gl-js in the long run?

This PR seems a bit reckless IMO.

[curran]

Might we want to keep these, so that it would still be possible to interface with Mapbox APIs via maplibre-gl-js?

[curran]

The component that makes this stuff is still in the repo https://github.com/maplibre/maplibre-gl-js/blob/f87090b70b8a6fbde1a779c44933ce32bffc5d2c/src/ui/control/attribution_control.js . Did you mean to delete that stuff too? This styling seems to still make sense to keep, maybe we could just rename it to not refer to Mapbox.

[hyperknot]

A case against removing Mapbox code:
#41

[anarchodin]

In my understanding, this change implies that it cannot be used at all with any Mapbox services without breaking their TOS.

It's worse than that. There's nothing whatever to say that using it as it stands is not a violation of the terms of service.

[wipfli]

@HarelM this is outdated, right?

[HarelM]

Yes, but it has code changes that I think should make it in, like the removal of the access token.

[HarelM]

@petrsloup what's preventing this from being merged?
Any chance you merge from main, and prepare this for merger by fixing the code review comments so I can merge this and close this PR?

[HarelM]

Closing in favor of #293.
Feel free to review it there. I think I didn't almost the same process and got a very similar results.