Se você desenvolve software como pessoa jurídica e entrega o resultado para um cliente, a pergunta prática é direta: de quem é o código-fonte depois da entrega? A resposta padrão surpreende parte dos desenvolvedores. Na ausência de cláusula em sentido contrário, o software criado sob contrato de encomenda pertence a quem contratou o serviço, não a quem escreveu o código.
A propriedade intelectual software no Brasil é tratada pela Lei do Software (Lei 9.609/98) e, de forma complementar, pelas regras de direito autoral. O programa de computador é protegido como obra intelectual, e essa proteção nasce com a criação, independentemente de registro. Mas proteção não é o mesmo que titularidade. Uma coisa é o código estar protegido contra cópia. Outra é definir quem tem o direito de explorá-lo, vendê-lo, modificá-lo e licenciá-lo.
Para o desenvolvedor PJ, a diferença tem impacto direto no faturamento e na possibilidade de reaproveitar o próprio trabalho. Este guia explica as regras de titularidade, o que muda conforme o tipo de contrato e como reservar seus direitos antes de entregar a primeira linha de código.
A regra padrão da encomenda: o código é de quem contratou
O art. 4º da Lei do Software estabelece que, quando o programa é desenvolvido por prestador contratado especificamente para essa finalidade, os direitos pertencem ao contratante, salvo estipulação em contrário. Essa é a regra da encomenda, e é a situação típica de quem trabalha como PJ prestando serviço de desenvolvimento.
Na prática, se você fecha um contrato para construir um sistema de gestão para uma empresa e não há cláusula tratando de titularidade, a empresa se torna titular do software entregue. Você recebe pelo serviço, mas não retém direitos de exploração sobre o resultado.
Isso vale tanto para o produto final quanto para o que foi produzido no processo. Sem ressalva expressa, presume-se que o contratante adquire o conjunto do que resultou do trabalho contratado. A frase “salvo estipulação em contrário” é a chave: ela abre espaço para o contrato dizer algo diferente, e é aí que o desenvolvedor precisa agir antes, não depois.
O que muda quando há contrato bem redigido
O contrato é o instrumento que redistribui direitos. Ele pode manter a titularidade com o contratante, transferir parte ao desenvolvedor ou criar um modelo de licenciamento em vez de cessão. Tudo isso é lícito, desde que esteja escrito com clareza.
Alguns cenários frequentes:
Cessão total. O contrato transfere ao cliente a titularidade integral do software. É o modelo mais comum em projetos sob encomenda. O desenvolvedor entrega o código e não retém direitos sobre o produto.
Licença de uso. Em vez de transferir a titularidade, o desenvolvedor mantém a propriedade e concede ao cliente uma licença de uso. Esse modelo é típico de quem desenvolve um produto próprio e o disponibiliza a vários clientes. O software continua sendo seu, e cada cliente usa dentro dos limites da licença.
Modelo híbrido. O software específico do cliente é cedido, mas os componentes preexistentes (bibliotecas, frameworks internos, módulos genéricos) permanecem com o desenvolvedor, licenciados para uso naquele projeto. Esse modelo protege o direito de reaproveitar o que você já construiu.
A escolha do modelo depende do seu tipo de atuação. Quem presta serviço personalizado costuma ceder. Quem tem produto próprio costuma licenciar. O erro é não escolher: sem cláusula, a lei escolhe por você, em favor do contratante.
Componentes preexistentes e código reaproveitado
Poucos desenvolvedores escrevem cada projeto do zero. Você reutiliza bibliotecas próprias, padrões de arquitetura, componentes já testados. Esse acervo é valor acumulado, e ele merece tratamento contratual próprio.
Sem cláusula que distinga o preexistente do específico, há risco de o contrato de cessão total arrastar junto tudo o que foi entregue, inclusive componentes que você usa em outros clientes. Se depois você reutiliza aquele mesmo componente em outro projeto, o primeiro cliente pode alegar que aquilo lhe pertence.
A solução é definir no contrato duas camadas. A primeira é o software encomendado, criado especificamente para aquele cliente, que pode ser cedido. A segunda são os componentes preexistentes ou genéricos, que continuam seus e são apenas licenciados para uso naquele projeto. Essa separação precisa constar por escrito e, idealmente, com descrição do que se enquadra em cada categoria.
Vale a mesma lógica para código aberto de terceiros. Se você incorpora bibliotecas com licenças específicas, o contrato deve deixar claro que aquelas partes seguem as licenças originais e não são de titularidade sua nem do cliente. Ignorar isso cria risco jurídico para ambos os lados.
Registro no INPI: quando faz sentido
O registro do programa de computador no INPI é opcional. A proteção existe sem ele. O registro serve como prova: documenta autoria, data de criação e o conteúdo depositado.
Para software com valor comercial relevante, ou quando há histórico de conflito sobre quem criou o quê, o registro reduz o custo de provar autoria no futuro. Em uma disputa, quem tem registro parte de posição mais confortável para demonstrar que criou aquele código naquela data.
O depósito no INPI permite proteger o código sem torná-lo público, o que preserva o segredo do que foi desenvolvido. Isso interessa a quem tem produto próprio e não quer expor a lógica interna.
Se o registro não for feito, é possível provar autoria por outros meios: repositórios de código datados, histórico de commits, e-mails, contratos e documentação do projeto. São provas válidas, mas exigem mais esforço de demonstração. O registro apenas antecipa e simplifica essa prova.
O que diz a lei
A base normativa da proteção de software no Brasil está na Lei 9.609/98, conhecida como Lei do Software. O art. 1º define o programa de computador, o art. 2º estabelece que sua proteção segue o regime das obras literárias e o art. 3º deixa o registro a critério do titular.
O art. 4º prevê que, quando o programa é desenvolvido por empregado, prestador de serviço ou contratado especificamente para essa finalidade, os direitos pertencem, em regra, ao empregador ou contratante, salvo disposição em contrário no contrato. O § 2º do mesmo artigo faz a ressalva inversa: pertence com exclusividade ao contratado o programa gerado sem relação com o contrato e sem uso de recursos, informações ou equipamentos do contratante. Essa é a regra que afeta diretamente o desenvolvedor PJ.
A proteção do software também se apoia na Lei de Direitos Autorais (Lei 9.610/98) no que for compatível, já que o programa é tratado como obra intelectual. Disso decorre que a proteção nasce com a criação, sem necessidade de registro, e que o registro no INPI tem função probatória, não constitutiva.
Na prática dos tribunais, o que está escrito no contrato é o primeiro critério para definir titularidade. Quando o contrato é claro, ele é aplicado. Quando o contrato é omisso, aplica-se a regra legal, que favorece o contratante nas relações de encomenda. Por isso a redação contratual é decisiva: ela desloca ou confirma a presunção legal.
As informações sobre o registro de programa de computador estão na página do INPI. Se você está do outro lado da mesa, contratando um desenvolvedor, o post sobre quem é o dono do software feito por terceirizado trata da mesma regra sob a ótica do contratante.
Quando vale procurar advogado
Boa parte da proteção acontece antes do problema, no momento de redigir o contrato. Um modelo de contrato de desenvolvimento genérico, baixado da internet, dificilmente cobre a distinção entre componentes preexistentes e específicos, o modelo de titularidade adequado ao seu negócio e as ressalvas de reaproveitamento. Revisar ou construir esse contrato com apoio técnico evita a maioria das disputas.
Procurar advogado faz sentido nas seguintes situações:
Quando você vai fechar contrato de desenvolvimento e quer definir com precisão o que cede e o que retém. Esse é o momento de maior alavancagem, porque tudo ainda pode ser negociado.
Quando um cliente alega titularidade sobre código que você considera seu, ou impede que você reutilize componentes próprios. Aqui a análise do contrato e do histórico do desenvolvimento define quem tem razão.
Quando você identifica que seu software foi copiado, redistribuído ou usado além dos limites licenciados. A Lei do Software prevê medidas contra a violação, e a expectativa razoável depende de você conseguir demonstrar autoria e os termos do uso autorizado.
Quando você quer estruturar um produto próprio para licenciar a vários clientes e precisa de um modelo de licença que preserve sua titularidade e defina o que cada cliente pode fazer.
Situações mais simples, como registrar um software no INPI ou organizar repositórios datados como prova de autoria, você consegue conduzir sozinho. O valor do apoio técnico aparece quando há contrato relevante em jogo ou quando o conflito já começou. A atuação para profissionais de TI e em propriedade intelectual cobre os dois momentos.
Conclusão
A pergunta “de quem é o código?” não tem resposta única. Tem a resposta que o seu contrato der. Na ausência de cláusula, a Lei do Software entrega a titularidade a quem encomendou o desenvolvimento, e o esforço do desenvolvedor PJ se converte apenas em pagamento pelo serviço, sem direitos sobre o resultado.
Definir titularidade, separar componentes preexistentes do que é específico e escolher entre cessão e licença são decisões que precisam estar por escrito antes da entrega. Depois que o código sai da sua máquina, a margem de negociação encolhe. Quanto mais cedo o contrato tratar desses pontos, menor o risco de perder direito sobre o que você mesmo construiu.