This is the second in a series of articles designed to provide SXSW and LSI USA ’26 attendees and other MedTech professionals with practical considerations for efficiently executing mission-critical life science deals.

Collaborations often start with a simple premise: build something together, share the risk, and create value.

The complexity shows up later when investors or buyers ask who actually owns the platform.

In co-development structures involving devices and software, ownership and control are rarely binary. They are defined by layered licensing arrangements, regulatory allocations, manufacturing dependencies, and IP assignments that were often negotiated quickly to get a deal done.

Those early decisions determine whether a company can scale, pivot, or exit without renegotiating foundational agreements under pressure.

Background IP

In most collaborations, each party brings value in the form of its existing or background intellectual property (IP).

Distinguishing this key background IP from IP developed during the collaboration is critical.

Investors and buyers focus on:

• Does the company own its background IP outright?
• What rights does the partner have to background IP?
• Who owns improvements to background IP developed during the collaboration?
• Do the partner’s rights to background IP limit a buyer’s potential use cases?

We regularly see agreements where a company’s background IP is broadly “licensed” to a partner without sufficient restrictions. This can create ambiguity and limit the company’s ability to leverage its own technology in other contexts risk for a buyer.

To ensure a successful collaboration, it is essential to maintain ownership of core technology while granting reasonable usage rights throughout the partnership. If the partner can use, modify, and sublicense the company’s foundational background IP without restriction, the company has effectively given away platform control.

Developed IP, Improvement, and Reuse Rights

Typically, the goal of a collaboration is to develop something. Most parties think about ownership of the developed IP.

However, in platform development collaborations, value often accrues through improvement to the parties’ background IP or future improvements to the developed IP.

The question is who owns those improvements and who can reuse them.

If improvements developed with one partner cannot be deployed with other customers, scalability is constrained. If the partner can use improvements freely without compensation or restriction, the company loses control over its platform evolution.

Key issues include:

• Who owns improvements to the software or device?
• Can the company apply enhancements to multiple customers?
• Does the partner have royalty-free rights to improvements?
• Are improvements subject to field restrictions or exclusivity?

Experienced teams separate improvements to background IP (which should flow back to the owner) from improvements in developed IP (which may be shared). They also preserve the right to incorporate learnings and functionality into the core platform for use with other customers.

If improvement rights are not clearly defined, diligence becomes contentious and deal risk increases.

Field Restrictions and Portability

Field-of-use restrictions limit where and how the platform can be deployed.

A partner may request exclusivity in a specific clinical area, patient population, or geography. That may be reasonable if narrowly defined. It becomes problematic when restrictions are vague, broader than intended, or if a buyer cannot terminate the license and has a different use case in mind.

Investors and buyers evaluate:

• Can the company deploy the platform in adjacent markets?
• Do restrictions apply to the device, the software, or both?
• How are field boundaries defined, and who decides if a use case falls within a restricted field?
• Can field restrictions be terminated or narrowed over time?

Field restrictions that made sense during a pilot can block expansion into high-value markets later. They should be drafted with scale in mind and include clear termination or step-down provisions as the relationship matures.

Software Licensing Structure

In device-software collaborations, the software licensing model determines who can use the platform, how, and under what restrictions.

Most structures involve a combination of:

• Licenses from the company to the partner.
• Licenses from the partner to the company.
• Sublicensing rights for third-party deployment.
• Field-of-use restrictions that limit where the software can be used.

The licensing structure should align with the business model. If the company intends to license the platform broadly, restrictions that limit deployment to specific devices, customers, or geographies create friction.

We often see licenses granted on a “non-exclusive, royalty-free” basis during co-development. That language can be appropriate. It can also create problems if the license is irrevocable, transferable, or includes broad sublicensing rights that allow the partner to compete or enable others to do so.

Licensing terms that seemed reasonable early on can become constraints when the company seeks to monetize the platform independently.

Data Ownership

Data ownership and use cannot be assumed, especially as the importance of quality of data continues to rise. When dealing with AI-specific software, the importance increases even more. Data inputs are usually owned by the entity that provides them, which should be clearly established between the parties. It is the data output that often comes into question for data ownership.

Key issues include:

• Who owns the data inputs and outputs?
• Can all parties use the data output equally?
• Do all parties get equal access to the data outputs at the same time?
• Can all parties modify or build upon the data outputs?
• Who can file patent applications on discoveries/innovations based on the data outputs?
• Should confidentiality provisions apply to the data output?
• Can all parties train their AI on the data output?

Care must be taken to preserve or appropriately allocate ownership and use of platform outputs with input value in mind. Data used as an input by a jointly developed platform can be equally valuable.

Consider how data will be used on the platform, both with other data and as output. If a first party’s valuable data is used as an input and a partner uses the resulting outputs, the first party may lose important rights to its original data.

Regulatory Considerations Affecting Ownership

In healthcare and other regulated environments, defining ownership and control starts with understanding who is responsible for regulatory compliance.

If one party holds the regulatory filing and the other develops the software or a hardware component, ownership becomes entangled with operational control. The entity that owns the device clearance or approval often controls product modifications, labeling, and distribution.

That creates leverage.

Investors ask:

• Who holds the regulatory submissions?
• Can the company modify the software without partner approval?
• What happens if the regulatory holder terminates the relationship?
• Can the company file independently in other markets?

We regularly see structures where a health system or strategic partner holds the FDA clearance or CE mark, and the company provides the software under license. That arrangement may work during pilot phases, but it becomes a constraint when the company wants to scale independently or enter adjacent markets.

The co-development agreement should clearly allocate regulatory responsibilities and preserve the company’s ability to obtain its own regulatory approvals if the relationship ends or expands.

What This Means for Investors, Health Systems, and Strategics

The common thread is specificity. Vague language around ownership, licensing, and control creates negotiating risk later. Provisions that feel collaborative early on often become leverage points during financing or M&A.

Teams that structure these arrangements with scale and exit in mind build platforms that can grow without renegotiating foundational rights under pressure.

For investors, these collaboration provisions define scalability and can equate to deal acquisition risk. Collaboration structures that limit platform portability or fragment IP ownership increase cost and complexity of growth.

For health systems, clarity around regulatory responsibility, data rights, and improvement ownership determines whether collaboration creates sustainable value or long-term risk.

For strategics, understanding who controls the platform, how it can be deployed, and what restrictions apply affects acquisition valuation and integration planning.

Most collaborations are formed with good intent. What matters is whether the structure holds up when capital, growth, or transaction timelines accelerate.