White-label and OEM software: who can license the data?

Who owns the data when software is sold under someone else's brand?#

Ownership in a white-label or OEM arrangement is split three ways, and the split follows the contracts rather than the logo on the login screen. The vendor typically owns the software and the records of building it, the reseller controls its relationship with end customers, and each end customer controls the content it puts into the product.

The difficulty is that one record can carry all three. A support escalation from a reseller to the vendor may describe an end customer's configuration, quote the end customer's data and include the reseller's internal notes. Before anyone asks whether that record can be licensed, the general counsel needs a map of which contract governs which part of it.

A three-party ownership map#

An ownership map sorts each record family by who controls it and who must approve its use. Build it from the actual agreements, because OEM deals are heavily negotiated and the defaults below shift from one reseller to the next.

Treat the third column as the sign-off list for the rights review. If more than one party appears in a row, the record can be licensed only with every listed approval or after the other party's material has been removed.

Which clauses decide what the vendor can license?#

A handful of clauses across the contract stack decide the vendor's scope, and they rarely sit in one document. Read them together, because a broad data-use right in the vendor's pass-through terms can be narrowed by a confidentiality definition in the OEM agreement.

• 1Ownership and license grant: who owns the platform, derivative works and any customizations built for the reseller.
• 2Confidentiality: whether the definition covers the reseller's customer lists, pricing, configurations and support communications.
• 3Data-use and aggregated data rights: whether the vendor may use de-identified or aggregated data, and for what purposes.
• 4Pass-through or flow-down terms: whether the reseller must bind end customers to vendor terms, and whether those terms mention data use.
• 5Data processing terms: whether the vendor is a processor or sub-processor, bound to act only as the reseller directs.
• 6Non-solicitation or customer-contact limits: whether the vendor may contact end customers directly, which affects any notice plan.

Why processor roles narrow the scope#

Processor roles narrow scope because a processor generally handles personal data only on its customer's instructions, not for its own purposes. In many OEM stacks the reseller is a processor or service provider for its end customers and the vendor is a sub-processor below it, two steps removed from the people whose data is in the product.

That chain means personal data in end-customer content is almost never something the vendor can license on its own authority. Depending on who the end users are and where they live, GDPR, the CCPA or similar laws may apply, and counsel assesses that for each deal. Vendors usually find the safer, faster scope in records they created themselves.

Scoping a package that survives all three contracts#

A package survives the contract stack when every record in it has a clear controller and every required approval is in writing. In practice that means starting with vendor-created records and adding shared records only where the other party agrees.

Engineering histories are the natural core: issues, pull requests, code reviews, incident records and release notes describe how the vendor built and fixed the product. Vendor-to-reseller escalations can often be added after reseller names, end-customer identifiers and pricing are removed, provided the OEM agreement's confidentiality clause allows it or the reseller consents. End-customer content stays out unless every layer of the stack clearly permits it.

Telemetry and error logs are the gray zone. Usage events can look like the vendor's own operational data, yet they often carry end-customer account IDs, user emails and record names inside payloads. Include them only when both the OEM agreement and the reseller's end-customer terms permit that use of aggregated or de-identified data, strip identifiers at the field level, and disclose the use in the vendor's own terms going forward so the next renewal settles the question in writing.

Illustrative: an inspection platform sold under three brands#

Illustrative: a fictional vendor builds an inspection scheduling platform that three equipment distributors sell under their own brands. The vendor runs Jira, GitHub and a Zendesk instance for escalations from the distributors' help desks; each distributor handles its own end-user support in its own tools.

The general counsel built an ownership map and found that two OEM agreements allowed the vendor to use de-identified support data to improve its services, while the third defined all communications from the distributor as confidential with no carve-out. Engineering records were vendor-owned across the board, except for a reporting module one distributor had funded and owned.

The company scoped a package of Jira issues, GitHub pull requests and escalation tickets from the first two distributors, with distributor and end-customer names removed and the funded module excluded. It asked the third distributor for consent rather than relying on silence, and kept that distributor's escalations out while the request was pending. End-customer inspection records were never in scope.

How SourceX approaches multi-party rights#

Layered contracts are settled during Rights, the second stage of the SourceX five-step transaction, before any record is prepared. The review follows the record, not the brand: for each record family it identifies the controlling agreement, the parties whose material appears, and the approvals needed.

The result is written into the SourceX Evidence Packet as licensing rights, permitted use and release authorization for each record family, so the buyer can see the chain of rights and the supplier can see exactly what it approved. Nothing is shared during the initial fit check, which collects only metadata about systems and record types.