Who Owns the Code When You Hire a Development Agency

Most companies find out who owns their software at the worst possible moment: when they want to change vendors, sell the company, or raise money and an investor's lawyer asks for the intellectual property assignment. The answer should have been settled before the first line of code was written. This guide is written from the buyer's side: what ownership means, what the contract has to say, what you never own regardless of the contract, and what to ask before you sign.

One caveat before we start. We build software; we are not lawyers. What follows is general information based on how development contracts work in practice, not legal advice. Contract law and copyright rules differ by country and change over time, so have your own attorney review the ownership clauses of any agreement before you sign it.

Ownership is not automatic

A common assumption is that paying for software makes it yours. In practice, ownership of code follows copyright, and copyright starts with whoever wrote the code, unless a contract moves it. In the US the “work made for hire” concept covers employees, but for outside contractors it applies only to specific categories of work and only with a written agreement, and custom software often does not fit those categories cleanly. That is why professional contracts do not rely on it; they include an explicit assignment.

With a foreign vendor there is a second layer: the vendor's own law. In most European countries, including Serbia, the rights to a work start with its author and move to someone else only by contract. Without a written assignment you may end up holding a license to use the software, which is not the same as owning it. You can run it, but modifying it, selling it or handing it to another vendor may all be in question.

Work for hire, assignment and license: what the words mean

An assignment transfers ownership to you. A license gives you permission to use something that someone else still owns, on terms they set. A “perpetual, exclusive license” sounds comfortable until you try to sell the company, sublicense the software to a partner or hire someone else to change it, and discover the license does not cover that. If the goal is ownership, the word in the contract needs to be assignment.

A usable IP assignment clause says, at minimum: that all deliverables, including source code, designs, documentation and configuration, are assigned to you; when the assignment takes effect, on creation or on payment, stated clearly; that it is worldwide and irrevocable; that the vendor waives or agrees not to assert moral rights where the law allows; that the vendor will sign any further paperwork needed to record the transfer; and that the clause survives termination of the contract. It should also say what happens if you stop paying, because a vendor will reasonably want that covered too.

Repositories and accounts in your name from day one

The contract is the legal side. The practical side is where the code lives. Create the repository organization, the cloud account, the domain registration, the app store accounts and the accounts for any third-party services yourselves, with your company's email and your company's payment method, and give the vendor access as a collaborator. Access you grant is access you can revoke. If the code lives on the vendor's infrastructure and “will be handed over at the end”, the handover becomes a negotiation instead of a formality.

This also protects you from smaller failures than a dispute: a vendor closing down, a key person leaving, or a card on file expiring and an account being suspended. When everything is in your name, the worst case of a bad breakup is that you need a new vendor. When it is in theirs, the worst case is that you need a lawyer. Serious agencies prefer it this way as well, because it removes an entire category of arguments about what was delivered.

What you do not own: open source and third-party components

No modern software is written from scratch. Your system will include open-source libraries, frameworks, and probably services accessed through APIs. You do not own any of those, and no contract can make you. What you have is a license for each, and licenses differ. Permissive licenses such as MIT and Apache let you use the component in a proprietary product with minimal obligations. Copyleft licenses such as the GPL family can impose obligations on your own code if the component is combined with it in certain ways. Ask your vendor which license types are allowed in your project and to keep a list.

The vendor's own pre-existing tools are the second category. Many agencies bring internal libraries, templates or utilities to every project. That is efficient, but it means part of your system is “background IP” that the vendor keeps. The contract should say that any such components are identified and licensed to you perpetually and without further payment, so they can never be used to hold your system hostage. At handover, ask for a component list showing every third-party and vendor-owned piece, with its license.

Escrow, and why you rarely need it

Source code escrow means a neutral third party holds a copy of the source and releases it to you if the vendor goes out of business or breaches the contract. It makes sense when you license a finished product from a vendor who keeps the source code, because in that situation you have no other way to get it.

For custom development where the repositories are in your organization from day one, escrow adds cost and administration without adding protection: you already hold the source, every commit of it, in an account you control. If a vendor proposes escrow instead of putting the repositories in your name, that is a sign the ownership arrangement is weaker than it should be. Fix the arrangement rather than insuring against it.

What to ask before signing

Six questions settle most of it. Which clause assigns the intellectual property to us, and when does it take effect? Where will the code live during development, and in whose accounts? Which pre-existing components of yours will be used, and how are they licensed to us? Which open-source license types do you allow, and will we get a list? What exactly do we receive at handover: source, documentation, credentials, deployment instructions? And what happens if we stop the project halfway, in terms of both code and payment?

The answers reveal more than a portfolio does. A vendor who has them ready has been through this before; one who has to check is telling you something. These questions belong alongside the rest of the partner selection checklist, and they interact with the pricing model: in a fixed-price contract the assignment should follow milestone payments, not wait for the end of the project.

What we put in writing

Our own terms are simple, and we are happy to have them checked. The intellectual property is assigned to the client from the first day, in writing, with no conditions beyond payment for the work delivered. We sign the client's NDA and master services agreement rather than requiring ours. Repositories, cloud accounts and services are created in the client's name, with our engineers added as collaborators. At handover the client receives a component list with licenses, documentation and deployment instructions, and a documented exit is part of the contract, not a favor.

You can read more about who we are and how we work, or see how these terms fit into a custom software engagement. If you have a contract in front of you and want a practical, non-legal read of the ownership clauses, send it over and we will tell you what we would ask.