De quem é o código do projeto freelance: propriedade intelectual, cessão de direitos e o que colocar no contrato

Você entregou o projeto, o cliente pagou, todo mundo feliz. Seis meses depois você quer usar aquele módulo de autenticação em outro projeto, ou colocar prints do sistema no portfólio, e trava: pode? O código é seu? É do cliente? E aquela biblioteca interna que você carrega de projeto em projeto, você acabou de ceder ela junto?

A maioria dos devs freelancers no Brasil nunca parou para responder essas perguntas. Não por preguiça, mas porque ninguém pergunta sobre propriedade intelectual até o dia em que ela vira problema: cliente que ameaça processo porque você reusou código, cliente que some sem pagar a última parcela mas segue rodando o sistema, NDA que proíbe você de mostrar o melhor trabalho da sua carreira. Vou te falar como funciona do lado de quem recebe os leads: na OCA, a cláusula de propriedade intelectual é uma das primeiras coisas que cliente maduro pergunta. Se você não tem resposta pronta, parece amador. Se tem, fecha mais fácil.

O que a lei brasileira diz sobre o código que você escreve

Aqui vem a verdade desconfortável. Muita gente assume que "eu escrevi, então é meu, e o cliente só tem licença de uso". No Brasil, para software, é quase o contrário.

A Lei do Software (Lei 9.609/98) diz, no artigo 4º, que o software desenvolvido durante contrato de trabalho ou de prestação de serviços pertence ao contratante, salvo estipulação em contrário. Traduzindo: se o cliente te contratou para desenvolver aquele sistema e não existe contrato dizendo o oposto, a titularidade tende a ficar com ele, não com você.

Isso derruba dois mitos de uma vez:

• Mito 1: "sem contrato, o código é meu". Não necessariamente. Em desenvolvimento sob encomenda, o padrão legal favorece quem encomendou.
• Mito 2: "então não preciso de contrato, a lei já resolve". Precisa sim. Porque a lei resolve mal para os dois lados: o cliente fica sem garantia clara sobre bibliotecas de terceiros, e você fica sem proteção sobre seu código reutilizável e sem direito de portfólio.

O contrato não existe para brigar com a lei. Existe para preencher tudo o que ela deixa vago, e é aí que você se protege.

Cessão de direitos ou licença de uso: a decisão que muda o preço

Existem dois modelos principais, e você deveria saber precificar os dois.

Cessão total de direitos

O cliente vira dono do código-fonte. Pode alterar, revender, contratar outro dev para evoluir. É o que a maioria dos clientes espera quando paga por desenvolvimento sob medida, e é o modelo certo para sistemas que são o core do negócio dele.

Se é isso que você vai entregar, duas regras:

• A cessão só se completa com o pagamento integral. Escreva isso no contrato, com essas palavras. Enquanto houver parcela em aberto, o cliente tem licença de uso provisória, não a titularidade. Isso transforma a última parcela de "favor do cliente" em obrigação com consequência real.
• Cessão total custa mais que licença. Você está abrindo mão de reusar aquele trabalho. Precifique isso. A conta é simples: se o módulo levou 40 horas e você o reusaria em 3 projetos, ceder com exclusividade tem que valer mais do que ceder sem.

Licença de uso

Você continua dono, o cliente tem direito de usar. Faz sentido quando você entrega um produto seu configurado para o cliente, ou quando o projeto usa pesadamente uma base sua. Clientes corporativos maiores raramente aceitam esse modelo para software crítico, e com razão: ninguém quer o core da operação preso a um fornecedor. Se oferecer licença, seja transparente sobre o que acontece se você sumir do mapa. Isso não é teoria, boa parte dos projetos de resgate que chegam na OCA são sistemas cujo dono do código desapareceu.

As três camadas do seu código (e por que ceder tudo é burrice)

O erro clássico é assinar "cedo todos os direitos sobre o código desenvolvido" sem separar o que é o quê. Todo projeto tem três camadas, e cada uma merece tratamento diferente no contrato:

1. Código específico do cliente. Regras de negócio dele, telas dele, integrações dele. Esse você cede sem dó, é para isso que ele pagou.
2. Seu ferramental reutilizável. Boilerplate, hooks genéricos, estrutura de autenticação, componentes de UI que você carrega há anos. Isso é seu ativo. No contrato, entra como "ferramentas e componentes preexistentes do desenvolvedor, licenciados de forma não exclusiva para uso no projeto". O cliente usa à vontade dentro do sistema dele, mas você não perde o direito de usar em qualquer outro lugar.
3. Código de terceiros e open source. Você não pode ceder o que não é seu. React, Express, aquela lib de PDF: tudo isso já tem licença própria. O contrato deve dizer que componentes de terceiros seguem suas licenças originais.

Sem essa separação, você tecnicamente cedeu seu boilerplate com exclusividade para o primeiro cliente que assinou, e cada projeto seguinte usando aquele código vira um risco jurídico dormindo no seu repositório.

Open source no projeto do cliente: onde mora o risco real

Já que falamos de terceiros: nem toda licença open source é igual, e isso importa mais do que parece.

• MIT, Apache 2.0, BSD: permissivas. Pode usar em projeto comercial fechado sem drama. É o caso da maior parte do ecossistema JavaScript.
• GPL e derivadas: licenças de copyleft. Dependendo de como você integra, o código derivado pode ter que ser aberto também. Para um cliente que pagou por software proprietário, isso é uma bomba.

Você não precisa virar advogado. Precisa de um hábito: antes de adicionar dependência relevante, olhar a licença. E de uma cláusula: listar no contrato (ou num anexo de entrega) as principais dependências e suas licenças. Cliente técnico respeita, cliente leigo confia mais, e você fica coberto.

Portfólio e NDA: negocie antes de assinar, não depois de entregar

O direito de mostrar o trabalho é a parte da propriedade intelectual que mais afeta o seu pipeline futuro, e é a que os devs mais esquecem de negociar. Se você já entrega bem, o seu problema não é técnico, é distribuição, e portfólio é distribuição.

O que colocar no contrato:

• Cláusula de divulgação: você pode citar o cliente e o projeto no portfólio, com prints e descrição geral, sem expor dados sensíveis, métricas confidenciais ou código.
• Se o cliente exigir NDA total, tudo bem, é direito dele. Mas isso tem preço: você está abrindo mão de um ativo de marketing. Negocie um meio-termo (case anônimo, "fintech do setor X") ou embuta o custo.
• Nunca aceite NDA retroativo de graça. Cliente que aparece depois da entrega pedindo para você remover o case do portfólio está pedindo algo que não comprou.

Na OCA, todo case público que você vê em nosso portfólio passou por esse acordo antes do contrato. É literalmente assim que a máquina de leads funciona: projeto vira case, case vira prova, prova vira o próximo cliente chegando pelo Google ou por uma IA citando a gente. Sem o direito de mostrar, a roda não gira.

O checklist mínimo para o seu próximo contrato

Resumindo em algo que você pode aplicar hoje:

1. Definir o modelo: cessão total ou licença de uso, com preço coerente com a escolha.
2. Condicionar a cessão ao pagamento integral, por escrito.
3. Separar as três camadas: código do cliente, ferramental preexistente seu, dependências de terceiros.
4. Garantir cláusula de portfólio, ou cobrar pela ausência dela.
5. Anexar a lista de dependências relevantes e licenças na entrega.

Não precisa de contrato de 30 páginas. Precisa dessas cinco respostas escritas e assinadas antes da primeira linha de código.

Onde a OCA entra nessa conversa

Um contexto honesto: a OCA aparece no Google e nas respostas de IAs para buscas de desenvolvimento de software no Brasil, e isso traz mais leads qualificados por dia do que nosso time consegue atender. Nossa resposta foi montar uma rede de parceiros: devs seniores e times pequenos que recebem projetos já vendidos, com escopo fechado e, justamente, contrato com propriedade intelectual bem resolvida. O parceiro entra para construir, não para caçar cliente nem redigir cláusula.

O que a gente espera de um parceiro é o que este artigo inteiro descreve: alguém que entrega bem e trata o lado contratual com a mesma seriedade do código. Se esse é o seu perfil e o seu gargalo é pipeline, a conversa faz sentido.

Entre para a rede de parceiros da OCA

E independente de rede: esta semana, abra o contrato do seu projeto atual (ou o e-mail que está servindo de contrato) e procure a palavra "propriedade". Se ela não estiver lá, você acabou de encontrar sua tarefa de sexta-feira.