Yup, love that post, mikel.

As has been pointed out at least by Frederik and Tim, I am stoking a conversation we have had before. So what has changed that should make it worthwhile to rehash arguments that seem we've already had? After all this conversation isn't always fun ;-)

Here's why I see dropping share-alike becoming more and more important for OpenStreetMap:

1. There is more open data coming online by the day and we are not compatible. Especially when it comes to the type of data OpenStreetMap captures. The proliferation of non-share alike open data sources makes OpenStreetMap the open data oddball that isn't compatible. We're the selfish player importing from all kinds of open data sources while we're limited in giving back, creating zero incentives for open data set holders to engage with OpenStreetMap (the NYC gov example).
2. The world is doing more stuff with raw data. There is a growing data economy of businesses, non profits and governments exchanging data in raw formats - for money or other benefits (the Wheelmap example and the Wikipedia example)

These are trends that have been gaining momentum in the past five years and I expect them to expand. OpenStreetMap's share alike license limits our participation here. We're a silo.

This conversation is also not a rehash of the GPL versus BSD argument of the software world. OpenStreetMap's problem is that share-alike's diminishing effect on utility is more severe for data than for software. Data isn't code. In many ways, data is the application. Data in its raw form has utility in and itself. This is very different from software. It is impossible to use an emacs editor in ways that extend its GPL license to the work I create with it. Yet with OpenStreetMap data the equivalent is possible. While as Simon said, the ODbL's share alike stipulations are limited to modifications, they do very clearly exclude important use cases and they come at the price of huge complexity.

Let me restate my examples from above clearer of what specifically is not possible or unclear under the current OpenStreetMap license:

• If the NYC government wanted to copy buildings that have changed from OpenStreetMap to the NYC building dataset they couldn't as their data needs to remain in the public domain.
• If Wheelmap wanted to offer wheelchair accessibility attributes it collects in OpenStreetMap to commercial data providers this a) severely questions on whether this would lead to existing POIs infected by share-alike (Simon's narrow interpretation of the ODbL might offer a solution here, but is by no means clear from the license text itself) and b) while the commercial data provider could create maps from the composite dataset, it would be impossible to relicense this data to others.
• Similar limitations exist for Wikipedia using OpenStreetMap data. As it stands, Wikipedia can only copy OpenStreetMap data where it is able to guarantee to make it available under the ODbL, cleanly separated from all other content available under different licenses (o the irony that OpenStreetMap gets to use simple facts off of Wikipedia as CC-BY-SA 3.0 is not effective on data).

In the light of a growing raw data space I am seeing these examples not as fringe cases but as a vanguard of future use cases that we should support as OpenStreetMap in a straightforward and unambiguous way. We'll want to support these use cases just like we want to allow everyone to create their own tiles from OpenStreetMap data without worrying about the license. I just don't see how we'll do this with the ODbL.

I am clear that while dropping share-alike would be a huge leap in the right direction, it might not be possible to solve all compatibility problems with a single license. What matters is taking steps forward. In this context, I do like the idea that SK53 brought up of special data sharing agreements with particular partners. What if the OSMF could grant the NYC government permission to extract any building and address data at no licensing restriction, essentially compatible with New York City's Local Law 11 of 2012?

OpenStreetMap's license is a strategic decision taken by the community, and we shouldn't take it lightly. More than anything, with this blog post I want to send a signal to anyone trying to do something today with OpenStreetMap that is not possible under the current license, to bring it up and explain their situation. I want to encourage everyone to not think about the OpenStreetMap license as something's that is set in stone. There is a mechanism to change the license and there are also good reasons why we should be open to do so. Participate in OpenStreetMap and say what you need it to be. OpenStreetMap's license does matter, even if our graphs look good. While they point to the top and to the right like Steve said they are not exponential with the exception of user registrations and shutting out applications of OpenStreetMap data does mean shutting out incentives to contribute.

Now to the flip side of the coin: the supposed protective function of share-alike. As opponents and proponents of share-alike have stated, the actual power of OpenStreetMap is its community. Today's data isn't worth a thing, the real power of OpenStreetMap comes in being able to create the map of tomorrow. If you're taking OpenStreetMap's data, close it and have your own paid army of surveyors, street view cars and digitizers maintain it, you've not hurt the project but made an incredibly dumb business decision: You couldn't do this without cutting the dataset off its stream of updates and thus the most valuable part of OpenStreetMap - the community.

Similarly, OpenStreetMap doesn't have to fear a thing from better contribution tools that somehow would entice a significant part of the OpenStreetMap community to defect to a closed source "enemy". In the end only an open data project with direct access to raw data can provide the basis on which a communal effort like OpenStreetMap can flourish.

What's more, in contrast to even large scale software projects, OpenStreetMap's community has a particularly strong position as mapping the world is a task of huge inertia and growing a community around this is an organic, slow process.

Let me also talk about my motivation for starting this conversation as some have questioned the integrity of my argument. I work at Mapbox where one of our key products, Mapbox Streets is based on the awesome OpenStreetMap. As company and individuals we've been involved in OpenStreetMap as mappers, designers and developers for years contributing or improving key projects like Mapnik, Carto CSS, the iD editor, most recently Leaflet.js and more. None of which based on the need to comply with a license, but because of individuals' passions and an understanding that in an open source project like OpenStreetMap, contributing yields huge positive externalities that help us as a business. We have a deep open source culture at Mapbox and that's not just because we may or may not be nice people, it's because it makes business sense.

Merely looking at our products, Mapbox is just fine with OpenStreetMap's license as-is, also in our days now as a venture backed company since October last year. We can cover the applications we're offering or planning to build out all under the ODbL. We're fine precisely because we're not competing on data, we're competing on the services on top of it, the legos we build for others to create location based applications. There is zero gain for us in owning data, it's a commodity and it is most efficiently managed in true open source commons like OpenStreetMap. Just look at how "well" some of the commercial data providers are doing.

Now would a better OpenStreetMap with more possible applications and thus better incentives to contribute and grow community and data benefit Mapbox? Of course it would. But wouldn't this also benefit everyone else involved, isn't this exactly what we have in common? The interest for OpenStreetMap to grow, to be successful and to matter?

It seems that this has been the understanding in the OpenStreetMap community all along. The past license change is a case in point. I am not proposing a change of course, I am pointing out that share alike is becoming an impediment to the project while it affords no particular benefit.

A much bigger effort is needed. I will continue to work on some of these issue.

David - how do you see this effort structured? Would rendering a map from current OCTO data and then trace from it be a good idea? Should we dump all street names of DC and compare them to a dump of street names in OCTO data? Is just using the TIGER 2012 layer a good approach?

Great summary. I wanted to highlight that the TIGER tracing layer Eric Fischer blogged about on Mapbox.com and that you mentioned here is highly actionable and available in OSM's iD editor plus you can add it to JOSM as described in the blog post.

Hey Pieren -

I'm not improving the Mapbox map data, the "your" map data

Of course you're not. You're improving everybody's map data ;-)

Just clarified that line, no offense intended.

https://www.mapbox.com/about/maps/

Hey there - you can easily install your own tasking manager from here https://github.com/hotosm/osm-tasking-manager

Mikel:

So in summary, I think good and well linked notifications management is a good idea. But there's really no significant technical changes, because if you posted to a group, you should also definitely be subscribed in some way.

Not quite. On a technical level I'm proposing to allow posting to a group (topic) that you're not subscribed to and to not automatically subscribe someone to a group (topic) that he/she posted to.

I do think we should automatically subscribe people to comments on entries they wrote and comments on entries they commented on (very similar to how it works today). There should always be an opt-out obviously.

Thanks for taking time to respond everyone. I really appreciate it.

My point here was less about no social on OSM, but about the merit of groups specifically. I think that was by and large clear but I wanted to reiterate this.

Now, this argument here from Richard is compelling to me and I'm starting to understand what we're really missing on OSM:

I see your point, Alex, that "today OpenStreetMap enthusiasts gather in spaces on mailing lists, Meetup.com, Twitter, Facebook, forums, and Google Groups"... but honestly, I don't think they do. Not over here, anyway. Super-connected guys in metropolitan areas are doing so, I guess, but that fixes London and NYC and SF - not the rest of the world.

With this in mind I took another look at the groups PR. Specifically, here's what I like about it:

1. Groups expand on Diaries
2. You can comment on a post in a group you're not member of

However, I still need to join a group in order to be able to post a new post to that group, I assume also email notifications will be tied to group membership. Could this be more open? Also: we'll likely wind up where we'll want to offer opt out email notifications of groups for the ones who read online.

I'd like to suggest a small modification to the group concept that I think makes the approach tighter:

• Do away with joining groups.
• Call groups 'topics'. Once there's no joining, the 'group' branding is misleading.
• Introduce an email notifications management page that allows for opt-in emails. Make this look great and prominent: "Subscribe to topics you're interested in".

This move, while technically a fairly small change, would bring significant improvements:

• allow us to conceptually tie what's called groups right now even tighter to diary entries
• not have a group join page and a notifications management page
• emphasize topics over people, "groups" rings always a bit exclusive "what makes me a worthy 'member'?"

Thoughts?

Thank you for taking your time to write this up:

My biggest confusion at first was that my edits didn't show up right away, and the interface provided no hint about why that was happening (so I wondered if I was doing something wrong).

https://github.com/systemed/iD/issues/1660

Any specific POI's you couldn't find in iD that make you switch back to Potlatch? iD is the intended successor to Potlatch so any suggestions to improve iD are more than welcome. Feel free to file requests directly to the GitHub repository for iD: https://github.com/systemed/iD/issues

seav -

I think another vital tool is a way to easily analyze a single changeset.

Interesting... didn't know of OSM History Viewer. I see it's slow computing some changesets, how could it be fast? Just preprocess them all?

Mikel -

Issue is that it only works efficiently at high zoom level

we could get to lower zoom levels by speeding up the API endpoints - i. e. getting tiled data. Not sure what'd be involved there in terms of setting up infrastructure or what existing APIs (overpass?) we could use here but it's a solved problem from an architecture perspective.

balrog-kun - I see, wasn't aware of a PDF. I just posted a ticket to Jeff Haack: https://github.com/hotosm/learnosm/issues/73

balrog-kun - I'm pretty certain there's never been a Polish version. I've been in the past tricked into thinking there was one as the Indonesian flag looks so similar. I'm sure a Polish version would be welcome though.

They just did this quietly? Or is there a larger announcement somewhere?

Hey karlos -

Check out the Taginfo projectt or pop into #ideditor and suggest your idea to tmcw, jfire, richardf et al.

If you'd like to see how taginfo is currently being used, check out iD's code: https://github.com/systemed/iD

Related reading:

• Taginfo in iD
• New API version for Taginfo

I see a flaw in your setup that might be the cause of a lot of the differences. Mapnik is not very determenistic and small variance in the input data such as order of elements etc. can make a big difference in the rendered map. You are using a relativly newly imported database for the carto rendering and a very old database for the osm rendering. For a propper comparason you should use the same database for both maps.

Thanks for pointing this out, Gnonthgol. I sort of had this hunch especially with label placement.

I would love to see some new development on the osm style.

Can't wait for that, personally.

Zverik: I just opened an issue for that

Stereo: you're spot on, I should be closer to the footprint :)

aseerel4c26: what looks like curve refinement, there isn't much curve refinement going on right now :) Glad you're excited about movement on iD though, expect a more comprehensive update on development status before the end of the year.

I don't think I would have ever made it to Hyattsville if not for OpenStreetMap. As ever, it's a perfect way to pay more attention and see the hidden world just around the corner.

Right on.

Here's a quick rendering of the changes produced so far from yesterday's mapping party, as far as I can see not all changes have been entered yet. Click for interactive map:

O, the town of Thank you, Montana :D

Thanks to you for setting this up!