Cessão de Direitos Autorais sobre Código-Fonte: Como Proteger sua Empresa em Contratos com Desenvolvedores

Existe uma armadilha silenciosa que afeta milhares de empresas brasileiras de tecnologia, e que costuma só ser descoberta no pior momento possível: durante uma rodada de investimento, em uma negociação de venda da empresa ou em uma disputa com um ex-colaborador. A armadilha é simples de explicar e cara de resolver. Sua empresa pode estar usando comercialmente um software cujo código, juridicamente, não pertence a ela.

Isso acontece porque, no Brasil, software é tratado como obra intelectual e protegido pela mesma lógica do direito autoral. E, pela lógica do direito autoral, quem cria a obra é dono dela, salvo regra ou contrato em contrário. Quando uma empresa contrata um desenvolvedor freelancer, uma agência ou uma software house para criar parte do seu sistema, e não formaliza adequadamente a transferência de direitos, a titularidade do código fica com quem escreveu, não com quem pagou.

Este artigo explica como evitar esse problema. Vamos abordar a base legal, o que precisa estar em um contrato bem feito, as diferenças entre as situações de freelancer, funcionário CLT e agência terceirizada, e os erros mais comuns que vejo na prática.

A base do problema: software é direito autoral

A Lei nº 9.609/98, conhecida como Lei do Software, regula a proteção dos programas de computador no Brasil. Ela se conecta com a Lei nº 9.610/98 (direitos autorais), aplicando ao software, com adaptações, a lógica geral da proteção autoral.

A consequência prática é importante: a proteção sobre o código nasce automaticamente no momento em que ele é escrito, sem necessidade de registro. E, mais importante, a titularidade originária pertence ao autor, ou seja, à pessoa física que efetivamente programou.

Para que essa titularidade vá para uma empresa, é preciso que exista um dos seguintes mecanismos:

• A criação ocorra dentro de uma relação de emprego em que esteja contratualmente previsto que o código pertencerá à empregadora, conforme o art. 4º da Lei do Software.
• Exista um contrato de cessão de direitos patrimoniais entre o autor e a empresa.
• Exista um contrato de prestação de serviço com cláusula expressa de cessão.

Sem nenhuma dessas hipóteses, o que se tem na prática é uma licença implícita de uso, que não é o mesmo que titularidade. A empresa pode usar o software, mas não é, juridicamente, dona dele. E não ser dona significa não poder vendê-lo, não poder licenciá-lo a terceiros, não poder ceder a um adquirente em uma operação de M&A, e não poder impedir que o próprio autor continue usando o código em outros projetos.

A diferença entre direitos morais e patrimoniais

Antes de falar de contrato, é preciso entender uma distinção fundamental do direito autoral: a separação entre direitos morais e direitos patrimoniais.

Os direitos morais são o vínculo pessoal entre o autor e a obra. Incluem o direito de reivindicar a paternidade da criação, de manter a obra inédita, de ter o nome citado, de se opor a modificações que afetem a integridade da obra. Esses direitos são, em regra, inalienáveis e irrenunciáveis. Mesmo que sua empresa adquira tudo o que pode adquirir sobre o código, o desenvolvedor continuará sendo, juridicamente, o autor.

Os direitos patrimoniais, por sua vez, são os direitos de exploração econômica da obra: reproduzir, distribuir, modificar, traduzir para outras linguagens, licenciar, comercializar. Esses sim podem ser cedidos integralmente.

Na prática, isso tem duas implicações importantes para empresas de software:

• A cessão precisa ser dos direitos patrimoniais. Não adianta um contrato dizer que "o desenvolvedor cede todos os direitos sobre a obra", porque os direitos morais não são cedíveis. O texto correto fala em cessão dos direitos patrimoniais.
• Mesmo após a cessão, o autor pode, em situações específicas, invocar direitos morais. Por isso é prudente, em contratos de software, incluir cláusula em que o autor renuncia ao exercício de prerrogativas morais compatíveis com renúncia, como a exigência de creditar o nome do programador no código de produção comercial.

O que precisa estar no contrato com um desenvolvedor

Um bom contrato de prestação de serviço de desenvolvimento ou contrato de obra intelectual precisa ter, no mínimo, os seguintes elementos relacionados à propriedade intelectual.

Cláusula de cessão expressa, total e definitiva dos direitos patrimoniais. A redação precisa ser clara: o desenvolvedor cede, em caráter total, definitivo, irrevogável, irretratável e por prazo indeterminado, todos os direitos patrimoniais sobre o código produzido durante a vigência do contrato. A cessão deve abranger o direito de reproduzir, modificar, criar obras derivadas, distribuir, comercializar, licenciar a terceiros e usar o código em qualquer plataforma e por qualquer meio, conhecido ou que venha a ser desenvolvido.

Definição clara do escopo do que está sendo cedido. O contrato deve descrever o que o desenvolvedor fará e estabelecer que tudo o que for produzido no contexto da prestação de serviço, incluindo código, documentação técnica, scripts auxiliares, designs de banco de dados, arquitetura e demais entregáveis, está incluído na cessão. Isso evita discussões posteriores sobre o que foi ou não foi cedido.

Contraprestação financeira destacada. O contrato precisa indicar que o pagamento contratado já remunera tanto a prestação do serviço quanto a cessão dos direitos. Sem isso, abre-se margem para o desenvolvedor alegar, no futuro, que a remuneração foi apenas pelo trabalho e que a cessão exigiria pagamento adicional.

Cláusula de obrigação de assinar documentos complementares. Mesmo com um contrato bem redigido, eventualmente surge a necessidade de formalizar atos específicos, como termos para registro do software no INPI ou documentos exigidos por compradores em uma due diligence. Por isso é prudente incluir cláusula em que o desenvolvedor se obriga a assinar, sem custo adicional, documentos complementares razoáveis solicitados pela empresa para confirmar a cessão.

Renúncia ao exercício de direitos morais compatíveis com renúncia. Como visto, direitos morais são em regra irrenunciáveis, mas há prerrogativas específicas que podem ser objeto de acordo, como dispensa de creditação no produto final.

Garantia de originalidade e indenidade. O desenvolvedor deve garantir que o código entregue é original, não viola direitos de terceiros e não incorpora componentes com licenças incompatíveis com o uso pretendido pela empresa. Em caso de violação, o desenvolvedor se obriga a indenizar a empresa por eventuais danos.

Cláusula de confidencialidade. Embora seja tema próprio, vale lembrar que a confidencialidade caminha junto com a cessão. O desenvolvedor terá acesso a informações sensíveis e precisa estar contratualmente obrigado a não divulgar nem utilizar essas informações para outros fins.

Freelancer, CLT e agência: as três situações típicas

A forma de proteger a titularidade muda conforme o tipo de relação contratual. Vou explicar as três mais comuns.

Desenvolvedor freelancer ou autônomo

Esta é a situação de maior risco para a empresa, porque a regra geral do direito autoral se aplica integralmente: o autor é o titular originário, e a empresa só adquire direitos por meio de cessão expressa.

O contrato com freelancer precisa, sem exceção, ter cláusula de cessão de direitos patrimoniais clara, completa e antes do início dos trabalhos. Idealmente, a cessão se aplica a todo o material produzido durante a vigência do contrato.

Atenção a um ponto frequente: muitas empresas contratam freelancers por meio de plataformas internacionais (como Upwork, Fiverr, Toptal). Os termos dessas plataformas geralmente incluem cláusulas de cessão padrão, mas elas variam em qualidade e em compatibilidade com o direito brasileiro. Para projetos relevantes, é prudente ter um contrato adicional brasileiro, mesmo que em paralelo aos termos da plataforma.

Funcionário CLT da área de tecnologia

Para funcionários celetistas, a situação é mais favorável à empresa, mas não automática. O art. 4º da Lei do Software estabelece que pertencem exclusivamente ao empregador os direitos sobre o programa de computador desenvolvido durante a vigência do contrato de trabalho, desde que o desenvolvimento decorra das atividades para as quais o empregado foi contratado, ou que sejam utilizados recursos, informações tecnológicas ou equipamentos da empresa.

Na prática, isso significa que:

• O contrato de trabalho precisa descrever com clareza que as atividades incluem desenvolvimento de software para a empresa. Cargo genérico ou descrição vaga de atividades pode gerar discussão.
• É recomendável incluir, no contrato de trabalho ou em aditivo, cláusula expressa confirmando a regra do art. 4º e a titularidade integral da empresa sobre todos os códigos produzidos no contexto do emprego.
• Atenção redobrada para códigos desenvolvidos fora do horário de trabalho, em projetos pessoais do funcionário. Se o funcionário usa equipamento ou informação da empresa, ainda assim a titularidade pode ser da empresa. Mas se o desenvolvimento é completamente paralelo, pessoal e sem uso de recursos da empresa, ele pode pertencer ao funcionário.

Esse último ponto costuma gerar conflito quando funcionários saem da empresa e começam a desenvolver produtos próprios. Quanto mais clara estiver a separação no contrato, menos margem para disputa.

Agência ou software house contratada

Quando a empresa contrata uma agência ou software house para desenvolver um sistema, a situação é, em essência, semelhante à do freelancer: a regra geral é a titularidade originária do autor. A diferença é que aqui o autor é a pessoa física do desenvolvedor da agência, não a agência em si.

Isso significa que o contrato precisa ter dupla camada de proteção:

• Cláusula de cessão da agência para a empresa contratante, abrangendo todos os direitos patrimoniais sobre o código produzido para o projeto.
• Garantia, prestada pela agência, de que ela possui contratos válidos com seus desenvolvedores que asseguram a titularidade dos direitos cedidos. Idealmente, com cláusula de indenização caso essa cadeia se quebre.

Sem esses elementos, o que pode ocorrer é a empresa contratante receber a cessão da agência, mas a agência não ter, ela própria, recebido a cessão dos desenvolvedores. O resultado é que o título cedido é frágil.

Para projetos relevantes, vale exigir da agência cópia dos termos de cessão internos com seus colaboradores ou, ao menos, declaração formal sobre a existência desses termos.

Os erros mais comuns que comprometem a titularidade

Na prática, vejo os mesmos erros se repetindo. Vale destacá-los.

• Contrato genérico de prestação de serviço sem cláusula de PI. Muita empresa usa modelos de contrato encontrados na internet ou herdados de outros projetos, sem adaptação. Esses modelos costumam não ter cláusulas de propriedade intelectual ou ter cláusulas vagas, que dão margem a interpretação.
• Confiar no acordo verbal ou em e-mails informais. Cessão de direitos autorais exige forma escrita, conforme art. 50 da Lei nº 9.610/98. Combinados informais não substituem contrato. Mesmo que ambas as partes confirmem hoje que houve cessão, sem documento escrito a empresa não tem como provar isso de forma robusta a um terceiro investidor ou adquirente.
• Cláusula de cessão limitada a "uso interno" ou "exploração comercial atual". Cessão precisa ser ampla, sem limitação de finalidade. Limitações criam exatamente o tipo de discussão que se quer evitar. Se a empresa for vendida, o adquirente precisa receber a titularidade plena, e cláusulas restritivas podem inviabilizar isso.
• Esquecer da cessão para projetos antigos. Empresas em fase de levantamento de PI costumam descobrir que partes importantes do sistema foram desenvolvidas anos atrás, por pessoas que já não fazem parte da empresa, sem qualquer contrato. Resolver isso depois é caro e às vezes impossível, porque depende de localizar e convencer ex-colaboradores a assinarem termos de cessão retroativos.
• Não documentar a história do código. Em uma due diligence rigorosa, o investidor pode pedir a "cadeia de titularidade" do software: quem desenvolveu, quando, sob qual contrato, com qual cessão. Empresas que não mantêm essa documentação têm dificuldade em comprovar a titularidade limpa, mesmo quando ela existe na prática.
• Misturar código aberto sem critério. Bibliotecas e componentes open source têm licenças com regras próprias. Algumas, como a MIT, são bastante permissivas. Outras, como a GPL, exigem que o software derivado também seja licenciado em open source. Usar componentes sem analisar a licença pode contaminar o produto e impedir a comercialização.

O que fazer se descobrir o problema agora

Se ao ler este artigo você percebeu que sua empresa pode estar nessa situação, há um caminho para regularizar, e a boa notícia é que a maioria dos casos tem solução, desde que se aja antes de ter pressão externa.

Mapeie o código. Identifique os principais módulos do seu sistema e quem desenvolveu cada um. Inclua funcionários atuais, ex-funcionários, freelancers, agências e qualquer outro contribuinte.

Verifique os contratos existentes. Para cada pessoa identificada, levante o contrato em vigor (ou que estava em vigor à época do desenvolvimento) e analise se há cláusula de cessão adequada.

Identifique as lacunas. Onde houver ausência de contrato ou cláusula insuficiente, trate como pendência a resolver.

Formalize termos de cessão complementares. Para colaboradores atuais, inclua aditivos contratuais. Para ex-colaboradores, busque a assinatura de termo específico de cessão, eventualmente com pequena contraprestação financeira simbólica para reforçar a validade. Quanto mais cedo, mais fácil. Pessoas que saíram em bons termos costumam assinar sem resistência.

Documente a história. Mesmo após regularizar, monte um dossiê com os contratos, termos e cessões, organizado por módulo do sistema. Em uma due diligence futura, esse dossiê é o que diferencia uma resposta de cinco minutos de uma negociação travada por meses.

FAQ: perguntas frequentes sobre cessão de direitos sobre código

Se eu pago um desenvolvedor, o código não passa automaticamente a ser meu?

Não. No Brasil, a titularidade dos direitos autorais é, em regra, do autor. Pagar pelo serviço não transfere automaticamente os direitos patrimoniais sobre a obra. É preciso contrato com cláusula expressa de cessão.

Acordo verbal ou e-mail valem como cessão?

Não. A Lei nº 9.610/98, em seu art. 50, exige forma escrita para a cessão de direitos autorais. Acordos verbais ou trocas informais de e-mail não são suficientes para uma cessão robusta, embora possam servir como indício em discussões judiciais.

A regra para funcionários CLT é a mesma?

Não. Para funcionários CLT, a Lei do Software (art. 4º) prevê que o código desenvolvido no contexto do contrato de trabalho pertence à empregadora, desde que decorra das atividades contratadas ou que sejam usados recursos da empresa. Mas é altamente recomendável que essa regra esteja confirmada em cláusula contratual expressa.

Preciso registrar o software no INPI mesmo com contrato de cessão?

O registro no INPI não é obrigatório, mas é recomendado. Ele cria prova robusta da existência do código em determinada data e facilita operações societárias e M&A. Contrato e registro são complementares, não substitutos.

Se eu uso código aberto, isso afeta a titularidade do meu software?

Pode afetar. Componentes open source têm licenças próprias. Algumas exigem que o software que os utiliza também seja distribuído como open source, o que pode inviabilizar a comercialização do produto proprietário. Antes de incorporar componentes externos, é essencial analisar a licença.

Investidores costumam exigir contratos de cessão?

Sim. Em rodadas de investimento, especialmente a partir do estágio Seed e Série A, investidores fazem due diligence de propriedade intelectual e exigem comprovação da titularidade limpa sobre o software. Lacunas nesse ponto podem atrasar ou inviabilizar a operação.

Conclusão

A propriedade sobre o código-fonte é, para empresas de tecnologia, um ativo central. Não tê-la formalizada é como construir um prédio sem registrar a escritura: enquanto ninguém questiona, parece que está tudo bem; quando questionam, o problema vira muito caro.

A boa notícia é que regularizar essa estrutura é trabalho de baixo custo quando comparado ao valor protegido. Contratos bem redigidos, aditivos contratuais e termos de cessão complementares resolvem a esmagadora maioria dos casos.

O que custa caro é deixar para resolver depois, sob pressão de uma rodada de investimento, de uma operação de M&A ou de uma disputa com ex-colaborador. Antecipar é sempre mais barato do que remediar.

Sobre este conteúdo: este artigo tem caráter informativo e não substitui orientação jurídica específica. Cada caso tem particularidades, e a estratégia de proteção de propriedade intelectual sobre software deve ser desenhada considerando o contexto e os objetivos do seu negócio.