De quem é o código do seu sistema sob medida?

De quem é o código que um studio escreveu para a sua empresa? Pela Lei 9.609, salvo estipulação em contrário, os direitos sobre o programa desenvolvido sob contrato pertencem ao contratante. Mas a Lei 9.610 traz exigências de forma para a cessão de direitos, e o contrato diz como elas se aplicam. Na prática, a resposta está no que foi assinado.
A empresa que paga pelo sistema é dona do código?
A lei aponta para o contratante, mas a regra tem condições e o contrato pode afastá-la.
O artigo 4º da Lei 9.609/1998 atribui ao contratante de serviços os direitos sobre o programa de computador "desenvolvido e elaborado durante a vigência de contrato". A condição é que o contrato seja destinado à pesquisa e desenvolvimento, ou que a atividade do contratado esteja prevista nele ou decorra da natureza dos encargos. Num contrato para construir um sistema interno, desenvolver o programa é a própria atividade prevista, o que aponta para essa hipótese, mas o enquadramento depende do texto assinado.
Em 2019, a procuradoria do INPI analisou programas que o instituto encomendou a uma empresa terceirizada. Concluiu que a titularidade pertence ao contratante e que a empresa contratada não tem direitos sobre o programa, porque apenas prestou o serviço. O parecer considera incomum que o contrato disponha diferente. Ele é uma manifestação administrativa, não uma decisão judicial, e não vincula contratos entre particulares. O caso era de um órgão público, mas o texto do artigo 4º fala do contratante de serviços em geral.
Isso não encerra a conversa. A regra começa com "salvo estipulação em contrário", e é nessa estipulação que muitos contratos de studio e de freelancer diferem do que o cliente imagina.
O que a Lei 9.610 muda nessa conta?
Ela acrescenta exigências de forma para qualquer transferência de direitos. O artigo 2º da Lei 9.609 diz que o software tem o regime de proteção das obras literárias, nos termos da legislação de direitos autorais. Por isso o artigo 49 da Lei 9.610/1998 entra na análise de um contrato de desenvolvimento.
Esse artigo traz limites que valem para cessões e licenças:
- a transmissão total e definitiva só se admite por estipulação contratual escrita;
- sem estipulação contratual escrita, o prazo máximo é de cinco anos;
- a cessão vale só para o país onde o contrato foi firmado, salvo estipulação em contrário;
- ela cobre só as modalidades de utilização já existentes na data do contrato;
- quando o contrato não especifica a modalidade de uso, ele é interpretado de forma restritiva.
O artigo 4º é uma regra de titularidade. O artigo 49 trata de como os direitos se transferem. Como as duas leis convivem num contrato específico, quando ele é omisso, é questão para advogado de propriedade intelectual e, no limite, para um juiz. O que cabe ao empresário é não deixar o ponto em branco. Este texto não é aconselhamento jurídico.
A lei obriga o studio a entregar o código-fonte?
No texto da lei, a entrega do código-fonte aparece como obrigação em um caso específico. O artigo 11 da Lei 9.609 prevê que o INPI registre os contratos de transferência de tecnologia de programa de computador, para que produzam efeitos perante terceiros. Para esse registro, o fornecedor deve entregar ao receptor a documentação completa, em especial o código-fonte comentado, o memorial descritivo, as especificações funcionais internas, diagramas e fluxogramas.
Para o contrato comum de desenvolvimento, o que garante o código no seu repositório é o que está escrito no contrato. Ser titular dos direitos e ter o código em mãos são duas coisas. Uma empresa pode ser dona de um programa que só roda na infraestrutura de quem o escreveu, e aí a titularidade não ajuda a trocar de fornecedor. O artigo sobre a dependência de uma pessoa só descreve as outras camadas dessa mesma exposição: contas, ambiente e decisões.
Um exemplo hipotético
Imagine uma distribuidora de materiais elétricos com faturamento de R$ 500 mil por mês. Há dois anos, contratou um studio para construir o sistema de pedidos. O contrato tem duas páginas: objeto, valor, prazo e forma de pagamento. Não diz nada sobre titularidade do código nem sobre entrega do repositório.
Hoje a empresa quer migrar a manutenção para outro fornecedor. O novo fornecedor pede o código. O studio original responde que entrega o sistema rodando, mas que o código é licenciado. A distribuidora tem um argumento no artigo 4º, porque o programa foi desenvolvido sob contrato de serviços. Só que o argumento precisa ser sustentado, com proposta, e-mails e aditivos, enquanto a migração fica parada.
O cenário é inventado, e nenhum número dele é medição. O ponto é o custo de descobrir o que o contrato não diz depois que a relação esfriou.
A dúvida sobre o código raramente é jurídica na origem. Você não tem um problema de tecnologia. Você tem um problema de arquitetura: ninguém decidiu, por escrito, quem é dono de quê, onde o código mora e quem consegue operá-lo. O contrato é a parte jurídica dessa decisão. A Yowpi assume sistemas herdados, como no caso da Colo Saúde, que chegou sem dono técnico, com uma plataforma construída por um fornecedor anterior.
O que o contrato de desenvolvimento precisa dizer?
Cinco pontos merecem resposta por escrito. Para cada um, a pergunta é se ela existe no seu contrato.
- Titularidade e forma da cessão. O contrato diz se a transmissão é total e definitiva ou se é licença, para qual país e para quais usos? Se a empresa pode querer usar o sistema fora do Brasil ou licenciá-lo a parceiros, o contrato precisa dizer isso, porque, sem essa previsão, a cessão vale só para o país do contrato e o uso é lido de forma restritiva.
- Momento em que o direito passa. A cessão vale na entrega de cada etapa, no pagamento final ou no encerramento do contrato? Se a cessão só vale depois do último pagamento, a titularidade pode ficar com o studio até lá.
- Entrega do código e da documentação. O contrato diz que o código fica num repositório da empresa, com histórico, e que a documentação técnica acompanha cada entrega?
- Componentes anteriores ao contrato. A regra do artigo 4º fala do programa desenvolvido durante o contrato. O que o studio já tinha antes, e as bibliotecas de código aberto que entram no sistema, seguem suas próprias licenças. O contrato deveria listar o que está nessa categoria.
- Reaproveitamento pelo studio. Usar a experiência e o método em outros clientes é normal. Reaproveitar o código do seu sistema depende do que ficou escrito. Essa cláusula precisa existir para os dois lados saberem a fronteira.
O registro no INPI resolve o problema?
Não resolve, mas ajuda a provar. A cartilha do INPI e da ABES sobre registro de software diz que a proteção existe mesmo sem registro e que o registro serve para comprovar autoria, titularidade e data de criação. Ele não cria o direito autoral.
Na prática, registrar o programa depois de pronto pode servir como prova de autoria, titularidade e data de criação numa disputa. Ele combina com um contrato claro e não o substitui. A própria cartilha informa que é material informativo e que não substitui a legislação nem a orientação jurídica.
Perguntas frequentes
Não tenho ninguém técnico nem jurídico na equipe. Como confiro um contrato desses?
Leia o contrato com as cinco perguntas da lista acima e marque as que ficaram sem resposta escrita. Leve só essas lacunas a um advogado de propriedade intelectual. A consulta fica mais objetiva, e você chega sabendo o que precisa perguntar.
Cessão total e definitiva deixa o projeto mais caro?
Costuma mudar a negociação, porque o studio abre mão de reaproveitar o código. A lei não fixa preço para isso, então o efeito aparece na proposta. Peça as duas versões, cessão e licença, e compare o que cada uma permite depois que o projeto terminar.
Já tenho um sistema pronto e o contrato não diz nada. O que faço?
Reúna primeiro o que existe: proposta, aditivos e e-mails que definiram o escopo. Depois peça ao fornecedor, enquanto a relação está boa, um aditivo que registre a titularidade e a entrega do código. Com o fornecedor disponível, tende a ser uma conversa. Depois de um rompimento, tende a virar disputa.
O próximo passo
Se você está avaliando um studio, ou herdou um sistema cujo contrato não diz de quem é o código, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para mapear o que existe, onde o código mora e quem consegue operá-lo. A leitura jurídica do contrato continua sendo de um advogado de propriedade intelectual.
Cases relacionados

Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico