You paid for the software, it went live, and your teams use it every day. But if you ever want to part ways with the development company or hand the system over to another team, will you actually have the source code? Many companies run into this question for the first time when it is already too late. When intellectual property rights in custom software are not clearly regulated in the contract, the fee you paid may not give you the ownership you expected.
In this article, you will find the default legal status of source code, the difference between assignment and licensing, the clauses that belong in your contract, and a checklist you can use at handover. Our goal is not to give legal advice, but to help you ask the right questions at the right time. We strongly recommend working with a lawyer for the final contract text.
Who Owns the Source Code by Default?
In Turkey, computer programs are protected as works under the Law on Intellectual and Artistic Works (FSEK). The law considers the author to be the person who created the work. In other words, the person or organization that wrote the code retains the rights unless a contract says otherwise. Simply having paid for a piece of software does not mean those rights automatically pass to you.
Two concepts need to be distinguished here:
- Moral rights: These protect the author's bond with the work and cannot be transferred.
- Economic rights: These are the financial rights such as reproduction, adaptation, distribution, and making the work available. They can be assigned or licensed by contract.
The assignment of economic rights generally has to be in writing, and the assigned rights are expected to be listed individually in the contract. A general sentence such as "the software is delivered to the client" often fails to meet this requirement and leads to disputes over interpretation later on.
The difference between an employee and an independent contractor also matters. For programs developed within an employment relationship, there are special rules in favor of the employer regarding economic rights. When you buy services from an outside company, however, the company building the software is an independent contractor, and the rights stay with it unless they are assigned. So do not treat code produced by your in-house team the same way as code produced by an agency or software company.
Assignment or License? Three Core Models
Saying "we want the source code to be ours" does not describe a model on its own. In practice we see three different structures, each with its own cost, flexibility, and risk.
| Model | What does it mean? | Advantage | Watch out for |
|---|---|---|---|
| Full assignment of rights | Economic rights are assigned to the client; the code becomes the client's property. | You can develop the software with any team you like, sell it, or turn it into a product. | It usually comes at a higher price; pre-existing components should be carved out as exceptions. |
| Non-exclusive license | You have the right to use the software, while ownership stays with the developer. | The upfront cost is low, and the developer can offer the product to other clients too. | Duration, scope, number of users, and code access limits must be written clearly. |
| Partial assignment / hybrid model | Custom modules pass to the client; the shared core stays with the developer and is licensed. | It balances customization and cost. | Which part belongs to whom should be documented with an attached component list. |
The right model depends on the purpose of the software. For an internal system that only runs your own operations, full assignment usually makes sense. If it is a product you plan to sell to others, keeping the rights firmly in your hands from the start becomes even more important. This is especially critical in SaaS platform development projects, because the product itself determines the value of the company.
Intellectual Property Clauses Your Contract Should Include
Defining the working model (fixed price, time and materials) is not enough on its own. The assignment of rights should be regulated in a separate, explicit clause. We covered the differences between working models in our guide to software contract models; here we list the headings you should look for in a contract from an intellectual property perspective:
- Scope of the assigned rights: Listing rights such as reproduction, adaptation, distribution, and modification one by one.
- Time and geography: Whether the assignment is perpetual and also covers territories outside Turkey.
- Timing of the assignment: Do the rights pass at signing, or when the final payment is made? An assignment conditional on payment is common and reasonable.
- Materials to be delivered: Source code, database schema, API documentation, installation scripts, design files.
- Pre-existing components: Defining the libraries and frameworks the developer produced independently of the project in a separate list.
- Third-party and open source components: Reporting the packages used together with their license types.
- Confidentiality and non-compete limits: How the developer will protect your trade secrets and data, and whether it can build a similar product for someone else.
- Warranty and indemnification: A statement that the delivered code does not infringe the rights of third parties.
- Maintenance period and code access: Who will hold code and environment access once support ends.
We recommend going through this list together with the technical scope before the contract is signed. The topics in our article 12 questions to ask before starting a custom software project make a good foundation for that conversation.
Pre-Existing Components and Open Source Libraries
Is the developer's "ready-made core" part of your code?
Most software companies carry internal libraries, authentication modules, or admin panel skeletons that they reuse across projects. These exist before your project starts, and the developer may want to only license them to you. This can be a legitimate request, but if it is not clearly written into the contract, it turns into an argument over who owns half of the code.
The practical solution is simple: attach a component list to the contract. For each component, the list should state its name, who owns it, and under what scope you are granted the right to use it (perpetual, transferable, together with the product). A perpetual and irrevocable license is the most critical wording for your source code to keep working on your side.
Open source licenses can be a silent risk
Most modern software relies on open source packages. Permissive licenses such as MIT and Apache generally cause no problems in commercial use. By contrast, some "copyleft" licenses may require you to share your own source code under the same license when you distribute it. This matters especially if you plan to sell the software as a product or distribute it to customers.
What you should ask for at delivery is a dependency report that lists all the packages used along with their licenses. This report is also useful later in processes such as investor due diligence or the sale of the company.
AI-assisted coding
It is now common for development teams to use code assistants. Practice is still not settled regarding the legal status and license risks of code produced with these tools. In your contract, we recommend asking explicitly whether the developer uses AI tools, whether client data is sent to these tools, and how the generated code is reviewed.
Scenario: Paid in Full, Code Never Delivered
Let's consider a realistic example. A mid-sized logistics company commissions a custom web application for shipment tracking. The contract only says "delivery of the software"; there is no provision on source code, assignment of rights, or infrastructure access. Three years later, the company wants to expand the system with a new team.
The former developer says that only the compiled application and a right of use were delivered, and that the source code remains its own property. The server and domain name are also sitting in the developer's account. The result: the company has to either buy the code at a high price or have the system rewritten from scratch.
None of the problems in this scenario is technical; all of them could have been prevented with contract clauses written upfront. Another way to reduce similar risks is to clarify the technical scope from the start. In our custom software development process, we put these topics on the table at the proposal stage.
Handover Day Checklist
Even if the assignment of rights is written in the contract, the right stays on paper unless actual delivery takes place. At project close, verify the following one by one:
- Full access to the source code repository (Git) through an account opened in your name, and a complete transfer of the commit history.
- Documentation describing the build and deployment steps, along with CI/CD configuration files.
- Database schema, sample data, and the backup/restore procedure.
- Server, cloud, domain name, SSL certificate, email service, and third-party API accounts all being in your name.
- For mobile apps, Apple Developer and Google Play accounts being run under your own corporate account.
- Secret keys, environment variables, and passwords being delivered in a secure environment.
- Dependency and license report, and the up-to-date version of the pre-existing component list.
- Design source files, plus font and image licenses.
- A record of which environments the developer accessed during the maintenance period and with what permissions.
You can also run a technical independence test: check whether a developer who has never seen the project can get the delivered code up and running in their own environment. If the setup can only be done with the former team's knowledge, the handover is incomplete.
When Does Code Escrow Make Sense?
A full assignment may not be possible or necessary in every project. For example, if the developer licenses a shared product core and your business depends on it, the company shutting down or discontinuing the service creates a serious business continuity risk. In that case, a source code escrow approach comes into play: the code is held by a neutral third party and released to you upon predefined trigger events (such as bankruptcy or a breach of maintenance obligations).
This structure makes the most sense for critical business processes, at enterprise scale, and for software worked with under a license model. For a small internal tool, a direct assignment is usually a simpler and cheaper solution.
Frequently Asked Questions
I paid for the software. Does the source code automatically become mine?
No, not automatically. Under FSEK, the assignment of economic rights requires a written contract and an explicit statement of the assigned rights. If the contract has no assignment clause, in most cases you only hold a right of use limited to the purpose of the contract.
Is delivery of the source code the same as assignment of rights?
No. Receiving the code does not give you the right to modify, reproduce, or sell it. Delivery is a factual matter, while assignment of rights is a legal transaction. Both need to be regulated separately in the contract.
Can the development company sell the software it built to other clients as well?
If the rights have been fully assigned to you and the contract says nothing to the contrary, it cannot; however, a shared core or pre-existing components may remain its property. This is why the non-compete, confidentiality, and component list clauses need to be made clear.
Who owns the source code in a SaaS or subscription model?
It generally stays with the company providing the software, and you only receive a usage license. If this model is critical for your business continuity, you should have safeguards added to the contract, such as the right to export your data, service level commitments, and, where needed, code escrow.
Does using open source libraries affect my ownership rights?
It depends on the license. Most permissive licenses do not affect ownership of your own code. Some copyleft licenses, however, can impose an obligation to share your code if you distribute it. Requesting a license report at delivery makes this risk visible.
Who should prepare the assignment agreement?
The healthiest approach is to prepare the technical scope with the software team and the legal text with a lawyer. The software team accurately describes the components to be delivered and the risks, and the lawyer turns that into a binding document.
Conclusion: Put Ownership in Writing From the Start
Intellectual property rights in custom software should be settled at the proposal stage, not after the project ends. When you write down from the start who will own the source code, which components will remain licensed, and what you will receive at handover, you protect both your budget and your freedom to grow the software later.
If you are planning a new software investment, let's clarify the intellectual property and handover criteria together in the first meeting. To discuss the scope of your project and the ownership model, you can get in touch with us through our contact page and request a quote.
