Why licensing tends to work better as a relationship than a transaction

The licence is signed and the agreed diagnostic data package is delivered. During implementation, the intermediary discovers that the Seed & Key algorithm needed for a specific vehicle system is missing.

The contract may describe the required scope correctly. Someone still has to identify the gap, arrange delivery and confirm that the intermediary can perform the agreed function.

That work continues after the initial handover. Information changes, systems are replaced and people move on. A licensing relationship needs a way to deal with those events throughout the term, with the contract remaining the source of the parties’ rights and obligations.

Check that the agreed use works

A signed licence can be in force while practical access is incomplete. An agreed vehicle range or model year may be absent from the dataset. An interface may return an outdated version. Authentication may be active without supporting the required function, or an update feed may arrive less often than agreed.

Implementation should check whether the delivered information and access support the use described in the licence. The depth of that check should reflect the arrangement; it need not involve inspecting every data item. Any gaps need an owner, a response route and a record of what remains outstanding.

It also helps to separate the agreed service from ideas discussed during negotiation. A possible future delivery method should not enter operation simply because somebody raised it before signature. Operating records help people apply the licence; they do not amend it.

Automotive experience shows why this matters. A European Commission review found that the completeness, accuracy, format and visibility of repair-information updates could affect the time and effort needed to find and use the information. (European Commission report) Article 61 of Regulation (EU) 2018/858 likewise illustrates that effective access can depend on completeness, format, continuing availability and updates—not only the initial grant of permission. These are European requirements in their applicable setting, but the operating lesson carries across.

Give issues a clear route

Once access is working, most contact can be prompted by an event: missing data, an authentication failure, a system update or a proposed new use. Both parties should know who can investigate and who can approve a change.

The OEM may know what was published or configured in the source system. The intermediary may see the failure during use. Bringing those accounts together helps identify whether the cause sits in the data, interface, provider process or an assumption made during implementation. Recording an issue provides a basis for diagnosis; it does not establish fault.

A recurring problem deserves more than another reset. If the same update fails each month, restoring the feed leaves the underlying cause unresolved. The record should show the recurrence and who is investigating it.

Licences spanning several systems, recipients or information streams may need scheduled reviews as well. The frequency should follow the work and the risks. A clear contact and a usable issue record are often more valuable than another standing meeting.

Decide when a change needs approval

Resetting an account or supplying missing data may restore the service already agreed. Adding an information category, territory, recipient or permitted use raises a different question: does the licence cover the proposed change?

A replacement interface or provider can also affect security, support and access controls, even if the intended use stays the same. The parties may need to revisit part of implementation and confirm that the revised delivery still meets the agreement.

Keep the decision visible. A workaround used repeatedly should not become the accepted service by default, and an operational contact should not be left to approve a change outside their authority.

Keep a record that survives a handover

Agreement, implementation, operation, change and renewal are connected stages. They can overlap: a new information stream may be going live while another is under review, or renewal may begin before an outstanding issue is resolved.

The records should let a successor establish:

• what scope and use were agreed;
• what information and access were actually put in place;
• which issues remain open and who is handling them; and
• what changes were authorised during the term.

This does not require a separate account of every conversation. It requires a reliable connection between the agreement, the configured service and subsequent decisions. If that connection exists only in one person’s memory, a staff change can leave both parties reconstructing the history from their inboxes.

Use that history at renewal

Renewal is the point to compare the original scope with what the intermediary now needs and what the OEM can support. Repeated failures, new uses, changed providers and unresolved limitations should inform the decision alongside commercial terms.

The outcome may be continuation, a revised licence, a different delivery model or an end to the arrangement. An operating history makes those choices easier to explain and implement.

By the time renewal begins, both parties should be able to see what worked, what changed and what needs a decision. Maintaining that record through the term is much easier than rebuilding it when the licence is about to expire.