Titularidade do código: autoria, propriedade e acesso não são iguais

A pergunta “quem é dono do código?” só parece simples quando todas as camadas do software são tratadas como se fossem uma única criação. Um produto pode combinar código desenvolvido no projeto, bibliotecas open source, ferramentas anteriores do fornecedor, serviços de terceiros, documentação, interface e ativos produzidos por empregados ou subcontratados. Cada camada pode ter uma origem e um regime de direitos diferente.

Autoria, titularidade e acesso técnico não se confundem

A Lei nº 9.609/1998 disciplina especificamente os programas de computador e contém regras sobre direitos relativos a software desenvolvido durante vínculo de emprego ou prestação de serviços. A Lei de Direitos Autorais complementa a análise de outros elementos protegidos que podem existir no produto.

Quem escreveu determinada linha de código não necessariamente conserva todos os direitos patrimoniais sobre ela. Da mesma forma, controlar a organização do GitHub ou possuir uma cópia do repositório não prova, por si só, cadeia jurídica de titularidade.

A cadeia de direitos precisa chegar até o titular atual

Em projetos com equipe interna e fornecedores, a documentação deve permitir reconstruir quem criou cada componente relevante e sob qual vínculo. Se uma software house subcontrata parte do desenvolvimento, ela só pode transmitir ao cliente aquilo que efetivamente recebeu do subcontratado.

Contratos de trabalho ou prestação, instrumentos de cessão ou licença, registros de versões, commits, notas sobre componentes preexistentes e inventário de dependências ajudam a fechar essa cadeia. Uma cláusula genérica de “propriedade total” não cura uma lacuna anterior.

Componentes anteriores e de terceiros precisam ser separados

É comum que um fornecedor utilize frameworks internos, bibliotecas próprias e ferramentas desenvolvidas antes do projeto. Obrigar transferência irrestrita de tudo pode ser inviável. O caminho mais claro é identificar o que é resultado específico, o que permanece com o fornecedor e qual licença o cliente recebe sobre elementos necessários ao funcionamento.

A mesma lógica vale para componentes open source: eles não se tornam exclusivos apenas porque foram incorporados ao produto.

Antes de uma venda, investimento ou troca de fornecedor, essa trilha também reduz custo de due diligence: em vez de reconstruir direitos sob pressão, a empresa consegue demonstrar de onde veio o ativo e quais limitações o acompanham.

Faça o teste por módulo crítico

Escolha uma função importante do sistema e reconstrua: quem escreveu, sob qual contrato, quais dependências foram usadas, qual licença acompanha cada componente e por qual documento os direitos chegaram ao titular atual. Se houver um salto que só pode ser explicado por “sempre foi entendido assim”, existe uma pendência documental.

Depois disso, separe duas outras questões: qual licença será concedida aos usuários e quem precisa ter acesso operacional ao código-fonte. Resolver titularidade sem resolver esses dois pontos ainda pode deixar o negócio tecnicamente preso ou juridicamente exposto.