May 29, 2026 · 7 min read
Data licensing for travel B2B: why per-row license tags matter
Every serious travel data product is a blend. Nobody collects the whole world from scratch. The question isn't whether you've blended sources — it's whether your customer can tell which row came from which source. That's a license question, and it determines whether a real B2B buyer can actually ship your data.
What an honest travel API is built from
Modern travel APIs lean on a small set of sources. Foursquare's Open Source Places dataset gives a global POI baseline under Apache 2.0 with attribution. OpenStreetMap provides geometry and admin boundaries under the Open Database License, which is share-alike for derivative databases. Wikidata supplies multilingual names and cross-IDs under CC0. UNESCO's World Heritage list and the Archaeological Survey of India's Centrally Protected Monuments list are public-domain government compilations. There are smaller streams too: state tourism board PDFs, transport authority schedules, gazetteers.
Each of these has different reuse terms. Apache 2.0 wants attribution. ODbL has share-alike obligations on databases. CC0 waives rights. Government public-domain data is usable but might have factual errors you inherit. Mix them in a single product and you get a license stack — and a B2B customer's legal team is going to want to see it row by row.
Why a single product-wide license isn't enough
The cheapest thing a vendor can do is publish a single Terms of Service that says "you can use this data in your product." That works until a customer asks: "if we ship your data into our embedded chatbot widget, which we resell to airlines, what attribution do we need to show, and where?"
The honest answer is: it depends on which row. A row sourced from OSM may need attribution and may oblige share-alike on the resulting dataset. A row sourced from a public-domain government compilation has no such obligation. Lumping these into a single line of legal boilerplate either over-restricts the easy rows or under-restricts the hard ones. Both are bad for the buyer.
Per-row license metadata is the fix
The right shape — and the one that actually unblocks procurement — is to surface license metadata per row in the API response. When a legal reviewer scrolls through a sample payload, they should be able to see, on each record, which source family it came from and which license applies. That review takes minutes. Without it, the review becomes a months-long correspondence with the vendor.
A response with a license header looks something like this:
{
"id": "...",
"name": "Mahabodhi Temple Complex",
"city": "Bodh Gaya",
"lat": 24.6962, "lon": 84.9911,
"license": "public_domain_unesco",
"attribution": "UNESCO World Heritage Centre"
}
The customer's downstream system can then render attribution correctly, gate share-alike rows out of closed contexts, or tag derivative work appropriately. None of that is possible if the license is implicit.
What B2B legal teams actually ask
The questions that come up on the second sales call, in roughly the order they appear: which sources do you blend; can you point us to the upstream license for each; do you surface that lineage in the API; what indemnification do you offer if a row is mis-licensed; and what happens to our derivative database if your terms change.
A vendor who can answer all five in one email closes the deal. A vendor who can't answer them ends up in a five-week review and usually loses.
The competitive moat is clarity, not coverage
Coverage is the headline. Licensing is the close. We've watched larger vendors with bigger row counts lose deals because their license posture was vague enough to spook a buyer's general counsel. A smaller, cleaner dataset with per-row provenance and a one-page license guide wins those bake-offs more often than the row count would predict.
If you're building a travel API and you have to choose between doubling coverage and shipping per-row license metadata, ship the license metadata. It's the thing your customers' lawyers will read, and lawyers approve deals.