Your Product Works: Do You Have the Rights to Commercialize It?

The demo works. A potential customer is interested. Then the contract arrives, asking the company to confirm that it has the rights necessary to provide the product, protect customer information, and stand behind an infringement claim.

The company’s customer commitments must match the rights it actually holds. A working demo alone cannot establish that match.

Consider a startup whose co-founder wrote the initial code before incorporation. A contractor added features using AI development tools and open-source libraries. Now an enterprise customer wants a pilot, and an investor wants to review the company’s intellectual property.

Each contribution raises a different question about ownership, licensing, or permitted use, and affects what the startup can promise in the pilot agreement. Founders should resolve those questions before a customer contract or financing deadline makes the answers urgent.

Separate Ownership, Permission, and Protection

Founders often describe a product as “our technology.” That shorthand can conceal distinctions that matter when the company starts making contractual commitments.

Ownership asks which rights belong to the company and how it acquired them. Permission asks what the company can use under someone else’s license. Protection asks which elements qualify for legal protection and what the company can prevent others from copying.

A startup may own some original code, license a third-party library, and incorporate AI-generated material that does not independently qualify for copyright protection. Each category requires a different explanation.

The company needs sufficient rights for its business model and an accurate description of those rights. A license may permit commercial use without permitting exclusivity or unrestricted transfer to a customer. That distinction becomes consequential when the sales team agrees to terms the product’s underlying licenses cannot support.

AI Assistance Does Not Answer the Ownership Question

Under U.S. copyright law, human authorship remains central. The U.S. Copyright Office’s report on AI and copyrightability distinguishes using AI to assist human creativity from relying on AI to generate the expressive material itself.

Using AI does not automatically eliminate copyright protection. Original human-authored code, qualifying modifications, or sufficiently creative selection and arrangement may be protected. That protection does not automatically extend to underlying AI-generated material. The Office also explains that prompts alone generally do not provide sufficient control over generated expression to establish authorship.

Suppose the startup’s contractor says, “I used AI, but reviewed everything.” Reviewing code to confirm that it functions does not establish what the contractor authored. The company still needs to distinguish the system’s output from the contractor’s original expression before describing the code as proprietary in a customer agreement.

The provider’s terms require a separate review. A contractual provision allocating output rights cannot create copyright protection where the law does not recognize it. Permission from a provider also does not establish that every output is free from third-party claims.

Retain development records that identify material AI contributions and the basis for the company’s rights. Review the terms applicable to the tools and plans actually used.

Paying for Development Does Not Necessarily Transfer the Rights

The contractor delivers the features, the startup pays the invoice, and the founder assumes the company owns the work.

Payment alone does not establish that the contractor transferred the rights.

The Copyright Office’s work-made-for-hire guidance explains that the doctrine applies to employee work created within the scope of employment and certain specially commissioned works meeting statutory requirements. Labeling a contractor’s deliverables “work made for hire” does not make them qualify.

Contractor agreements should address assignments, retained materials, permitted uses, and subcontractor contributions. If the contractor incorporates a pre-existing framework, the company needs to know what remains the contractor’s property and whether its license supports the product’s operation, modification, and distribution.

The co-founder’s initial code deserves equal attention. If it predates incorporation, what document transfers the relevant rights to the company? If it originated during another engagement, could obligations to a former employer or client affect its use?

Founder status and equity ownership do not substitute for establishing the company’s rights. Confidentiality provisions serve a different purpose from assignments. For copyright transfers, Section 204 of the Copyright Act generally requires a writing signed by the rights owner or an authorized agent.

Missing assignments or unclear licenses can also lead to additional investor diligence, required remediation, and delayed closing. Resolve them while contributors are available and aligned.

Third-Party Components Shape Customer Commitments

Third-party tools and open-source software are ordinary parts of product development. Their terms help determine what the startup can deliver.

Distinguish a tool used during development from a component embedded in the product or a service required to operate it. Each can raise different questions about commercial use, modification, redistribution, customer access, and continued availability.

Open source is licensed software. Obligations depend on the license and implementation. The Apache License 2.0, for example, includes notice and other redistribution requirements. AGPLv3 can require offering corresponding source code to remote users interacting with a modified covered program. Not every open-source component requires disclosure of an entire proprietary product; the actual license and use require evaluation.

Suppose the enterprise customer requests exclusive ownership of the pilot’s custom features. If a feature includes the contractor’s pre-existing framework or an open-source component, the startup must distinguish what it can assign from what it can only license. The agreement should identify the rights the customer receives and any applicable restrictions.

The same review should inform ownership representations and infringement indemnities. Is the company accepting liability beyond the protection available from its suppliers?

Before signing, compare those commitments with the rights and protections available under the underlying agreements.

What Are You Giving the AI Access To?

A company’s rights review should also examine the information and authority it gives AI tools.

An October 22 Reuters report described banks blocking third-party AI agents from customer accounts amid concerns about access and actions beyond users’ instructions. The relevant lesson for founders is that access, authorization, and control require separate attention.

If the contractor uploads proprietary code or customer records to an AI tool, the company needs to establish whether that use is permitted under its existing obligations. AI integrated into the product may also retrieve customer information or act within connected systems.

Permission to access information for one purpose does not necessarily authorize sharing it with another provider or using it for a different purpose. The company must examine the relevant customer obligations and provider terms.

Technical controls matter as well. The Open Worldwide Application Security Project’s ( OWASP’s) guidance on excessive agency identifies risks from excessive functionality, permissions, and autonomy, including harmful actions triggered by manipulated instructions.

Review retention, training, and confidentiality terms alongside actual settings and integrations. Limit access to what the task requires, test those limits, and establish approval requirements for consequential actions.

Address these uses before promising the enterprise customer that its information will remain confidential or subject to specified use restrictions.

Ask These Questions Before the Next Commercial Milestone

Before launch, an enterprise pilot, or financing, founders should be able to answer six questions:

1. Who contributed to the product? Identify founders, employees, contractors, and subcontractors, including people who have left. Account for work created before the company existed.
2. What establishes the company’s rights? Locate signed assignments and applicable licenses. Identify retained materials, exclusions, and missing documents.
3. Where was AI used? Identify material generated content, relevant human contributions, and the provider terms governing that use.
4. What came from third parties? Inventory significant libraries, models, APIs, datasets, and other assets. Record applicable license versions and requirements.
5. What information and authority are being shared? Determine what enters AI tools, whether that sharing is permitted, and what connected agents can access, disclose, or change. Test whether the intended limits work.
6. Do commercial promises match reality? Compare the findings with customer contracts and financing representations, including ownership, licensing, confidentiality, security, and indemnity provisions. Resolve material gaps or adjust commitments before signing.

The result should be a usable record of important components, their sources, the basis for ownership or permitted use, restrictions, and outstanding actions. Legal and engineering teams should maintain it together as the product changes.

Use that record to resolve gaps or qualify contractual commitments before a customer or investor relies on them.

Before signing the next pilot agreement, the startup should be able to explain which rights it owns, which it licenses, and how those rights support the commitments it is making.

Image Source: Deposit Photos
Author: vitaliy_sokol
Image ID: 99285096