If your customers will receive company data from you, the licence you hold has to allow it. This guide sets out where redistribution begins, what the data itself carries that you pass on, how to use the manifest of each export as a record of lineage, how much notice of change you can promise, and the questions to put in writing before you sign. It is a working list to take to your own counsel and is not legal advice.
Three uses, and where redistribution starts
Fokals licenses data by written agreement for internal use, for embedding in a product or for redistribution.
Delivery does not change with the use: it is a REST API and bulk files in each case. What differs is what reaches the person at the end of your chain. Use a working test, and write it into the agreement so that both sides read it alike.
| Use | What happens on your side | What the end user receives |
|---|---|---|
| Internal use | Analysts, models and tools inside your organisation read the data | Nothing from the dataset itself |
| Embedding in a product | Your application shows a value or result computed from the data | A score, a flag, a sentence or a chart |
| Redistribution | You pass the data on | Rows, files or an API of yours that returns records |
A worked case, with Acme Robotics as the illustrative company. Your dashboard shows its weekly CRM score from Intent Scores and the evidence behind it, which is embedding. Your customers can download the announcements of the companies they follow from Company News as a file, which is redistribution. Your own analysts study both, which is internal use. Two datasets serve three uses, and the agreement should name each of them.
Derived values are where the lines blur. A technology count for a company is computed from rows, while a copied last-seen date is the row itself. Ask that the agreement says on which side of the line each kind of derived value falls.
What the data carries that you pass on
Several properties of the data are useful to your customers when you keep them through your pipeline.
Attribution. Web Traffic rows carry an attribution column with the attribution text for the monthly traffic tier. Keep the column, and show the text wherever a tier is shown. The manifest of each export names its sources, so read it for any other source that carries terms.
Label versions. Every label and score belongs to a version that stays frozen once released, and each row says which: label_version on Job Postings and Company News, intent_version on Intent Scores, sales_label_version on Job Postings and role_version on Company News. A dataset can hold two versions side by side: postings labelled under jobs-v1 and under jobs-v2 sit together, and jobs-v2 adds labels. Keep the version column, and your customers can tell a label that is missing from a label that does not exist.
The reconstructed flag. A row with reconstructed=true was written more than a week after its period closed. A customer who back-tests on your data uses the flag to separate rows that existed on time from rows that did not.
Observation times. Every record carries the time it was observed, in observed_at, first_seen_at or at. Keep them as delivered and do not flatten them into one updated field. Customers use them to ask what was known on a date.
Identifiers. The Fokals company ID is stable, and a listed company carries its ticker, MIC, ISIN, LEI and share-class FIGI, with those of the listed parent on a brand or subsidiary. ISIN and LEI are checked against their check digit before they are stored. Pass the identifiers on so that your customers can join your records to their own and to later deliveries.
Reading notes. A first observation of a site or job board serves as a baseline and creates no event. A detection shows presence on the website. Labels are produced under frozen versions, and every intent score carries the dated signals behind it. A customer who meets an empty cell in your product should be told what an empty cell can mean: nothing was observed for that field.
The manifest as your record of lineage
Each bulk export comes with a manifest that lists its sources, its period, its label versions and its licence. Store the manifest beside the files, and write the same four things into the delivery record you send with each delivery to a customer. An illustrative record follows.
{
"delivery_id": "2026-10-05-weekly",
"datasets": ["company_news", "company_intent_weekly"],
"period": { "from": "2026-09-28", "to": "2026-10-04" },
"sources": ["company websites", "company careers pages", "company newsrooms and feeds", "regulatory filings"],
"label_versions": ["news-v1", "sec-items-v1", "intent-v2"],
"licence": "your agreement reference",
"manifest": "path to the stored manifest"
}A record like this answers three questions a customer will ask: where a value came from, which version of the method produced it, and which licence governs it. It also lets you reproduce a delivery from the files you hold.
What notice you can promise
A breaking change to the labels, the scoring or the topics arrives as a new version, announced at least 90 days ahead. Additions to the technology and software catalogues go in the changelog instead. The notice you receive is the most you can pass on. With 90 days from Fokals and 30 days for you to test and release, you can promise your customers 60. A customer promised 180 days has been promised something the supply cannot back.
Frozen versions settle the other direction too. A value written under a version keeps its meaning, and the rows of a closed day or week are written once and never revised, so those datasets need no corrections for past periods. Your terms to customers can say so for them.
What happens when the agreement ends
Rows you have already delivered raise the question of the end of the term. Because the rows of a closed day or week are final, a customer's copy of them stays an accurate record of what was delivered for its period, and that is exactly why the licence has to say whether the customer may keep it, use it or must delete it. The same goes for the history in your own store. Decide both before the first delivery, not at the end, and record the answers in the terms your customers sign with you.
Questions to settle before you sign
The methodology, the sourcing statement and the data dictionary answer how the data is sourced, how it is labelled and versioned, and how it is delivered. Who may receive it, for how long and on what terms belong to the agreement. Put these questions to any vendor, Fokals included.
- Which datasets and columns are covered, and does the list extend when a dataset is added?
- Who may receive the data: your direct customers, their affiliates or resellers? May they pass it on?
- In what form may it travel: rows, files, an API of yours, aggregates or a derived score? Which derived values count as redistribution?
- May a recipient keep and use what it received after its subscription or your agreement ends?
- What attribution must travel, in what words, and where must it be shown?
- Which versions are delivered, for how long after a new version starts, and are old and new delivered side by side during the notice period?
- What notice do you receive of a change that needs no new version?
- What must you tell your customers about reading the data, and in what form?
- What happens to the history you hold when the agreement ends: deleted, frozen or kept for audit?
- What reporting is expected of you on recipients and use?
Delivery into your platform
Fokals data is company-level throughout, and a leadership change is recorded by role. The sourcing statement and the compliance page are the documents to give your own reviewer. Fokals is delivered direct, by REST API and as bulk files, which you load into your platform with its own loader, and the manifest of each export travels with the files into your store.
How Fokals delivers it
Data reaches you by REST API or as bulk exports in JSON, JSON Lines or CSV, each export with its manifest. The data platforms page describes licensing for embedding and redistribution, and the data licence guide treats the three uses side by side. The delivery page lists the endpoints and formats. For the embedding case in a sales product, see powering account scores in a sales platform.
Frequently asked questions
What is a data redistribution licence?
A redistribution licence lets you pass the data itself on to your own customers, as opposed to using it inside your organisation or showing them a result computed from it. Fokals licenses all three uses, internal use, embedding in a product and redistribution, by written agreement. The agreement should name the datasets, the recipients and the term.
Can I resell company data that I license from a vendor?
Where the agreement names it. A licence for internal use covers your own organisation, and a licence for embedding covers showing results in your product. Handing customers the rows is the third use. Fokals licenses all three by written agreement, so the scope you need is set out in the terms you sign.
Do I have to credit the source when I redistribute company data?
Where the terms of a dataset require it. The monthly traffic tier in Web Traffic carries an attribution column that must travel with the tier. The manifest of each export names its sources, so read it for any others.
What should a data licence say about changes to the data?
It should say which versions of the labels and scores are delivered, how long an old version continues after a new one starts, and how much notice a breaking change carries. Fokals names and freezes its versions and announces a breaking change at least 90 days ahead. The points to settle in writing are the overlap and the notice for changes that need no new version.
How is the right to redistribute company data agreed?
By written agreement. Licensing covers internal use, embedding in a product or redistribution, and the agreement names the datasets, the recipients, the attribution that travels and the term. Sample data for the companies you track, sent with the data dictionary and methodology, lets your counsel and your engineers review the fit before you sign.
The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.