Quem é Dono do Código-Fonte? Licença, Cessão e Contrato de Software

Uma empresa paga durante oito meses pelo desenvolvimento de um sistema e, no fim do projeto, descobre que não pode acessar o código-fonte. Outra compra uma licença “definitiva”, mas perde as atualizações quando cancela o suporte. Uma startup adapta seu produto para um cliente e depois ouve que a customização não pode ser oferecida a mais ninguém. Essas discussões parecem técnicas, porém começam no contrato.

Software reúne elementos diferentes: código-fonte, código executável, interface, documentação, banco de dados, marca, componentes de terceiros, infraestrutura e serviços humanos. O cliente pode receber o direito de usar alguns desses elementos sem adquirir a propriedade intelectual. Também pode ser titular do código desenvolvido e continuar dependente do fornecedor para hospedagem, manutenção ou conhecimento operacional.

Por isso, dizer apenas “o sistema pertence ao cliente” ou “a plataforma é do fornecedor” não resolve. O contrato precisa responder quais ativos estão incluídos, quais direitos são concedidos, por quanto tempo, em qual ambiente, para quantos usuários e o que acontece com dados, integrações e código quando a relação termina.

O ponto de partida é escolher o instrumento adequado. Para conceder direito de uso sem transferir a titularidade, o DiretoDoc oferece um Contrato de Licenciamento de Software personalizável, com opções de escopo, remuneração, suporte, propriedade intelectual, proteção de dados e rescisão.

Licença de uso não é compra da propriedade do software

Na licença, o titular autoriza outra pessoa a usar o programa dentro de limites. A propriedade intelectual permanece com o licenciante. É semelhante a receber uma chave de acesso com regras, e não as chaves de toda a fábrica. O usuário pode executar o programa, mas não ganha automaticamente o direito de copiar, revender, modificar ou entregar o código a terceiros.

A Lei nº 9.609/1998, conhecida como Lei de Software, determina no art. 9º que o uso de programa de computador no Brasil será objeto de contrato de licença. Se não houver contrato, o documento fiscal relativo à aquisição ou ao licenciamento da cópia pode comprovar a regularidade do uso, mas dificilmente responde a todas as questões operacionais.

Uma licença pode ser perpétua ou temporária, exclusiva ou não exclusiva, gratuita ou remunerada. Pode abranger instalação local, acesso por navegador, aplicativo móvel ou combinação de ambientes. O nome comercial do plano não substitui essas definições.

Mesmo uma “licença perpétua” não significa suporte e atualização eternos. Em geral, ela permite usar determinada versão por tempo indeterminado, enquanto manutenção, hospedagem, correções e novas versões seguem prazo e preço próprios. O contrato deve deixar essa divisão visível.

Cessão transfere direitos; licença apenas autoriza o uso

Na cessão, o titular transfere direitos patrimoniais sobre o software nos limites do documento. A transferência pode ser total ou parcial, exclusiva, territorialmente limitada e sujeita a condições. Como negócios sobre direitos autorais são interpretados de forma restritiva, não convém presumir direitos que não foram descritos.

A Lei nº 9.610/1998 inclui programas de computador entre as obras protegidas e determina, no art. 4º, interpretação restritiva dos negócios sobre direitos autorais. A Lei de Software aplica regime específico, mas essa lógica reforça a necessidade de enumerar o que foi transferido.

Comprar todos os direitos pode ser adequado em sistema estratégico feito sob encomenda. Para produto padronizado oferecido a vários clientes, a cessão total normalmente inviabilizaria o modelo do fornecedor. Nesse caso, licença ampla ou cláusula específica sobre customizações pode atender melhor.

Também existe situação híbrida: a plataforma-base permanece com o fornecedor, enquanto determinado módulo criado e pago exclusivamente pelo cliente é cedido a ele; ou o cliente recebe licença irrevogável sobre a customização, e o fornecedor conserva componentes genéricos. O contrato deve mapear cada camada.

Quem é dono do software desenvolvido sob encomenda?

O art. 4º da Lei de Software estabelece regra relevante: salvo estipulação em contrário, pertencem ao empregador ou contratante os direitos sobre programa desenvolvido durante o vínculo quando o trabalho era expressamente destinado à pesquisa e desenvolvimento, quando essa atividade estava prevista ou quando decorria da própria natureza dos encargos.

Essa regra não torna desnecessário o contrato. Ainda é preciso identificar o programa, as versões, os módulos e as pessoas envolvidas. Também convém declarar se o preço inclui a transferência, se o desenvolvedor pode reutilizar componentes genéricos e como ficam ferramentas anteriores ao projeto.

O mesmo artigo preserva ao empregado ou prestador os direitos sobre programa criado sem relação com o vínculo e sem uso de recursos, informações tecnológicas, segredos, materiais, instalações ou equipamentos do contratante. Projetos pessoais e corporativos podem se misturar se não houver política e inventário.

Estagiários, bolsistas e colaboradores também precisam ser contemplados. A empresa que pretende licenciar ou vender o software deve conseguir demonstrar a cadeia de titularidade desde cada autor até a pessoa jurídica. Uma lacuna pode surgir justamente em investimento, auditoria ou venda do negócio.

Pagar pelo projeto é suficiente?

O pagamento é prova de uma relação contratual, mas não explica sozinho se o objeto era licença, desenvolvimento, manutenção ou cessão. A nota fiscal pode dizer “serviços de tecnologia” e deixar em aberto todos os direitos de exploração econômica.

Para reduzir a dúvida, o contrato deve usar verbos precisos: desenvolver, entregar, licenciar, ceder, hospedar, manter e suportar. Cada verbo corresponde a uma obrigação diferente. A descrição técnica deve ser anexada e versionada.

Quando a empresa paga apenas uma assinatura de SaaS, o cenário usual é licença de acesso, não aquisição do produto. Quando financia código exclusivo conforme especificação própria, pode haver titularidade do contratante pela regra legal, mas a redação expressa evita disputa sobre base preexistente e customizações.

Ter o código-fonte é diferente de ser titular dos direitos

O código-fonte é uma forma legível do programa, usada para compreender, compilar, corrigir e evoluir. Receber uma cópia não transfere necessariamente a propriedade intelectual. O cliente pode ter acesso apenas para auditoria ou contingência, sem autorização para distribuir ou explorar comercialmente.

O inverso também pode ocorrer: o cliente é titular do código desenvolvido, mas o repositório está na conta do fornecedor, sem histórico, chaves, instruções de compilação ou dependências. Nesse caso, a titularidade formal não garante autonomia prática.

O contrato deve separar quatro permissões: acessar, copiar, modificar e disponibilizar a terceiros. Pode autorizar manutenção por prestador substituto apenas após encerramento ou descumprimento, mantendo confidencialidade e vedando concorrência indevida.

Também indique o formato da entrega: repositório Git completo, histórico, branches relevantes, documentação de arquitetura, scripts de implantação, lista de dependências, credenciais transferíveis e instruções para gerar a versão em produção. Um arquivo compactado sem contexto raramente assegura continuidade.

Quando o acesso ao código-fonte é necessário?

Em licença padrão de produto mantido pelo fornecedor, acesso amplo pode não ser necessário. O cliente depende do fornecedor por escolha comercial, e o preço normalmente considera que o mesmo produto será evoluído para vários usuários.

Em sistema crítico, altamente customizado ou instalado na infraestrutura do cliente, o risco de descontinuidade é maior. Acesso condicionado, depósito de código ou obrigação de entrega em eventos definidos pode equilibrar proteção do fornecedor e continuidade do cliente.

Empresas reguladas podem precisar realizar auditorias, testes de segurança ou apresentar evidências. Isso não exige sempre receber todo o código. O contrato pode permitir análise controlada, relatório independente, acesso em ambiente restrito ou entrega de artefatos específicos.

Se o cliente pretende modificar o programa por conta própria, o contrato deve prever compatibilidade com atualizações, responsabilidade por falhas e suporte. O fornecedor não deve responder por defeito introduzido por alteração não homologada, mas a exclusão precisa guardar relação com a causa do problema.

Escrow de código-fonte: o que é e quando funciona?

No escrow, uma cópia atualizada do código e da documentação fica sob custódia de terceiro. O material é liberado ao cliente apenas se ocorrer evento previsto, como falência, encerramento definitivo do produto, descumprimento grave de suporte ou desaparecimento do fornecedor.

O depósito só é útil se estiver completo e atualizado. É preciso definir periodicidade, validação, confidencialidade, custo, formato e testes. Um repositório antigo, sem dependências ou sem instruções de implantação, não resolve a continuidade.

O evento de liberação deve ser verificável. Expressões como “risco de descontinuidade” são subjetivas. Procedimentos com notificação, prazo de cura e comprovação reduzem liberação indevida e protegem o segredo industrial.

Depois da liberação, quais direitos o cliente recebe? Pode usar internamente, contratar manutenção, corrigir falhas e criar versões? Pode sublicenciar para empresas do grupo? A licença de contingência precisa responder a essas perguntas antes do depósito.

Como definir o escopo da licença

O escopo transforma a expressão “direito de uso” em regra operacional. Defina usuários nomeados ou simultâneos, empresas autorizadas, unidades, país, ambiente, dispositivos, módulos, volume de dados e integrações. Se houver métricas de consumo, explique como são contadas.

Empresas de um mesmo grupo não são automaticamente a mesma pessoa jurídica. A licença deve dizer se controladas, controladoras, franquias, clientes ou prestadores podem acessar. Também deve prever o que acontece quando uma empresa deixa o grupo.

Ambientes de desenvolvimento, teste, homologação, contingência e produção precisam de tratamento. Cobrar como produção uma cópia que não atende usuários pode gerar conflito; permitir réplicas ilimitadas pode ampliar uso muito além do preço.

Licença territorial continua relevante em software online quando existem restrições de exportação, infraestrutura regional, suporte por fuso ou direitos de terceiros. Não use “mundo inteiro” automaticamente se o fornecedor não pode operar em todos os locais.

SaaS, on-premise e licença híbrida

No SaaS, o programa roda na infraestrutura do fornecedor ou de subcontratado e o cliente acessa o serviço. O contrato combina licença, hospedagem, manutenção, segurança, suporte e tratamento de dados. O cliente não recebe necessariamente uma cópia instalável.

No modelo on-premise, o software é instalado em infraestrutura do cliente. Isso aumenta o controle sobre ambiente e dados, mas exige definir requisitos técnicos, atualização, acesso remoto, responsabilidade por backup e compatibilidade com componentes.

O modelo híbrido mantém parte local e parte na nuvem. Falhas podem surgir na fronteira: rede do cliente, API do fornecedor, provedor de nuvem ou integração de terceiro. A matriz de responsabilidade deve indicar quem monitora e qual evidência identifica a origem.

Não basta usar a palavra SaaS. O contrato precisa descrever disponibilidade, regiões de armazenamento, dependências críticas, janela de manutenção, exportação de dados e procedimento de encerramento. Os Termos de Uso podem complementar regras para usuários finais, sem substituir o acordo comercial entre as empresas.

Customizações: quem pode reutilizar o que foi criado?

Customização pode ser regra de negócio específica, tela, relatório, conector ou melhoria genérica. Tratar todas como um único bloco cria extremos: o cliente reivindica o produto inteiro; o fornecedor tenta reutilizar segredo exclusivo.

O art. 5º da Lei de Software dispõe que os direitos sobre derivações autorizadas pertencem a quem as fizer, salvo estipulação contratual em contrário. A aplicação depende do caso e da relação entre base e derivação. Por isso, o contrato deve antecipar a titularidade.

Uma solução é separar propriedade preexistente, entregável específico e conhecimento genérico. O fornecedor conserva bibliotecas, framework e ferramentas anteriores. O cliente recebe direitos sobre especificação, dados e elementos pagos como exclusivos. Melhorias reutilizáveis podem permanecer com o fornecedor, desde que não revelem informação confidencial.

Se a exclusividade for importante, defina objeto, território, setor e prazo. Proibir o fornecedor de usar qualquer ideia semelhante pode inviabilizar sua atividade; permitir reutilização integral pode retirar a vantagem competitiva pela qual o cliente pagou.

Componentes open source e direitos de terceiros

Quase todo software moderno usa bibliotecas de terceiros. Cada componente tem licença própria. Algumas exigem preservação de avisos; outras impõem condições para distribuição de obras derivadas. O contrato não pode prometer exclusividade sobre código que o fornecedor não controla.

O fornecedor deve manter inventário de componentes, versões e licenças, especialmente quando entrega software para distribuição. O documento pode ser apresentado como SBOM ou lista técnica atualizada. Componentes críticos precisam de política de atualização de segurança.

Open source não significa ausência de obrigação. Licenças permissivas e copyleft têm efeitos diferentes. A análise deve considerar como o componente foi incorporado, se haverá distribuição e quais direitos serão concedidos ao cliente.

O contrato deve prever responsabilidade por alegação de violação de direitos de terceiro, processo de defesa, substituição do componente e limites. A Lei de Software considera nula cláusula que exonere os contratantes de responsabilidade por ações de terceiros decorrentes de violação de direitos autorais em hipóteses do art. 10.

Registro no INPI: obrigatório ou útil?

A proteção do software independe de registro, conforme art. 2º, § 3º, da Lei de Software. Ainda assim, registrar pode fortalecer a prova de autoria, titularidade e data, especialmente em licenciamento, investimento e disputa.

O INPI mantém guia oficial para registro de programa de computador. O procedimento usa resumo digital do código e documentação, preservando o sigilo dos elementos técnicos conforme a legislação.

O contrato deve indicar quem registrará, quem pagará taxas e quem será declarado titular. Se houver nova versão relevante, as partes podem prever atualização do registro. O certificado não corrige uma cadeia de contratos incompleta; ele deve corresponder à titularidade efetiva.

Em transferência de tecnologia, o art. 11 da Lei de Software prevê registro do contrato no INPI para efeitos perante terceiros e exige documentação técnica adequada à absorção da tecnologia. Licença simples e transferência de tecnologia não devem ser confundidas.

Validade técnica, manutenção e suporte

Os arts. 7º e 8º da Lei de Software exigem indicação do prazo de validade técnica da versão comercializada e prestação de serviços técnicos complementares durante esse prazo, consideradas as especificações. A obrigação pode persistir se o produto sair de circulação, salvo justa indenização de prejuízos.

Validade técnica não significa garantia de que qualquer ambiente futuro será compatível. O contrato deve indicar sistemas suportados, navegadores, banco de dados, requisitos mínimos e política de atualização. Mudança feita pelo cliente pode exigir projeto adicional.

Manutenção corretiva resolve defeitos em relação à especificação. Evolutiva cria funções novas. Adaptativa acompanha mudança de ambiente ou legislação. Suporte orienta o usuário. Misturar tudo em “manutenção inclusa” gera expectativa impossível de medir.

Defina canais, horários, prioridades, tempo de resposta e tempo de solução ou contorno. Nem todo incidente pode ter prazo fixo de solução, mas o fornecedor deve assumir processo, comunicação e escalonamento compatíveis com a criticidade.

SLA e disponibilidade do sistema

Disponibilidade deve ter fórmula, fonte de medição e exclusões. Informe período mensal, minutos totais, indisponibilidade atribuível ao fornecedor e janelas de manutenção. Uma porcentagem sem fórmula pode esconder diferenças relevantes.

Exclusões precisam ser proporcionais. Falha de internet do cliente, uso fora da especificação e manutenção previamente avisada podem ser excluídos. Chamar qualquer falha do provedor de nuvem de força maior transfere ao cliente um risco que o fornecedor escolheu administrar.

Créditos de serviço podem compensar descumprimento recorrente, mas não devem ser a única resposta para dano grave quando a lei não permite. Também é preciso definir procedimento e prazo para solicitar crédito, sem exigir prova inacessível ao cliente.

Após repetidas violações, o cliente pode ter direito de rescindir e receber dados. Essa saída deve funcionar mesmo se créditos foram concedidos. O SLA não pode transformar indisponibilidade crônica em simples desconto previsível.

Dados do cliente não são o mesmo que o software

O fornecedor pode ser titular da plataforma e não ter direito de explorar livremente os dados carregados pelo cliente. O contrato deve definir titularidade ou controle contratual sobre bases, conteúdo, registros e resultados, respeitando direitos de terceiros e legislação de proteção de dados.

Quando houver dados pessoais, as partes precisam identificar papéis e instruções. Um Contrato de Tratamento de Dados Pessoais pode detalhar controlador, operador, finalidade, segurança, suboperadores, incidentes, retorno e eliminação.

A LGPD exige finalidade, adequação, necessidade, segurança e prestação de contas. Uma frase genérica autorizando uso de todos os dados para “melhoria do produto” pode ser incompatível com as funções reais das partes e com a expectativa dos titulares.

Dados anonimizados e telemetria merecem definição. Quais eventos são coletados? Para qual finalidade? É possível reidentificar? O contrato deve distinguir métricas operacionais necessárias de exploração comercial independente.

Segurança e incidentes

A obrigação de segurança precisa combinar medidas técnicas e processo. Controle de acesso, criptografia, logs, gestão de vulnerabilidades, backup, teste de restauração e resposta a incidentes são exemplos, mas devem refletir o risco e a arquitetura do produto.

O contrato deve prever prazo de comunicação entre fornecedor e cliente, conteúdo mínimo, atualizações e cooperação. A ANPD explica que o controlador deve comunicar incidentes com risco ou dano relevante; por isso, o operador precisa avisar o controlador em tempo suficiente para avaliação.

Não use prazo apenas “após confirmação”. Investigar é necessário, porém esperar certeza absoluta pode atrasar resposta. É possível exigir aviso preliminar após ciência de indício relevante, seguido de informações complementares.

A Política de Privacidade informa titulares sobre o tratamento, mas não substitui cláusulas operacionais entre fornecedor e cliente. Os dois documentos devem ser coerentes.

Auditoria de uso sem vigilância excessiva

O licenciante pode precisar verificar número de usuários, instalações ou consumo. O contrato deve informar quais dados serão coletados, frequência e consequência do excesso. Auditoria surpresa e irrestrita em sistemas do cliente pode criar risco de segurança e confidencialidade.

Prefira relatórios do próprio sistema, certificação pelo cliente ou auditor independente. A inspeção presencial deve ser excepcional, com aviso e horário, sem acesso a informação de terceiros não relacionada à licença.

Se houver uso excedente, defina período de regularização e preço. Cobrança retroativa pode ser limitada ao período comprovado. Bloqueio imediato de sistema crítico pode ser desproporcional quando o excesso é discutível.

A medição também deve permitir contestação. O cliente precisa acessar registros suficientes para conferir usuários inativos, contas técnicas, testes e duplicidades.

Proibições de uso e engenharia reversa

O contrato normalmente proíbe reprodução não autorizada, sublicença, remoção de avisos, tentativa de acesso ao código e uso para criar produto concorrente. As proibições devem respeitar permissões legais e não impedir atividades necessárias autorizadas.

O art. 6º da Lei de Software lista situações que não constituem ofensa, como cópia de salvaguarda de exemplar legitimamente adquirido e integração tecnicamente indispensável para uso exclusivo, nas condições legais. Uma cláusula não deve fingir que esses direitos inexistem.

Testes de segurança devem ser regulados, não simplesmente proibidos. Defina ambiente, aviso, limite de carga, tratamento de vulnerabilidades e divulgação responsável. Isso protege a infraestrutura sem impedir gestão de risco do cliente.

O uso de resultados de benchmark também pode ser disciplinado. Proibição absoluta de qualquer comparação pode ser difícil de justificar; proteção de métodos confidenciais e prevenção de divulgação enganosa são objetivos mais específicos.

O que acontece quando a licença termina?

O encerramento afeta acesso, dados, integrações, usuários e continuidade. O contrato deve distinguir término normal, rescisão por inadimplemento, encerramento do produto e insolvência. Cada cenário pode ter prazo e suporte de transição diferentes.

No SaaS, defina período para exportação, formato, documentação e canal seguro. Formato tecnicamente aberto não basta se os campos não têm descrição. O cliente precisa conseguir relacionar tabelas, anexos e históricos.

Após o prazo, o fornecedor pode eliminar cópias, salvo obrigação legal, backup imutável ou disputa. A eliminação deve seguir política informada. O cliente deve remover instalações e chaves quando a licença não for perpétua.

Se a rescisão ocorrer por falha do fornecedor, cobrar taxa elevada para entrega dos dados pode neutralizar o direito de saída. O contrato deve separar exportação padrão incluída de migração assistida, que pode ser remunerada.

Preço da licença e serviços adicionais

Separe licença, implantação, customização, treinamento, suporte, hospedagem e consumo adicional. Isso facilita reajuste, tributação, cancelamento parcial e comparação. Pacote único pode ser comercialmente simples, mas o contrato ainda deve indicar o que está incluído.

Defina métrica de cobrança: usuário, empresa, unidade, transação, armazenamento ou valor processado. A métrica precisa refletir o benefício e ser tecnicamente mensurável. Mudança unilateral de métrica pode alterar completamente a economia do contrato.

Promoção inicial, piloto e desconto por volume devem ter prazo e condição de encerramento. O preço após o piloto deve aparecer antes do início, evitando que dependência operacional seja usada para impor valor inesperado.

Reajuste segue índice e periodicidade contratados. Revisão de preço por mudança de escopo deve ser vinculada a módulo, usuário ou consumo adicional, e não apresentada como simples correção monetária.

Limitação de responsabilidade precisa ter exceções coerentes

Contratos de software costumam limitar indenização a determinado valor. A cláusula deve considerar natureza do serviço, preço, seguro e riscos. Limite simbólico pode não ser adequado para sistema que controla operação essencial.

Defina danos diretos, lucros cessantes, perda de dados e multas de terceiros com linguagem clara. Não basta copiar termos de outro país. Regras brasileiras, relação de consumo quando aplicável e deveres de proteção de dados influenciam a validade.

Exceções comuns envolvem dolo, violação de confidencialidade, propriedade intelectual e proteção de dados, mas o desenho depende do poder de negociação. A exceção deve conversar com cobertura de seguro e procedimentos de defesa.

Backup também precisa de responsabilidade compartilhada. Se o fornecedor promete cópias e restauração, deve informar frequência e objetivo de recuperação. Se o cliente tem obrigação de backup local, o produto precisa oferecer meio real de realizá-lo.

Checklist antes de assinar pelo cliente

Identifique se está adquirindo licença, desenvolvimento ou cessão. Verifique titularidade da base, das customizações e da documentação. Confirme se terá acesso ao código, escrow ou outro mecanismo de continuidade.

Simule crescimento: mais usuários, empresa do grupo, nova unidade, integração e aumento de dados. Calcule preço e verifique se o fornecedor pode bloquear acesso. Teste os prazos de suporte com incidentes reais da operação.

Confira exportação de dados, prazo de transição, formato e custo. Peça amostra de exportação antes da assinatura. Liste componentes críticos e dependências de terceiros.

Alinhe contrato, proposta, SLA, política de privacidade e documento de tratamento de dados. Se houver conflito, estabeleça ordem de prevalência.

Checklist antes de assinar pelo fornecedor

Comprove cadeia de titularidade de empregados, sócios, prestadores e componentes. Separe tecnologia preexistente de entregas do cliente. Não prometa exclusividade que impeça a evolução do produto para toda a base.

Defina limites de uso mensuráveis e procedimento de regularização. Descreva manutenção e suporte que a equipe consegue cumprir. Evite SLA criado apenas pela área comercial sem capacidade operacional.

Mapeie dados tratados, suboperadores e local de hospedagem. Prepare processo de incidente e exportação. Especifique quais alterações do cliente retiram suporte e como o produto pode ser restaurado.

Formalize mudanças por aditivo ou ordem de serviço. Cada customização deve declarar escopo, aceite, preço, prazo e direitos intelectuais.

Como montar um contrato coerente

Comece por um mapa de ativos: plataforma-base, módulos, customizações, código, documentação, dados, marca e infraestrutura. Ao lado de cada item, indique titular, acesso, permissão de uso, duração e destino final.

Depois, conecte obrigações operacionais: implantação, aceite, suporte, segurança, disponibilidade, atualização e saída. A propriedade intelectual não pode ficar em capítulo isolado, contradita por anexos técnicos.

Use o modelo de Licenciamento de Software do DiretoDoc para estruturar os direitos de uso, e complemente com confidencialidade e tratamento de dados quando o projeto exigir. A escolha entre licença e cessão deve refletir o negócio real.

Um contrato de software funciona quando o cliente sabe exatamente o que pode fazer e o fornecedor sabe exatamente o que continua sendo seu. Essa divisão reduz dependência oculta, protege investimento e permite que suporte, evolução e encerramento sejam tratados como processos — não como surpresa no momento de maior conflito.