Mapbox-gl-js: v2.0 changes merged with updated TOS and license

[asheemmamoowala]

v2.0 release changes merged with updated TOS and license

We just merged the v2.0 release changes to main, including performance enhancements reducing map load time by 30%, 3D terrain rendering, new satellite imagery, a low level camera API, and a new sky layer type. See the CHANGELOG for the full list of changes.

The SDK bundle and source code are distributed in ways that make it easy for developers to include the library in their javascript build system and integrate with their tool chain. All new features and improvements will only be available in v2. Old versions of GL JS (

The project source code is available here on Github for open collaboration with the community. Mapbox GL JS v2+ are governed by the Mapbox Terms of Service (this is a change from the old 3-clause BSD license). Developers can fork the public GL JS repository and make modifications to the code as long as abiding by the conditions of the license as documented in the Mapbox Terms of Service, including prohibitions on breaking the law or violating human rights:

Copyright © 2020 Mapbox

All rights reserved.

Mapbox gl-js version 2.0 or higher (“Mapbox Web SDK”) must be used according to the Mapbox Terms of 
Service. This license allows developers with a current active Mapbox account to use and modify the Mapbox
 Web SDK. Developers may modify the Mapbox Web SDK code so long as the modifications do not change 
or interfere with marked portions of the code related to billing, accounting, and anonymized data collection.
 The Mapbox Web SDK only sends anonymized usage data, which Mapbox uses for fixing bugs and errors, 
accounting, and generating aggregated anonymized statistics. This license terminates automatically if a user
 no longer has an active Mapbox account.

For the full license terms, please see the Mapbox Terms of Service at https://www.mapbox.com/legal/tos/

GL JS is available to developers on pay-as-you-go — no commitments, usage is billed by Map Load, which correlates to page load metrics. In v2, a map load occurs whenever a Map object is initialized on a webpage. Each map load includes unlimited vector tiles, raster tiles, and terrain tiles for the length of the map session. Map Load pricing includes a generous free tier to get started. Updating to v2 has no pricing impact for 99% of Mapbox customers. Pricing is published for all services, including volume discounts that automatically trigger as usage increases.

We continue to build in the open on Github in collaboration with the community. All source code is publicly visible, and available for modifications, with the exception of code related to billing, accounting, and anonymized data collection. These areas of the project are clearly marked. Public contributions to the project are welcome and encouraged - community work is governed by our Contributor License Agreement. Check the CONTRIBUTING guidelines to get started.

FAQ

Can I still use self-hosted map tiles?
Yes. Developers simply need a Mapbox account and access token to use this v2.

Can I use data or tiles from Google Maps or other non-Mapbox services?
Yes. GL JS is fully interoperable with third party map sources that provide vector or raster tiles in supported formats. Usage of v2 is billed by Map Load to the Mapbox account owner. The license terms make no distinction between data sources.

Can I keep using the legacy versions of Mapbox GL JS?
Yes. Old versions of GL JS will remain publicly available via NPM and our CDN endpoints. Updates to the v1 releases will only be made for critical browser compatibility or security issues for a limited time. All new features and improvements are only available in GL JS v2.

What data does Mapbox collect from GL JS v2?
GL JS only sends anonymous usage data for the purposes of fixing bugs and errors, accounting, and generating aggregated anonymized statistics. For example, the browser or OS usage to determine how to prioritize defects from edge cases.

Does the updated license affect other Mapbox GL JS dependencies?
No. Other projects like geojson-vt and supercluster retain their OSI license.

cc @yhahn @gundersen @kathleenlu09 @mapbox/gl

[aparshin]

@asheemmamoowala

Can I still use self-hosted map tiles?
Yes. Developers simply need a Mapbox account and access token to use this v2.

Just to make sure I understand this change correctly: now, starting from v2.0, even if I don't use any server-side Mapbox resources (tiles, glyphs, icons, etc.), I'll still have to pay Mapbox for Mapbox GL JS library usage (when I'll exceed the free tier limit). Is it correct?

[thunderkid]

Can I still use self-hosted map tiles?
Yes. Developers simply need a Mapbox account and access token to use this v2.

So I'm trying to understand this change. Am I correct in thinking that in version 1 I could npm install mapbox-gl, point it at my own tile source, and never have to ask mapbox's permission for anything ever again, whereas to use my own tiles in version 2, I need to do that through a mapbox access token. So that if it chose to, mapbox could decide that my website using my tiles was spreading fake news, for example, and could turn me off?

What is the thinking behind this?

[joedjc]

In addition to these questions. Would usage of mapbox-gl for development purposes eat into my free tier? I can imagine a lot of our map initialising events come from developers working on apps, rather than end users.

On a more positive note - very excited (and pleasantly surprised) to see 3D terrain and associated features coming in - though would have been good to have known if/when it was coming. Are there any examples available yet?

EDIT: I was too quick. Just seen this, looks really nice: https://docs.mapbox.com/mapbox-gl-js/example/add-terrain/

[aleksejleonov]

@asheemmamoowala

First of all, I want to thank the Mapbox team for their great work.

I use mapbox-gl-js for years for so different purposes and really happy with it. I am not a real contributor (I am mostly a back-end dev), but I reported bugs and promoted mapbox-gl-js for many devs from the very beginning of the project.

I believe this change with billing for each Map load (independently of mapbox.com services) could be very disruptive.

In our company, we use mapbox-gl-js both with our own vector/tile raster server (free for us) and with mapbox.com layers (as paid service).

For example, we have a CI/CD pipeline with a huge amount of integration specs using Headless Chrome.
In total, each full run loads about 10000 pages testing different scenarios. Half of them loads mapbox-gl-js in one or other way. Sometimes it's a small avatar-like map, sometimes static preview, sometimes a full-featured map. For CI/CD we configured styles to use our own tile server, so everything works fine for testing purposes and we don't need to touch mapbox.com paid services. Also, the same place on the map used each time in CI, so most tiles are cached and even don't touch our tile server.

With v2 it looks like we would be billed for 5000 Map views on each CI/CD run. With ~50 CI/CD runs a day we will have 250000 Maps views. Means 250000 * 3$ per 1000 = 750$ per day = 22500$ per month. I believe it's an enormous amount of money.

Of course, there could be some way around:

• Fully stub mapbox-gl-js in CI/CD, but we lose the ability to test map interactions.
• Use leaflet as much as possible instead of mapbox-gl-js. But actually, we spent years to migrate from leaflet to mapbox-gl-js to have consistent styles and codebase.

I understand that mapbox.com is a business that should make money, no complaints here :) It's necessary to keep the development of the mapbox-gl-js.

The old billing model was great for us. We were able to use mapbox-gl-js free in dev, CI/CD. In production, on some pages, we use full-featured maps with satellite layer as a paid service from mapbox.com. On some pages, we use small avatar-like maps with our own free tile-server with OSM-based data.

The new billing model introduces many complications and feels unfair:

• It's cheaper to have a SPA than the classic web app. SPA could initialize the map once per session, classic rails app would initialize the map on each action/page view.
• It introduces complications to testing.
• It limits the usage of mapbox-gl-js in any non-full-featured map scenarios (avatars, small animated previews, data visualizations without background). We should revert back to leaflet to avoid excessive spendings.

In my case, we definitely would stay with v1.

Of course, it's your right to change billing for the new version.
But so many devs invest their time to contribute and help project growth due to its open-source nature and flexible billing model. And now it feels sad.

I really hope that there is a place for discussion to keep the previous billing model.

[mike-marcacci]

Excellent technical changes in this release.

The license change is one I certainly empathize with, but it's also hard to express the depth of disappointment associated with losing the de facto mapping package from the open source landscape.

You obviously deserve to get paid. You provide an amazing, amazing tool. But this is just so sad.

Have you considered a dual-licensing model, perhaps using a license with copy-left provisions like LGPL? In a sort of sinister way this might actually crush the inevitable v1 fork, as academic projects and tutorials would probably use the current LGPL version over a fork, and it would force the release of those projects as more "mapbox usage examples."

[binakot]

This is the same as if you simply removed the repository from the github. I think the community did not just create issues, make PR and use the library in their projects. Apparently, the company is going through hard times if it has to change the terms of using the library in the open repository on github in this way.

[AdventureBeard]

In v2, a map load occurs whenever a Map object is initialized on a webpage.

Struggling with definition of "map load"; should I be looking at "pages viewed with a mapbox object", or "sessions in which at least one mapbox object was initialized"? For my relatively small application that has low unique users, but extremely high activity per user (users have many pages and navigate page to page, back and forth), the former is $3000 a month, the latter $250.

[ErinQuinn]

@AdventureBeard - https://docs.mapbox.com/help/glossary/map-loads/

[asheemmamoowala]

Would usage of mapbox-gl for development purposes eat into my free tier? I can imagine a lot of our map initialising events come from developers working on apps, rather than end users.

For example, we have a CI/CD pipeline with a huge amount of integration specs using Headless Chrome.
In total, each full run loads about 10000 pages testing different scenarios. Half of them loads mapbox-gl-js in one or other way. [ ...] It introduces complications to testing.

@joedjc @aleksejleonov thanks for asking these questions. We hadn't considered extremely heavy usage in testing/CI and will see if there are any ways to address these concerns.

[snickell]

UPDATE / TL;DR: we're organizing at https://www.npmjs.com/package/maplibre-gl to continue open source development of the awesome code mapbox contributed to the community in the form of mapbox-gl-js 1.x, our primary goal is avoiding fragmentation by broadly sharing ownership of maps-gl, esp in the early days. If you're wanting to help ease this transition, please join us!

ORIGINAL POST:

Just to be clear: it appears that with this change, going forward, mapbox-gl-js (https://github.com/mapbox/mapbox-gl-js) is no longer open source.

Its now a relatively restrictive "shared source" model, similar to what Microsoft and Oracle sometimes use, and providing that source code to paying customers, and therefore can not be used to build open source derivatives.

To continue development, upstream open source projects will need a new not-mapbox-gl project to be forked off the last BSD release of mapbox-gl 1.x. In order to avoid wasted effort, ideally a single clear new project will emerge to continue the mapbox-gl 1.x branch under a different name as a new project.

I personally greatly appreciate what mapbox has already contributed to the open source commons. Would mapbox be willing to tolerate tracking/coordinating setting up a new open source project based on 1.0 in the mapbox-gl-js issue tracker? This would help raise the odds that a single clear healthy open source project has an opportunity to form.

A classic problem with a healthy fork (as the open source community and mapbox-gl now find themselves on different code paths) is nowhere knows where to look to find the "new definitive central place" for development.... being able to use this issue tracker for a couple weeks to get everyone on the same page (=decide on a primary new issue tracker!) would be /very/ helpful if mapbox inc is willing to help!

UPDATE: I've been working on setting up a BSD fork without any "tainted" commits, and I'm happy to add anyone with a stake in a healthy BSD fork as a dev/owner as appropriate: https://www.npmjs.com/package/maplibre-gl

Shall we regroup there, if only to figure out where it should live long term? I don't have a big stake in this, so I'm happy to let somebody else(s) drive, but I think its beneficial for a clear, openly managed successor to emerge rather than divergent micro-forks, and I suspect quick coherent action raises the chance of that. I also nabbed @maps-gl on npm.

SIDE COMMENT: Its actually a little tricky to get a legally clean fork with the way the rebased/squashed v2.0 PR was merged, and I want to make sure to not accidentally pull in commits under the new license. Instead of trying to start with mapbox-gl-js head and reverse-cherry-pick, I ran a search for the most recent github fork from before the merge with no commits added, and forked from that.

[morphy2k]

https://github.com/hewegoz/mapbox-gl-js
This one is from Dec. 7 and should be better suited. It contains the last V1 release.
I used GitHub's REST API for this.

[AdventureBeard]

@ErinQuinn , appreciate the clarification. Seems this change has big impact on consumer-facing, navigation-heavy apps; the definition of map load makes it much too expensive for us. V1 is pretty dang cool though; best of luck with v2. 👍

[stevage]

@asheemmamoowala

Question: is offline use still possible? (Both technically, and legally speaking).

[stevage]

Would usage of mapbox-gl for development purposes eat into my free tier? I can imagine a lot of our map initialising events come from developers working on apps, rather than end users.

For example, we have a CI/CD pipeline with a huge amount of integration specs using Headless Chrome.
In total, each full run loads about 10000 pages testing different scenarios. Half of them loads mapbox-gl-js in one or other way. [ ...] It introduces complications to testing.

@joedjc @aleksejleonov thanks for asking these questions. We hadn't considered extremely heavy usage in testing/CI and will see if there are any ways to address these concerns.

Just chiming in that I have experienced this requirement on a project previously. We had to demonstrate that our Mapbox application could cope with a load of tens of thousands of simultaneous users for a government client.

[fakegis]

goodbye mapbox, good luck！

[geoyogesh]

Usage counts even if map object is initialized in my localhost???.. what if some automated testing tools ran my application ??...

[vfonic]

We hadn't considered extremely heavy usage in testing/CI and will see if there are any ways to address these concerns.

Seems like you hadn't considered quite some things here.
There's nothing wrong with rethinking this now and changing your decision. That's certainly an option.

The v1 fork has already happened. This is turning into a mess in a matter of hours...

[geoyogesh]

Are there any free plans available for other open source and free softwares who wants to use just your mapping api?

[fsteggink]

I've set up a petition to keep Mapbox GL JS open source. In that petition I'm also asking for a better way for governance of this project and related technologies (for example the MVT standard). Please sign it if you agree with this.

Since I'm not a native English speaker, I would like to ask if someone could review and improve the text of the petition.

[snickell]

If anyone is looking for a community maintained derivative of mapbox-gl-js v1, please consider merging your efforts into:
https://github.com/maps-gl/maps-gl

Fragmentation is the biggest initial risk to a healthy open source afterlife for the mapbox-gl-js v1 codebase, my primary focus is on easy-transition, and sharing leadership as we figure out the next steps forward, particularly for codebases that are unable to legally upgrade to mapbox-gl-js@2 as they aren't mapbox-gl customers.

PLAN UPDATE: as of Dec 8, we're releasing @maps-gl/[email protected] to NPM, providing a simple transition path for those required to migrate off mapbox-gl@latest in short order to maintain legal compliance. Semver does provide some safety here from accidental not-licensed upgrades to mapbox-gl@2, but its probably better safe than sorry.

We're starting to assemble as a project on gitter.im as much as anything: https://gitter.im/maps-gl/maps-gl

Upgrading should be a simple package.json changing of the package name to @maps-gl/maps-gl, as both v1.13s will be compatible.

EDIT: I'd like to add that I'd very much prefer it if mapbox changed their mind as per @fsteggink above, I'm hoping they reconsider, but its completely understandable if that's not best for them, they've donated an amazing amount of great work that we all enjoy already

[snickell]

@morphy2k thanks for finding that, I'm merging it in now ... I guess my rest api script had bugs 😱🤦‍♀️, I had a pre-1.13 pull cherry-picked, but I see that after the release commit there's a post release hash-updating commit

[wjbgis]

I'm sorry to hear that. Understandable, but hard to accept.

[jacmendt]

Congratulations to the Mapbox team on the v2 release. Especially the support for terrain tiles and 3D scenarios is a real step forward.

How far we can adapt the new version for our projects is currently being examined. As for many writers before me, the new license leads to different risks for us.

For example, there are on-premise installations in Europe where we want to prevent services from being accessed outside the network. In this case the communication of the Mapbox GL JS library would already be an exclusion criterion.

[aleksejleonov]

@asheemmamoowala

There are many comments from customers who are embarrassed with such rapid change (and I am one of them :), describing their pain.

I believe it would be extremely helpful if you could share the reasoning behind the new billing:

• Why it was introduced?
• Is there some overuse by customers that introduce business risks for Mapbox?
• How the new billing should resolve those issues?

I truly understand that this is Mapbox's internal decision, and may not be something allowed to share.

[jacmendt]

Is also the licensing / pricing of Mapbox GL JS v2 as SDK conceivable? From our perspective, this would be a better solution for the On Premise case, both in terms of security requirements and cost control.

[bravecow]

You announced the end of support for IE11 in advance, but not about such big changes. Or i missed something.

[bravecow]

@asheemmamoowala

In addition to testing and offline use, you are disadvantaging sites that are not SPA. For example, site with search box and page reloads after submitting it. Can you consider the notion of a session longer, like Google Analytics do?

[geoyogesh]

Google bots will run javascript in page to detect the dynamic content...will it increase my usage in that case

[geoyogesh]

how mapbox gl js can be used in secured environment with no internet access... do we need to setup license server inside our infrastructures ??... these issues feels like dejavu all over again... it was the main reason why switched to mapbox initally from license based esri products...

[geoyogesh]

i dont think mapbox api should collect anonymous location data since it become licenced product..... or provide ability to turn off the data collection from developer level instead of end user level...

Thanks

[catalinconstant]

It is a matter of attitude, I fill that after use mapbox-gl as an opensource library, suddenly I have paracticaly a torjan horse in the software I develop, this is not an ethical way to use opensource. What if github will change their TOS or Microsoft will change Visual Code Studio TOS or D3 or WebGl or V8 etc. If you wanted to have an private library you should do it from start not now.
Sorry I like this awsome library but the way I was treated is unbereable, I already unstar this libary and I am looking for other libraries like maps-gl or openlayers

[asheemmamoowala]

there are on-premise installations in Europe where we want to prevent services from being accessed outside the network. In this case the communication of the Mapbox GL JS library would already be an exclusion criterion.

how mapbox gl js can be used in secured environment with no internet access.

@geoyogesh @jacmendt Could you please contact us) so we can help address this type of use case.

Google bots will run javascript in page to detect the dynamic content...will it increase my usage in that case

@geoyogesh Thanks for pointing this out. Lets track this in a separate issue as it is worth discussion and understanding of the expected behavior for bot-driven page loads.

you are disadvantaging sites that are not SPA. For example, site with search box and page reloads after submitting it. Can you consider the notion of a session longer, like Google Analytics do?

@bravecow We're interested in learning more about this type of usage of the library. Could you share more detail in a separate ticker on how you have GL-JS integrated, and why multiple map instances need to be instantiated within a single web page or single user session?

[exotfboy]

@asheemmamoowala : Can you provide a clear answer to the question most people in this post really cared about:

"Does it mean we have to pay Mapbox and the sdk will sends anonymized usage data to mapbox server even if we use our own tiles, glyphs, icons, etc?"

[morphy2k]

@exotfboy According to this, yes.
Usage data do not seem to be optional.

[stevage]

It's very clear: yes. Every map load is billable, even if it doesn't consume any Mapbox hosted services.

[pathmapper]

What data does Mapbox collect from GL JS v2?
GL JS only sends anonymous usage data for the purposes of fixing bugs and errors, accounting, and generating aggregated anonymized statistics. For example, the browser or OS usage to determine how to prioritize defects from edge cases.

@asheemmamoowala is there somewhere a complete list about which data will be collected from GL JS v2?

• https://www.mapbox.com/legal/privacy doesn't explicitly mention GL JS v2/Mapbox Web SDK
  and
• https://www.mapbox.com/telemetry looks like it is only about the Maps SDKs for iOS and Android.

[dangerden]

It's very clear: yes. Every map load is billable, even if it doesn't consume any Mapbox hosted services.

It feels like MapBox found a way to sell many years of open-source community efforts. Even though we already pay for MapBox in our projects this move feels unfair...

[majkshkurti]

What about the Mapbox services (like map tiles api, etc) ? Are those going to remain usable (legally and technically) from the forked versions of v1 or other libraries (ex. Openlayers) ?

[brucknera]

@asheemmamoowala , could you please be so kind and share your strategy how to deal with applications running in an environment with no internet access? We have started using mapbox gl/js for a mission critical application over a year ago. The requirement to access an off premises server for license checks is an exclusion criterion for us (and i believe for many others) and we have to consider switching to an alternative library now.

[techieshark]

Hi 👋 @asheemmamoowala thanks for this update (I found it very useful & informative).

V2 sounds like it includes some exciting technical changes (a 30% load time improvement is amazing!) while raising some questions about license usage (this point about a real world CI/CD usage being $22.5K a month is concerning! - so it's good to hear Mapbox is looking into how to resolve issues like that).

I applaud Mapbox for seeking to prevent their work from being used to violate human rights (via the TOS).

My question to Mapbox is - would you consider updating your TOS to include provisions from the Climate Strike License - https://github.com/climate-strike/license ? For example, these two provisions from that license:

1. The software may not be used in applications and services that are used for or aid in the exploration, extraction, refinement, processing, or transportation of fossil fuels.

1. The software may not be used by companies that rely on fossil fuel extraction as their primary means of revenue. This includes but is not limited to the companies listed at https://climatestrike.software/blocklist

Major companies like Mapbox taking steps to ostracize the fossil fuel industry could go a long way in our efforts to limit climate disruption in the years and decades to come.

I used to work right next to Mapbox and I know many of the employees are very keen on tackling climate change, and it was just last year that Eric Gundersen himself wrote in support of the Climate Strike, so I think such an addition could be a welcome change at Mapbox.

Thanks for considering this idea.

[thunderkid]

@techieshark
Please consider the ramifications of your suggestion. The notion that some package on npm should be looking over my shoulder and deciding whether my content appeals to their current political sensibilities is completely antithetical to the concept of open source. I use around 60 packages. Should each of them be providing their own political wish list in their TOS? Apparently your main concern is global warming. For someone else it could be mitigation of poverty, freedom of speech, indigenous rights, righting historical wrongs for their particular nation, etc. etc. Many of these issues are complex, nuanced, and in total conflict with each other, and I have zero wish to see npm become yet another political battleground.

If I had to worry about how every library developer might possibly take political offense at the way I'm presenting data, then I'd be far better off deleting node_modules and just rebuilding everything from scratch myself.

@asheemmamoowala
Please don't consider this idea.

[asheemmamoowala]

What about the Mapbox services (like map tiles api, etc) ? Are those going to remain usable (legally and technically) from the forked versions of v1 or other libraries (ex. Openlayers) ?

@majkshkurti There are no changes to the Mapbox Vector and Raster API services. They continue to be accessible in other client libraries. The Map load pricing is only available through Mapbox's officially supported SDKs.

share your strategy how to deal with applications running in an environment with no internet access?

@brucknera could you please contact us so we can better understand your usecase and provide a solution.

[techieshark]

@thunderkid thanks for your reasoned consideration. I appreciate what you're saying. I'm a big fan of open source or free software (that is, the "free as in freedom" kind) as well.

That said, I think the effort to maintain a livable planet is worth the effort of asking myself the simple question "Am I Saudi Aramco? (or any of these companies)". I'd maintain that as long as the mapbox-gl license is ceasing to be free software anyway (as in, they've made that decision already), the difference between the effort to ask myself "am I violating human rights?" (as required by the TOS) vs "am I violating human rights?, and also, am I Saudi Aramco (etc)?" is very minimal indeed. In my own experience, this would certainly take less time than the time spent considering the number of package downloads, github issues, technical writeups, and the like when trying to decide between frameworks or packages to depend on.

[MikeKovarik]

No thanks. I'd rather keep my hobby project 30% slower on an older version. It's already loosing me a fortune and will never be profitable.

Because that's what nice people do. Make nice things for other people to enjoy. Free of charge.

[jxlarrea]

Hold on a second. I currently use tileserver-gl with tiles purchased at https://openmaptiles.org/. I do not use any tiles hosted at mapbox.com. Does this mean that v2.0 will require a (billable) mapbox access token to work, even if all my tiles are loaded locally?

WTF?

I'd gladly pay a one time fee for the library itself, but paying per map load is ridiculous when using my own locally hosted tiles server and data.

[bravecow]

@jxlarrea I think thats why maptiler have own fork of mapbox-gl-js: https://github.com/maplibre

imho mapbox made life more difficult for maptiler, cause users have to pay twice for now.

[zingi]

@techieshark
I don't like the idea of bringing political opinions into code.

If you want to exclude somebody or some party of using this library, because of their political affiliation, that is discrimination.

Everybody should have the same rights to access and use open source code regardless of whether you or I think their activities are good or not.

[Dahkon]

I insisted a lot on my company to migrate all our maps and tools from google and leaflet to mapbox, that takes a lot of time. We pay for mapbox directions and geocoder services, it's fair. But we host our own tiles servers.

How can I justify that billing cost of something self hosted ? That's nonsense.

A fixed cost by year, month or a one time buy would be more logical to me.

I think we were a lot to leave behind Google Maps when they announced their billing policy changes. You just take the same path.
Hopes you will reconsider.

[aleksejleonov]

@jxlarrea @Dahkon

I have a quite similar situation. We use some paid Mapbox services. But, on most maps, we use only our own in-house generated tiles. V2 billing change will increase our costs orders of magnitude, way above we could consider as reasonable. Also, always-on telemetry data (even anonymized) would be considered an issue by some of our clients.

Fixed costs by year or one time buy may be a good solution for us.
As one more option — session-based billing model (https://github.com/mapbox/mapbox-gl-js/issues/10178).

Right now there are 2 options:

• stick to version 1.13, it still available with the old billing model;
• an open-source project https://github.com/maplibre/maplibre-gl-js was started based on 1.13.

deck.gl have plans to add support for base maps. Not so advanced as MapboxGL JS, but may be suitable for some use-cases (https://carto.com/blog/our-thoughts-as-mapboxgl-js-2-goes-proprietary/). It may be an option in the future, but migrating one more time to another map library — always hard and painful.

[frnsys]

Thank you @techieshark for suggesting the Climate Strike License. It would be great to see it adopted.

If I can add my 2c, adopting a license like the CSL is not about "politically offending" someone (as if it were just an issue of politeness or political correctness), but as @techieshark says, about maintaining a habitable planet. And there is a list of specific companies that are blacklisted from the license. The vast majority of developers and companies will be unaffected.

And finally, open source is a political movement, but a lot of people forget that history. Developing a model of co-production to challenge the dominant profit-driven model? What could be more political than that?

[asheemmamoowala]

@pathmapper @aleksejleonov The telemetry collection from v2 is no different than what we have had in the past. The Privacy page includes information collected from APIs and SDKs, and our policies on dealing with the customer data, i.e its use for internal diagnostic and analytic purposes.

[candu]

Definitely wanted to thank the Mapbox GL team for their work here over the last several years - it's been a stellar tool to work with!

Unfortunately, I also have to add a big +1 to the "these licensing changes mean we'll have to seek another option" chorus. On the civic tech project I'm working on through Code for Canada, the combination of open-source / open data commitments, constraints around procurement, and security policies around dependency updates make it impossible for us to use Mapbox GL v2 moving forward. (More specifically re: procurement: pay-as-you-go pricing is an anti-feature in some contexts, as it means costs can't be known upfront; often that means having to find a service reseller and draft up a fixed-cost contract. That's enough of a headache for things like AWS that at least have robust reseller markets; it's overkill for a single dependency.)

Of course, we were never paying customers to begin with; we'd gone the self-hosted / publicly-available map layer / data route, and never made use of Mapbox's APIs or hosted services. We'd assumed that Mapbox GL would remain open-source - it's exceedingly rare that libraries switch from open-source to closed-source, especially without any kind of dual-licensing model in place for downstream open-source projects. Sadly, "rare" is not "never", and it turns out that our assumption was wrong in this case.

As many others have suggested here, I'll be looking into https://github.com/maplibre/maplibre-gl-js to see if that emerges as a viable, well-maintained alternative (and to see if there are ways I can help out, time permitting!)

[marenab]

For @candu and others working on not-for-profit / education / public good / civic tech projects: If you have questions or concerns about Mapbox costs or would like guidance on how to use Mapbox tools, the Mapbox Community team is here to support you. We can help with donated services or options for organizations with fixed budgets (and so can't use pay-as-you-go). You can reach us via the form at mapbox.com/community or directly at [email protected].

[jxlarrea]

I would have never guessed that open source also contributes to the mess that 2020 is. Word "disappointed" doesn't cut it.

Two polarizing thoughts:

• Thank you for this contribution, Mapbox is amazing, you have obviously worked hard on it
• How dare you to commercialise the work of hundreds of volunteers? It's even worse, you lock them out too!

Sorry, had to get that out of my system, this is very sad news.

This makes me little paranoid toward open source to be honest. What if e.g React does this sh*t?

Their company must be really struggling for them to even consider pulling a move like this one so they got nothing to lose.

[stevage]

How dare you to commercialise the work of hundreds of volunteers? It's even worse, you lock them out too!

This criticism isn't really fair. All of that work is still available in v1.3, in MapLibre, and (if you're ok with the terms/license), in v2. It's valid to feel disappointed that Mapbox isn't going to continue doing this thing you have enjoyed so far (investing very significantly in building a library that they give away completely free). And there are legitimate disagreements to be had about the new direction.

But I don't think there is reason to accuse Mapbox of unethical behaviour here: they're totally within their rights to no longer be investing in development under those terms, and I don't think they have ever made any particular promise to continue to do so for any particular time frame. At worst, you could accuse them of creating and fostering expectations that they have failed to live up to.

[StephenAtty]

Like others we use your excellent JS library but ALL our tiles are rendered locally using our own tiles built from our own data and the OpenStreetMap data.

The idea that we should have to pay you each time we render a map object (some of our pages have multiple maps) and we're running at about 35 Million page loads per year is just lunacy. We run a hobby website and do not charge for access.

Why not offer a annual fee which gives you access to the libraries but NOT any of your map sources. If that was a sensible amount then we'd probably look at buying a licence.

As is we'll stick with 1.13 until it stops working.

[joedjc]

I've used mapbox-gl for quite a few years and am a big fan. I have been conscious that mapbox is a commercial organisation and needs to make money so I can understand why a change like this is needed.

One aspect of the new pricing i'm a little concerned about is that there no differentiation between those using mapbox commercially (like us) - taking advantage of it's rich features but with lower volumes of use, and those who might be using it publicly on their websites with higher volumes of use - but often using less of the functionality.

Going back a few years to when we first started using mapbox - the old model used to mean we had to pay a minimum $400/500 per month (can't remember exactly) to use mapbox services commercially. While I thought that was a bit steep for us as a smaller company, I thought it was fair to charge for this type of usage. In fact, we paid this for a while just because I wanted to be giving something back to mapbox. However, it was too much for a small company starting out so we reluctantly switched to a cheaper service (maptiler) - I did contact mapbox at the time to see if we could negotiate a more appropriate deal but received no reply.

Since then, mapbox got rid of that commercial use charge and we thought about switching back (again - mainly to be giving something back to mapbox). However, there wasn't much advantage in doing so and as a result that wasn't prioritised (plus, we didn't really want the mapbox logo watermark for UI reasons).

For us, using mapbox with relatively low volumes of use in a commercial setting, the new pricing broadly makes sense - we are ok with it and will continue to use mapbox. As others have mentioned I would rather see 'sessions' used and some concession for using mapbox during development. Otherwise we might have to make artificial design decisions to try to minimise how often mapbox is initialised - or perhaps even use mapbox 1.13 where we don't need the new features.

Where I see a problem is if we want to use mapbox-gl in a public facing way - such as on our company website. This would be much more challenging as we might get a lot more hits, but much less value from them. E.g. if we had mapbox on our landing page it might get loaded a lot even if users don't even look at the map. I imagine mapbox is used a lot in this way and it'll force those developers to look elsewhere - it just won't be viable to use mapbox. We might even be subject to abuse - as far as I know we can't set a cap on map loads?

Essentially - the implications of a 'map load' are very different depending on whether they are:

• Our developers/internal use (high volume, very low/no value)
• Using mapbox on a public facing website (high volume, low/medium value)
• Using mapbox behind a pay wall/commercial facing use (low volume, high value)

In my opinion i'd therefore have liked to have seen a difference between how mapbox handle pricing for higher value, lower volume commercial use cases vs higher volume, lower value non-commercial use cases. Admittedly, this could make the pricing more complex but given mapbox is for developers that might be ok. Perhaps differentiating by features could be considered.

As a final note - i'd have been happy to be involved in a dialogue with mapbox about this - like others we were taken by surprise. I understand the motivation but I think this new approach could be tweaked and I hope not too much damage has been done.

We'd like to support mapbox to continue to be a successful company while reaping the benefits of new features like those introduced in v2. For us, the new pricing is pretty much ok in our commercial facing use but it will limit how we can use mapbox and I can see it causing a problem for others using mapbox in non-commercial/direct revenue generating ways so the value proposition won't make sense. Incidentally, it would be helpful to have sight of new features like this to help us tie into our own development roadmap.

[gzurbach]

Our small nonprofit is using MapboxGL + MapTiler. When we migrated our map to MapboxGL back in 2017, we considered using Mapbox for tiles, but it was way too expensive. Even today, we wouldn't mind paying for Mapbox, it would be only fair. But instead of trying to offer affordable maps for everyone, you pretty much just pack your toys (after letting thousands contribute to them). I am the only dev in an organisation of five employees, and really this kind of news are a huge setback. I'd rather work on our mission rather than rewriting maps every 3 years.

This is a disaster.

[douglasg14b]

One of the largest problems with this, aside from the per-load billing model with use-cases that see a lot of loads in a single session, is that this still requires an API Key and still charges for loads when you're using your own tiles.

This pretty much means Mapbox GL JS 2.0+ is 100% a no-go for games. Imagine paying $1/m PER PLAYER in your mobile game that often switches away from and back to the map? It's entirely unfeasible. Even a less-than-successful game might have 50k monthly active users, that's $50,000 per month in MapBox fees just for the privilege of loading this library. And a game that's based around enjoyment and player experience, and not being a cash-cow, every individual hosting $ counts... With the per-user pricing this would cost $100/m, which while still being a lot for a non-cash-cow, it's SIGNIFICANTLY more reasonable.

I might not mind paying a flat-rate fee (Assuming reasonability...) to use the lib, but charging for map loads when the application isn't even using MapBox hosted services is insanity.

---

What kind of billing model charges each time the tool/application/library is loaded? Imagine being charged every time you visited google docs, or opened excel, or every time you pushed a commit to GitHub. Imagine paying for every time you load an icon from an icon library, or paying for each API request to your own node/django/asp.net backend.

It's non-sensible.