Most Software Disputes Come Down to One Missing Clause

When a software dispute file lands on a desk, the parties are usually arguing about one thing: does the software work or not.

The reason that argument can't be settled is not technical. The contract never defined what "works" means. With no acceptance criterion, the developer says it was delivered, the client says it wasn't received, and each is right by their own measure.

This single gap is the common thread running through most of the software disputes I've seen.

How to write an acceptance clause that actually works

Acceptance is the moment that triggers the legal consequences of delivery — including when the warranty period for defects starts running. An undefined acceptance date means an undefined end date for liability too.

A working acceptance clause covers: the list of acceptance tests, the environment they run in, who runs them, the objection period, and a provision that acceptance is deemed to have occurred if no objection is raised within that period.

The item most often left out is the test environment. Software that runs on the developer's machine may not run in the client's environment, and at that point responsibility becomes a matter for argument. Define the environment in the contract and the argument doesn't arise.

Tying acceptance to satisfaction is the worst option of all. Acceptance conditioned on "the client's satisfaction" creates an open-ended obligation, and the developer's job never actually ends.

Intellectual-property rights don't transfer on their own

The second common mistake is an assumption about ownership. Clients tend to think that paying for the work makes them the owner of the code. That's not the legal position.

Computer programs are protected as works under Law No. 5846, and unless otherwise agreed, the economic rights stay with the author. Any transfer needs to be set out expressly, made in writing, and list the transferred rights one by one. A general statement like "all rights are transferred" is open to dispute.

Beyond that, three categories need to be kept separate. Code written specifically for the client is usually transferred. The developer's pre-existing components are usually licensed rather than transferred, with the scope and duration of the licence written separately. Open-source components are subject to their own licences, and a list of what's used should be attached to the contract.

When these three aren't kept separate, this is what happens: the client believes it owns all the code, the developer keeps using its own library in another project, and the problem only surfaces once a dispute is already under way.

A contract with no change-management process doesn't survive contact with the project

However well the scope is written, change requests come in during the project. If the contract doesn't say how those requests are handled, every request turns into a negotiation.

A working provision answers five questions. Who does a request go to, and in what form? Who assesses the impact, and within how many days? How are price and schedule impact calculated? Whose sign-off approves it? What happens to a request that isn't approved?

Answer those five and a change stops being a crisis and becomes a process.

Becoming a data processor can happen without anyone noticing

Where a developer has access to a client's personal data, they become a data processor within the meaning of Law No. 6698. That status is often acquired without either party realising it.

The most common route is using real data in a test environment. A copy of the production database gets pulled into staging, developers work with it, and from that point a data-processing relationship exists. If the contract says nothing about it, the relationship runs with no legal basis.

The cleanest fix is never to create that situation at all. Testing with masked or synthetic data is not technically difficult and largely removes the risk. Where access to real data is genuinely necessary, the subject matter, duration and purpose of the processing, the developer's obligation to act only on instruction, use of sub-processors, security measures, and return or deletion of the data at the end of the contract all need to be set out in writing.

Maintenance is a separate contract

Finally, maintenance and support. This is a separate undertaking from development and should be treated separately.

What needs to be written down is not response time but fault classification. Without a definition of which fault falls into which class, every issue gets raised as top priority. Once classes are defined, response and resolution times can be set separately for each.

There's also a measurement question. A service-level commitment that can't be measured has no teeth when it's breached. The contract needs to say how measurement happens and whose records it's based on.

Who should draft this

Every one of these clauses needs law and engineering to decide together. A lawyer can't write acceptance criteria alone, because they don't know what's actually testable. An engineer can't write the IP transfer alone either.

A party that goes into contract negotiation without a technical team ends up agreeing to terms that turn out to be unworkable. An unworkable term behaves, once a dispute arises, as if it had never been written at all.