Governing licensed data with Unity Catalog

A data licence limits who may use the data, for what, and where it may go. Unity Catalog cannot read a contract, but it can make the permitted use the easy path and leave evidence about the rest: a catalog for each agreement, grants to named groups, tags that record the licence on every table, lineage that shows what was built from licensed tables, and checks on what has been shared out. This guide builds that setup for data licensed for internal use. The examples use Fokals tables and an illustrative buyer, Acme Robotics, whose agreement covers internal use of the hiring and marketing stack datasets.

Fokals is licensed by written agreement for internal use, embedding in a product or redistribution, as the licensing page explains. It is delivered direct, by REST API and as bulk files in JSON, JSON Lines or CSV, which you load into your own workspace with Databricks's own loaders, as the guide to loading company data into Databricks shows. Everything below governs what you then hold.

What a licence asks and what Unity Catalog offers

Databricks describes Unity Catalog as the unified governance layer for data and AI built into Databricks, with access control, lineage, auditing and data sharing among its capabilities. Each of them answers a question a licence raises.

One catalog per agreement, one schema per dataset

Databricks's privileges reference says a privilege granted on a catalog applies to current and future objects in it, and that USE CATALOG and USE SCHEMA are needed to reach anything inside but do not grant access to data. Its best practices say catalogs correspond to an environment, a team, a business unit or a mix of these, that grants should go to groups and not to users, and that production catalogs and schemas should be owned by groups.

A licence is a scope, so an agreement makes a natural catalog boundary. Every table loaded under it inherits the grants, and a second agreement, such as an embedding licence, gets its own catalog and its own group instead of widening the first.

CREATE CATALOG IF NOT EXISTS licensed_fokals COMMENT 'Fokals data under an internal-use licence';
CREATE SCHEMA IF NOT EXISTS licensed_fokals.hiring;
CREATE SCHEMA IF NOT EXISTS licensed_fokals.marketing_stack;
CREATE SCHEMA IF NOT EXISTS licensed_fokals.ops;  -- manifests and load logs

GRANT USE CATALOG ON CATALOG licensed_fokals TO `fokals-readers`;
GRANT USE SCHEMA, SELECT ON SCHEMA licensed_fokals.hiring TO `fokals-readers`;
GRANT USE SCHEMA, SELECT ON SCHEMA licensed_fokals.marketing_stack TO `fokals-readers`;

Four decisions are in those lines and the text around them. Dataset scope is a schema, because Acme's agreement names the hiring and marketing stack datasets and the intent dataset is not loaded at all. The ops schema gets no grant to the readers group, so manifests and load logs stay with the engineers. Sample data, which Fokals sends on request for the companies a buyer names, belongs in a separate catalog, so evaluation data and licensed data never share grants. And the service principal that runs a customer-facing application receives nothing here, because embedding is a separate agreement.

If the agreement later restricts where the data may be processed, workspace-catalog binding lets a metastore admin, the catalog owner or a user with MANAGE limit the catalog to named workspaces, and Databricks's page gives preventing certain data domains from being joined together as one of its uses.

Tag every table with its scope

A tag on each table says what it is and under whose licence, so that a query can find the rest. Databricks's page on tags describes them as keys with optional values on securable objects, and the SET TAG statement as the way to set one from Databricks Runtime 16.1, with ALTER TABLE ... SET TAGS available from 13.3. Setting a tag needs the APPLY TAG privilege and USE SCHEMA and USE CATALOG on the parents, and a key that already exists raises an exception, so unset a tag before you change its value.

Governed tags add allowed keys and values and need the ASSIGN permission on the tag, so a licence tag cannot take a value outside its list or be set by a user who lacks that permission. Databricks's pages on attribute-based access control and on row filters and column masks say a policy attaches at catalog or schema level and applies automatically to tables by their governed tags, so one rule can cover every table tagged internal_use, including tables loaded next year. The first page describes this as generally available, with metastore-level policies and DENY policies in Beta.

Set the tags from the data, not from memory. The manifest that comes with each Fokals export names its sources, period, label versions and licence, so load every manifest into licensed_fokals.ops and have the load job apply the licence tag from it.

SET TAG ON TABLE licensed_fokals.hiring.company_hiring_daily licence_scope = internal_use;
SET TAG ON TABLE licensed_fokals.hiring.company_hiring_daily licence_source = fokals;

SELECT catalog_name, schema_name, table_name, tag_name, tag_value
FROM system.information_schema.table_tags
WHERE tag_name LIKE 'licence_%';

Databricks's information schema page says the schema in the system catalog covers all catalogs in the metastore and shows only the objects the reader has privileges on. A report run by an account with narrow rights therefore undercounts, so run governance reports as a principal that can see every licensed catalog.

Show what was built from licensed tables

Lineage answers the question a licence cares most about: what depends on the data. Databricks's lineage page says it records, at table and column level, which queries and files populate a table, which jobs and notebooks transform it and which dashboards use the result, and that it can be read in Catalog Explorer or in the system tables. The lineage system tables hold a rolling one-year window, with columns including source_table_full_name, target_table_full_name, entity_type, created_by and event_date.

The query below lists tables built from the licensed catalog in the last 90 days and keeps those that carry no licence tag. Its target is zero rows. A row is a table that may hold licensed data without saying so.

WITH downstream AS (
  SELECT DISTINCT target_table_full_name AS table_full_name
  FROM system.access.table_lineage
  WHERE startswith(source_table_full_name, 'licensed_fokals.')
    AND target_table_full_name IS NOT NULL
    AND NOT startswith(target_table_full_name, 'licensed_fokals.')
    AND event_date >= date_sub(current_date(), 90)
),
tagged AS (
  SELECT concat_ws('.', catalog_name, schema_name, table_name) AS table_full_name
  FROM system.information_schema.table_tags
  WHERE tag_name = 'licence_scope'
)
SELECT d.table_full_name
FROM downstream AS d
LEFT JOIN tagged AS t ON d.table_full_name = t.table_full_name
WHERE t.table_full_name IS NULL;

Lineage is evidence of what Databricks captured, not proof that nothing else happened. The system tables page says records are written only when lineage can be inferred, and the lineage page says that lineage is not preserved for renamed catalogs, schemas, tables, views or columns, and that column lineage cannot be captured when a source or target is referenced as a path. In practice: never rename a licensed table, reference tables by name and not by path, and treat an empty result as a prompt to check coverage, not as a clean bill.

Control what can be shared out

Passing licensed data to another organisation is redistribution, a use separate from internal use, and a share is the way Databricks does it. The privileges reference names CREATE SHARE, CREATE RECIPIENT and SET SHARE PERMISSION among the privileges that apply to sharing. Keep them with a small group. The page on creating shares adds that the owner of a share needs SELECT on each table in it, so who owns a share matters as much as who can create one.

Check rather than assume. SHOW SHARES lists the shares, and SHOW ALL IN SHARE returns the name, type and shared object of everything a share holds. Once a month, compare those objects with the licensed catalog and with the downstream tables from the lineage query. The guide to Delta Sharing explains how a share works, and the use case on redistributing company data under licence lists what a redistribution licence has to settle. Embedding is a separate case, covered in the use case on enriching company records in a data product.

One side effect is worth knowing. Databricks lists among the limitations of row filters that OpenSharing providers cannot share tables with table-level row filters. Treat that as a fact about the product and not as a licensing control, because a limitation can change.

What Unity Catalog does not do

It does not read the licence. Whether a table derived from licensed data is still licensed data, and whether an aggregate may leave the company, are questions for the agreement and for a lawyer. The tags and the lineage make them answerable table by table. It does not stop a person who may read a table from exporting what they read, so the licence and your policies still govern use of results. And its audit is a record, not a barrier: the audit table logs events with a user identity, request parameters and a response after they have happened.

Four numbers make a monthly report: licensed tables without a licence tag, downstream tables without a tag, shares that contain licensed objects, and principals with SELECT on the catalog who are not in the readers group. The target for each is zero, or a reviewed exception. The manifest of each Fokals export names the licence, so the first number can be checked against it. Fokals is delivered direct, so all of this governance sits in your workspace.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

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