Do not remove Mapbox code

[hyperknot]

I wanted to write an anti-feature request, that is, to please do not remove Mapbox code (as in #21).

Right now, mapbox-gl-js 1.x is an almost perfect library to be used both with Mapbox sources and with independent sources. Setting an API key is 100% optional, it works perfectly without it.

If you do supply the key, then it enables all the mapbox:// specific features.

For example, my project is MapHub (https://maphub.net/), where users can select from multiple basemaps. Some of them are from Mapbox, some of them are from independent sources, and mapbox-gl-js 1.13.x works perfectly as of today.

If you decide to break mapbox:// sources, then using this library wouldn't be a possibility for me, and for many other users who'd like to keep using multiple providers, including Mapbox.

A much better approach would be to leave mapbox:// as it is and introduce alternative urls, like maplibre:// which doesn't apply the API token (today I have to use transformRequest + regex as a hack). Also renaming accessToken -> mapboxAccessToken would be a good thing, but definitely not removing the whole code.

[anarchodin]

The warning in the file seems unlikely to be enforceable as stated. In particular, it cannot be true that modification of anything in that file is a violation of Mapbox ToS. That would imply that the APIs could only be accessed by Mapbox-authored SDKs.

That said, it would make sense to replace whatever's in that file and causes them to put that warning there ... if there even is anything other than FUD. (Edit: Oh, and of course also brace for changes to the terms of service that actually do ban use of code not supplied by Mapbox. When someone shows you who they are...)

[hyperknot]

The Mapbox requirements seems clear to me: do not modify the logic what would affect Mapbox billing. Since in 1.13.x it's simply one SKU token per map loading. As long as we keep the SKU code unmodified, we should be good.

[stevage]

I totally agree.

IMHO, any MapLibre-GL-JS v1.x should be backwardly compatible with Mapbox-GL-JS v1.13. Removing support for mapbox:// etc doesn't really make sense.

[anarchodin]

I went and looked at the specifics of the terms of service. Those refer to a distinct document, the service terms. A clause there says the following:

You may only use mapbox gl-js version 2.0 or higher (“Mapbox Web SDK”) under this Agreement.

There's an earlier clause about using the 'Mapping APIs', which makes this really strange. (If you can access the mapping APIs with any client, this can't be enforced.) In any case, that looks to me like a reason not to trust any argument based on what seems reasonable.

[anarchodin]

Wait, no. It just needs you to look at it from the perspective of billing, rather than a technical perspective.

Keeping the current code would be a violation, because it would continue to use "map load" pricing. That can't be maintained.

[hyperknot]

And what about all their clients who want to use IE 11? As an enterprise company, I'm sure they have many of them. Since 2.x drops IE support, what are they going to do?

I think a more realistic scenario is they keep supporting 1.x clients for a very long time.

[anarchodin]

The current terms of service say they don't. It may be worth requesting clarity on that point.

[gitcatrat]

We should make sure that modules are set up in a way that all Mapbox specific code gets tree-shaken if it's not needed. If that's the case, I won't mind it one bit. This lib has loads of features but I doesn't mean that bundle size is not important.

[ForsakenHarmony]

And what about all their clients who want to use IE 11? As an enterprise company, I'm sure they have many of them. Since 2.x drops IE support, what are they going to do?

I think a more realistic scenario is they keep supporting 1.x clients for a very long time.

I mean honestly, IE should not really be supported, it's a security risk for any company using it either way

[hyperknot]

IE will be living with enterprise companies for a long time, it is still supported by Microsoft.

[cigone-openindoor]

Well, just do like all other tools that rely on IE: do not update.

[hyperknot]

do not update

That's exactly my point: there will be companies who use IE -> Mapbox needs to support 1.x for a while.

[anarchodin]

Are you assuming they've thought this through?

I wouldn't.

[ForsakenHarmony]

We should make sure that modules are set up in a way that all Mapbox specific code gets tree-shaken if it's not needed. If that's the case, I won't mind it one bit. This lib has loads of features but I doesn't mean that bundle size is not important.

Not possible if you want everything to work like it does now, there's no separate import that could include all mapbox code

[marcelnormann]

Its hard to tell if this issue is ever solved, so I convert it into an discussion.