Desenvolvimento de software: quem é dono do código-fonte?

A titularidade de um software depende da origem do desenvolvimento, do vínculo entre os envolvidos e das regras contratuais, examinados à luz da Lei de Software. Pagar pelo projeto não resolve, sozinho, todos os direitos sobre o código. Também não é correto afirmar que os direitos sempre permanecem com quem programou.

Além de identificar o titular, o contrato precisa esclarecer o que será entregue e como a empresa poderá usar, modificar e manter a solução. Direitos patrimoniais, licença de uso, acesso ao repositório e domínio técnico do sistema são questões relacionadas, mas diferentes. Uma empresa pode ter permissão de uso sem receber o código-fonte; pode receber uma cópia do repositório sem obter todos os direitos sobre cada componente.

O que a Lei de Software determina

O art. 4º da Lei nº 9.609/1998 estabelece uma regra relevante: salvo estipulação em contrário, os direitos relativos ao programa pertencem ao empregador ou contratante nas hipóteses delimitadas pelo dispositivo. Ele trata do desenvolvimento durante vínculo expressamente destinado a pesquisa e desenvolvimento, em que a atividade esteja prevista ou decorra da natureza dos encargos.

Portanto, a pergunta não termina em “quem pagou?” ou “quem digitou o código?”. É preciso confrontar o contrato, a atividade desenvolvida e a relação do programa com os encargos assumidos. Descrições vagas dificultam demonstrar se um módulo foi criado para aquele projeto ou já integrava uma solução anterior do fornecedor.

O § 2º do mesmo artigo prevê situação diferente para programa gerado sem relação com o vínculo e sem utilização dos recursos, informações, segredos, materiais, instalações ou equipamentos ali indicados. A exceção tem requisitos cumulativos que precisam ser examinados; desenvolver fora do horário habitual não resolve isoladamente o enquadramento.

Já o § 3º estende o tratamento do artigo a bolsistas, estagiários e assemelhados. Essas regras reforçam a importância de documentação compatível com a atividade real, em lugar de uma declaração genérica de que “todo código pertence à empresa”.

Empregado, prestador e sócio: organize a cadeia de direitos

No desenvolvimento por empregado, verifique as funções, as instruções, a finalidade do programa e as cláusulas do vínculo. Em uma contratação de serviços, identifique o escopo contratado e se a empresa fornecedora também utiliza empregados, subcontratados ou componentes de outros titulares. O contrato principal não elimina a necessidade de coerência na cadeia de direitos.

Ser sócio não significa, por si só, que toda criação pessoal tenha sido transferida à sociedade. É necessário identificar se houve desenvolvimento dentro de outro vínculo, contribuição de direitos, cessão, licença ou outra disciplina documental. A condição societária, isolada, não substitui esse exame. O objetivo aqui é esclarecer a origem do software, sem confundir participação na empresa com autorização irrestrita de exploração de qualquer criação.

Um inventário simples pode relacionar cada módulo, quem o desenvolveu, em que período, sob qual vínculo e qual documento sustenta seu uso. Essa organização é útil tanto para quem contrata quanto para quem fornece tecnologia, especialmente quando diferentes pessoas trabalham em etapas sucessivas.

Titularidade, licença e cessão têm efeitos diferentes

O art. 9º da Lei de Software disciplina a licença de uso. Ela não deve ser tratada como sinônimo de transferência de titularidade. Autorizar a utilização de um sistema pode atender ao objetivo da contratação sem autorizar sua revenda, sublicença ou exploração como produto próprio.

Quando o negócio envolve cessão, a Lei de Direitos Autorais deve ser lida em conjunto com o regime específico do software. Seus arts. 49 e 50 tratam da transferência de direitos e da formalização escrita da cessão, com delimitação do objeto e das condições. A redação precisa representar a operação efetiva: uma frase sobre “propriedade de tudo” não esclarece componentes excluídos, modalidades de uso ou direitos de terceiros.

Também não se deve prometer transferência indistinta de qualquer direito moral. O art. 2º, § 1º, da Lei de Software contém tratamento específico, preservando as faculdades ali indicadas relativas à autoria e a determinadas alterações prejudiciais. O contrato deve respeitar esse regime.

Receber o repositório não basta para manter o sistema

Um repositório pode conter código sem instruções de instalação, histórico incompleto ou dependências inacessíveis. Para uma entrega tecnicamente utilizável, convém definir os elementos necessários ao projeto:

• código-fonte e histórico acordado, com identificação da versão entregue;
• instruções de instalação, compilação e configuração;
• dependências, versões e licenças aplicáveis;
• documentação das integrações e dos ambientes;
• testes e critérios de aceite previstos no escopo;
• procedimento seguro de transferência ou substituição de credenciais;
• responsabilidades por hospedagem, domínios e serviços externos.

Esses itens são critérios de organização e negociação, não uma lista legal obrigatória igual para todo software. O nível de detalhe depende do produto, do modelo comercial e do que foi contratado. Sistemas licenciados como serviço, por exemplo, podem não incluir entrega do código ao cliente.

Credenciais e segredos não devem ser simplesmente copiados para um arquivo público no repositório. A transição precisa permitir que a contratante assuma os acessos pertinentes sem expor dados de outros clientes ou ambientes do fornecedor.

Componentes preexistentes e bibliotecas de terceiros

Um sistema pode reunir código desenvolvido especificamente para o cliente, ferramentas próprias já existentes, bibliotecas abertas e serviços comerciais. O contrato deve identificar o tratamento de cada camada e evitar a promessa de exclusividade sobre o que o fornecedor não tem poder para transferir.

Software de código aberto não significa ausência de licença. As condições concretas precisam ser lidas para a versão utilizada e para a forma de uso, modificação ou distribuição pretendida. Obrigações de atribuição, avisos e disponibilização de código, quando existentes, não são iguais em todas as licenças. O artigo não atribui obrigações específicas a uma biblioteca que não foi identificada e examinada.

As derivações também merecem atenção. O art. 5º da Lei de Software contém regra sobre derivações autorizadas, ressalvada estipulação contratual em contrário. Diferencie uma evolução do programa existente de uma criação independente e registre a autorização correspondente. O rótulo “customização” não resolve sozinho a titularidade do resultado.

A obrigação de entregar um produto não autoriza incorporar material de terceiros em desacordo com sua licença. Uma cláusula de responsabilidade não substitui o inventário técnico dos componentes.

Registro, manutenção e encerramento

A proteção do programa independe de registro, conforme o art. 2º, § 3º, da Lei de Software. O registro pode compor a estratégia documental, mas não corrige uma contratação mal delimitada nem transforma automaticamente quem registrou em titular legítimo de direitos de terceiros.

Manutenção corretiva, evolução funcional, suporte e hospedagem devem ser separados no escopo. Quem recebe direitos sobre o programa não recebe, por esse único fato, a obrigação de manutenção indefinida por parte do desenvolvedor. Ao mesmo tempo, obrigações contratuais e as regras aplicáveis da Lei de Software, inclusive seus arts. 7º e 8º, precisam ser consideradas na oferta e na validade técnica da versão comercializada.

No encerramento, indique quais licenças continuam, quais serviços cessam, quais materiais serão entregues e como a mudança de prestador ocorrerá. Evite deixar para esse momento a definição sobre acesso ao repositório. A interpretação e a execução devem observar a boa-fé, conforme o art. 422 do Código Civil.

Exemplo hipotético: plataforma encomendada com módulos anteriores

Imagine que uma empresa contrate uma plataforma de gestão. O fornecedor desenvolve telas e integrações específicas, mas utiliza um módulo próprio criado antes do contrato e bibliotecas de terceiros. O pagamento do projeto não permite concluir, sem análise, que todas essas camadas foram cedidas com exclusividade.

É necessário distinguir o desenvolvimento encomendado, o componente anterior, a licença necessária para continuar usando o produto e as condições dos terceiros. Também importa saber se a contratante pode contratar manutenção com outro profissional e se receberá material técnico suficiente para isso. Uma descrição detalhada dessas entregas reduz a distância entre expectativa comercial e capacidade real de continuidade.

Checklist antes de contratar ou receber o software

• O escopo distingue criação nova, componente anterior e terceiro?
• A titularidade foi analisada conforme o art. 4º e os vínculos reais?
• Licenças e eventual cessão têm alcance compreensível?
• Direitos de subcontratados e demais participantes foram verificados?
• O repositório e a documentação integram as entregas, quando negociados?
• Dependências e licenças estão identificadas por versão?
• Manutenção, suporte e transição têm limites definidos?
• A versão aceita e os materiais entregues serão registrados?

Para contextualizar esse trabalho, veja o guia de documentos jurídicos para empresas digitais e a distinção entre termos de uso e política de privacidade.

Serviço relacionado e aviso informativo

A estruturação de contratos digitais pode alinhar direitos, entregas e continuidade técnica. Este artigo é informativo e não determina a titularidade de um código específico. Essa conclusão depende dos documentos, dos componentes e dos vínculos envolvidos. O contexto de uma contratação pode ser apresentado pelo canal de contato.

Referências oficiais

• Lei nº 9.609/1998 — proteção e comercialização de programas de computador.
• Lei nº 9.610/1998 — transferência de direitos autorais.
• Código Civil — interpretação e boa-fé contratual.