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
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
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?
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.
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?
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?
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.
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.
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.
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.
+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.
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.
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.
- 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.
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.
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!
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.
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.
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.
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.
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.)
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."
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.
> 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.
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)?
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?
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.
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?
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?
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.
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?
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.
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 :-)
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.
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]
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).
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.
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.
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 hello@geocode.earth and we can set you up with a smaller plan to get you started, if you'd like.
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).
> 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.
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.
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.
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.
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 maps-gl@1.13.0: https://www.npmjs.com/package/@maps-gl/maps-gl
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 ).
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).
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?
> 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.
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.
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.
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)
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.
>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.
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.
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?
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.
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...
* 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!