Data provider attribution: the rules when data is shown in a product

An attribution requirement is the part of a data provider's terms that says what your product must display when the data is shown to its users: usually a name, a link, a licence notice and a mark of any changes, placed beside the data. This post sets out where such requirements come from, what the open licences and published API terms we read ask for, and how to apply them to one screen. It reports what each text says, with its version or date, and is not legal advice.

Where an attribution duty comes from

An attribution duty reaches your product by one of three routes, and the route decides who wrote the terms and where you read them.

The routes stack: a dataset you license can carry a credit owed upstream, delivered as a field or a notice. Which use a feature falls under, internal use, embedding or redistribution, is set out in what a data licence covers. This post deals with the credit itself.

What does attribution to a data provider require when its data is shown in a product?

Attribution requires what the governing text names. The texts we read draw on five elements: the provider's name in the words it designates, a link to the source or the licence, a notice naming the licence, a mark of changes you made, and a position near the data. API terms add logos, set wording and style rules.

Four open licences show how the elements combine, each reported by its version.

Two points recur. Each licence attaches its condition to an act it names, so whether display inside a signed-in product counts as that act is a reading to settle with counsel. And the credit can often sit one link away: CC BY 4.0 and OGL v3.0 both accept a link to a resource holding the details, in the cases their texts describe.

Attribution requirements in API terms: how data provider credit is displayed in a product

API terms are where attribution gets most specific. Between them, the three sets we read fix the words or the logo, the link and its target, and the position against the data, and Google's Places policies forbid removing, hiding, obscuring or modifying the credit. They govern the API's content where your product displays it.

Crunchbase's general Attribution Instructions, effective 23 November 2016, add that the credit must clearly state the content is sourced from Crunchbase and link to its page there; the link should go to the entity page for one entity or the homepage for several.

Record each verb with its rule. Crunchbase Basic says must; the Census Bureau's terms say should; Google's policies say the logo should be used whenever possible. A register that keeps the verb lets your counsel weigh the two apart.

Powered by credits: API terms of service attribution requirements for a data source

Powered by is one way to word a credit, and the right wording is the one the terms give. Crunchbase Basic requires Powered by Crunchbase with a hyperlink to Crunchbase; the Census Bureau's terms ask for a notice that pairs the credit with a disclaimer of endorsement; Google's Places policies ask for the Google Maps logo whenever possible.

The wording matters because Powered by can read as a relationship between two companies, and several texts rule one out.

• CC BY 4.0, section 2(a)(6): no permission to imply that you or your use are connected with, sponsored, endorsed or granted official status by the licensor.
• OGL v3.0: no right to use the information in a way that suggests official status or the provider's endorsement.
• The Census Bureau's terms: its name may not be used to imply endorsement of any product, service or entity.

So use Powered by exactly where a text prescribes it, with its link. Where a text names the provider but sets no form, a plain line such as Source, then the designated name and the links asked for, gives the credit without suggesting a partnership. Where a text supplies a logo, follow its rules for the file: the Places policies say not to modify the logo in any way.

Credit on the screen, terms in the delivery

ODbL 1.0 treats showing the data and passing it on under different clauses. Using a Produced Work publicly needs the notice in section 4.3. Conveying the database or a derivative publicly brings in section 4.2: only under the licence or one it permits, with the licence or its address in the database and its documentation, and copyright, database right and licence notices kept intact. CDLA-Permissive-2.0 draws a similar line between data, which travels with the agreement text, and Results, which carry no obligation.

In a commercial agreement the same step is the one from embedding to redistribution, and redistributing company data under licence is the working list for that step. Map credit by surface, then: each screen, export file, report and API of your own. A download button can move a screen from one clause to the other.

What Fokals data carries for attribution

We license Fokals data by written agreement, for internal use, for embedding in a product or for redistribution, as a data licence or a redistribution licence. Your agreement sets the terms for Fokals data in your product, so read them before the screen is designed. Three things in the delivery help.

• Attribution in the rows. The Web Traffic dataset is delivered with attribution: each row carries the attribution text for its monthly traffic tier. Keep the text with the tier wherever the tier appears. The field is defined in the data dictionary, and the dataset belongs to the announcements and scale product.
• A licence in the manifest. A bulk export can come as a package of files with a manifest naming its period, versions and licence. Keep it beside the files, and any value on your screen traces to its delivery and licence, the provenance an audit asks for.
• A link to the original. Company News carries the address of each original announcement or filing, so a headline can link to the company's own text.

A checklist for a product team

Run these for each surface before it ships, and again when a text or a design changes.

1. List every source behind each screen, export, report and API response, with its governing text, version or date, and the day you read it.
2. Copy each credit exactly, words, logo files and link targets, into one register your components read.
3. Place each credit where its text puts it: the same visual container for Places content, close to the data for Crunchbase, prominently for the Census Bureau's notice, associated with the work for an ODbL Produced Work.
4. Design the narrow state. Places accepts the text Google Maps where space is limited; set each source's form on a phone, a card and a tooltip.
5. Log your changes. CC BY 4.0 asks the credit to indicate modifications and keep earlier indications, so record each filter, rebase and conversion.
6. Check each link's target, an entity page or a homepage, and any nofollow your link component adds by default.
7. Word credits without suggesting endorsement, and use Powered by only where a text gives it.
8. Treat each export, report and API of your own as a separate surface: display or passing the data on.
9. Follow the credit to derived values where the text reaches them: an ODbL Produced Work carries its notice, CDLA-Permissive-2.0 Results carry none, and an agreement says for itself.
10. Re-read each text on a schedule, and remove a credit when a licensor asks, as CC BY 4.0 requires to the extent reasonably practicable (section 3(a)(3)).

Then test each screen. Tag every displayed value with its source key, and count values with no key and keys with no credit in the same container. Both counts should be zero on the narrowest layout and the widest.

Worked example: one screen, three sources

This example is illustrative. Acme Robotics is an invented company, and your sales platform shows its account page to your customers' users, drawing on three sources under three kinds of text.

Assumptions:

• The page has three panels: Location, Regional labour market, and Technology and reach.
• Location shows 2 values from the Google Places API, the headquarters address and its pin, on a Google Map.
• Regional labour market shows 2 values from a table an invented publisher, the Example Statistics Office, releases under CC BY 4.0: the 12-month employment change in Acme Robotics' home county, and that change rebased by your team to an index.
• Your counsel reads display to your customers as sharing under CC BY 4.0.
• Technology and reach shows 9 values from licensed company data under your embedding agreement: 6 technologies from Technology Stack, the monthly traffic tier from Web Traffic, and the open and new postings from Hiring Activity.
• Your agreement gives a credit line, used as written, and the platform has a page called Data sources and licences.

The working:

1. Values: 2 + 2 + 9 = 13, each tagged with one of 3 source keys. Values with no key: 0.
2. Credit elements: 1 + 1 + 2 + 1 = 5, of which 4 sit in a panel and 1 in the footer.
3. Keys with no credit in their panel: the logo covers Places, the source line the statistics table, the agreement's line the licensed data. Count: 0.
4. The sources page holds what the regional line points to: creator, copyright notice, licence notice, disclaimer notice and the link to the table, the kind of linked resource CC BY 4.0 gives as an example of what may be reasonable.
5. The index is a changed form of the table, so its change note stays on the panel in every layout, the one-line phone form included.

Last, the export button. A download sends the 9 licensed values out as rows, which your agreement may treat as passing the data on: settle it before the button ships. If export is granted, each Web Traffic row's attribution text travels in the file with its tier.

Frequently asked questions

What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.