Delta Sharing is an open protocol for letting another organisation read tables where their owner holds them, rather than receiving a copy. Databricks introduced it, uses it to power its Marketplace, and since June 2026 calls it OpenSharing. This guide explains how the protocol works in the terms Databricks now uses. It then sets out what a licensing team should settle when data sharing replaces delivery by file: who holds the credential, what a recipient may copy, what revoking does, and whose cloud account pays for delivery.
One protocol, two names
The Linux Foundation announced the OpenSharing Project on 10 June 2026 as an open, vendor-neutral protocol for sharing AI assets and data, contributed by Databricks. On 15 June Databricks's announcement said that Delta Sharing is now OpenSharing and called OpenSharing the next evolution of Delta Sharing. The project site describes itself as a Linux Foundation AI & Data project, formerly Delta Sharing, built on the existing Delta Sharing ecosystem of clients, tools and platforms.
The new name also marks a wider scope. The Foundation says OpenSharing covers agent skills, AI models and unstructured data volumes as well as tables, and adds Apache Iceberg clients to the recipients it can reach. Databricks's documentation uses the name OpenSharing, the original specification is still published on GitHub as the Delta Sharing protocol, and the Python client is still installed as delta-sharing. This guide says OpenSharing for the current Databricks feature and Delta Sharing for the original protocol. For licensing the difference is small, because the questions below apply to both.
Providers, shares and recipients
Databricks's overview defines three terms. A provider is an organisation that shares data. A share is a read-only collection of tables and table partitions that the provider wants to share with one or more recipients. A recipient is an organisation that receives shares, and in Unity Catalog it is an object that ties that organisation to a credential or a sharing identifier. A provider that uses Databricks's built-in server needs at least one workspace enabled for Unity Catalog. A recipient can be on any computing platform.
The data does not travel inside the protocol's messages. The specification describes a REST protocol in which a recipient's client asks a sharing server for a table and then reads the files from cloud storage, either through pre-signed URLs for individual files or through temporary credentials for the table's directory. The files stay in the provider's storage, and the recipient reads them from there.
Databricks documents two sharing models. In open sharing the provider issues a bearer token or sets up OpenID Connect federation, and the recipient can be any organisation. In Databricks-to-Databricks sharing the recipient has a Unity Catalog workspace, identified by the sharing identifier of its metastore, and no token is managed. Tables can be shared in both models. Notebooks, volumes and models need the Databricks-to-Databricks model.
What the recipient receives
In open sharing the provider creates the recipient in Catalog Explorer, with SQL or with the CLI, and Databricks generates a token and a credential file that holds it. Databricks's page on bearer tokens says the recipient gets an activation link and can download the file only once. A token is valid for at most one year, a recipient can hold at most two tokens at a time, an active one and a rotated one, and the provider can limit a recipient to listed IP addresses. With OpenID Connect federation the provider grants short-lived tokens in exchange for tokens from the recipient's own identity provider.
The credential file holds an endpoint and a bearer token, and the protocol's profile format also carries an expiry time. A recipient reads the data with a connector. Databricks's page on reading shared data lists Apache Spark and pandas through the delta-sharing package, Power BI, Tableau and Iceberg clients, and names Snowflake, Trino, Flink and Spark among the Iceberg clients.
import delta_sharing
# The documented form: <profile-path>#<share-name>.<schema-name>.<table-name>
df = delta_sharing.load_as_pandas("<profile-path>#<share-name>.<schema-name>.<table-name>")What sharing changes in a licence
A licence written for files assumes the buyer receives something and holds it. Sharing changes the mechanics, and each change maps to a clause.
| What the mechanism does | What the licence should settle |
|---|---|
| The recipient is a named object tied to an organisation, and access runs through a credential held by whoever downloaded the file | Which organisation and which affiliates are licensed, who may hold the credential and what happens when that person leaves |
| A recipient can read and copy shared data, and revoking access ends access to the share only | Retention, deletion on termination and the use of derived tables, which no protocol can enforce |
| A token lasts at most a year and is rotated, and federation issues short-lived tokens | The term of access and who renews it |
| A share can include the table's history, with time travel and streaming reads | Whether earlier versions of the data are licensed, and for how long |
| Provider and recipient actions are written to audit logs | What usage evidence the provider may see and what the recipient must be able to show |
| Reads across clouds or regions can incur egress fees from the provider's cloud vendor | Who bears the cost of delivery, and who chooses the method |
| A licensee that copies shared data into its own tables can share those tables onward | An explicit redistribution licence, with named onward recipients |
The two sharing models give a licensing team different things to name. In open sharing the control is a secret, a bearer token in a credential file, so the licence should say who may hold it and how a leak is reported. In Databricks-to-Databricks sharing the control is an identity: the recipient's metastore, which the provider names by its sharing identifier when it creates the recipient. Federation sits between them, because the recipient's own identity provider vouches for each short-lived token.
Audit is visible from both sides. Databricks's audit page says provider logs record the actions of providers and recipients, with details such as the recipient, the table and file counts and sizes, while recipient logs track access to shares. A usage clause can therefore be checked by either party.
Revocation and cost deserve a closer look. On revocation, the documented act is a single statement, and SELECT is the only privilege a provider can grant a recipient on a share. The mechanism therefore has no partial rights: a recipient can read the share or cannot. Terms such as internal use only or no embedding in a product live in the licence and in the recipient's own controls. Revoking ends access to the share, and copies a recipient made earlier sit outside it.
-- Acme Robotics (illustrative) shares a summary of its own fleet telemetry
CREATE SHARE IF NOT EXISTS partner_share;
ALTER SHARE partner_share ADD TABLE acme.reports.fleet_summary WITHOUT HISTORY;
GRANT SELECT ON SHARE partner_share TO RECIPIENT partner_one;
-- The act of withdrawal
REVOKE SELECT ON SHARE partner_share FROM RECIPIENT partner_one;On cost, Databricks's page on egress says that sharing within a region incurs no egress cost, while a cloud vendor may charge egress fees when data is shared across clouds or regions. The page is addressed to providers, so the charge lands on the provider's cloud account. A licence that names a delivery method should also say who carries that cost.
History is the other row worth a sentence. A share added with WITH HISTORY lets a recipient run time travel queries and streaming reads against earlier versions of a table, and one added WITHOUT HISTORY does not. If earlier versions matter to the buyer, for a back-test or an audit, the licence and the share definition have to agree.
Sharing Fokals data, and data derived from it
Fokals 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. From there, any sharing is yours to govern. The delivery page sets out the methods and formats, and the guide to loading company data into Databricks shows the load.
Fokals is licensed by written agreement for internal use, embedding in a product or redistribution, as the licensing page explains, and the manifest that comes with each export names the licence. If you pass Fokals data to your own customers through a share, that is redistribution, one of the three uses an agreement names. Whether a table derived from the data counts is also a term of the agreement, so settle it before you share anything built from it. The use case on redistributing company data under licence lists what to settle before signing. An internal-use licence does not become a redistribution licence because the technology makes onward sharing easy.
Databricks adds two technical points. According to its page on row filters and column masks, a table with a table-level row filter cannot be shared through OpenSharing. And its page on creating shares says the owner of a share needs SELECT on each table in it and that recipients lose access if the owner loses that privilege, so share ownership is a privilege worth restricting. The guide to governing licensed data with Unity Catalog covers CREATE SHARE and SET SHARE PERMISSION and how to audit what each share contains. The buyer's view of the same protocol is in the guide to Databricks Marketplace.
Frequently asked questions
Is Delta Sharing now called OpenSharing?
Databricks says so. Its June 2026 announcement states that Delta Sharing is now OpenSharing, the next evolution of the protocol, and its documentation uses the new name. The Linux Foundation hosts the OpenSharing Project, which Databricks contributed. The original specification is still published as Delta Sharing on GitHub, and the Python client is still installed as delta-sharing.
Do recipients need Databricks to read shared data?
No. In open sharing the recipient gets a credential file and reads tables with a connector such as Apache Spark, pandas, Power BI or Tableau, or with an Iceberg client. A recipient with a Unity Catalog workspace can use the Databricks-to-Databricks model instead, which needs no token and also allows notebooks, volumes and models to be shared.
Can a provider take back data it has shared?
A provider can revoke a recipient's access to a share with one statement, and tokens expire after at most a year or sooner if the provider sets it. That ends access to the share. It does not reach copies, because Databricks says recipients can read and make copies of shared data. What happens to copies is a matter for the licence.
Does Delta Sharing copy the data to the recipient?
Not by itself. The recipient's client asks the sharing server for a table and then reads the files from the provider's cloud storage, through pre-signed URLs or temporary credentials. The data is read where it is held. A recipient can still make its own copies of what it reads, so a licence should not assume that no copy exists.
Who pays when data is shared across clouds?
Databricks's page for providers says sharing within a region incurs no egress cost, while a cloud vendor may charge egress fees for sharing across clouds or regions. The provider's cloud account is the one billed. The page also describes ways to limit egress, such as replicating shared data to Cloudflare R2 object storage, which it says charges no egress fees.
How does Fokals data reach a Databricks workspace?
Fokals is delivered direct, by REST API and as bulk files in JSON, JSON Lines or CSV. You load the data into your own workspace with Databricks's own loaders. If you later share the data, or tables derived from it, with your own customers through OpenSharing, check that your agreement covers redistribution, which is one of the three uses it can name.
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.