Secure the Rights Needed to Productize

Task

Review service contracts for reusable IP, data rights, and productization limits.

Summary

Review intellectual property, data rights, contracts, and operational constraints before reusing service-created assets.

Make Sure Your Service Contracts Let You Build the Product

Task ID: S1-13

A service company can discover a valuable, repeatable product and still lack the legal right to sell it. Before reusing code, methods, templates, customer data, or project improvements, the company must separate what belongs to the customer from what it may retain and commercialize. This article explains how to find those limits, change the contracts, and document a defensible productization decision.

Why service contracts become product limits

A consulting company delivers a similar solution for several customers. The projects use the same workflow, code libraries, templates, prompts, data transformations, and delivery methods. Customers keep paying because the work produces a useful result. The founder now wants to turn the repeated parts into a standalone product.

Then someone reads the contracts.

One agreement says the customer owns “all work product” created during the engagement. Another prohibits using anything learned from the customer for another party. A data-processing addendum permits customer data to be used only to deliver the contracted service. A subcontractor agreement says nothing about ownership. An old statement of work grants one customer exclusive rights in its industry.

The product opportunity may be real, but the company’s right to pursue it is uncertain.

The central operating principle is straightforward:

Separate customer-specific assets from reusable company assets before depending on either one in a product.

That means distinguishing at least four categories:

1. Customer materials and data: information, systems, content, records, specifications, and intellectual property supplied by the customer.
2. Existing company assets: software, tools, methods, templates, models, libraries, documentation, and know-how developed before or outside the engagement.
3. Project-specific results: deliverables or inventions created specifically for the customer during the engagement.
4. Reusable improvements: general enhancements, techniques, components, and learning produced during delivery that do not disclose customer confidential information or contain customer-owned material.

The contract must say who owns each category, what each party may do with it, whether a licence is required, and which restrictions survive the end of the project.

Buying a deliverable does not necessarily transfer the copyright in it. In Canada, the author is generally the first copyright owner, subject to an employee-work exception, and an assignment or grant of an interest must be written and signed. UK guidance similarly states that an independent creator usually retains copyright in commissioned work unless the parties agree otherwise in writing; an implied licence may let the customer use the work for its intended purpose without transferring ownership. U.S. “work made for hire” treatment has its own legal requirements and should not be assumed merely because a customer paid for the work.

This review belongs early in the move from consulting to a repeatable offer or software product. The company is not yet deciding the complete product architecture, subscription terms, or sales model. It is determining whether the assets discovered through customer work can lawfully support those later decisions.

The required evidence is therefore more than a lawyer’s general reassurance. It should include an intellectual-property and data-risk checklist, a risk register tied to individual contracts, required changes to future contract templates, and a remediation plan for existing agreements. “Risks logged” is a useful working target, but logging is not the same as resolving or consciously accepting a risk.

What has changed around intellectual property and data rights

The distinction between a custom deliverable and a reusable product is not new. What has changed is the range of assets involved.

A service engagement may now produce source code, configuration files, prompts, evaluation data, vector representations, fine-tuning records, generated content, usage telemetry, synthetic data, workflow definitions, and improvements made with third-party artificial-intelligence systems. Older contracts often discuss only “documents,” “software,” and “confidential information.” They may not answer whether the provider can reuse a generic prompt pattern, train a model on customer interactions, retain aggregated telemetry, or incorporate an improvement into a multi-customer product.

At the same time, data-protection rules impose duties that cannot be solved simply by declaring that one party “owns the data.” Where a provider processes personal data for a customer, the contract may need to identify the processing purpose, duration, data types, affected people, security duties, subprocessors, assistance obligations, audit rights, and return or deletion requirements. European Commission standard clauses and UK Information Commissioner guidance set out these elements expressly.

The last five years have made these questions more operationally important:

timeline
    title Developments affecting service-to-product contract reviews
    2021 : EU adopts standard controller-processor clauses
         : Federal Circuit rules that exceeding a software licence condition can constitute infringement
    2023 : U.S. Copyright Office opens its artificial-intelligence study
    2024 : EU Data Act enters into force
         : EU Artificial Intelligence Act enters into force
    2025 : EU Data Act begins to apply
         : General-purpose AI obligations begin to apply
         : U.S. Copyright Office releases its report on generative-AI training
    2026 : Wider EU AI Act provisions are due to apply on August 2
         : Full enforcement of general-purpose AI provider obligations begins

The timeline shows why an old service agreement may no longer cover the actual work. In June 2021, the European Commission adopted standard controller-processor clauses that require the parties to document the processing and control subprocessors. The EU Data Act entered into force on January 11, 2024, and began applying on September 12, 2025, introducing rules concerning access to connected-product data, data sharing, unfair contractual terms, and switching between data-processing services.

Artificial-intelligence rules have added another layer. The U.S. Copyright Office began a formal AI initiative in 2023 and released a pre-publication report on generative-AI training on May 9, 2025. In the European Union, obligations for providers of general-purpose AI models began applying on August 2, 2025. They include technical documentation, information for downstream providers, a copyright-compliance policy, and a public summary of training content. Broader AI Act provisions were scheduled to apply on August 2, 2026, although some high-risk-system dates have been extended.

A service company is not necessarily a regulated general-purpose model provider. The business lesson is narrower: contracts must now say whether customer information may enter an AI tool, whether the tool provider may retain or train on it, whether outputs may be reused, who reviews output rights and risks, and whether customer consent is required.

Research also argues against searching for one universal ownership formula. A 2025 open-access study coded contracts from 484 university–industry projects and found substantial variation in ownership, use rights, publication, and confidentiality. The researchers identified proprietary, controlled-access, and open models rather than a single dominant allocation suitable for every collaboration.

The appropriate structure therefore depends on what the customer is buying, what each party contributes, how sensitive the data is, who finances development, and whether the provider is being paid merely to deliver a result or also to surrender future commercial rights.

Choose the rights model before editing individual clauses

A contract review becomes confused when the team starts redlining words without first deciding the intended business arrangement.

The company should choose a default rights model for its repeatable offer, then identify customer agreements that depart from it. Four common approaches are compared below.

Public model agreements show that ownership and use can be separated deliberately. Canada’s archived acquisition clauses distinguish “Background Intellectual Property” from “Foreground Intellectual Property” and pair ownership with licences needed to use the resulting work. The UK Lambert Toolkit offers several models: one party may own results and license them to the other, ownership may be divided by result, or commercial rights may be allocated by field and territory. Its guidance recommends avoiding joint ownership where a clearer division is possible.

These models were designed for public procurement and research collaboration, not as ready-made terms for a software consultancy. Their useful lesson is structural: ownership, access, use, modification, commercialization, confidentiality, and data protection are separate decisions.

For many consulting-led software companies, the most practical default is:

• The customer retains its pre-existing intellectual property, confidential information, and data.
• The provider retains its pre-existing tools, software, templates, methods, models, and general skills.
• The contract states whether the customer owns bespoke deliverables or receives a durable licence to them.
• The provider retains general improvements and reusable components, but may not disclose customer confidential information or reuse customer-owned content.
• Each party receives the licences needed to use the combined deliverable.
• Additional rights—such as exclusivity, transfer of reusable source code, or model-training rights—are priced and approved separately.

This is a business starting point, not a legal rule. A customer financing substantial research, assuming unusual risk, contributing essential technology, or buying a genuinely exclusive result may reasonably demand broader rights. Conversely, a low-fee implementation project should not quietly transfer a platform whose development was funded across many customers.

Exclusivity deserves particular attention. It can be limited by product, customer segment, field of use, territory, named competitor, or time. An unrestricted promise not to use similar ideas for other customers can prevent productization far beyond the revenue of the original engagement. Any exception should be deliberate, priced, approved, and recorded.

Run the review against the actual work

The review should cover the entire contract stack, not just the paragraph headed “Intellectual Property.”

A customer relationship may be governed by a master services agreement, statements of work, change orders, purchase orders, data-processing terms, security exhibits, confidentiality agreements, online terms, proposal language, and later email amendments. An order-of-precedence clause may cause one document to override another.

The legal review should be conducted alongside an operational map of what the team actually created and used. Lawyers can interpret language, but delivery leads, engineers, product staff, security staff, and data owners know where the code, prompts, datasets, configurations, and third-party components came from.

The following checklist turns that review into an operating record.

Data rights need a separate analysis from copyright ownership. A customer may contractually control the provider’s use of data, but personal information remains subject to legal rights and duties. Under processor-contract guidance, required provisions can include documented instructions, confidentiality, security, subprocessor controls, help with individual rights and breach duties, deletion or return at termination, and audit support.

The contract should therefore describe permitted uses rather than relying on a vague statement that one party “owns all data.” At minimum, distinguish:

• data supplied by the customer;
• data generated through use of the service;
• operational and security logs;
• statistics aggregated across customers;
• information inferred from customer records;
• model inputs, outputs, evaluation records, and feedback;
• backups and legally required records.

A right to use data for delivery does not automatically include a right to use it for benchmarking, marketing, unrelated analytics, product development, or model training. Those purposes should be stated separately, with an opt-out or affirmative permission where the applicable law and risk justify it.

The same discipline applies to software licences. In Bitmanagement Software GmbH v. United States, the U.S. Navy installed software on more than 429,000 computers after buying a much smaller number of licences. The Federal Circuit found an implied licence but held that the Navy’s failure to use the agreed licence-tracking mechanism put its copying outside the licence’s scope. The case illustrates how deployment rights, copy counts, simultaneous users, technical controls, and licence conditions can determine whether use is authorized.

For a productizing service company, the lesson is not limited to enforcement against customers. The provider also needs to know whether its own licence from a customer, subcontractor, model vendor, or component supplier permits the intended product deployment.

Measure risk and prove readiness

The primary measure is the number and type of contract risk items discovered. That count is useful for managing work, but it is not a performance benchmark. Ten minor drafting issues may be less important than one clause assigning the customer all reusable improvements.

A credible risk register should connect each item to the affected contract, asset, customer, revenue, product capability, and proposed remedy.

A simple internal prioritization score can multiply severity, likelihood, and business reach. For example, each risk might receive a severity score from one to five, a likelihood score from one to five, and a reach score from one to three. That is an internal decision tool, not an industry standard. The correct scale and acceptance threshold will vary by jurisdiction, customer concentration, deal size, data sensitivity, and product architecture.

quadrantChart
    title Illustrative contract-risk priorities
    x-axis Low product impact --> High product impact
    y-axis Low urgency --> High urgency
    quadrant-1 Fix first
    quadrant-2 Compliance urgent
    quadrant-3 Monitor
    quadrant-4 Resolve before scaling
    "Customer owns all work": [0.92, 0.92]
    "No existing-IP carve-out": [0.88, 0.84]
    "Customer-data use unclear": [0.84, 0.94]
    "AI training not addressed": [0.78, 0.81]
    "Contractor assignment missing": [0.74, 0.73]
    "Publicity approval unclear": [0.29, 0.34]

The positions above are illustrative. The production version should use actual register data. A useful chart type is a bubble chart with product impact on the horizontal axis, urgency on the vertical axis, and bubble size representing affected revenue, customer count, or number of dependent product capabilities.

The register should separate four statuses:

• Fact: the signed agreement contains a particular clause.
• Interpretation: counsel or the operating team believes the clause has a stated effect.
• Assumption: the team expects a customer or contributor to agree to a change.
• Decision: the risk has been resolved, avoided, transferred, or accepted by a named person.

This separation matters because a risk can look “closed” merely because someone assumes the customer will consent later.

The review is complete only when the company can trace important product assets back to valid rights, identify any use that still requires permission, and show how future agreements prevent the same uncertainty. The number of risks is unspecified until the contract population and product asset map are known.

Risks, judgment calls, and remaining research

Several failure modes make a contract review look complete when it is not.

Reviewing only the current template. The new master agreement may be sensible while the most valuable customer relationship remains governed by a five-year-old assignment clause.

Treating payment as proof of ownership. Copyright and licence rules depend on authorship, employment status, written assignments, and governing law—not simply on who paid the invoice.

Leaving the existing-IP schedule blank. A contract can say that the provider retains existing technology, yet provide little protection if no one can identify what that technology includes.

Using “general know-how” as a substitute for rights. A know-how clause may protect skills and experience, but it does not necessarily authorize copying customer-owned code, data, documents, or confidential designs.

Calling information anonymous without testing it. Removing names does not by itself establish that information cannot be linked back to a person or customer. The contract, data architecture, and technical process must agree on what is retained and how re-identification is prevented.

Ignoring contradictory documents. A master agreement may permit service improvement while the data-processing addendum limits processing to documented customer instructions. A security exhibit may require deletion while the intellectual-property clause expects retained development records.

Promising rights the company never obtained. Public model-agreement guidance emphasizes acquiring rights from contractors who participate in creating project results. A customer-facing assignment is unreliable if the provider’s own contributor agreements do not support it.

Assuming more contractual control is always better. Research involving 344 senior IT employees found that contractual mechanisms were associated with joint innovation, while relationship mechanisms were important to learning; the study also found inverted-U effects, suggesting that excessive governance can become counterproductive. Clear terms are necessary, but they cannot replace working communication about new uses, changes, and boundaries.

There are also legitimate exceptions to a reuse-first default.

A customer may require exclusive ownership because it is funding the full development cost of a strategically distinctive system. Health, financial, government, employment, or other sensitive data may make cross-customer reuse inappropriate even when a contract could theoretically permit it. A narrowly defined exclusive field may be commercially worthwhile. Some reusable functionality may be cheaper and safer to rebuild independently than to renegotiate disputed legacy rights.

The decision should compare the value of the right being surrendered with the price, strategic relationship, replacement cost, and effect on future customers. An assignment of a one-off report is not economically equivalent to an assignment of the core software library required by every future implementation.

The remaining research is company-specific. It cannot be completed from standard clauses alone. The operating team and qualified counsel still need to determine:

• the governing law and jurisdiction of each material agreement;
• the full population of customer, employment, contractor, supplier, and partner contracts;
• which repositories, datasets, prompts, models, documents, and processes the planned product will use;
• who created each important component and under what agreement;
• whether third-party software, data, and AI-service terms permit the planned use;
• whether any customer information can be removed, regenerated, licensed, or replaced;
• which customers must approve an amendment, waiver, consent, or new licence;
• whether the intended data uses match the company’s technical controls and public representations.

No formal prerequisite may have been assigned to this task, but practical inputs are still required: a complete contract inventory, an asset and data-flow map, a proposed ownership model, and access to people who understand how the work was delivered. This is an operating review supported by legal advice, not a substitute for counsel qualified in each governing jurisdiction.

The decision this work should support

At the end of the review, the company should be able to answer a narrow but consequential question:

Can it build and sell the planned product without using intellectual property or data beyond the rights it actually holds?

A defensible “yes” requires more than a favourable reading of one clause. The company should be able to show:

• what the customer owns;
• what the company owns;
• what each party merely licenses;
• which project results are customer-specific;
• which components and improvements may be reused;
• which data uses are permitted;
• how employee, contractor, vendor, and third-party rights flow through the product;
• which exclusivity or market restrictions apply;
• which legacy agreements still need amendments, consents, waivers, or replacement assets;
• who has accepted any remaining risk.

Future contract templates should then preserve that answer. The master services agreement, statement of work, data terms, contributor agreements, and product terms should use compatible definitions and rights. Existing customers with blocking terms require individual remediation; a new template does not rewrite an old contract.

Once those conditions are met, the company can evaluate the product opportunity on customer demand, delivery economics, and product performance rather than discovering later that its most reusable asset was assigned away, its data use was never authorized, or its licence does not cover the way the software is sold.

Sources

Primary and official sources

• Government of Canada, Copyright Act, section 13, covering first ownership, employee works, assignments, and licences.
• UK Intellectual Property Office, Ownership of Copyright Works, including employee and commissioned-work guidance.
• U.S. Copyright Office, Circular 30: Works Made for Hire.
• European Commission, standard controller-processor contractual clauses under Article 28.
• UK Information Commissioner’s Office, required controller-processor contract contents.
• European Commission, EU Data Act application guidance.
• European Commission, AI Act implementation timeline and general-purpose AI provider obligations.
• U.S. Copyright Office, Copyright and Artificial Intelligence initiative and reports.
• CanadaBuys, archived acquisition clauses distinguishing background and foreground intellectual property.
• UK Intellectual Property Office, Lambert Toolkit and model-agreement guidance.
• U.S. Court of Appeals for the Federal Circuit, Bitmanagement Software GmbH v. United States.

Open research

• Lie, Egelie, Grimpe, and Sørheim, “The Fine Print of Collaboration: How Contractual Provisions Govern IP and Disclosure in Publicly Funded Research,” Research Policy, 2025.
• Kranz, “Strategic Innovation in IT Outsourcing: Exploring the Differential and Interaction Effects of Contractual and Relational Governance Mechanisms,” Journal of Strategic Information Systems, 2021.