Mapbox-gl-js is no longer under the 3-Clause BSD license

Mapbox has been extremely generous in releasing their rendering libraries under a permissive license. Creating a map renderer that matches the user experience of Google Maps is a FAANG-level effort, and Mapbox GL also encompasses:

* A single style specification format that works well for both base map rendering and data overlays

* Parity across native and web rendering

* Smooth SDF text rendering with decent i18n support

* A font to SDF renderer that is open source: https://github.com/mapbox/node-fontnik

* A tiled data format that is open source: https://github.com/mapbox/vector-tile-spec

I hope this licensing change can spur some competition among open source renderers. I’d recommend taking a look at:

* Tangram: https://github.com/tangrams/tangram - another WebGL based renderer with some key advantages over MapboxGL JS such as custom shaders and canvas text

* OpenLayers: https://openlayers.org has some vector and WebGL capabilities now as well

* Harp: https://www.harp.gl is another new WebGL option

I've been working recently with Tangram, so contact me (see user link) if you have questions or are interested in collaborating!

Thank you! I'd also like to list some of the building blocks of GL JS that remain open source and are heavily used in other open source projects:

- GeoJSON-VT (fast GeoJSON processing) https://github.com/mapbox/geojson-vt

- Earcut (triangulating polygons) https://github.com/mapbox/earcut

- Supercluster (point clustering) https://github.com/mapbox/supercluster

- vt-pbf (converting GeoJSON tiles to VT) https://github.com/mapbox/vt-pbf

- vector-tile (decoding vector tiles) https://github.com/mapbox/vector-tile-js

- pbf (fast reading/writing of protobuf) https://github.com/mapbox/pbf

- TinySDF (generating SDF from local CJK fonts) https://github.com/mapbox/tiny-sdf

- Potpack (generating sprite layouts) https://github.com/mapbox/potpack

- grid-index (spatial index for collisions/querying) https://github.com/mapbox/grid-index

- Pixelmatch (image comparison in render tests) https://github.com/mapbox/pixelmatch

- Polylabel (fitting labels into polygons) https://github.com/mapbox/polylabel

Can you comment on how likely similar future license changes are for these libraries? Thanks a lot for your work in the mapping space btw.

I'd say extremely unlikely — it wouldn't make sense both technically (stable, mature, small, razor-focused libraries that are already open source) and business-wise.

As far as I know as someone who worked here for 7+ years (take this as personal opinion), Mapbox wants to keep investing heavily in open source and open data sustainably and indefinitely, and this GL JS change is an unevitable prerequisite for that. This may not be easily apparent at this moment but it will be soon.

It is not only GL JS. If Mapbox wants to keep investing heavily in open source why is it that 3 bigger mapbox libraries have a commercial license after it was open source a while ago? (mapbox navigation android & mapbox GL Native)

Thanks Peter for calling this out. It's unfortunate that many businesses made the decision to work with mapbox-native and mapbox-gl-js based off the premise they could self-host and save money. It definitely feels like a bad bait and switch, and right after it gained market dominance too. Bad taste in my mouth for Mapbox products now, though clearly this is just whining because they will be successful with this change. They just get to feel like bad people for doing it, or at least I hope they do.

I wouldn't be working for Mapbox if it actually were a villainous company with an evil plan to "bait and switch" with open source, or undercut all these small competing businesses just out of spite, and it's easy to succumb to these simplistic conspiracies in the heat of the moment, but I do hope these sentiments will be short-lived.

“Oh look here’s an unattended purse, I need the money so I’ll just take it. They left it here anyway”

Introducing a drastic billing change under the implied threat that your year or more of man hours performed using an underlying open source library with an understandable billing model is now potentially at risk, is shady. These billing changes make some self hosted tile users go from $0 to tens of thousands of dollars a month in usage. It’s shady, don’t lie to yourself.

Also, you are not your company. I am not saying you are shady, because you are just a person who has bills and a skill and you need a salary. Don’t conflate criticisms of your employer as attacks on yourself, or you can have a hard time seeing what other people see. Tricking yourself to believe something that might not be true is one of the worst thing you can do.

> These billing changes make some self hosted tile users go from $0 to tens of thousands of dollars a month in usage. It’s shady, don’t lie to yourself.

This only happens if the developer deliberately upgrades and adds a token. If you do nothing and you keep using v1 - nothing changes for you.

That's the implied threat. Our business puts serious engineering efforts behind maps, such that it takes months of effort to change out mapping clients. We do this across three platforms. It will continue working for a while, but that $250k we just spent will need to be re-spent in the next 1-2 years as the old library falls to the wayside.

The frustrating thing is that we just went through this with google. We paid a reasonable amount, but then got extorted to pay more or jump ship. We jumped ship to a reputable company, mapbox, and we paid a reasonable sum of money for how we used the software, and now the cycle continues. To be clear, I am not complaining that we are paying $0 and we should get the benefits for free. I am saying that we shouldn't be jumped up multiple orders of magnitude in cost, which isn't in-line with our actual usage. That's the shady part.

Speculating (remember that I'm just an engineer and not in charge of business decisions), but perhaps because Mapbox tried really hard to build a business on server-side services alone while gifting most of its innovations to the world, and after a decade of enormous effort, keeping the client of such enormous complexity fully open source appears to be unsustainable? Would you rather see Mapbox getting eaten by big tech corporations and ceasing to exist?

> ould you rather see Mapbox getting eaten by big tech corporations and ceasing to exist?

With move like this, what's the difference?

(Yes, I do share anonfornoreason's sentinent in the sibling comment.)

There may be no difference for you with this level of vitriol, but there's a difference for hundreds of people who have jobs, and for dozens of engineers like me who will keep contributing to open source significantly at work hours.

The point was, that it is no longer open source, when ToS acceptance with rights of audit is needed.

It's no different to the likes of Oracle. Oracle also employs hundreds of people.

But hey, if you think everyone who criticizes it is full of vitriol, I don't think any further discussion is needed.

Congratulations on the V2 release! Does this release set the stage for (extruded) buildings to be "addressable" in 3D? eg. Can you place a marker 5 stories up on a 10 floor building?

About Polylabel, I found this blog post more informative than the readme in the repo.

How did I not know Tangram existed?!? You are a life saver!! Fantastic!

In Mapbox there was an easy way to build mapping tools. It let you create rubberbands, hook into map events. Is that possible with Tangram?

What a shame. I guess they got sick of people taking their code and ripping out their API subscriptions.

For anyone interested in an open source mapping library (that also has 3D support) that can handle raster data (including the Mapbox tiles), I launched a project 2 weeks ago that is the culmination of 7 years effort: https://github.com/felixpalmer/procedural-gl-js/.

I must say (while acknowledging my huge bias) that I'm disappointed with how the 3D terrain works in the new Mapbox version. It is the top-billed feature, but the controls feel clunky, the terrain often disappears and they didn't even bother implementing distance fog to give the scene scale. When they announced the 3D feature last year I was expecting more.

> For anyone interested in an open source mapping library (that also has 3D support) that can handle raster data (including the Mapbox tiles), I launched a project 2 weeks ago that is the culmination of 7 years effort: https://github.com/felixpalmer/procedural-gl-js/.

This is really impressive. Just one question about the distance fog, though: as you say it does give the scene scale when you're close to ground, but if you zoom out everything becomes foggy so it seems like it kind of gets hard to see anything. Wouldn't it make sense to somehow reduce the fog as you zoom out so this doesn't happen?

You're not the first person to point this out and the answer is: yes it does need tweaking. I'll add it to the list!

What other alternatives exist? I know now:

* openlayers, but vector tiles have no web GL support there

* Procedural GL JS

* tangram

* deck.gl (from Uber)

* harp.gl (from HERE Maps)

Openlayers has some prototype webgl support that's a bit promising. I enjoyed working with it (but hate working with buggy webgl in general).

Leaflet is also great.

If you're doing any sort of front end GIS I recommend openlayers above all else including mapbox.

But I suspect 99% of users just need basic maps. Leaflet is great for that.

Openlayers has web GL support but not for vector tiles and I would like to have fast vector tiles :)

They removed this support in some previous version, I think.

Or do you have a link to a pull request or issue?

(IMO Leaflet is dead now that the creator is working since several years for Mapbox)

7+ years to be exact. It's unfair to call Leaflet dead — it's still quite actively maintained, gets regular releases and has a huge community of both users and contributors, and Mapbox have always been supportive of me spending time on it during work hours.

What someone can see as less development activity is simply a sign of a mature product that doesn't need many new features and changes to remain useful — focusing on the core basic mapping needs has always been its goal, and it continues to adhere to it.

Thanks for replying and all your amazing work :) !

What I see or meant as a sign of "dead" is that there will be no new features that Mapbox GL JS has but that are critical for future applications. Like proper or inbuilt vector tiles support.

Reading this comment makes me a bit sad because I wrote a really good incremental tile based renderer for leaflet that could easily be adapted for vector tiles.

Unfortunately that whole business unit got canned and the code is now gathering dust somewhere :/ would have loved to open source that one

> Unfortunately that whole business unit got canned and the code is now gathering dust somewhere :/ would have loved to open source that one

I'd encourage you to reach out and ask for permission to release it. In the past I've found that the sticking point was usually copyright assignment rather than the release per-se (with a side helping of worry over hidden IP violations), so get them to release a tarball under a permissive license like MIT/BSD, even if your intention is to immediately fork it.

Basically, if you can manage to do the work for them so they can just rubber stamp the release, you can probably get it done.

> Like proper or inbuilt vector tiles support

I thought one of the primary features of Leaflet was its modularity. Would built-in vector tile support be an anti-pattern?

I suspect Leaflet's current install base is many times that of any alternative - it's certainly not dead, and I'd argue its simplicity makes it ideal for most basic mapping applications.

I work on WebGL in Chrome and WebKit and am interested to hear what problems you've experienced with WebGL.

I'm probably being very unfair given I'm new to it.

I've perpetually run into memory leaks and Max gpu issues whenever I try to use WebGL stuff in Openlayers depending on which browser I use.

Something will work fine in Chrome but max out my laptop's discrete card in Firefox until my laptop thermal throttles.

If you want a concrete example of this I would be happy to put together a reproducible example for you.

That would be great. There are a practically infinite number of things we could improve, and without feedback we won't end up working on the ones that matter to people.

+1 for CesiumJS, they have been doing 3D since ages... Also webpage mentions its Open Source from 2012 until Forever (Apache 2.0). I guess its time to switch.

I’ll add cesium also has commercial support and has been doing this for a while. It’s excellent. Patrick Cozzi and crew really know their stuff, highly recommend.

Does it have vector tiles support?

It has had 3D tiles for a long time. Not Mapbox 2D vector tiles though.

The ESRI JavaScript API https://developers.arcgis.com/javascript/latest/showcase/

It does 3d, 2d, vector tiles, client side geoprocessing, and plenty of open data/service types

Will any of these work with LIDAR data under their 3D rendering?

I'm keen on industrial archaeology and it's really helpful to have 3D visualisations of sites like old quarries.

Stand-alone 3D models can be done like [1] and the detail is substantially better compared to the map 3D views [2] (pits are pits again!) but I want to embed these into a website and start overlaying other data - just like I can with Mapbox maps.

1. https://sketchfab.com/3d-models/dinorwic-snakes-ladders-and-...

2. https://felixpalmer.github.io/procedural-gl-js/, search for Llanberis

Mapbox actually put out this blog post for visualizing point clouds in 3D with GL JS + Deck.GL in May 2019 - should still be totally possible!

https://blog.mapbox.com/coloring-lidar-4522ca5a7186

You might be interested in this: https://developers.arcgis.com/javascript/latest/sample-code/...

I have seen in demos coming from a few construction projects using this.

Note that deck.gl was originally developed inside Uber, but was donated to the Urban Computing Foundation (part of the Linux Foundation) and is now under open governance.

Looks like you're making good progress on windows, less spikes in terrain than I saw last time (I think it was the same project).

We also created a 3D renderer for sports tracking app Ayvri. Our standard player is Cesium, but if you click on the view beta link, you'll see our custom renderer. Still improvements to be made in tile loading.

https://ayvri.com/scene/v5plro09jr/cki6prg1a00013b6baegp6ub6

Isn't your custom player also Cesium? I see a Cesium logo in the top right on both players

Very very cool :)

Three observations:

- Why have a vertical limit when rotating in 3D? I have to click on 2D to look directly top-down. This would be the natural result if I simply tilted the camera all the way downward, but instead it maxes out at some arbitrary angle. (Same the other way, I want to look at the horizon, but I guess there are bandwidth issues involved.)

- Scroll zoom is waaay to slow. I have a mouse with an inertial wheel, so I can just let 'er rip, but this must be frustrating with a regular mouse wheel.

- +/- keys don't zoom, like I'd expect them to.

The camera limits are just defaults, and can be overridden. Manipulating a camera in 3D can be counterintuitive, so the defaults try to keep things manageable at the expense of flexibility.

As you say, the further you can see the higher the bandwidth bill. If you really want to see the horizon, make the window narrow :)

For the other issues, could you please file a issue on the repo? This is not expected and works great on all machines I've tested.

I've also noticed a minor issue, I don't have time at the moment to file a report on github.

I noticed on the demo that if I zoom all the way out, and then use my mouse wheel to zoom in quickly enough I can clip into the earth and see the black below. This does seem to depend on scroll speed being high enough.

Kudos to you. Was a cesium user for a brief period in time. This domain is deceptively difficult.

Kudos for great project. I did see some funny looking monument looking artifacts while browsing your NZ parks examples.

procedural-gl-js is very cool tech! It's unfortunate it doesn't work globally, above 60 degrees north (yet?).

Well, that sucks. I've been a happy Mapbox GL JS user for years, hosting my own tiles and not using their service at all. I even had a few (very small) pull requests accepted into the project. Hopefully the OSS community can maintain a fork of the 1.x codebase.

-edit-

The FAQ says developers can still use self hosted tiles, but also says that usage is now billed per map load, and "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.".

To me that sound like while I can still use my own map tiles, it would still costs the same as if I used Mapbox hosted tiles.

> To me that sound like while I can still use my own map tiles, it would still costs the same as if I used Mapbox hosted tiles.

That's my reading of it, as well. Even though it's somewhat expected on the data collection side, it's decidedly unexpected that they not only require ToS acceptance, but also licensing fees for what used to be entirely free, OSS software.

> Hopefully the OSS community can maintain a fork of the 1.x codebase.

I'm sure this will happen. My company is trying to get some consensus around the best way to proceed. Email in bio if you're interested in taking part!

The https://github.com/openmaptiles/gl-js proposed as the primary shared repo for an open-source fork of the Mapbox GL JS 1.x codebase.

Let's set autobuild of documentation, packages and configure CI on pull requests. Pull requests, forks & contributions welcome - as on other parts of the https://openmaptiles.org/ project providing free and open-source vector tiles of entire world for self-hosting.

LOL haven't you guys had enough legal trouble with Mapbox already ;)

In all seriousness I completely agree as someone in the mapping community this seems like a logical home. You have my vote!

Hopefully the fork will be GPL, so Mapbox won't be able to steal all of the work the new developers do and release it in their new proprietary product.

Why not? Mapbox has been allowing us to steal the work of their developers and release it in our proprietary products up until this point.

Because if they can take all of the improvements from the fork, but the fork can't take any of their improvements, the fork will wither and die.

That's not the case. There is already a massive ecosystem around MVT (vector tiles) that needs an open source renderer. Mapbox GL can have all the bells and whistles it wants, but since it's still tied to Mapbox's SaaS pricing, it's not a viable alternative for that ecosystem.

Can't you just use the old version? Only the new code is under this new license.

Of course! And that's what everyone will keep doing for a while. However, without a maintained version, it will eventually wither from neglect.

We're still using v0.47 on our project! Our use case is basic, and we like map rendering to be a set it and forget it deal. Since 0.47 I hadn't ever thought, "I wonder if there's an update." Of course, NOW I'm thinking about it. And I'm thinking of switching to leaflet.

We make a competitor to MapboxGL for mobile called WhirlyGlobe-Maply (https://mousebird.github.io/WhirlyGlobe/). It supports vector tiles & Mapbox style sheets, works on Android and iOS, even supporting Metal on iOS. Indirect mode in Metal, actually, which is no mean feat.

WhirlyGlobe/Maply has been around a long time. It actually predates MapboxGL and it's used in popular apps like Dark Sky, as well as a ton of aviation apps and a not a few GIS apps.

Engineers like to write their own, so we're going to hear from a ton of random projects here. And hey, more power to 'em.

But you're looking for a fast, open source mobile map toolkit that's going to be around next week? It us.

> Upon written notice to you, we may (or may appoint appoint a nationally recognized certified public accountant or independent auditor to) audit your use of the Services and Mapbox Software to ensure it is in compliance with these Terms. Any audit will be conducted during regular business hours, no more than once per 12-month period and upon at least 30 days’ prior written notice (except where we have reasonable belief that a violation of these Terms has occurred or is occurring), and will not unreasonably interfere with your business activities. You will provide us with reasonable access to the relevant records and facilities.

LOL no.

This follows the same happening for Mapbox GL Native (iOS/Android) earlier this year.

With Native it's more critical. A GL JS fork can continue quite easily. The iOS Native library, however, uses OpenGL and will therefore stop working when Apple finally switches to Metal-only. (Mapbox only released their Metal port under the new proprietary TOS.)

Can you point to where/when this happened for their native code? As far as I can tell, that's still licensed under 2-clause BSD (https://github.com/mapbox/mapbox-gl-native/blob/master/LICEN...)

Even with just 3666 daily loads, you will pay them 10 USD/day for using the code on your site! "Beginning with v2.0.0, a billable map load occurs whenever a Map object is initialized."

Under 50,001 monthly loads is free but after that it costs $5.00 per 1,000 loads: https://www.mapbox.com/pricing/

Can someone confirm this? Do you need an actual Mapbox token to even run an offline map from data you've downloaded off of, say, Maptiler?

The quotes are directly from Mapbox. "Usage of v2 is billed by Map Load to the Mapbox account owner. The license terms make no distinction between data sources." https://github.com/mapbox/mapbox-gl-js/issues/10162

> Mapbox GL JS v1.x.x: A map load occurs whenever a Mapbox GL JS Map object is initialized on a webpage and you request a Mapbox-hosted map tile.

> Mapbox GL JS v2.x.x: A map load occurs whenever a Mapbox GL JS Map object is initialized on a webpage. https://docs.mapbox.com/help/glossary/map-loads/

"This license allows developers with a current active Mapbox account to use and modify the Mapbox Web SDK."

"This license terminates automatically if a user no longer has an active Mapbox account."

- https://github.com/mapbox/mapbox-gl-js/blob/main/LICENSE.txt

also

> 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.

They're charging for Mapbox GL JS, even if you don't actually use their tiles.

https://github.com/mapbox/mapbox-gl-js/issues/10162

I wrote that paragraph and I agree with the decision to change GL JS's licensing.

I'd love to hear more of your thoughts on this. Was it wrong to openly license v1? Or the market changed enough from v1 to v2 that necessitated this change?

I'd be interested to hear why. I have no problem with companies choosing not to open source in the first place, it is just the idea of taking an open source project with an active community around it and closing it up that is a tough pill to swallow.

I won't get into all the context, but I think we should consider whether a community without contributors is a community. GL JS never had major active contributors outside of the company, and there are no self-funded webgl experts with lots of time who are ready to maintain a fork.

OSS, we hoped, was about enabling people and unlocking people's ability to collaborate. It turns out that in 2020, it's mostly helping companies and getting nothing in return. That's not a dynamic you can build a sustainable business on.

Oh come on Tom. Making a great, free toolkit utterly decimated the competition. Just completely destroyed any funding for a competitor. And I should know.

I believe that you believe this is well intentioned, but it had a very negative impact on open source geospatial software development. Again, I SHOULD KNOW.

Mapbox is doing what is good for Mapbox. It's a company. But let's not pretend this change is good for anyone but Mapbox.

If by open sourcing initially it hurt their competition, surely by going proprietary now it should help their competition (and FOSS geo stuff generally)?

For those competitors who still exist, maybe a little. But once a solution is entrenched and it isn't tooooo onerous, developers won't switch away.

It's certainly true that GL JS and Native never really got third-party contributors, and that the complexity of the task is a major reason; like you say, there aren't many GL hobby devs. Another reason is that they're simply great libraries and there hasn't been that much reason for anyone to contribute - I can only ever recall encountering one significant issue and it wasn't a showstopper.

But there's more to it. When the roadmap of an open-source project is tightly controlled by a sponsor, that can make third-party contributions hard or impossible. I know OSRM much better than MBGL so I'll cite an example from that - the distance matrix issue. This is massive for many users, plays right to OSRM's strengths, but Mapbox wouldn't accept patches to provide it for _years_. IIRC it only got in when Mapbox's attention shifted to Valhalla.

I'm not blaming the Mapbox devs at all for that; it wasn't important for Mapbox's business, and any extra code inevitably brings a maintenance burden. But it partly explains why third-party contributors are reluctant to contribute when the roadmap's out of their control.

Back on MBGL, there was/is a community, but the community formed around MVT rather than MBGL specifically - again, possibly because MBGL is just so good. https://github.com/mapbox/awesome-vector-tiles sums up the enormous community energy in the space (I think that might be your document originally, apologies if not). It's kind of a shame that MBGL being so far ahead of everything else has probably crimped development on alternative renderers.

I'm really sorry to hear it didn't work out the way Mapbox would have needed. However, pull requests to the core are not the only way to contribute to an open source project: think of all the map data you needed (by OSM contributors), all the bug reports you received, all the code people built that supported your paid product ecosystem (the map APIs).

Regarding code contributions, the community contributed e.g. the TypeScript and React bindings, or am I mistaken?

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

https://github.com/urbica/react-map-gl

https://github.com/visgl/react-map-gl

I'm one of the more frequent non-Mapbox contributors to the project. I've made a lot of PRs over the years and I try to help out with reviewing PRs and to triage incoming issues.

While I agree there has been non-trivial contributions external to the core of gl js (eg. bindings, plugins), and these help the ecosystem, they don't replace work on the core.

Personally I'd hoped that those businesses who were using GL JS commercially without a commercial subscription through Mapbox would contribute and become part of the core development and maintenance, but that didn't happen to a large degree.

An incredible ironic statement since what you’ve done is only possible because of open source. If you don’t realize that taking a huge dump on the open source community will have profound consequences for Mapbox then you’re in for a surprise.

It won't make much difference. The damage is done, Mapbox has remade the community in its image and we can only live in that world.

You may be right, it’s certainly a complex area. But I do think this will put a lot of wind in the sails of Mapbox’s competitors. The inevitable fork of version one will serve most people’s needs and it may pick up some real momentum. But most of all, I think the move will generate an incredible amount of ill will in the developer community. Who would trust Mapbox after this kind of bait and switch? Why would anyone use anything coming out of Mapbox if they have any kind of alternative?

Communities have a way of escaping corporate thinking, when enough of us agree on something. :)

I don't understand your last paragraph. On the one hand you're saying OSS in 2020 mostly helps companies, but on the other hand you say this dynamic of company-helping is not one that you can build a sustainable business on. Am I missing something?

To be clearer: "it helps other companies, for free."

I have proposed MapLibre as a new home, unaffiliated with any existing project, but at the same time inviting maintainers from everywhere, including OpenMapTiles (I'm a big contributor there), as well as other entities. So far a lot of positive response on twitter, hopefully it will pick up. See original post at https://twitter.com/nyuriks/status/1336493514646052864 (includes a nice reply from MapBox CEO)

Could we change the title to more clearly reflect that this is a license change from a permissive to a restrictive licence? Maybe "Mapbox GL JS v2 no longer uses a permissive license"? I initially thought by the title that Mapbox had removed the library from GitHub completely.

What is this talk about "permissive" licenses? It was open source, it's not open source any more. The Open Source Definition: https://opensource.org/osd

EDIT: The title has now changed but it was "Mapbox GL JS is no longer open source", which is the point: they didn't change from an open source license to another.

To be honest I just wanted to see a more descriptive title specifically to avoid the tired, unproductive discussion of "what is open source".

No need to discuss what is open source as there are agreeing definitions by multiple parties (OSI, FSF, Debian etc.). How is it more productive to use terms like a "permissive" and a "restrictive" license for which there is no generally agreed meaning?

I guess we should expect to see a fork of the v1 codebase?

Founder, Stadia Maps here.

We're looking into this, as well as trying to build consensus with the other map vendors on how to approach it.

If you're a vendor and what to be part of it, email me (luke at stadiamaps.com).

Glad to see this. I’m a long time mapbox gl js user for https://onthegomap.com which costs $300-400 per month for running my own graphhopper routing servers and Stadia Maps tile hosting. It would cost over $3000 per month to upgrade to 2.0 and I have no need for 3D.

I also use mapbox gl js for visualizing large datasets locally (precomoute vector tiles from non-geographic datasets), which doesn’t seems like it needs to be reaching out to mapbox servers.

Happy to help, I’ve had a few pull requests accepted to the mapbox gl js codebase.

Switch to OpenLayers e.g https://openlayers.org/en/latest/examples/index.html?q=mapbo... (the example can use Mapbox but any vector tiles styles are fine). It can consume Mapbox GL JS styles if using ol-mapbox-style project https://www.npmjs.com/package/ol-mapbox-style#olms. A bit slower but except this, most of the things are supported. PS: fine if you don't use 3D

I use your site all the time to measure running routes - Thanks for the great work!

Any plans for monetization you can share? $300-400 per month seems an expensive gift to the public ...

The site shows google ads when the screen is big enough, luckily that covers the monthly hosting costs. Would definitely like to find a value-adding (rather than reducing) way to cover the costs though. I've been thinking about adding an account system where you can save a couple routes for free and unlimited with a subscription, along with other "premium" features, but haven't finalized anything yet. Definitely open to suggestions :-)

I've found Patreon works well for my site (cycle.travel).

side question: who are you using for satellite imagery? I see them being served from ArcGIS but can't find a tile service offering from them.

Yes, ArcGIS World Imagery https://www.arcgis.com/home/item.html?id=10df2279f9684e4a9f6... - from everything I can gather in their docs and talking with sales reps, it is fine to use with proper attribution, which took a bit of work to update dynamically as you pan to different regions.

I love your site, thank you for building it!

Where's the active OSS fork? Surely one will shake out of all this.

Doesn’t deck.gl also use map box? What are they doing?

deck.gl is completely independent from Mapbox and Mapbox GL JS. You can use it with Google Maps, for example; most people used it with Mapbox because it was the most advanced open source basemap available.

We'll probably end up removing Mapbox from the deck.gl examples, but I can't say for sure.

Yes, I'm a maintainer of deck.gl. That's a development dependency, not a runtime dependency. You have the option of using deck.gl completely standalone [0], or integrations are provided for Google Maps and Mapbox GL JS [1]

[0]: https://deck.gl/examples/tile-layer/ [1]: https://deck.gl/docs/get-started/using-with-map

Cool, thanks for the clarification!

> We'll probably end up removing Mapbox from the deck.gl examples

If that's because of the licensing, would you remove Google Maps & ArcGIS examples as well?

Sorry I painted too wide a brush... Some of the examples are integration examples, and I fully expect we'd have at least one example for Mapbox, Google Maps, ArcGIS, and hopefully more providers in the future.

The rest of the examples are to show deck.gl's capabilities. They currently use Mapbox GL JS v1 (recently changed to use Carto's basemaps so that new users can test deck.gl without any API key). Those examples focusing on deck.gl are what I meant to refer to originally; it seems unlikely we'd move them to GL JS v2, at least, because we aren't currently using Mapbox services with them. (But again, the team hasn't had full discussions about this yet).

It looks like they integrate with it, but don't require it directly.

We tried to implement mapbox on a new product last week. I like the style options for the maps but their reverse geo lookup and local search performed poorly vs google maps.

Pins dropped down the street from actual address and search results don't narrow in accurately using POI and city/state - for example "Chipotle Parker Colorado" rather than showing the 3 chipotles in Parker, CO lists:

- the city "Parker, CO"

- Parker street in Pueblo, CO

- childrens hospital therapy center in Parker, CO

It just doesn't match the behavior our users have - probably because they have been trained how to search using google and google maps.

I am guessing the main use for mapbox is actually custom tiles and custom datasets but anyone using it as a replacement for google maps I'd love to hear if you were able to solve this without too much trouble. We preferred their API, sdks, and pricing over google maps but just couldn't get the results we wanted.

https://docs.mapbox.com/search-playground/

Try us out at Geocode Earth! (https://geocode.earth)

We wrote and maintain the open-source Pelias geocoder(https://github.com/pelias/pelias) at Mapzen and have been continuing to improve it in the 3 years since Mapzen's shutdown.

Geocode Earth is our hosted service built around Pelias so you can get started quickly, not worry about keeping data up to date, or doing all the fine tuning and optimization that we've had to do to get fast and reasonably accurate autocomplete outside of Google and Mapbox.

Using our hosted comparison tool you can see that we do a pretty decent job of finding two out of 3 of the Chipotles (the third might have been deduplicated or not in OSM): https://pelias.github.io/compare/#/v1/autocomplete?text=Chip...

Most our users end up passing a focus point, in which case the results are generally even better, although they're the same in this example https://pelias.github.io/compare/#/v1/autocomplete?focus.poi...

Nice - tested a bunch of the ones we were benchmarking against and they all worked well!

We will keep you in mind as our usage grows or if we have another project. Your tiered pricing doesn't make sense for us as we launch.

Great, glad they worked!

Thanks for the good feedback on our pricing. We plan to roll out pay-as-you-go pricing in 2021 that should help with that. In the meantime feel free to reach out to us at [email protected] and we can set you up with a smaller plan to get you started, if you'd like.

Geocoding is really hard. :)

https://opencagedata.com seems to be the best around using open data and offer API compatibility (or did at last check).

afaik, Mapbox's geocoding service was never meant to provide the lng,lat of retail entities.

Looking over their API docs, you can search for points of interest (POI), but that's it: https://docs.mapbox.com/api/search/geocoding/

For your use case, you should look into a geocoding service [0]. And then you can display the location results with your mapping library of choice. Google Maps does provide an all-inclusive service, but as you've mentioned, styling is better with Mapbox (and pricing).

[0] - Aside from Google and Mapbox, I've never used any of these alternative geocoding services: https://smartystreets.com/articles/is-there-a-geocoding-api-...

> The Mapbox Geocoding API does two things: forward geocoding and reverse geocoding. Forward geocoding converts location text into geographic coordinates, turning 2 Lincoln Memorial Circle NW into -77.050,38.889.

https://www.mapbox.com/place-search

I think "location text" is the part they are not parsing well.

The screenshots all over that page show someone entering a couple of letters and getting the resulting POI with address.

Unfortunately, we could not get reliable results using their web place search so maybe they just have better mobile sdks that are adding more filter data to the requests automatically ¯\_(ツ)_/¯

You're right, Mapbox does claim to search for businesses.

If you're sticking with Mapbox, you'd probably need to a two-step lookup to obtain some useful results.

1. If there's no street address, check the search string to see if there's a city, or city, state. Find the lng,lat of that to use as the proximity bias. If nothing exists, use the user's current location. (Maybe this is why the mobile SDK is better.)

2. Then add the proximity bias while searching for the POI

But just a heads up, even a simple city query can be problematic. From personal experience, "san jose" would return San Jose in Costa Rica, or San Jose City in the Philippines, and rarely San Jose, CA, US unless a user was to type all that.

Google definitely has better NLP to handle user search queries.

Their geocoding seems to work decently enough for street addresses from what I've seen, which is what it's technically advertised to do. It doesn't have a Google-sized database of business entities, so I'm not surprised it doesn't work for any POI less significant than a major landmark (i.e. "city hall", "the statue of liberty", etc.)

Pretty common to use Google to look up an entity (to either get address or full geocoding results) and then Mapbox to do the display though.

This is going to fracture the fledgling community building on mapbox-gl-js - I expect we'll see a divergent BSD version as a result.

I regret building out on mapbox-gl-js rather than leaflet...

Tangram is pretty nice if you end up not finding / wanting one of the forks of mapbox-gl-js

You can keep using v1.13 (or earlier) for now. It looks like there's significant community support for an independent, open fork (see my other threads). More on this soon.

Forked from version v1.13.0, the last released tag with the BSD license. Sigh. I use this for something that doesn't use their map tiles at all.

Hundreds of new forks on Github in the last few hours. Maybe there will be a semi-official community version.

It’s in the works! Lots and lots of community interest. Working out the details of governance, code hosting, etc., so that one commercial entity isn’t the sole controller of what comes next. Email me (in bio) if you want looped-in.

Sent msg. I figured that would happen. I have one minor site that uses it, but others have much more significant uses.

We're working on a community-driven fork of mapbox-gl-js here: https://github.com/maps-gl/maps-gl

Our initial primary goal is to avoid fragmentation, and thereby support a healthy OSGeo community.

Updating from mapbox-gl-js should be pretty smooth, I just pushed the first batch of release builds to npm for what will become [email protected]: https://www.npmjs.com/package/@maps-gl/maps-gl

Link to the new LICENSE terms https://github.com/mapbox/mapbox-gl-js/blob/v2.0.0/LICENSE.t...

IANAL, but it seems you can only use the library if you have an active account, and you can still modify the code except billing and analytics. The it links to the TOS ( https://www.mapbox.com/legal/tos ).

Plus when you deploy something, you have to pay a significant amount for using the library.

After the 50k free map loads per month.

1667 free page loads per day is significantly more restricted than the earlier infinite free loads (of non-Mapbox content). Also, they can change the pricing at any time and some uses might suddenly become unfeasible essentially pulling the rug from under your feet (same as happened with Google Maps pricing earlier).

Well, yes, any finite numbers is significantly more restricted than infinity...

Happy mapbox customer here, but unfortunately I expect some of the longshot feature requests may never see the light of day now that outside development contributions are going to go to zero.

Is there any OSS or economical (Non-ESRI; non-Google) commercial solution for WebGL maps and vector base layer that supports non-mercator projections without hacks? (Arbitrary projections, not just distorting mercator onto a spehere)

I would be more inclined to just keep using 1.x. That plugin is much less performant and doesn't have 3D or rotation.

Well that sucks. Is this to try to clamp down on users circumventing subscriptions, or something else?

The weird part is that you were always violating your contract with Mapbox by circumventing their billing code[0], so now you just have a copyright violation added on top of that. The way to bypass it is identical to what it was before.

But, the big change is in their issue[1] they opened about it:

> 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?

They're charging for Mapbox GL JS, even if you don't actually use their tiles.

[0]: https://github.com/mapbox/mapbox-gl-js/blob/c7ed000f6d628531...

[1]: https://github.com/mapbox/mapbox-gl-js/issues/10162

People have been using the open source library without using any Mapbox data or APIs and thus within the terms. The map data is open data by the OpenStreetMap community etc. anyway.

I guess they don't like that people can generate their own vector tiles more easily nowadays, or services like Maptiler [0] (see [1] for some more context) that provide tiles at lower costs.

[0]: https://www.maptiler.com/mapbox-alternative/

[1]: https://www.maptiler.com/news/2020/05/the-future-of-openmapt...

There really aren't many competing tile services. Maptiler isn't necessarily cheaper - it depends on the exact volume, and it has changed back and forth over the last couple of years as each party changes their pricing structure.

It's understandable. People tend to forget the obvious, that the primary goal of Mapbox is to make money. Investors have given their money to Mapbox with the expectation that they will get back more, preferably much more.

I have nothing against people wanting to make money but don't put a free product then yank it out under my feet once I'm comfortable using it (I'm not affected in this case since i don't use mapbox, but the CentOS treachery is still hurting).

At least 50% of my work projects happen because the resources I'm using are free. If it isn't free, the project either doesn't happen, or I spend a few months coding what is missing.

So I'd rather they tell me upfront that I can't afford their product than waste my time.

> but don't put a free product then yank it out under my feet once I'm comfortable using it

Why? This strategy often maximizes shareholder value. Provide a free product in the growth phase and once you shake off competitors and build a moat (aka a monopoly), you start taking profits. Charging money during the growth phase will slow down the growth.

Because it's a dick move to waste people's time, and it's also a dick move to expect 'but I'm maximizing shareholder value!' to make people feel better about their time being wasted.

I can't tell if you're serious or if it's sarcasm but I'll assume it's serious.

First as bigbubba said it's a dick move and second, do you really want users that have no trust in your company. Google is missing a lot of potential users for its cloud business due to them killing products on seemingly random basis.

I was just trying to explain how Mapbox investors think. Their primary goal is to grow Mapbox as fast and possible and then make money, that's why they've invested in the first place. They don't care that some people could consider their strategy a dick move.

There are many companies making money with open source. Mapbox used to make money by providing APIs - apparently it didn't work out.

How are they able to change the license of code that people committed under the 3-clause BSD license without the permission of those people?

Read the BSD license. There's nothing preventing the code being redistributed in another product (in this case, Mapbox JS v2) under any license terms whatsoever, as long as the copyright holders are appropriately credited.

I don't see an issue with this - It's well understood that this can happen with permissive licenses, although often it's from BSD -> GPL/copyleft license.

Because the BSD license is a permissive/pushover license, which let you relicense other people's work as proprietary. The reason that copyleft licenses like the GPL are better is exactly that they don't allow this sort of behavior.

99% of the code in Mapbox GL was written by Mapbox employees on company time. The GPL would have made no difference.

Except in practice, removing that 1% (or getting permission from its contributors) could be extremely complicated.

They aren’t changing the licence of the existing code.

It's open source code; you use it like any other open source code, ship the license with the software.

Will bug fixes for Mapbox GL JS 2.x be backported to 1.x (by the Mapbox team)?

From the Github issue: "Updates to the v1 releases will be made only for critical browser compatibility or security issues for a limited time."

Does this mean "private repo" closed source, or "don't copy paste our shit" closed source?

>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.

See: https://github.com/mapbox/mapbox-gl-js/blob/main/LICENSE.txt

"Pay $5 per 1,000 page loads" closed source.

Up to 50,000 - Free

https://www.mapbox.com/pricing/ A map load is counted every time Mapbox GL JS initializes on a webpage or in a web app. A map load includes unlimited Vector Tiles API and Raster Tiles API requests.

So, now we must be careful not to clear out such initializations? Not React friendly at all.

Closed source nonetheless.

That doesn't answer the question. And has nothing to do with closed source, really.

So C cannot answer the false dichotomy of A or B?

Not all closed source software is pay-per-use, but this one is. And can you point me to an open source license that requires pay per use?

This move to closed source stops the free use that was possible this far with the open source license. To me, that's a plausible motive. Is there a more significant one?

yeah, posted notes/deets https://www.mapbox.com/blog/mapbox-gl-js-v2-3d-maps-camera-a... Developers need a Mapbox account and access token. v2 is available in the same way as v1 -- the project source code is available on Github at https://www.mapbox.com/blog/mapbox-gl-js-v2-3d-maps-camera-a... for open collaboration with the community. New features will be on v2.

Please stop the open-washing: v1 was available under the BSD open source license, v2 is not. You are making a fool of your company by acting as if open source is not important.

Why would the community want to collaborate on a project that's not openly-licensed?

There might be a bug that only affects a handful of people and doesn't get prioritized by the company. Then one of those people might want to collaborate on the project just to get their personal pain point fixed.

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

It was open source (BSD licensed) before today, 9:23 AM. That is when version 2 was released.

That's the 3-clause BSD license. (OSI approved)

Thanks. Didn't recognise it as BSD at first glance

Wait, I thought that open source was the panacea? Why are they switching away from it? Maybe if they used GPL they would have done better?

It is as if people were exploiting their ideological free labor for personal benefits... weird how the real world works...

Mapbox-gl-js is no longer under the 3-Clause BSD license | Hacker News

Recommend

Google maps price hike…

mapbox-gl-js/LICENSE.txt

Parsing JSON parameters stored in AWS Parameter Store using jq

Hot reload tailwindcss changes with browser-sync

Accessing local domains in local dev environment from Android emulator

Minimal IAM permissions for AWS CDK deployments

Microsoft 365 and Power Platform User group - India

What's new in Microsoft Teams

Microsoft 365 Saturday Gurgaon (19-Sep-2020)

M365 Saturday Gurgaon 2020

About Joyk