OSM Licensing & ODbL Compliance

Licensing is the one part of an OSM pipeline where being approximately right is not a defensible position, and where the cost of getting it wrong arrives years later, in a conversation nobody wanted to have. It is also, once the vocabulary is clear, far less complicated than its reputation suggests.

The one distinction the licence turns on A decision node asking what is actually being distributed, with three outcomes. Distributing a map image, a report, a rendered tile or any other visual or textual product is a produced work, which requires attribution and nothing more. Distributing data that somebody else could query or extract is a database, which requires attribution and, if it is derived rather than merely collective, share-alike. Distributing nothing at all, because the data is only used internally, carries no distribution obligation although attribution on any public output still applies. What are you actually distributing? A picture, or the data? Everything follows from this Answer it before anything else A produced work Images, reports, rendered tiles: attribution only A database Data others can query: attribution plus share-alike if derived Nothing externally Internal use only: no distribution obligation arises Almost every licensing question resolves once this is answered, and almost every licensing mistake comes from never asking it.
A rendered map is a produced work; the tiles behind it may well be a database. The same pipeline can produce both.

The Problem This Topic Solves

You are building something with OpenStreetMap data and need to know what you owe in return. The answer affects architecture — whether you can combine OSM with a proprietary dataset, what you can publish, how attribution reaches users — so it is much cheaper settled at the start than discovered at launch.

The failure scenario is a product built on an assumption nobody wrote down. A team combines OSM with a licensed commercial dataset, publishes an API that serves the result, and discovers at launch review that the output is a derived database subject to share-alike, which the commercial licence forbids them from satisfying. The engineering is fine. The problem is that the question was never asked, and the architecture that would have avoided it — keeping the two datasets separable — was not built.

The Vocabulary That Matters

Three terms carry all the weight, and confusing them is the source of most misunderstanding.

A produced work is something made from the database that is not itself a database: a rendered map image, a printed atlas, a report, a visualisation. Distributing one requires attribution. It does not trigger share-alike.

A derived database is a database made from the OSM database — an extract, a filtered subset, a transformed schema, a routing graph, in most readings a vector tile set. Distributing one requires attribution and share-alike: the derived database must itself be offered under the same licence.

A collective database is OSM data placed alongside other data without the two being combined. A directory holding an OSM extract and a separate proprietary file is collective; the proprietary file does not become subject to share-alike merely by sitting next to the extract.

The line between derived and collective is where real architectural decisions live, and it is the subject of Deciding if a Derived Database Triggers Share-Alike.

What each kind of output owes, and what it does not A grid of three output kinds against three obligations. A produced work such as a rendered map or a report owes attribution, owes no share-alike, and may be distributed under any terms. A derived database such as an extract, a routing graph or a tile set owes attribution, owes share-alike, and must itself be offered under the same licence. A collective database, where OSM data sits alongside other data without being combined, owes attribution for the OSM part only, owes no share-alike on the other part, and leaves the other part's terms untouched. Three kinds of output, three different bills Attribution Share-alike Other data Produced work yes no unaffected Derived database yes yes becomes subject Collective database for the OSM part no unaffected The middle row's third column is the one that catches product teams: combining proprietary data into a derived database pulls it in too.
Keeping a combination collective rather than derived is an architectural choice, and it has to be made early.

Attribution: Where, Not Whether

Attribution is the obligation that applies to almost everything, and the questions people actually have are about placement rather than principle.

The requirement is that users of your work are made aware the data comes from OpenStreetMap and its contributors. For an interactive map, that means visible attribution on the map itself — a corner credit, not a link buried three pages away. For a printed product, it means in the legend or the credits. For a data download, it means in the accompanying documentation and, ideally, in the data itself.

Two practical points recur. A link is expected where the medium allows one, pointing at the project’s copyright page. And attribution should survive the pipeline: a tile archive whose metadata carries the credit, a GeoParquet file with the source in its schema metadata, a database with a provenance table. Automating ODbL Attribution in Derived Products makes that mechanical rather than a thing somebody must remember.

Share-Alike and the Architecture It Implies

Share-alike bites when you distribute a derived database. The obligation is to offer that database under the same licence, which for a pure OSM derivative is usually unproblematic — the output was going to be open anyway.

It becomes an architectural question when a second dataset is involved. If combining OSM with a proprietary source produces a single derived database that you then distribute, the whole thing falls under share-alike, and a licence forbidding that makes the combination undistributable.

Three architectures avoid the collision, and all three have to be chosen deliberately.

Keep them separable. Distribute the OSM-derived part and the proprietary part as distinct databases, joined by the consumer. This is the collective-database route, and it works when the consumer can reasonably do the join.

Distribute only produced works. A rendered map, a report or an image made from the combination is a produced work, and share-alike does not reach it. This is why a great many commercial products render rather than publish data.

Do not distribute at all. Internal use creates no distribution obligation. Many pipelines that worry about this turn out to be entirely internal, and the question simply does not arise.

Three architectures that avoid a share-alike collision with a second dataset Three panels. Keeping the datasets separable means distributing the OSM-derived part and the other part as distinct databases that the consumer joins, which keeps the combination collective rather than derived. Distributing only produced works means publishing images, reports or rendered output rather than the data itself, which carries attribution but not share-alike. Not distributing means the combination stays internal, so no distribution obligation arises at all, though attribution still applies to anything published. Three ways out, all chosen before building Keep separable Two distinct databases Consumer does the join Collective, not derived Works if the join is easy Hard to retrofit Produced works only Images, reports, renders Attribution, no share-alike Data never leaves Why many products render Limits what you can offer Do not distribute Internal use only No distribution obligation Attribution still on outputs Often already the case Internal becomes external All three are architectural rather than legal manoeuvres, which is why the question belongs in the design review and not the launch review.
The third option is more often available than teams assume, and the first is the only one that is expensive to adopt late.

Validation and Error Handling

Condition Root cause Detection Remediation
Attribution absent from a product Nobody owned the requirement A user or reviewer points it out Automate attribution into the build, not the checklist
Proprietary data pulled into share-alike Combined into one derived database Legal review at launch Keep the datasets separable, or distribute produced works
Provenance lost mid-pipeline Source not carried through transformations Cannot say which extract a result came from Record source and date at ingestion and propagate
Attribution stripped by a consumer Credit only in documentation Downstream copies carry no credit Embed the credit in the data’s own metadata
Unclear whether output is a database The distinction never examined Nobody can answer the question Settle produced work versus database explicitly
Import blocked on source licence Assumed availability meant permission Community or foundation objection Establish permission in writing before importing
Compliance decays over releases A one-off review, never re-run New outputs ship without attribution Check attribution in the build as a gate

Questions Worth Settling Early

Four questions come up on almost every OSM project, and each is far cheaper answered at design time than at launch.

Who is the distributor? If your organisation serves data to customers, you are distributing. If you provide software that customers point at their own OSM data, they are. The distinction decides whose obligation it is, and it is worth being explicit rather than assuming.

Is a customer-facing API a distribution? Generally yes, if the response contains extractable feature data. An endpoint returning geometry and attributes is distributing a database to whoever calls it, whatever the commercial framing around it.

What about screenshots and documentation? Any published depiction of the data is a produced work and carries the attribution obligation. That includes the map image in a sales deck, which is the single most commonly uncredited artefact in most organisations.

Does an internal tool that anyone can access count? Access within an organisation is not distribution, but the boundary of “the organisation” is worth checking: contractors, partner companies and a customer-facing support tool are each somewhere on the spectrum, and the answer follows from who can actually retrieve the data rather than from whose logo is on the interface.

Automating Compliance

Compliance that depends on somebody remembering will eventually fail, usually at the least convenient moment. Three mechanisms make it structural instead.

Attribution as a build artefact. The credit string is generated from the pipeline’s own provenance record and written into every output format’s metadata — tile archive metadata, Parquet schema metadata, a database table, a documentation header. Nothing ships without it because nothing can.

Provenance as a first-class column. Every record carries, or is joinable to, the source extract and its date. This satisfies the licence, and it is independently the most useful debugging aid an OSM pipeline has — the point argued in Recording OSM Data Provenance in a Pipeline.

A gate in the build. A check that fails when an output lacks attribution costs almost nothing and turns a recurring review into a one-time implementation.

Performance and Scale

Compliance has essentially no runtime cost — a credit string and a provenance column are negligible next to geometry — but it has a real architectural cost if retrofitted. Adding provenance to a pipeline that never carried it means re-deriving every output to learn where it came from, which for a warehouse of any size is a project rather than a change.

The practical consequence is that this is a day-one decision. Carrying the source and date from the moment an extract is read costs one column and one string; adding them two years later costs a migration and a period during which nobody can answer questions about older data.

Guides in This Topic

Frequently Asked Questions

Is a rendered map image subject to share-alike?

No. A rendered map is a produced work — something made from the database that is not itself a database — and produced works carry an attribution obligation but not share-alike. That is why many commercial products render rather than publish data: the image can be distributed under whatever terms they choose, provided the credit is visible. The tiles behind the image are a different question, because a vector tile set is data somebody could extract from.

Where does attribution have to appear?

Somewhere users of the work will actually see it, which depends on the medium. An interactive map needs a visible credit on the map itself rather than a link several pages away; a printed product needs it in the legend or credits; a data download needs it in the accompanying documentation and, better, in the data’s own metadata. Embedding it in the data is what keeps it attached when somebody copies the file elsewhere.

Does combining OSM with proprietary data make the proprietary data open?

It can, which is exactly why the architecture matters. If the combination produces a single derived database that you then distribute, share-alike applies to the whole of it. Keeping the two separable — distributed as distinct databases the consumer joins — avoids that, as does distributing only produced works, as does not distributing at all. The choice has to be made before the pipeline is built, because retrofitting separability is expensive.

Do I owe anything if the pipeline is entirely internal?

Distribution is what triggers the obligations, so a pipeline whose outputs never leave your organisation creates no share-alike duty. Attribution still applies to anything you do publish, including screenshots in a public document or a map shown to customers. It is also worth noting that “internal” has a habit of becoming external later, and a pipeline that carried provenance from the start is the one that can answer the question when it does.

Is a vector tile set a produced work or a database?

Generally a database, because a tile set contains structured features with attributes that a consumer can query and extract rather than merely look at. A rendered raster image of the same map is a produced work. The distinction is not about the file format but about whether what you distribute lets somebody get the data back out, and a vector tile set very clearly does.

Up one level: OSM Data Fundamentals & Architecture.