Who Owns Software Intellectual Property in the US?

A founder who pays a developer for an app, platform or website can still end up without owning the code. The common mistakes are assuming payment equals ownership, accepting files in a repository as proof of legal rights, or signing an agency proposal that is silent on intellectual property.

Software IP ownership matters when you raise funding, sell the business, license the product, enforce copycat claims or switch development teams. A messy position can slow down diligence, block a product launch, or leave the original developer with leverage over your roadmap.

The goal is to know who owns the code, designs, documentation and other deliverables before work starts. A clear contract should say what is assigned to your company, what is only licensed, what third-party tools are included, and what happens to pre-existing materials and open source components.

Software IP Ownership Checklist Before Work Starts

The safest position for a founder is a written agreement that assigns the project-specific intellectual property to the company and clearly identifies anything the developer keeps.

Before the first sprint, deposit or handover, confirm the deal in writing. A statement of work, master services agreement or software development agreement can be enough if it includes the right intellectual property language. An invoice, quote or email chain usually will not deal with all the rights you need.

Use this checklist to pressure-test the commercial deal:

• Who is doing the work? Identify the developer, agency, subcontractors, designers, product consultants and any offshore or freelance contributors.
• What deliverables are being created? List source code, object code, APIs, databases, schemas, UI designs, wireframes, product copy, technical documentation, test scripts, models, prompts, workflows and deployment files.
• What will your company own? The agreement should say whether the deliverables, copyright, inventions and other project IP are assigned to your company.
• What will the developer keep? Developers often retain pre-existing code libraries, generic tools, templates, know-how and reusable methods. That can be fine if your company receives a broad enough license to use them in the product.
• When does ownership transfer? Some contracts transfer rights on creation, while others transfer only after full payment. The timing matters if a dispute arises mid-project.
• Can you access and modify the code? Owning custom software is less useful if you do not receive source code, credentials, build instructions and deployment access.
• Are third-party materials allowed? The agreement should control open source software, stock assets, purchased plugins, AI-generated outputs and third-party APIs.
• Can the developer show the work publicly? Portfolio rights, case studies and public announcements should be limited if your product is confidential or not yet launched.
• What warranties back the work? The developer should promise that, to its knowledge, the deliverables do not infringe third-party rights and that it has obtained rights from its personnel and subcontractors.
• What happens on termination? You should receive completed work, work in progress, access credentials and transition assistance, subject to the commercial terms you agreed.

A useful contract does not need to say your company owns every idea the developer has ever had. It should draw a practical line between project-specific work that becomes yours and background technology the developer can keep using elsewhere.

Payment, Possession and Legal Ownership Are Different

Paying for development work and receiving the files usually gives you practical access, but it does not automatically transfer copyright or other intellectual property rights.

This distinction surprises many founders. If an agency builds your minimum viable product and uploads the code to your repository, you may have possession of the code. If you paid the invoices, you may also have a contractual right to receive the services. But unless the agreement transfers ownership, the agency or individual developer may still own copyright in the code they created.

Under the federal Copyright Act, copyright generally belongs to the author of the work when it is created. For software, that often means the programmer or company that wrote the code. There are exceptions, but founders should not rely on assumptions.

An employee's work created within the scope of employment is often owned by the employer under the work made for hire doctrine. A contractor's work is different. A commissioned work under a work for hire agreement is only a work made for hire if it fits within specific statutory categories and there is a written agreement saying it is a work made for hire. Custom software development often will not fit neatly into those categories, so a separate written IP assignment agreement is commonly used.

A clean assignment says that the developer assigns to your company all right, title and interest in the project IP. It should cover copyright, inventions, patent rights if relevant, database rights to the extent recognized, design materials, documentation and any other rights in the deliverables. It should also require the developer to sign further documents if needed for registrations, funding diligence or a future sale.

Possession can create another false sense of security. You may have the Git repository, design files and admin logins, but legal rights can still sit elsewhere. You might be able to run the product for now, but not modify it, sublicense it, sell it as part of an asset deal, or stop the developer from reusing key code in a competitor's product.

The reverse can also happen. A contract might say your company owns the IP, but you cannot actually operate the software because the developer has not handed over source code, deployment instructions, credentials or third-party account access. Legal ownership and operational control need to be addressed together.

Founder example: a startup hires a freelancer to build a scheduling app. The freelancer is paid in full and sends a zip file with the latest build. Six months later, the startup raises seed funding and investors ask for IP assignments from everyone who contributed code. If the freelancer never signed an assignment, the company may need to renegotiate under pressure, even though it paid for the work.

Another example: an agency contract says the client owns the final deliverables after final payment, but excludes the agency's framework, reusable modules and internal tools. That can be acceptable if the client has a perpetual, worldwide, royalty-free license to use those items as embedded in the product. It becomes a problem if the exclusion is so broad that the company cannot maintain or commercialize the software without the agency's permission.

State law can affect contract interpretation, implied licenses, employment relationships, and remedies. The federal baseline for copyright is still crucial, but the wording of your agreement and the law chosen in the contract can change the practical answer.

What Copyright, Trademark and Trade Secret Law Usually Protects

Software projects contain several different types of intellectual property, and each one needs a different ownership or control strategy.

Copyright is the main protection for code and many creative deliverables. It can protect source code, object code, UI artwork, written documentation, website copy, illustrations and audiovisual materials. Copyright does not protect the general idea for an app, a business model, a broad feature concept or a method of operation in the abstract.

Registration with the US Copyright Office is not required for copyright to exist, but it can matter if you need to enforce copyright in court. For business planning, the first priority is usually to make sure your company has received the necessary assignments from developers, designers and other contributors.

Trademark law protects brand identifiers, not the software code itself. Under the Lanham Act, trademarks can include product names, company names, logos, slogans and other marks that identify the source of goods or services. USPTO registration can strengthen your position, but using a mark without clearance can create conflict even if your code ownership is clean.

A software project can also generate trade secrets. Under the federal Defend Trade Secrets Act, business information can qualify as a trade secret if it derives value from not being generally known and you take reasonable measures to keep it secret. In software, that may include source code, algorithms, product roadmaps, security architecture, customer data strategies, pricing models or technical processes.

Trade secret protection depends heavily on behavior. Confidentiality clauses, restricted repository access, password controls, limited disclosure, employee and contractor obligations, and sensible offboarding processes all help show that the company treated the information as confidential.

Patent rights may be relevant for some software-enabled inventions, although not every software feature is patentable. If your project includes a novel technical process, hardware interaction, machine learning method or data processing architecture, the agreement should assign inventions and patent rights created during the project. A patent attorney can help assess whether filing is worthwhile.

Data is another category founders often confuse with IP. Customer data, analytics, training data, log files and user content may be controlled by contract, privacy law and platform terms rather than simple ownership concepts. If the developer hosts or processes data, your agreement should address permitted use, security, deletion, return, and limits on using data to train models or improve unrelated products.

Open source software needs special attention. Many projects rely on open source libraries, frameworks and packages. Some licenses are permissive and compatible with commercial products. Others can impose disclosure, attribution, source code availability or license flow-down obligations. A founder should know what open source components are included and whether their licenses fit the product's business model.

AI-assisted development adds another practical layer. Developers may use code generation tools, design tools or AI-assisted testing. Your agreement can require the developer to follow your approved tool policy, avoid inputting confidential information into public tools, review outputs for infringement risks, and identify any AI-generated deliverables if that matters for your company records.

The best contracts map these categories to specific rights. Your company may own the new code, have a license to the developer's background tools, own the product name through trademark use and registration, protect the source code as a trade secret, and control customer data through privacy and security terms.

Clauses That Decide Who Owns the Code and Deliverables

The clauses that matter most are the IP assignment, license-back, background IP, third-party materials, confidentiality, acceptance and termination provisions.

A software development agreement should not bury ownership in vague wording. Phrases like the client owns the project or all files will be delivered may not be enough. Stronger drafting describes the rights being transferred and the assets covered.

Look for an assignment clause that covers deliverables created for your company. It should apply to work product whether complete or incomplete, and whether created by the main developer, employees, subcontractors or approved contributors. If payment is a condition of transfer, understand what happens to partially paid work or disputed invoices.

Common ownership models include:

• Full client ownership of project IP: The company owns custom code, designs and documentation created specifically for the project, while the developer keeps background tools and general know-how.
• Developer ownership with client license: The developer owns the software and grants the company a license to use it under a software license agreement. This may work for a white-label platform or configured product, but it is often unsuitable for a venture-backed product company.
• Split ownership: Different modules, content or assets have different owners. This can work if the boundaries are clear, but it creates diligence and enforcement complexity.
• Joint ownership: Both parties own some rights together. This is often harder to manage than founders expect because licensing, enforcement and commercialization rules can be unclear or vary by right and contract wording.

For most startups building their core product, full ownership of the project-specific IP is the cleanest target. If that is not commercially available, the license must be broad enough to support your business plan. It should cover use, reproduction, modification, hosting, sublicensing to customers or service providers, internal and external commercialization, and transfer in a financing, merger, asset sale or business sale.

Background IP is where many disputes start. Developers often bring their own libraries, snippets, templates, deployment scripts, admin dashboards, testing frameworks and reusable architecture. It is reasonable for them to keep those assets. The founder's concern is whether the product can operate, scale and be maintained without later permission. The contract should grant your company a perpetual, irrevocable, worldwide, royalty-free license to use any background IP embedded in or necessary for the deliverables.

Third-party materials should be approved and documented. A contract can require the developer to keep a list of open source packages, commercial plugins, stock assets, APIs and hosted services. It should also say who pays recurring license fees, who maintains subscriptions, and what happens if a third-party provider changes terms or shuts down an integration.

Confidentiality clauses should protect more than code. They should cover product plans, credentials, business strategies, customer information, security details, pricing, investor materials and technical documentation. They should also restrict the developer from using confidential information to build similar products for others. A narrow confidentiality clause can leave too much room for reuse of sensitive product knowledge.

Portfolio and publicity clauses deserve attention. Developers may want to mention your company on their website, show screenshots, publish a case study, or discuss the tech stack. That may be fine after launch, but it can be risky while you are fundraising, filing IP, entering a regulated market or testing a confidential feature.

Acceptance clauses decide when work is considered delivered and approved. A practical clause gives the company a review period, identifies acceptance criteria, and requires the developer to fix defects or nonconforming work. Without acceptance mechanics, a dispute over whether a feature is finished can turn into an ownership and payment standoff.

Termination clauses should deal with handover. If the relationship ends, you need the current source code, design files, documentation, database exports, credentials, build pipeline information and a list of dependencies. The agreement can require a transition period, especially if the developer hosts the software or controls production infrastructure.

Warranties and indemnities allocate risk if a third party claims the software infringes their rights. A developer may not accept unlimited liability, but founders should still seek promises that the work is original or properly licensed, that contributors have assigned rights, and that no harmful code has knowingly been introduced.

For companies preparing for funding or acquisition, keep signed copies of every relevant document. Investors and buyers often ask for invention assignment agreements from founders, employment agreements with IP terms, contractor agreements, agency agreements, open source records and evidence that the company owns or can use its software. A missing signature from an early developer can become more expensive to fix later.

FAQs

Does A Developer Own Code They Write For My Company?

A developer may own the code they write unless they are an employee creating it within the scope of employment or they have signed a written agreement transferring the rights to your company. For contractors and agencies, a written IP assignment is usually the cleanest way to confirm ownership.

Does Paying An Invoice Mean I Own The Software?

Payment alone usually does not transfer copyright. It may prove that services were bought and paid for, but legal ownership depends on the contract, work made for hire rules, assignment language and any license terms that apply.

Can My Company Own Custom Software If The Developer Keeps Their Tools?

Yes, if the contract separates project-specific deliverables from the developer's background IP. Your company can own the custom code and designs while receiving a broad license to any retained tools needed to run, maintain and commercialize the product.

What If The Contract Says Nothing About Software IP Ownership?

Silence creates risk. Copyright may remain with the person or company that created the work, subject to any implied license or other contract rights. Implied licenses can be narrow and fact-specific, so it is better to sign a clear assignment or amendment before the project becomes valuable.

Who Owns The Product Name And Logo?

The product name and logo raise both copyright and trademark issues. A designer may own copyright in logo artwork unless it is assigned, while trademark rights usually depend on brand use in commerce and can be strengthened through USPTO registration under the Lanham Act.

Key Takeaways

• Payment, file access and repository control do not automatically mean your company owns software intellectual property.
• Contractors and agencies should sign written IP assignment clauses that cover code, designs, documentation, inventions and other project deliverables.
• Developers can reasonably keep pre-existing tools and reusable know-how, but your company needs a broad license to anything required for the product.
• Copyright, trademark, trade secret, patent, data and open source issues should be treated separately because each has different rules.
• Clear records, contributor assignments and third-party materials lists make fundraising, product launches and future exits much easier.

If you are hiring a developer or agency, need to clean up past contributor paperwork, or want a software development agreement that covers ownership, licensing, confidentiality and handover, you can reach our team on (888) 449-8437 or team@sprintlaw.com. Where legal services are required, they are provided by licensed US lawyers at ElevateNext US, LLC, a trusted US law firm, through the Sprintlaw platform.