Attribution is the cheapest obligation in open data licensing. It requires no source disclosure, no share alike propagation, and no legal review of a derived work. It asks for a credit line. It is also, consistently, the obligation that organisations get wrong.
The reason is not defiance. Almost nobody sets out to strip a credit. It goes wrong because attribution is treated as a visual element rather than a data property, which means it lives in a template, and templates get redesigned, embedded, exported, cropped, and consumed through APIs that were never part of the original design conversation.
The result is a product that was compliant on the day it launched and quietly stopped being compliant three redesigns later, with nobody able to say when.
Why this specific obligation is the one that fails
Attribution fails in ways that other licence terms do not, and the mechanisms are worth naming because each has a different fix.
It is a design element in a system that treats design as mutable. A credit line lives in a footer, a corner overlay, or a caption. Those are exactly the components that get replaced during a redesign, and the person doing the replacing has no reason to know that a piece of text was a legal requirement rather than a stylistic leftover.
It is lost at boundaries. Data crosses from a database into an API response, from a response into a client, from a client into a screenshot, from a screenshot into a slide deck, from a slide deck into a printed report. Each hop is an opportunity for the credit to fall off, and each hop is usually handled by a different team.
It is diluted by aggregation. A figure computed from six sources needs to credit six sources, but the interface has room for one line and the product manager wants that line short.
It is invisible in machine outputs. A JSON response has no footer. An agent summarising that response into prose has no obvious place to put a credit, and no instruction to do so.
And it is nobody's job. Licence compliance sits with legal, who do not review UI changes. Design sits with design, who do not read licences. Data sits with engineering, who assume the front end handles it.
Nothing here is a comment on any specific organisation, and nothing here is legal advice. It is a description of how a requirement that everybody accepts ends up unmet.
What reasonable and visible actually means
Open licences tend to require attribution that is reasonable to the medium, and the vagueness is deliberate: a printed map, a mobile application, and a REST response cannot all carry the same credit in the same way. That flexibility is often read as permission to do the minimum, which is a mistake, because the test is functional rather than cosmetic.
The functional test is whether a reasonable person consuming the work can determine that the data came from that source, without special effort. Applied honestly, that rules out several common patterns.
A credit that requires interaction to discover is borderline at best. A line buried behind a small icon in a corner, revealed only on click, does not tell a user who never clicks. Some communities explicitly accept a compact control that expands, provided it is visible and obviously an attribution control rather than a decorative element. Others expect the text itself.
A credit on a different page is generally not attribution for the work in front of the reader. A site wide legal page listing every source used anywhere does not attribute the specific map on the specific screen.
A credit that names the wrong entity does not satisfy anything. Crediting the vendor who resold the data, or the library used to render it, instead of the party that produced the data, is common and wrong.
A credit in colour and size chosen to be unreadable is worse than none, because it demonstrates that somebody knew the requirement and worked to defeat it.
The reasonable interpretation runs the other way: if the product's own branding is legible, the attribution should be legible in the same conditions. That is a rule anybody can apply without a lawyer.
Name the source and the licence, not open data in general
Generic credits are the most widespread form of technically present, functionally useless attribution. A footer reading built with open data attributes nothing. It identifies no producer, points to no terms, and leaves a reader unable to verify anything or to reuse the same sources.
Proper attribution has three parts and each does specific work.
The producer, named as they ask to be named. Communities and agencies specify their preferred form, and using it matters because a downstream reader is trying to locate them, not to admire the phrasing.
The licence, named and preferably linked. Naming the licence is what tells a downstream user what they may do with the material. It is also self protective: it publicly evidences that the obligation was known and met.
Where a licence requires it, an indication of whether the material was modified, and often what the modifications were at a general level. Aggregation, filtering, geometric simplification, joining with other sources, and inference are all modifications.
There is a common objection that specific attribution clutters the interface. It does, slightly. The counter is that a specific credit is short, and that the alternative is not a cleaner interface, it is an unmet obligation plus an interface that is barely cleaner.
Maps, APIs, and printed output are three different problems
Attribution has to be solved separately per medium, because the constraints genuinely differ.
On an interactive map, the established convention is a persistent credit in a corner of the map surface, moving with the map rather than living elsewhere on the page. When layers can be toggled, the credit should change with them: crediting a source whose layer is switched off is noise, and failing to credit a layer that is switched on is a gap. This is straightforward to implement if each layer definition carries its attribution string as a field, and painful if the credit is hardcoded in the map component.
In an API, the attribution belongs in the response payload, not only in the documentation. Documentation is read by an integrating developer once. The response is read by the machine every time, and increasingly by an agent that has never seen the documentation. A per response attribution block listing the contributing sources and their licences is small, cacheable, and it is the only mechanism that reaches an autonomous caller. Response headers can carry a pointer as well, but headers are stripped or ignored often enough that they should supplement the body rather than replace it.
In reports, exports, and printed output, the credit must be baked into the artefact at generation time. A PDF has no footer component to inherit. A rendered image has no DOM. If attribution is applied by the web layer rather than by the rendering pipeline, then every export path silently drops it, and export paths multiply: print stylesheets, image downloads, scheduled email reports, embeds in third party dashboards. Each needs its own handling, and the only way to keep that tractable is for the attribution text to come from the data rather than from each template.
For images specifically, the credit has to be inside the pixels. Metadata fields survive some workflows and not others, and a screenshot survives none of them.
Aggregated figures, where several sources make one number
The hardest case is a single value that no single source produced. A risk score built from hazard extents, building footprints, elevation, and population. A catchment estimate built from road network, land use, and demographic surfaces. The number is one number. The obligation is plural.
Three patterns work in practice.
Attribution at the point of display, listing all contributing sources compactly, works when the number of sources is small and stable. It is the most direct reading of the obligation and the least popular with designers.
Attribution one interaction away, with a clear affordance, works when the source list is long. A visible marker next to the figure, leading to a panel that lists every source and licence for that specific figure, satisfies the discoverability test provided the marker is genuinely visible and the panel is specific to the figure rather than a global list.
Provenance carried in the API and surfaced by the client works best when both are under the same team's control. The response includes, per figure, the sources that contributed, and the client renders whatever its medium allows.
What does not work is a global source list decoupled from the figures. Once a product has thirty sources and a page listing all thirty, a reader cannot tell which contributed to the number in front of them, and neither can the team.
The related discipline is that a derived figure should record its inputs at computation time, not at render time. If the aggregation pipeline knows which sources contributed to each output row, attribution is a lookup. If it does not, someone will have to reconstruct it from the code, and they will get it wrong.
Attribution that survives into a customer's product
For anyone serving data to other builders, the obligation does not stop at their own interface. Attribution requirements travel with the data, so a customer embedding it in their application inherits them, whether or not they know.
Leaving that to the customer to discover is a poor outcome for everybody. They may not read the terms. They may read them and misunderstand which of many sources applies. They may implement something that satisfies one licence and not another. And when it goes wrong, the upstream community sees a violation, the customer sees a surprise, and the intermediary sees a support ticket.
Practical measures that reduce this materially:
- Ship attribution in the response so that a customer building against the API has the correct string available without looking anything up.
- Provide ready to use snippets for common cases: a map overlay, an HTML footer, a plain text line for reports.
- State the obligation in the integration documentation at the point where a developer is already reading, not only in the terms of service.
- Where the product has a client library or SDK, render attribution by default and require a deliberate step to move it rather than a deliberate step to add it.
- Make the machine readable licence field part of the public schema, so that a customer's own compliance tooling can find it.
The general principle: the party that knows the licence should do the work of communicating it, because they are the only party in a position to get it right.
Attribution as a data field, not a design decision
Everything above reduces to one structural change. Attribution stops being reliable when it lives in a template and becomes reliable when it lives with the data.
That means every source in the registry carries a machine readable record: the producer's preferred name, the licence identifier, a link to the terms, whether modification notice is required, and the exact credit string. Every record or tile or layer references that source. Every derived product records the set of sources that contributed to it. Every rendering path, screen, export, response, and report, reads the credit from that structure rather than containing its own copy.
The immediate payoff is that a redesign cannot break compliance, because there is no hardcoded string to delete. Adding a source automatically adds its credit everywhere the source is used. Removing a layer removes its credit. An audit becomes a query rather than a search through templates.
The larger payoff is that the same structure answers the questions that arrive later, and they always arrive: which sources are in this product, which of them require share alike treatment, which cannot be used in a commercial context, what happens if one of them changes terms. A team with attribution as a data field can answer in minutes. A team with attribution in a footer has to read its own code.
The check that actually catches it
The most useful compliance test is not a legal review. It is a walk through every path by which data leaves the product, listing what a recipient sees at the end of each one.
Screen, screenshot, printed page, PDF export, image download, emailed report, embedded widget, API response, SDK render, and whatever an agent produces when it consumes the API and writes prose. For each, the question is whether a recipient at that endpoint can identify the source and its licence.
Most teams running this exercise for the first time find two or three paths where the credit is absent, and they are almost always the automated ones, because those were built by a different team at a different time for a different purpose. Fixing them is usually a small amount of work. Discovering them is the part that requires deliberately going looking, since no user will report a missing credit and no test suite is watching for it.