Brazil Software Services: Separate Background Tools from Client Deliverables

For a Brazilian software-services engagement, do not rely on a sentence saying “the client owns the software” or “the contractor keeps all tools.” First list what already exists, what the project will create, what the customer must be able to use, and which rights are being licensed or transferred. Brazil’s Software Law, Lei 9.609/1998, has a specific default rule in art. 4 for certain software created during an employment, service, internship or apprenticeship relationship, “unless otherwise stipulated.” Its operation depends on the statutory conditions and relationship. The contract should make the parties’ intended allocation explicit and consistent with how the work is performed.

This is especially important when one statement of work combines consulting, reports, automation scripts, reusable libraries and custom software. A client may need a durable right to operate, maintain and modify a deliverable without acquiring every pre-existing tool used to build it. Conversely, a provider who reserves a component must still give the customer sufficient rights to use the delivered product and must have authority to license every included dependency.

Start with a four-part inventory

Before drafting an ownership clause, separate the project materials into categories. A spreadsheet or schedule is often clearer than a dense paragraph.

Give each item a name, version or repository reference, creator, creation date, source, and contract treatment. “All know-how” and “all code” are both too broad to operate reliably. The schedule should let a future maintainer see what is proprietary, what is third-party, and what may be reused.

Read the statute before applying a default

Article 4 of Lei 9.609/1998 says that, unless otherwise stipulated, rights in computer programs belong exclusively to the employer, service contractor or public entity when the program was developed during the term of a relationship expressly intended for research and development, where the worker’s activity includes that work, or where development follows from the nature of the relationship’s duties. Paragraph 1 says, absent contrary agreement, compensation for the work or service is limited to the agreed remuneration. Paragraph 2 addresses software made without a relationship to the contract and without using the enumerated employer/client resources, information, secrets, materials, premises or equipment.

Those are statutory words, not a shortcut for deciding every ownership dispute. A repository on a contractor’s personal laptop is not by itself proof that the project code is outside the contract. Similarly, customer payment does not automatically answer whether a party received a licence or an assignment of every right. The contract, scope, actual creation history, resources used, role, and law must be considered together.

The Copyright Law, Lei 9.610/1998, also matters for material that is not a computer program, including written documentation and some creative elements. Software is subject to its specific regime under Lei 9.609 as well as the referenced copyright framework. Avoid importing foreign “work made for hire” language as if it were Brazilian law. If the customer expects a transfer, define the works and rights, document the transfer in writing, and verify statutory formalities and any third-party limits with Brazilian IP counsel.

Write the licence or transfer so operators can use it

For each deliverable, the contract should answer practical questions:

• Is the client receiving a licence or an assignment of specified rights?
• Is the permission exclusive or non-exclusive, limited by territory, duration, purpose, users or affiliates?
• Can the client operate, copy, adapt, maintain, host, integrate and permit a replacement vendor to support the software?
• Can the client sublicense to customers, group entities or service providers?
• What payment, acceptance or other condition triggers the grant?
• Is source code included? Which repository, branches, build instructions, configuration and documentation form the handover?
• What happens to background components embedded in the client software?
• Are third-party or open-source notices, source code or licence obligations passed through?
• Are there restrictions on use with competitors, and are those restrictions specific enough to be workable?

A licence that is technically narrow can make a system impossible to maintain. A broad “all rights” assignment may be commercially acceptable, but the parties should knowingly price and define it. If the source code is essential for continuity, say whether source is delivered, how credentials and secrets are handled, whether the provider may retain an archival copy, and what deletion evidence is expected. Do not promise the client perpetual operational rights over a component that the provider does not own or cannot sublicense.

Align the documents and the development process

The master services agreement, statement of work, proposal, order form, repository rules, acceptance criteria, invoice conditions and security appendix should use compatible defined terms. If the proposal promises “use rights” but the master says “exclusive ownership,” ask which document controls and how conflicts are resolved. Keep change orders when a project changes from advisory work to bespoke software development.

Use a pre-project baseline for background assets. For each existing tool, capture a non-confidential identifier and description, version, author or ownership source, date, repository, and proposed use. The schedule need not expose a valuable algorithm or secret in a public-facing contract. It should identify the item clearly enough for the parties to know what is reserved. A private technical annex can hold detail under confidentiality terms.

During development, keep a project-specific repository or branch, issue trail, release tag, dependency lockfile, and delivery record. These records do not decide ownership, but they help show what was delivered, when, and from which sources. Preserve the approved contract and amendments with each release. Avoid silently copying client code into a generic library or taking confidential customer data into another project.

For related review mechanics, use the contract consistency workflow, document naming and version control guide, and template change-control workflow. The Brazil PJ and CLT classification guide addresses how the working relationship can affect the review.

Hypothetical: reports, automation and a commissioned application

Suppose a Brazilian consultancy is engaged to improve a client’s monthly reporting. It already has a generic data-cleaning library used across projects. The new scope includes consulting, reports and a dashboard that the client will operate. The client asks for “all intellectual property in any tool used,” while the consultant expects to retain its generic library.

The parties can first list the generic library as background material, identify the new dashboard and project-specific connectors as deliverables, and map any third-party libraries. They then negotiate what the client needs: perhaps rights to operate and maintain the delivered dashboard, including a licence to embedded background code, with a source handover for the project-specific component. If the client instead requires an exclusive transfer of a new program, scope and compensation can be expressly negotiated. Counsel should check that the chosen language is consistent with art. 4, the facts and the precise work category. The inventory is a drafting aid, not a guarantee about ownership.

Decision table: how should an item be treated?

Mistakes that create avoidable disputes

1. Leaving the IP schedule until handover. By then, the code may combine background material, client data, contractors’ contributions and third-party packages.
2. Calling every reusable asset “know-how.” Source code, secrets, general skills and client-specific confidential information need different treatment.
3. Assuming a personal device settles the issue. Article 4 looks to the relationship, duties and resources; equipment location alone should not be treated as dispositive.
4. Promising a complete assignment while using code under a third-party licence. The provider cannot transfer rights it does not control.
5. Forgetting operational rights. If the client cannot maintain or adapt a product, a narrow licence may undermine the purpose of paying for it.
6. Using the wrong jurisdiction’s doctrine. Terms like “work for hire” may import assumptions that do not match Brazilian law.

Before development checklist

• Identify the contracting parties and whether the engagement is employment, service, internship or another arrangement.
• Define consulting outputs, reports, scripts, software, documentation and support separately.
• Inventory background IP and the source/version of each component.
• Mark third-party and open-source components and their licence conditions.
• Decide whether each new item is licensed, assigned or treated another way.
• Define client operational, modification, maintenance and sublicense rights.
• Specify source, documentation, build and credentials handover scope.
• State payment, acceptance, termination and transition effects on rights.
• Align the master agreement, SOW, proposal and repository process.
• Obtain Brazil-qualified IP advice for high-value software, exclusivity or cross-border transfers.

Frequently asked questions

Does the customer automatically own every script built during a Brazilian service contract?

Not necessarily. Lei 9.609/1998 art. 4 provides a default for specified programs developed during covered relationships and duties, subject to contrary agreement. The facts, contract and statutory conditions matter. Identify background code, project work and external dependencies before asserting ownership.

If I use my own laptop, do I keep the code?

The laptop is one fact, not a complete test. Article 4 refers to the relationship, the work’s purpose and duties, and resources and information. A lawyer should review who commissioned the program, how it relates to the services, what the contract says and whether client resources or confidential information were used.

Is a software licence the same as an IP assignment?

No. A licence grants defined permissions while ownership remains elsewhere; an assignment transfers specified rights. Both can be broad or narrow. Name the rights, territory, duration, exclusivity, adaptation, maintenance, sublicensing and payment conditions.

Can a client receive a right to use my background tools inside the deliverable?

The parties can negotiate a licence if the provider has the right to grant it. The licence must be sufficient for the agreed operations, maintenance and permitted changes, while protecting unrelated reusable material and third-party obligations.

Does paying for the work prove the client owns the source code?

Payment proves an economic transaction but does not alone answer the scope of rights. Read the agreement and applicable law, and distinguish access to source code from ownership, license rights, and delivery obligations.

What if a proposal and signed master agreement conflict?

Check order-of-precedence, incorporation, amendment and signature clauses. Do not assume that the newest email silently overrides a signed agreement. Resolve the conflict in a signed amendment or a clearly incorporated SOW before development proceeds.

Should I list every line of code as background IP?

Usually the goal is a usable inventory, not an unmanageable code dump. Identify components and versions clearly enough to distinguish them, protect confidential details in an appropriate annex, and preserve repository evidence.

Can a client ask for source code but not ownership?

Yes, source delivery and ownership are separate contract questions. Define who can access and modify the source, whether a replacement vendor may work on it, what restrictions apply, and whether third-party licence conditions permit the proposed handover.

What should be done when the engagement’s scope changes?

Use a written change order. Reassess ownership, licence, data, security, schedule and price when an advisory project becomes software development or when a deliverable begins incorporating a reusable tool.

For a review workflow, explore Gotham’s legal workflows or contact the team. The workflow can organize contract and evidence materials; it does not decide ownership or replace Brazilian counsel.

General information, not legal advice. Brazilian software ownership and licensing depend on statutory rules, contract wording, facts and third-party rights.
How Gotham researches and reviews field guides