Who Owns Your Software's Source Code?

It's the clause nobody reads until they need it, and by then it's no longer negotiable.

You paid for a development. It works, it's in production, your company operates on it daily. Then one day you want to switch vendors, or the vendor shuts down, or simply raises the maintenance price and you have no alternative. That's when the question comes up: is this mine?

The honest answer is that it depends on what you signed, and plenty of people find out late that the answer is no.

Paying isn't the same as owning

This is the part that surprises people. Generally, and with variation by country, rights over a creative work stay with its creator unless there's an express assignment. Contracting and paying for a development doesn't automatically transfer intellectual property.

It's the same logic as with a photographer: you pay for the session, but the rights to the photos follow whatever you agreed.

With software almost nobody thinks about it that way, which is why it needs to be in writing, without ambiguity.

What the contract has to say

It doesn't need to be long. It does need to say these things plainly:

1. Assignment of intellectual property. That economic rights over the developed software transfer to the client, including source code, once payment is settled. Check that it says source code and not just "the software" — handing you an executable isn't handing you the code.

2. Delivery of the repository with history. Not a ZIP of files: the complete Git repository. The history is part of the value, because it explains why things are the way they are.

3. The accesses. Servers, database, domain, third-party services, App Store and Google Play accounts, payment gateways. As administrator, not as a guest.

4. Technical documentation. How to build the project, how to deploy it, what environment variables it needs, what integrations exist.

5. What happens if the relationship ends. A concrete deadline to hand everything over, conditioned on nothing beyond outstanding payments.

Code without accesses is worth little

A case we see regularly: the company has the code, feels safe, and the day they want to move the system they discover the domain is registered to the vendor, the server is in his personal cloud account, and the app is published under his developer account.

The code was theirs. The operation still wasn't.

Ask for a written list of every service the system uses and whose name each one is under. If anything is under the vendor's, have it transferred. It's a few minutes of paperwork while the relationship is good, and a nightmare when it isn't.

The signs you're being locked in

It isn't always ill intent — sometimes it's just vendor convenience. But the effect is identical:

• "The code is ours, you have a license to use it." A legitimate model if they say so up front and the price reflects it. It stops being legitimate when it appears afterwards.
• "It's on our server, it's easier that way." May be true, and it should be your server, or at least your account.
• "You don't need the repository." You do.
• No documentation. Sometimes sloppiness. Sometimes strategy: if nobody else understands the system, nobody else can maintain it.
• Unusual technology with no explanation. A proprietary framework nobody else uses means only they can work on it.

The five-minute test

Ask yourself: if I wanted to switch vendors tomorrow, could I do it without asking the current one for anything?

If you can pull the code from the repository, log into the servers with your own account and hand everything to another team, you're fine. If the answer depends on the vendor cooperating, you're locked in.

And note the timing: the moment to fix this is while the relationship is good. Nobody negotiates the exit in the middle of a dispute.

What's reasonable on the other side

To be fair, there are things a vendor can reasonably retain:

• Internal tools and proprietary libraries used across all their projects. The reasonable arrangement is a perpetual use license on that part and full ownership of everything specific to your project.
• Know-how. Nobody can ask them to unlearn.
• Showing the work in their portfolio, unless you agree otherwise.

What isn't reasonable is your business specifics — your processes, your rules, your data — staying in someone else's hands.

How we handle it

At Deepyze the code is 100% the client's, with the repository, the accesses and the documentation, and it's written into the proposal before work starts. Not out of generosity: because a client who stays out of preference is a better relationship than one who stays because they can't leave.

The flip side is that if you want to leave, you can. That seems like the right deal.

A checklist before signing

• The contract expressly assigns rights over the source code.
• It says "source code", not just "the software".
• The Git repository with full history gets delivered.
• There's a list of services and whose name each is under.
• Accesses are administrator-level and in your name.
• Deployment documentation exists.
• There's a dependency list with licenses.
• It's clear what happens, and how fast, if the relationship ends.

If any point draws resistance, ask why. The answer tells you a lot about what working together will be like.

---

If you're about to sign a development contract and want someone to read the proposal with a technical eye first, that's exactly what a one-off consulting session is for. And if you want to see how we write scope, ask us for a proposal.