Can software holding companies license data across their portfolio products?

The short answer for software holding companies#

Software holding companies can license data across their portfolio products, but not as one pooled dataset. Each product is a separate package with its own rights review, its own privacy preparation and, usually, its own signer, because the records belong to the operating entity that created them.

That structure is an advantage as much as a constraint. A holdco with many vertical products holds as many distinct histories of how software teams in different industries handle bugs, releases and customer escalations. Buyers value that variety when each package is documented cleanly, and a problem in one product does not block the others.

Per-product rights: own records versus customer content#

Per-product rights turn on one distinction: records the product company created while running the business versus content its customers put into the product. The first group is usually the licensable core. The second is governed by each customer's agreement and is normally out of scope without permission.

Use the table as a starting checklist for each product. The right-hand column is where most of the work sits, and the answers often differ between two products that look alike.

Hosting vendors' terms usually leave the product company owning what it keeps in their tools, but read the version actually signed. Section 8.4 of the GitLab Subscription Agreement (version GLSA_01.12.26 v8), for example, says the customer retains all right, title and interest in Customer Content, subject to a limited license to GitLab for providing, developing and improving the software. Which GitHub agreement applies depends on whether the product bought directly from GitHub or through Microsoft.

Code reviews and issue histories deserve a second look even though the company owns them. Diffs can include snippets of customer data used to reproduce a bug, and comments can name customer contacts or paste credentials. Those details are removed in preparation, but knowing how common they are in a given product helps estimate the preparation effort early.

Why acquired products carry different terms#

Acquired products carry different terms because each one arrived with the paper its founders wrote. One product's subscription agreement may include a broad clause on aggregated and de-identified data. Another may promise customers their data will be used only to provide the service. A third may have many negotiated enterprise agreements that override its standard terms.

Even within one product, customers signed different versions over the years. A rights review therefore starts with a contract census: which template versions exist, how many customers sit on each, and which enterprise agreements were negotiated. That census usually decides which record families can be scoped, long before anyone looks at the records themselves.

Updating terms now helps future records more than past ones. A holdco that harmonizes AI and data clauses across products at renewal should expect the new clause to govern mainly what happens after customers accept it. Records created under older versions are still read against the terms in force when they were created, so the census stays relevant even after the paper is modernized.

How shared services change the picture#

Shared services change the picture because they mix records from several legal entities in one system. Many holdcos run a central support desk on one Zendesk or Freshdesk instance, a shared Jira site, a group Slack workspace and a common Confluence space. Those records are useful, but the supplier for each record is the product entity it relates to, not the shared services team.

Before scoping a package from a shared system, confirm that every ticket, issue or thread carries a reliable product tag. Where tagging is missing or inconsistent, that system's history may need to be split or excluded. If shared services are provided under intercompany agreements, check what those agreements say about ownership of the work product.

A sequencing rule for the portfolio#

The sequencing rule is simple: start with the product whose own records are deepest and whose customer terms are cleanest, then reuse the rights template across the rest. A first package that closes cleanly gives every other product GM a worked example to follow.

Maintenance-mode and retired products often rank high under this rule. Their histories are finished, their customer bases are stable, and their engineering records capture years of decisions that no longer carry competitive sensitivity.

• 1Rank each product on depth of its own records: years of linked tickets, issues, code reviews and releases.
• 2Rank customer terms: share of customers on templates without restrictive data clauses.
• 3Rank operational readiness: admin access, export routes and a product GM with time to help.
• 4Flag products with shared-service records that lack product tags.
• 5Pick one product to pilot, complete its review and approvals, and record what took longest.
• 6Apply the same template to the next two products before widening further.

Illustrative: three products, three answers#

Illustrative: a fictional holdco owns three vertical products: marina management software, a self-storage facility platform and a dispatch system for small trucking fleets. The group COO asks each product GM for a contract census and a system list.

The marina product has many years of Jira issues linked to Zendesk tickets and standard terms with an aggregated data clause, so it goes first, limited to the company's own tickets, issues and code reviews. The self-storage platform's standard terms are restrictive and several large operators negotiated custom agreements, so only internal engineering records are scoped. The dispatch system shares a support desk with the marina product without reliable tags, so its tickets wait until a tagging pass is done, while its code history is reviewed on its own.

How SourceX works with multi-product holding companies#

SourceX runs each product as its own transaction through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The holding company can coordinate the program and set group policy, while each product entity approves its own package.

Each package gets its own SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization. Keeping the records separate by product makes it easier to answer a customer's question about one product without exposing decisions made for another.