Who Owns The Code In A Software Development Contract?

If I pay a developer to build software, do I own the code? Usually, not automatically.

The reassuring part is that software development contract ownership can be sorted out clearly with the right written terms. The risky part is assuming payment alone gives your business full ownership, because under US copyright law, that often isn't enough when you're working with an outside developer.

When you're hiring someone to build an app, website, internal tool, SaaS product or custom integration, you want to know exactly what your business can use, change, sell, protect and take with you if the relationship ends.

Let's break down how ownership works in the US, what to check in your contract, and how developer tools and open-source components can affect what you really own.

Does Paying A Developer Mean You Own The Software?

No, paying a developer doesn't automatically mean your business owns the software.

Under the US Copyright Act, copyright usually belongs to the person or company that creates the original work. Software code is generally protected as a literary work. That means an independent developer or development agency may own the copyright in the code they write unless your contract transfers it to your business.

This can surprise people because the business paid for the work and gave the instructions. But payment, project management and approval don't always equal ownership.

For example, say you run an online booking platform and pay a contractor to build a custom scheduling tool. You pay every invoice. You launch the tool. Six months later, you want another developer to modify it. If your contract doesn't include a proper copyright assignment or broad enough license, the original developer may still control key rights in the code.

In practice, your contract should say whether your business gets:

• Full ownership of the custom code created for you
• A license to use the code for certain purposes
• Access only to a product, platform or hosted service controlled by the developer
• A mix of ownership for custom work and licenses for pre-existing tools or third-party components

The difference matters because it affects whether you can modify the software, commercialize it, move it to another provider, register or enforce rights, or use it as part of a business sale or fundraising process.

What Is A Work Made For Hire?

A work made for hire is one situation where your business may be treated as the author and owner of copyright from the start.

There are two main paths under the Copyright Act:

• Employee work: If an employee creates software within the scope of their employment, the employer usually owns the copyright.
• Certain commissioned works: Some specially ordered or commissioned works can be works made for hire, but only if they fit specific categories and there's a written work for hire agreement saying the work is made for hire.

For software built by contractors, the second path is often not as simple as people expect. A commissioned software project may not neatly fit the statutory categories for work made for hire. Because of that, many software contracts include both:

• A work made for hire clause, to the extent it applies
• A backup assignment clause, transferring all copyright and other IP rights to your business

That backup assignment is usually the safer part. It says that if the work isn't legally treated as a work made for hire, the developer assigns the relevant rights to your business anyway.

State law can also affect how employment and contractor relationships are interpreted, so if the ownership position really matters to your product or valuation, get tailored advice before you sign.

Do You Own The Code Or Just Have A License?

It depends on what your contract says, and the difference can be huge.

Ownership means your business holds the copyright in the relevant code. A software license agreement means someone else owns it, but gives your business permission to use it on agreed terms.

When Ownership Usually Makes Sense

Ownership is often important where the software is central to your business model. For example, you may want ownership if:

• The software is your main product
• You plan to sell subscriptions or licenses to customers
• You want to raise investment or sell the business later
• You need freedom to appoint another developer
• You want to prevent the developer from reusing your custom features for competitors

When A License May Be Enough

A license can be perfectly workable where you're using the developer's existing platform, framework or tool, and the custom work is limited. For example, if a developer configures a booking system they already own, you may only need a license to use that system for your business.

Your license should still be clear. It should cover:

• Who can use the software
• Whether your affiliates, contractors or customers can access it
• Whether the license is exclusive or non-exclusive
• Whether it's perpetual or ends when the contract ends
• Whether you can copy, modify, host, sublicense or transfer it
• What happens if you stop paying fees

If the contract is vague and simply says you can use the software, you may find the practical rights are narrower than your business needs.

What Should Your Software Development Contract Say About Ownership?

Your contract should clearly separate custom work your business owns from background technology, third-party materials and developer tools you only get a license to use.

A good software development agreement usually deals with ownership in layers. That way, everyone knows what sits where.

Custom Code And Deliverables

The contract or statement of work should define the deliverables. This might include source code, object code, documentation, designs, database schemas, APIs, configuration files, technical specifications and test materials.

If your business is meant to own those deliverables, the contract should include a present assignment of IP rights, not just a promise to assign them later. It should also require the developer to sign any further documents reasonably needed to confirm the transfer, such as documents for a Copyright Office recordation if that becomes relevant.

Pre-Existing Materials

Developers often bring their own libraries, templates, snippets, frameworks and processes to a project. These are commonly called background IP or pre-existing materials.

It's usually not realistic to expect ownership of all of that. Instead, your contract should say that the developer keeps ownership of their pre-existing materials, but grants your business a broad enough license to use them as part of the software.

Developer Tools And Platforms

Your project may depend on cloud hosting, deployment tools, analytics tools, payment processors, AI coding assistants, repositories, no-code tools or proprietary platforms.

Your contract should say:

• Which accounts your business owns
• Which accounts the developer controls
• Whether you get admin access
• What happens to credentials when the project ends
• Whether any ongoing subscription fees apply
• How source code and documentation will be handed over

This is where ownership can get practical very quickly. You might own the custom code, but if the developer controls the hosting account, repository or deployment pipeline, you may still struggle to operate the software without them.

Can A Developer Reuse Code From Your Project?

Yes, a developer may be able to reuse code unless your contract restricts it.

Developers often reuse general know-how, standard functions and non-confidential building blocks. That can be reasonable. But you may want to stop them from reusing your unique business logic, confidential information, customer data, proprietary workflows or custom features built specifically for your competitive advantage.

Your contract can deal with this by drawing a clear line between:

• General skills and know-how the developer can keep using
• Reusable background code the developer already owned
• Custom deliverables your business owns
• Confidential information the developer must protect
• Trade secrets that need extra care and access controls

For trade secrets, federal law under the Defend Trade Secrets Act can protect certain valuable business information if you take reasonable steps to keep it secret. In plain English, that means you need more than a label saying confidential. You should control access, use confidentiality terms, limit sharing, and keep records of what was disclosed.

If your software involves sensitive data, customer lists, pricing logic, AI prompts, proprietary algorithms or technical architecture, confidentiality and trade secret protections should sit alongside the copyright ownership clause.

How Do Open-Source Components Affect Ownership?

Open-source components don't stop you owning your custom code, but they can limit how you use, sell or distribute the software.

Most modern software uses open-source libraries. That's normal. The issue is that open-source software comes with license terms, and those terms vary a lot.

Some licenses are permissive and relatively business-friendly. Others may require you to disclose source code, include notices, pass on license terms, or allow recipients to modify and redistribute certain parts of the software.

Your contract should require the developer to:

• Disclose any open-source components used in the project
• Identify the relevant license for each component
• Avoid using open-source code that conflicts with your business model
• Provide a software bill of materials if appropriate
• Include required copyright notices and license text
• Get approval before adding components with more restrictive terms

This is especially important if you plan to distribute software to customers, embed it in a product, offer it as a SaaS platform, or provide enterprise customers with security and IP warranties.

Open-source issues often appear during due diligence for a sale, investment round or major customer contract. Cleaning them up later can be painful, so it's better to keep records from day one.

What Other IP Rights Should You Think About?

Copyright is the main ownership issue for code, but it isn't the only IP right that may matter.

You may also need to think about:

• Trademarks: Your product name, logo and brand may be protected through use and, more strongly, through federal registration with the USPTO under the Lanham Act.
• Copyright registrations: The Copyright Office handles copyright registration, which can help if you ever need to enforce rights in the US.
• Patents: Some software-related inventions may be patentable, but the rules are technical and the threshold can be high.
• Trade secrets: Confidential algorithms, datasets, workflows and technical processes may be protected if you keep them secret.
• Data rights: Your contract should say who owns or can use data, analytics, logs, training data, licensed datasets and outputs generated through the software.

For many small businesses, the most practical starting point isn't a patent filing. It's a clear ownership clause, a confidentiality clause, a sensible license structure and clean records showing what was built, when, by whom and using what components.

What Should You Check Before Signing Or Paying The Final Invoice?

You should check the ownership, access and handover terms before you sign and again before you make the final payment.

Here's a practical checklist:

• Does the contract say who owns the custom code and deliverables?
• Is there a clear IP assignment clause, not just a vague statement about ownership?
• Does the developer give your business a license to any background IP needed to use the software?
• Are open-source components disclosed and approved?
• Do you get source code, documentation and build instructions?
• Does your business control the repository or at least have full admin access?
• Who owns the domain, hosting, cloud accounts and app store accounts?
• Can you hire another developer to maintain or improve the software?
• Are confidentiality and data security obligations clear?
• Does the contract include warranties that the developer's work won't knowingly infringe someone else's IP?
• Is there a sensible process for acceptance testing, bug fixes and final handover?

Templates can be a useful starting point, but software projects tend to have moving parts. A document works best when it's tailored to how your product will actually be built, hosted, maintained and commercialized.

Before final payment, ask for a handover pack. This might include repository access, deployment instructions, admin credentials, documentation, licenses, asset files, API keys transferred to your account, and a list of third-party services the software depends on.

Frequently Asked Questions

Can I Register Copyright In Software Code?

Yes. Software code can generally be registered with the Copyright Office, although you may need to follow special deposit rules for source code and trade secrets. Registration can help with enforcement, but it doesn't replace having a clear assignment from the developer.

Who Owns Code Written By My Employee?

Your business usually owns code written by an employee within the scope of their employment. Even so, your employment agreement and IP policy should confirm this clearly, especially for employees who create product, design or technical work.

Can I Sell Software If It Includes Open-Source Code?

Often, yes, but it depends on the open-source licenses involved and how the software is distributed. Check the license terms before you sell, sublicense, embed or distribute the software.

What If My Developer Refuses To Hand Over Source Code?

Your options depend on the contract. If source code handover is a required deliverable, you may have contractual rights to demand it. If the contract only gives you access to a hosted service, the developer may not have to provide source code.

Key Takeaways

• Paying a developer doesn't automatically give your business ownership of the code.
• For contractor-built software, a written IP assignment is usually safer than relying only on work made for hire wording.
• Your contract should separate custom code, developer background IP, third-party tools and open-source components.
• A license may be enough for some projects, but ownership is often important if the software is your core product.
• Open-source components can affect how you commercialize, distribute or disclose software.
• Access, documentation and handover terms are just as practical as the ownership clause itself.

If you'd like help with your software development contract, IP ownership clauses, open-source position or developer handover terms, you can reach our team at (888) 449-8437 or team@sprintlaw.com. Where legal services are required, they're provided by licensed US lawyers at ElevateNext US, LLC, a trusted US law firm, through the Sprintlaw platform.