The software development contract in Peru (and who ends up owning the code)

There is a widespread belief among people who commission software in Peru: that paying for the work makes you the owner of the code. It does not, and the surprise usually lands at the worst moment — when you want to change provider, when you ask for the repository, or when the system needs modifying and you find you have no right to touch it.

Paying for the service is not buying the work

In Peru, Legislative Decree 822 —the Copyright Law— protects a computer program as a work, in both its source and object versions, provided it is original. And it protects the work in favour of its author.

That means the service contract and the ownership of the work are two different things. You pay for a development service and you receive that service. The economic rights over what was built remain the author's until they are assigned, and the assignment happens through an express act, not through the fact of having paid the invoice.

This is not a lawyer's technicality: it decides whether in three years you can take your system to another team, or whether you have to negotiate that with whoever wrote it.

What can be assigned and what cannot

Peruvian copyright separates two blocks. Economic rights —reproducing, modifying, distributing, exploiting the work— are the ones that transfer and the ones you need.

Moral rights —recognition of authorship, among others— are inalienable. Nobody can assign them even by signing, and a contract that claims to is promising something the law does not allow. Your provider keeping authorship takes nothing from you operationally: you can still use, change and exploit the system.

The real warning sign is the opposite: a contract that says nothing about economic rights. Silence does not work in your favour — it works in the author's, which is what the statute protects by default.

What to assign beyond the source code

A clause that assigns “the software” and nothing else leaves you with a repository you may not even be able to deploy. This is what it actually takes to run and change the system.

The assignment should also state its scope: whether it is exclusive or not, for which territory, for how long and for which forms of exploitation. “Assigns the rights” on its own leaves far too much open.

The clauses that decide the project, not just ownership

If you are a public entity

That case has an extra layer. State entities usually require the assignment in broad terms —non-exclusive, unlimited, perpetual, worldwide exploitation, including reproduction, public communication, distribution and modification— and that has to be in the tender documents before signing, not negotiated afterwards.

If you are preparing the procurement, the piece that comes first is the requirements document. We work through it in how to write a TDR for custom software, which is where you define what you are contracting before discussing on what terms.

The mistakes we see

The most common is the downloaded template used as is. Many of the ones circulating are written for Argentina, Colombia or Spain, and plenty of others live on student-notes sites with no guarantee whatsoever. They are useful for understanding the structure; not for signing.

The second is leaving the assignment for the end, once the project is delivered and your negotiating position is the opposite one. The third is confusing access with ownership: being handed the repository does not mean you have the right to exploit it.

This does not replace a lawyer

We are engineers, not lawyers, and this article explains how the ground works so you know what to ask — it is not legal advice. To draft or review an actual contract, have a Peruvian lawyer specialising in intellectual property look at it.

What we can tell you from the technical side is what should be handed over for the system to genuinely be yours and operable. On our projects the code is 100 % the client's, and that sentence only means something if the contract spells it out.