Code Ownership: Who Owns What Your Dev Squad Writes?

By default, code belongs to whoever writes it — not to whoever pays for it. In most jurisdictions, including the United States, software commissioned from an independent contractor doesn't fall into the categories the law recognizes as “work made for hire,” so a squad, agency, or freelancer retains copyright in the code unless a contract explicitly assigns it to the company that paid for the project.

Paying the invoice isn't enough: without that assignment in writing, a company can end up without legal ownership of the product it financed. It's a problem that almost never shows up until it matters — a funding round that requires technical due diligence, a vendor switch, a dispute over exclusivity — and that's when someone reviews the contract and finds there was never an IP assignment clause, or that the one in place was poorly drafted.

Why doesn't paying for the code make you its owner?

Copyright law defines a closed list of categories eligible for “work made for hire” treatment on works produced by third parties — translations, contributions to a collective work, parts of a motion picture, and a few others — and software commissioned from an independent contractor isn't one of them (17 U.S. Code § 101). That's why the “work for hire” label alone, without an explicit rights assignment, almost never transfers real ownership of the code: the legal default is that the original author keeps the rights, and the contract has to reverse that rule in writing, not assume it.

What does a contract need to actually transfer ownership of the code?

A solid IP assignment isn't a loose sentence on the last page. At minimum, it needs to cover:

• An assignment clause written in the present tense — “assigns and transfers,” not “will assign” — so the transfer takes effect the moment the code is created, not pending some later step.
• The full scope of the work: not just the final deliverable, but documentation, internal scripts, infrastructure configuration, and any other artifact produced during the project.
• Explicit treatment of pre-existing libraries and components the squad already had before the project — those get licensed for the client's use, not assigned, and the contract needs to say which ones they are.
• A waiver of moral rights where the jurisdiction allows it, to prevent later claims over attribution or modification of the code.

What happens if an explicit assignment was never signed?

Without an assignment, the company that paid for the project ends up in a weaker legal position than it assumes: it doesn't hold an ownership right it can enforce against a third party, it can't file a copyright infringement claim over that code without being the rights holder, and any attempt to sell the product, raise a funding round, or switch technical vendors can run into the same unanswered question. Regulation is moving in this direction: in California, the Freelance Worker Protection Act — in effect since January 2025 — directly requires that every contract with a freelance worker be in writing, recognizing that leaving it verbal or implicit is the most common cause of these disputes.

How does Zenit solve this?

At Zenit, IP assignment isn't something every company has to negotiate from scratch with every squad: it's part of the agreement a squad operates under on the platform, not a loose point that depends on someone remembering to ask for it. That contractual clarity is paired with verifiable evidence: SafePay releases each payment against a specific milestone, with agreed acceptance criteria and work delivered in the repository — so beyond the contract, there's a concrete record of what was built, when, and under what condition.

That combination — a clear contract plus verifiable evidence — is the same logic that protects a company if a squad can't finish a project: what was already built and accepted doesn't depend on anyone's memory.