Who Owns Your Code? Software IP Explained

The default rule is not what most buyers assume

The intuition 'I paid for it, so I own it' describes how buying a chair works, not how copyright works. Code is authored, and authorship generally vests copyright in the author or their employer. When the author is your employee working within their job, ownership typically flows to your company; when the author is a contractor, freelancer or external studio, it typically stays with them unless a written agreement assigns it to you. The precise rules differ by country — some recognise 'work made for hire' categories, others do not — which is exactly why the contract, not the invoice, is where ownership lives.

In practice, a missing assignment clause rarely explodes on day one. It explodes when you try to sell the company and due diligence asks for the IP chain of title; when you hire a second developer to extend code the first one technically owns; or when a relationship sours and the leverage question gets asked out loud. All three are expensive moments to discover a sentence that should have been in the contract two years earlier.

The clauses that decide ownership

Open any development contract and search for the terms below. Together they answer the ownership question completely; where one is absent, assume the default rule fills the gap — against you. This is the same list a lawyer will check first, so checking it yourself makes the review faster.

• 'Assignment of intellectual property' — the keystone. Should assign all IP in the deliverables to you, ideally on payment, in plain words.
• 'Work made for hire' — a US-law category; useful where it applies, but a good contract pairs it with an express assignment as backup.
• 'Licence' / 'licence grant' — if this is the only IP language, you are renting. A perpetual licence is still not ownership.
• 'Background IP' / 'pre-existing materials' — the developer's reusable tools and libraries. Fine, if named and broadly licensed to you.
• 'Moral rights' — in some jurisdictions authors retain rights to attribution; contracts commonly include a waiver where local law allows.
• 'Open-source components' — the contract should oblige the developer to use only licences compatible with your commercial use.

Open source: the part nobody owns

Every modern application is mostly open-source components with your product's specific logic on top — and that is healthy, not a defect. You will never own React, Postgres or the thousands of packages underneath your product, and you do not need to. What you need is that each component's licence permits your commercial use, and that nothing in the stack carries obligations you cannot live with.

The practical concern is copyleft licences, which in some circumstances can require releasing your own source code. Most permissive licences — MIT, Apache — carry no such obligation and power the bulk of commercial software. You do not need to become a licensing expert; you need one line in the contract obliging the developer to use commercially compatible licences and to list the major components on request. For most small-business products this is a five-minute conversation, and a licensed advisor can review the list in the rare case something looks unusual.

The numbers behind the modern stack

How much of 'your' code is actually yours to own? Black Duck's Open Source Security and Risk Analysis has reported that 97% of audited codebases contain open-source components, and that 86% contained at least one vulnerable open-source component. In other words, the ownership question in practice is about the minority of the codebase that is genuinely bespoke — your workflows, your integrations, your product logic — plus the configuration that wires the open-source majority together. That is exactly the part an assignment clause must capture, and exactly the part a departing developer could otherwise hold.

There is also a quality dimension to ownership that rarely gets discussed. CISQ, the Consortium for Information and Software Quality, estimated the cost of poor software quality in the US at $2.41 trillion for 2022, with roughly $1.52 trillion of it sitting as accumulated technical debt — the cost of reworking software that was built badly or documented never. Legal title to an undocumented, unmaintainable codebase is a deed to a building with no doors. When you negotiate ownership, negotiate the documentation and deployment access that make it usable, or you own the liability without the asset.

Who owns AI-generated code?

A growing share of any new product is machine-drafted: Stack Overflow's 2025 Developer Survey found 84% of developers using or planning to use AI tools, and across PINCLER's 79 documented projects the tooling is on the record — GPT appears on 76 projects and Cursor on 75, with the full dataset at /research/what-you-can-build. That raises a fair question: if an AI wrote a function, can anyone assign its copyright to you?

The legal theory is unsettled and varies by jurisdiction — some copyright systems require human authorship, and purely machine-generated output may attract thin protection or none. The practical answer, fortunately, does not depend on how that resolves. Real production code is prompted, selected, edited and reviewed by humans, which anchors the usual rights, and the contract should simply assign whatever rights exist in all deliverables, however produced, to you. Pair that with the practical controls — your repository, your accounts — and the philosophical question stops mattering commercially. If AI authorship is central to your product's value, this is a named topic to raise with a lawyer in your jurisdiction.

Practical ownership: the checklist that makes it real

Legal ownership without practical control is a lawsuit waiting to be needed. Practical control means that if your developer vanished tomorrow — retired, acquired, unreachable — your product would keep running and any competent replacement could pick it up. That is achieved with accounts and access, not clauses, and you can verify every item below in an afternoon.

• The code lives in a repository owned by your account or organisation — the developer works in your GitHub, not their own.
• Hosting, database and domain are registered to accounts in your name, with billing on your card.
• Third-party services — Stripe, email delivery, LLM APIs, WhatsApp Business API — are your accounts, with keys you can rotate.
• You hold admin access to everything, tested by actually logging in, not by being told you could.
• Deployment is documented well enough that a new developer could ship a change without calling the old one.
• The assignment clause exists, and you have paid whatever it names as the trigger for transfer.

A worked example: what weak ownership costs

Put numbers on the risk. Suppose you commission a booking product at $1,450 — the median across PINCLER's 79 documented projects — but from a developer who hosts it on their own accounts with no assignment clause. Month eight, the relationship sours. Rebuilding from scratch with a new team costs the full price again, call it $1,450, plus data migration, downtime and your own hours re-briefing — conservatively another $500. Total: roughly $1,950, or about 134% of the original build, to end up where you already were.

Prevention, priced against that: the assignment clause and your-accounts arrangement cost nothing to ask for, plus perhaps one hour of legal review — assume $300 at a typical hourly rate — which is about 15% of the $1,950 cure. The maths worsens with scale. Clutch's published pricing guide puts US, Canadian and Australian rates at $100–$149 per hour at the time of writing, so a 300-hour rebuild at agency prices runs $30,000–$44,700. The protective sentence in the contract is identical at every size; only the cost of not having it grows.

Ownership models compared

Most arrangements you will be offered reduce to three shapes. The comparison below is what each one means when you want to switch developers, sell the business, or simply keep running after a dispute — read the middle column as 'what your lawyer will tell you during due diligence'.

What good looks like, and how to ask for it

The clean arrangement is simple to describe: IP assigns to you on payment; the work happens in your repositories from week one; every account is yours; the developer retains only their pre-existing tools, named and licensed. None of this is exotic — it is how PINCLER structures every project by default, because a client who can leave at any time is a client you have to keep earning, and we think that incentive belongs in the contract.

If you are negotiating with any developer, ask for exactly that arrangement in writing before work starts, and treat resistance as information. Then have the final document read by a lawyer in your jurisdiction — especially the assignment and licence language, where one word changes the meaning. If you want to see ownership-first terms with a fixed price attached, any of our use-case pages shows the shape of it, and a free 30-minute call will put it in writing for your specific project.