v2.0 changes merged with updated TOS and license #10162
Comments
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? |
So I'm trying to understand this change. Am I correct in thinking that in version 1 I could What is the thinking behind this? |
|
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/ |
|
First of all, I want to thank the Mapbox team for their great work. I use I believe this change with billing for each Map load (independently of mapbox.com services) could be very disruptive. In our company, we use For example, we have a CI/CD pipeline with a huge amount of integration specs using Headless Chrome. 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:
I understand that mapbox.com is a business that should make money, no complaints here :) It's necessary to keep the development of the The old billing model was great for us. We were able to use The new billing model introduces many complications and feels unfair:
In my case, we definitely would stay with v1. Of course, it's your right to change billing for the new version. I really hope that there is a place for discussion to keep the previous billing model. |
|
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." |
|
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. |
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. |
@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. |
|
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 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. |
|
https://github.com/hewegoz/mapbox-gl-js |
|
@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. 👍 |
|
Question: is offline use still possible? (Both technically, and legally speaking). |
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. |
|
goodbye mapbox, good luck！ |
|
Usage counts even if map object is initialized in my localhost???.. what if some automated testing tools ran my application ??... |
Seems like you hadn't considered quite some things here. The v1 fork has already happened. This is turning into a mess in a matter of hours... |
|
Are there any free plans available for other open source and free softwares who wants to use just your mapping api? |
|
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. |
|
If anyone is looking for a community maintained derivative of mapbox-gl-js v1, please consider merging your efforts into: 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 |
|
@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 |
|
I'm sorry to hear that. Understandable, but hard to accept. |
|
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. |
mourner
added
the
breaking change ⚠️
|
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:
I truly understand that this is Mapbox's internal decision, and may not be something allowed to share. |
|
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]. |
Their company must be really struggling for them to even consider pulling a move like this one so they got nothing to lose. |
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. |
|
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. |
|
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:
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. |
|
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. |
|
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. |
/mapbox/mapbox-gl-js/issues/10162#issuecomment-741596929
/mapbox/mapbox-gl-js/issues/10162#issuecomment-741596929
|
This license change is a bummer. I loved your library and appreciate the amount of work you're putting into it. But for our project, the price tag is way too high. Guess we'll have to use the fork now. Sad. |
|
Just wondering, how did they relicense this without getting permission from the many people that commited work to it? Seeing as they don't seem to have any form of those people having to sign away their right to their code? Thankfully I don't use Mapbox itself and only their tile service for my website because I use CesiumJS but still something seems fishy. |
There is a CLA at: which includes the note that BSD is a do-what-you-want license. |
|
That CLA is for the 2.0 version correct? So how did they relicense it (breaking clause 1 of the BSD-3 license) with out permission from all the people that commit to the work? |
ghost
mentioned this issue
Old code wasn't relicensed; it's still under BSD-3. Like @mvl22 already explained:
So while some parts of mapbox 2.x are still BSD-3, other parts are not. Which also means you can copy certain code (publicly commited before December 3) from mapbox 2.x and use it in a BSD-3 project. The combination of old and new code (like a mapbox bundle), will have to satisfy all involved licenses. So BSD-3 clause 1 isn't broken because the 2.0 source-code still contains the BSD-3 license, which satisfies the BSD-3 requirements: Lines 24 to 51 in 92be4e0 All new code is under mapbox license so the BSD-3 doesn't affect it, so there isn't anything that can be broken. |
|
Yet there is no clear way to see what is new code and what is old code. Also I am surprised that in their update release post they never mention the change in bill / the move away from an being an opensource library or anything of that sort and basically say go ahead and switch to 2.2.0, seems a bit rotten. Also how does this affect old code that mapbox say edits under this new license? It can't be licensed under the new license due to BSD-3 but it can't be BSD-3 due to the new license. |
Why would they? It's a business decision and marketing wise it wouldn't be smart to announce this loud and clear.
Like you implied: It can't be relicensed, so old code fragments remain BSD-3. If any portion of the new changes touch / refactor BSD-3 code, then they also still have to include the BSD-3 license because all those tiny bits that weren't touched remain under BSD-3. However, the potential existence of new mapbox CLA code (creating a mixture of BSD-3 and mapbox CLA) means you can't easily copy code from mapbox to your own BSD-3 project anymore (at least not sections which got somehow touched since December 2020) - it's acceptable for the BSD-3 portion, but the new mapbox CLA portion prevents it. Effectively, it doesn't really matter and it also gets philosophical really quickly: https://en.wikipedia.org/wiki/Ship_of_Theseus |
You can just diff against the last public release, v1.13. That's the beauty of version control. |
and others
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 (<v2) remain publicly available via NPM and our CDN endpoints. Updates to the v1 releases will be made only for critical browser compatibility or security issues for a limited time.
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:
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
Mapobject 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
The text was updated successfully, but these errors were encountered: