What is telemetry data, and who owns it?

What counts as telemetry data?#

Telemetry data is information a system records about itself and sends to whoever operates or supports it, without anyone typing it in. In a software company that means product usage events, feature counts, error and crash reports, performance traces, and logs from servers and databases. In equipment it means sensor readings, cycle counts, alarms, fault codes and runtime hours.

Telemetry differs from the records people create. A support ticket, a code review comment or a service report is written by a person and carries judgment. Telemetry is machine-generated, high volume, timestamped and narrow. That difference shapes both rights and value: telemetry is easy to collect at scale, but it rarely explains why something happened.

Who owns telemetry data?#

Telemetry data ownership is usually decided by contract, not by who generated the signal or who runs the server. In the US, raw facts such as a temperature reading or a click event generally get little or no copyright protection, although a compiled dataset kept secret can sometimes qualify as a trade secret. The practical questions are who has access, who the contract says controls the data, and what each party promised to keep confidential.

Three parties often have a claim. The vendor built the software or machine and collects the stream. The customer operates the product and may treat its own activity as confidential business information. Individual users, technicians or drivers may have privacy rights in data linked to them. A license to an AI developer has to respect all three.

That is why the word owner can mislead. A vendor may own the database and still be barred from sharing a customer's usage data. A customer may own its data and still have granted the vendor a broad right to use aggregated versions of it.

Three contract patterns that decide control#

Most software and equipment agreements fall into one of three telemetry patterns, vendor-controlled, customer-controlled or shared with limits, plus a fourth case where the contract says nothing. Identifying which pattern applies to each customer cohort is the first real step in any telemetry review.

Many companies hold all four patterns at once, because templates changed over the years and large customers negotiated their own paper. Sort agreements into cohorts by template version and by negotiated exceptions before deciding anything about the data itself.

Why 'improve the service' rarely covers an AI license#

A clause letting a vendor use telemetry to provide and improve its service usually describes internal use, not licensing to an outside developer. Training another company's model is a different purpose, carried out by a different party, for that party's benefit.

Counsel reviewing these clauses tends to look for an explicit chain: a right to create aggregated or de-identified data, a statement that the vendor owns that derived data, and permission to use it for any lawful purpose. Without that chain, the safer reading keeps telemetry inside the vendor's own operations.

• 1Definitions of customer data, usage data, service data and aggregated data, and where they overlap.
• 2Any clause on machine learning or AI training, including restrictions customers added in recent negotiations.
• 3Confidentiality terms that treat the customer's usage patterns as its confidential information.
• 4Privacy policy and data processing addendum language on analytics and secondary use.
• 5Post-termination clauses requiring deletion or return of data, including telemetry and backups.

What a licensable telemetry clause contains#

A telemetry clause that supports licensing defines usage data narrowly, reserves a right to aggregate or de-identify it, and says plainly that the result may be licensed to third parties for AI training. Each element answers a question that a customer's counsel or a buyer's diligence team will ask.

New terms govern data collected after customers accept them, so older history generally stays under the terms in force when it was collected. Expect negotiation: some enterprise customers strike AI training language or ask for an opt-out, and those exceptions need to be tracked customer by customer.

• 1Definition: usage data covers metadata about how the service runs and is used, and excludes customer content, files and messages.
• 2Derived data: the vendor may create aggregated or de-identified data, states the standard it applies, and owns the result.
• 3Purpose: derived data may be used for any lawful purpose, expressly including licensing to third parties to train and evaluate AI models.
• 4Protections: no output identifies the customer or its users, and recipients must not re-identify or link the data.
• 5Notice: the privacy notice and the data processing addendum describe the same secondary use.
• 6Exceptions register: customers who negotiated an opt-out are listed so their streams are excluded at export time.

When you are the customer, not the vendor#

Software companies are also customers of telemetry vendors: observability platforms, crash reporters, product analytics tools and cloud providers all hold streams about your systems. The same contract patterns apply in reverse, so check what each vendor's terms let it do with your logs and traces.

For engineering leaders, the more pressing point is what you can still export. Logs and traces stored in a vendor platform are often retained only for a window set by your plan, so older history may already be gone. If historical telemetry matters to a future license or to your own analysis, check retention settings and export routes before you need them.

Plants face the same question with controls and machine vendors. Equipment purchase terms and any connected-service agreement decide whether the plant can use CNC and sensor data freely, so read both before assuming the plant controls the stream.

Illustrative: a building automation software vendor sorts its telemetry#

Illustrative: a fictional building automation software company collects three streams: in-app usage events from facility managers, crash reports from its desktop console, and sensor readings from HVAC controllers at customer sites. An AI developer asks whether telemetry could be licensed alongside the company's support and engineering records.

The CTO and general counsel sort customer agreements into three template generations. The oldest is silent on data. The middle one lets the company use data to improve the service. The newest defines aggregated data as company-owned. Several enterprise customers also negotiated clauses barring any use of their sensor data outside the service.

They put forward crash reports that link to Jira issues, fixes and releases, because those sit closest to the company's own engineering work and carry little personal data after cleanup. Sensor readings stay out until clearer terms are in place, and the team adds an explicit aggregated data clause to the next renewal cycle.

How SourceX approaches telemetry rights#

SourceX treats telemetry as one record family among many in the Supply step of the SourceX five-step transaction and resolves its rights in the Rights step before any file moves. The fit check asks only which streams exist, which systems hold them and which contract templates cover them.

If telemetry is included, the SourceX Evidence Packet records the contract basis for each customer cohort, the privacy preparation applied, the permitted use and the supplier's release authorization. Streams with unclear rights are left out rather than argued over.