The short answer
In most cases, when developing the system is the very purpose of the contract, Brazil's software law tends to give the rights to the party that hired the work. This rule applies unless otherwise agreed, so the contract is what really decides, and it needs to say so in writing.
Having the right on paper is not enough either. In practice, the software is only yours when you have the code in a repository under your control, the documentation another team needs to understand the system and access to the infrastructure where it runs. This text is a practical guide, not a legal opinion: have the contract reviewed by a lawyer you trust.
What Law 9,609/1998 says about software ownership
Law 9,609/1998, known as Brazil's software law, treats a computer program as a work protected under copyright. Protection exists regardless of registration. Registration with INPI, the Brazilian patent and trademark office, is optional and serves as proof of authorship and date, not as a condition for holding the right.
For the case that matters here, the law sets a starting rule: unless otherwise agreed, the rights to a program developed under a service contract whose purpose is precisely that development belong to the party that hired it. The same logic applies to an employer regarding an employee hired to develop software.
The point that causes the most disputes is the phrase "unless otherwise agreed". The contract can provide otherwise, and many do, sometimes in a generic clause nobody read carefully. There are also gray areas the general rule does not settle on its own: tools and components the vendor already had before the project, third-party libraries and the vendor's own products adapted for you.
Assignment or license: the practical difference
Almost every software contract falls into one of two models, or a combination of them. With an assignment, the economic rights to the code pass to you. With a license, the vendor remains the owner and authorizes use under the conditions the contract sets.
| Point | Assignment of rights | License to use |
|---|---|---|
| Who keeps the code | You, as holder of the economic rights | The vendor, who authorizes use |
| Access to the source code | Delivered to you, with the version history | Depends on the contract; often not delivered |
| Switching vendors | Another team can take over the system | Requires negotiating with the vendor or starting over |
| When it usually makes sense | A system built for your operation that you want to evolve freely | A product the vendor sells to many clients |
| What to check in the contract | Scope of the assignment and what is excluded, such as pre-existing components | Term, users, updates, support and what happens if the contract ends |
Neither is wrong in itself. Licensing a ready-made product can be the best choice when the process is standard, as we discuss in off-the-shelf or custom software. The problem appears when you pay for a system built for your operation and find out, at the end, that you only got the right to use it.
A common and reasonable arrangement is a combination: you receive the assignment of what was built for your project and a permanent, free license to use the components the vendor already had and reuses with other clients. What matters is that this is in writing, with a list of what falls into each category.
What the development contract needs to say
Before signing, check that the contract answers these questions with no room for interpretation:
- Who holds the code. The clause needs to state whether the economic rights are assigned, from when the assignment applies (at delivery, with each payment or at the end) and whether it also covers documentation, design and the database.
- What is excluded. Components the vendor already had, third-party libraries and the vendor's own products should be listed, with the license you receive for each one.
- When and how the code is delivered. Ideally the code lives in your repository from the start, rather than being handed over all at once at the end.
- What happens when the contract ends. A transition period, help handing the system over to another team, return of access and export of the data in an open format.
- Confidentiality and data. Who can access the operation's data, for what purpose and how this fits with Brazil's data protection law (LGPD).
These points apply to any vendor. If you are still choosing who will build the system, they belong on the list of questions in the guide on how to hire a software house.
What to ask for when the system is handed over
Ownership you cannot exercise protects no one. If the vendor disappeared tomorrow, the question is simple: could another team get the system running, understand the code and carry on the work? For that, the handover needs to include:
- Code repository. In an account owned by your company, with the full version history, not a zip file sent by email.
- Technical documentation. How the system is organized, how to install it, how to release a new version and which integrations it uses.
- Decision log. Why each important choice was made, which risks were accepted and what was left for later.
- Administrative access. Hosting, database, domain, transactional email and third-party services in your accounts, or with you as administrator.
- Infrastructure description. Which environments exist, how they are configured and where the backups are kept.
- Credentials and keys. Stored in a password vault under your control, with a list of what each one does.
In our way of working, decisions, acceptance criteria, versions and risks are documented throughout the project, not only at the end. That is what keeps knowledge of the system from depending on anyone's memory, including ours.
Third-party libraries and open source
No modern system is written from scratch. Frameworks, libraries and open source components are part of almost every project, and that is good: they are pieces tested by many people. But they do not become yours. Each one has its own license, and you receive the right to use it under the terms of that license.
Most of the widely used licenses, such as MIT, BSD and Apache, are permissive: they allow use and modification even in closed software, basically asking that the license notice be kept. Others, such as the GPL family, impose conditions on distributing software that incorporates them. For a system that runs only inside your operation, this usually has little impact, but it is worth knowing which ones are in the project.
A reasonable request to the vendor is a list of the main dependencies with their licenses, and a commitment not to include components whose license conflicts with how you intend to use the system.
How to avoid being held hostage by your vendor
Being held hostage rarely happens out of bad faith. It happens by accumulation: the code sits in the vendor's account, the hosting is on their credit card, only one person knows how to release a new version and none of it is written down. When the relationship ends, or when that person leaves, the system becomes a black box.
A few simple practices prevent this from day one. Open the repository and the infrastructure accounts in your company's name and give the vendor access, not the other way around. Ask to see the documentation at every delivery, not only at the end. Prefer mainstream technologies, with a community and available professionals, over proprietary solutions only the vendor knows.
If you are already in this situation, with an old system nobody understands anymore, the path usually starts with a technical assessment before any decision. We cover this in the guide on how to modernize a legacy system, and it is the same care we take when we take over maintenance of a system built by another team in our custom software development work.