Direito Autoral e Titularidade de Software

Quando classificar um caso como LS-02

Use a LS-02 quando a controvérsia central é a quem pertence o software — não se ele foi copiado (LS-03), nem se foi entregue conforme o contrato (LS-01). A pergunta-chave do enquadramento: "as partes disputam propriedade/autoria de um mesmo código?" Se sim, é LS-02.

Tipologia (com critério de enquadramento)

• LS-02.1 — Empregado × empregador. Código criado durante vínculo CLT. Regra do art. 4º da Lei 9.609/98: pertence ao empregador quando decorre do contrato de trabalho — mas a exceção (criação desvinculada, fora do expediente e sem recursos do empregador, §2º) é exatamente o que se prova tecnicamente.
• LS-02.2 — Prestador (PJ) × contratante. Sem cláusula expressa de cessão, a titularidade tende ao autor. A análise combina contrato + evidência técnica de quem efetivamente criou.
• LS-02.3 — Sócios em dissolução. Quem fica com o produto quando a sociedade acaba. Contrato social + aportes + histórico de desenvolvimento.
• LS-02.4 — Open source incorporado. O produto contém componentes GPL/MIT/Apache: a análise verifica conformidade com as licenças e o efeito sobre o conjunto (copyleft).

Protocolo executável — 5 etapas

1. Etapa 1 — Preservação dos repositórios.
   Objetivo: garantir que o histórico de quem-fez-o-quê não seja reescrito.
   Insumos: acesso aos repositórios (GitHub/GitLab/Bitbucket/SVN) ou cópia completa com histórico (git clone --mirror).
   Execução: clonar com histórico integral; gerar hash do bundle; registrar data/hora e origem. Atenção: histórico Git pode ser reescrito (rebase, force-push) — coletar também dos servidores remotos e de máquinas locais quando possível.
   Entregável: repositórios preservados com hash e cadeia de custódia.
2. Etapa 2 — Reconstrução da autoria técnica.
   Objetivo: estabelecer quem escreveu o quê, quando.
   Execução: análise do log (git log, git blame, git shortlog -sne): autores, e-mails, datas, volume e natureza das contribuições; identificação de commits importados em bloco (código trazido pronto de fora); correlação entre identidades (mesma pessoa com e-mails diferentes).
   Entregável: Linha do Tempo de Autoria — quem contribuiu, em que período, com que peso.
3. Etapa 3 — Correlação com o vínculo jurídico.
   Objetivo: cruzar a autoria técnica com o período e o objeto da relação jurídica.
   Insumos: contrato de trabalho/prestação, CTPS, notas fiscais, registro de ponto quando existir.
   Execução: sobrepor a Linha do Tempo de Autoria às datas do vínculo; verificar se os commits ocorreram em horário de expediente, com equipamento/infra do contratante (e-mail corporativo nos commits, servidores da empresa); examinar cláusulas de PI, cessão, exclusividade.
   Entregável: quadro autoria × vínculo, apontando o que foi criado dentro e fora da relação.
4. Etapa 4 — Auditoria de licenças (quando houver open source).
   Objetivo: mapear componentes de terceiros e seus efeitos.
   Execução: varredura de dependências e licenças (SPDX; ferramentas como FOSSology/ScanCode); classificação por tipo (permissiva × copyleft); verificação de cumprimento das obrigações (avisos, disponibilização de fonte).
   Entregável: BOM (bill of materials) de software com risco por componente.
5. Etapa 5 — Parecer de Titularidade.
   Objetivo: unir tudo em uma conclusão jurídica-técnica utilizável.
   Execução: para cada módulo relevante, concluir: autor técnico + enquadramento legal (art. 4º caput ou §2º; cessão válida ou ausente) = titular. Registrar limites e incertezas.
   Entregável: Parecer de Titularidade com a matriz módulo × autor × fundamento × titular.

Checklist do advogado

• Acesso ou cópia espelho dos repositórios COM histórico (não só o código atual);
• Contratos (trabalho/prestação) com cláusulas de PI destacadas;
• Comprovantes do período do vínculo (CTPS, NFs, e-mails corporativos);
• Se houver risco de reescrita do histórico: pedido liminar de preservação.

Erros comuns

• Analisar só o código atual, sem o histórico — a autoria está no log, não no snapshot;
• Ignorar que git history pode ser adulterado — cruzar com fontes independentes (CI logs, code review, backups);
• Tratar cessão verbal como suficiente — a Lei 9.609/98 pede instrumento.

Base legal

Lei 9.609/98: arts. 1º–6º (proteção, autoria, titularidade; art. 4º e §2º para empregado/prestador). Lei 9.610/98 (subsidiária). CC arts. 104+ (validade da cessão). Art. 342 CP (falsa perícia).

Quesitos-modelo

• "Queira o Sr. Perito reconstituir, pelo histórico de versionamento, os autores e períodos de criação de cada módulo do sistema, indicando o volume e a natureza da contribuição de cada um."
• "Queira o Sr. Perito informar se os commits do Requerente ocorreram dentro do período do vínculo com a Requerida e se há elementos técnicos (e-mail corporativo, horário, infraestrutura) indicando uso de recursos da empresa."