Data pulled through Google or Microsoft integrations: can it be licensed?

Which data counts as integration-sourced?#

Integration-sourced data is anything your product retrieved from a platform such as Google Workspace or Microsoft 365 using access a user or tenant admin granted to your app. A CRM that syncs reps' mailboxes, a scheduling tool that reads calendars and a document product that imports files from Drive or SharePoint all hold it.

The category is wider than most teams expect, because integration data spreads into search indexes, data warehouses, feature stores and backups. The table shows the usual sources and how a licensing review treats them by default.

Why OAuth-scoped data is usually excluded#

OAuth-scoped data is usually excluded because three independent layers of restriction apply to it, and any one of them can block a license. The first is the platform's developer policy, which your app accepted to get access. The second is your contract with the customer whose users connected their accounts. The third is privacy law protecting the people whose mail, calendars and files you hold, many of whom never contracted with you at all.

The decision rule for CTOs is simple: if a record entered your systems through a user's OAuth grant, assume it stays out of any AI training license unless counsel finds a clear basis. That rule rarely costs much, because the most valuable records a software company holds are usually its own tickets, issues, code reviews and internal discussions.

The rule also protects the integration itself. A platform that concludes an app misused user data can restrict or suspend its access, and for a product built around mailbox or calendar sync, losing that access would hit the core product rather than a side project.

What the platform terms generally restrict#

Platform terms generally confine integration data to the user-facing purpose the user approved, which leaves little room for licensing it onward. Google's API Services User Data Policy includes Limited Use requirements that confine how user data obtained through certain scopes may be used and transferred, generally to providing or improving user-facing features, and Google's Workspace developer policies speak to AI and machine learning uses specifically. Apps requesting sensitive or restricted scopes also go through verification, in which the developer describes how it will use the data.

Microsoft publishes its own terms of use for Microsoft APIs, and access to Microsoft Graph depends on the permissions a user or tenant administrator consented to for your app. Those terms, the consent screen descriptions and your app's privacy statement together set what you told users the data was for.

Policies change, so read the current versions and the versions in force when the data was collected. Also reread the commitments your team made during app verification or publisher review, because a licensing plan that contradicts them can put the integration itself at risk.

Does derived data escape the restriction?#

Derived data rarely escapes the restriction on its source. An embedding of an email, a summary of a thread or a label predicted from a calendar pattern is still a use of the original data, and restrictions on use and transfer generally follow it. Platform policies and privacy laws tend to look at what the data came from, not the format it ended up in.

Genuinely aggregated statistics, such as the share of meetings rescheduled across all customers, may stand on different ground. Whether a specific aggregate is far enough from the source is a question for counsel, and the platform's own wording matters more than general principles.

Separating integration data from licensable records#

Separating integration data starts with knowing every path by which it enters your systems. CTOs who have done this find that most of the work is tracing copies, not finding the original connectors.

• 1List OAuth clients and scopes from the Google Cloud console and Microsoft Entra app registrations.
• 2Map each scope to the ingestion jobs that use it and the tables or buckets they write to.
• 3Add or confirm a source column on every record so integration data can be filtered out.
• 4Trace downstream copies in search indexes, warehouse models, feature stores and backups.
• 5Build the export from first-party systems such as Jira, GitHub, Zendesk or Intercom where your company is the account owner.
• 6Write down the exclusion logic so a licensee can see how integration data was kept out.

Illustrative: a sales engagement platform splits its warehouse#

Illustrative: a fictional sales engagement software company syncs reps' Gmail and Outlook mailboxes into a CRM timeline, and its Snowflake warehouse mixes synced email bodies, sentiment scores computed from them, in-app activity events and the company's own support and engineering records.

The CTO tags each table by ingestion source and finds that the sentiment scores and a reply-prediction feature table both derive from synced mail. Both are excluded along with the email bodies. Customer content typed into the app goes to a separate review under the customer contracts.

The package that moves forward is built from the company's own records: Intercom conversations where customers wrote to the vendor, Jira issues those conversations created, and the GitHub pull requests that fixed them. None of it passed through a user's OAuth grant.

How SourceX treats integration-sourced data#

SourceX treats integration-sourced data as out of scope by default during the Rights step of the SourceX five-step transaction. The fit check asks which systems hold the candidate records and how they were collected, using metadata only.

For each package that proceeds, the SourceX Evidence Packet records provenance by source system, the licensing rights relied on and the exclusions applied, so a buyer can see that records obtained through third-party platform access were kept out. The supplier approves the scope before Delivery.