Código-fonte é seu? O que o contrato de software deve dizer

A empresa pagou pelo desenvolvimento, usa o sistema todos os dias e considera o software um ativo. Um dia a relação com o fornecedor termina, e a pergunta aparece: onde está o código? Às vezes a resposta é "no repositório da software house", "na conta de nuvem que está no CNPJ dela" ou, pior, "no computador do desenvolvedor que saiu".

Ter pago pelo trabalho não resolve essa pergunta sozinho. Este texto é escrito do ponto de vista técnico, por quem desenvolve software, e não substitui orientação jurídica. O objetivo é que você chegue à revisão do contrato sabendo o que perguntar e quais entregáveis exigir para conseguir, se precisar, trocar de fornecedor sem perder o sistema.

Pagar pelo software não garante ser dono do código

Existem, na prática, três coisas diferentes que costumam ser confundidas:

• O direito de usar o sistema, que é o que uma licença garante.
• Os direitos patrimoniais sobre o código, que permitem modificar, contratar outra empresa para evoluir, revender ou incorporar a outro produto.
• A posse efetiva do código e do ambiente: ter o repositório, as credenciais, a infraestrutura e o conhecimento para continuar operando.

Um contrato pode garantir a primeira e deixar as outras duas indefinidas. E mesmo quando os direitos estão bem escritos, eles valem pouco se o código está numa conta que você não controla e ninguém sabe como colocar o sistema no ar.

O objetivo do contrato e da operação é garantir as três, ou deixar explícito, por decisão consciente, qual delas a empresa não vai ter.

A Lei do Software e a cessão de direitos, em linhas gerais

No Brasil, o programa de computador é protegido pela Lei 9.609/1998, a Lei do Software, que aplica a ele o regime de proteção dos direitos autorais da Lei 9.610/1998, com as adaptações que ela própria define. A proteção existe independentemente de registro; o registro no INPI é facultativo, mas pode ser útil como prova de autoria e data.

O art. 4º da Lei do Software estabelece que, salvo estipulação em contrário, pertencem exclusivamente ao empregador ou ao contratante de serviços os direitos sobre o programa desenvolvido durante a vigência do contrato, quando esse contrato é expressamente destinado à pesquisa e desenvolvimento, ou quando a atividade do contratado prevê ou decorre da natureza desse desenvolvimento.

Parece resolver tudo, mas há nuances que justificam não depender só da lei:

• A regra vale "salvo estipulação em contrário": o próprio contrato pode dispor de outro modo, e contratos padrão de fornecedores às vezes dispõem.
• Ela depende de o contrato ser, de fato, destinado ao desenvolvimento do programa. Contratos genéricos de "prestação de serviços de tecnologia" ou de licença com customização deixam margem para discussão.
• A legislação de direitos autorais manda interpretar restritivamente os negócios sobre esses direitos. O que não está escrito tende a não ser presumido a seu favor.
• O fornecedor pode ter usado componentes que já existiam antes do projeto, e esses não se tornam automaticamente seus.

Por isso a recomendação prática é uma cláusula de cessão de direitos patrimoniais explícita, por escrito, identificando o que é cedido (código-fonte, código-objeto, documentação, modelos de dados, artefatos de design), em que abrangência e a partir de quando. Se a cessão ocorre na entrega, no pagamento de cada fase ou ao final, isso também precisa estar escrito. Peça que um advogado com experiência em tecnologia revise o contrato: os detalhes de redação e as consequências de cada escolha são trabalho jurídico.

Repositório, nuvem e domínios no nome da empresa desde o início

Direito no papel sem posse do ambiente gera uma disputa, não uma transição. A forma mais eficaz de evitar isso é simples e custa quase nada: a empresa é dona das contas desde o primeiro dia, e o fornecedor recebe acesso a elas.

• Repositório de código numa organização em nome da empresa, na plataforma escolhida, com o fornecedor como colaborador. Não uma cópia enviada no fim, mas o repositório onde o trabalho acontece, com o histórico completo.
• Conta de nuvem no CNPJ da empresa, com faturamento e usuário raiz sob controle dela. O fornecedor opera com usuários nominais e permissões delimitadas.
• Domínios e DNS registrados em nome da empresa, com o contato administrativo interno.
• Contas de serviços de terceiros (e-mail transacional, mapas, gateway de pagamento, lojas de aplicativos, API oficial do WhatsApp) também no nome da empresa. A publicação de aplicativo na loja, por exemplo, fica vinculada à conta de desenvolvedor de quem publicou.
• Cofre de senhas e segredos acessível à empresa, com as credenciais de produção.

Quando o fornecedor sai, você remove os acessos dele. Não precisa pedir nada de volta.

Bibliotecas de código aberto e licenças de terceiros

Todo software moderno usa bibliotecas de código aberto, e isso é bom: são componentes testados por muita gente. Mas cada biblioteca vem com uma licença, e a cessão de direitos do fornecedor não cobre o que não é dele.

As licenças se dividem, em termos gerais, em dois grupos:

• Permissivas, como MIT, BSD e Apache 2.0, que permitem uso, modificação e distribuição com poucas obrigações, geralmente manter os avisos de direitos autorais e o texto da licença.
• Com copyleft, como a GPL, que em linhas gerais exigem que obras derivadas distribuídas mantenham a mesma licença e disponibilizem o código-fonte. A AGPL estende essa obrigação a sistemas oferecidos a usuários pela rede.

Para um sistema interno, a GPL raramente causa problema prático. Para um produto que você pretende vender, distribuir a clientes ou oferecer como serviço, a escolha de licenças pode afetar o modelo de negócio. O que pedir:

• Inventário de dependências com suas licenças, gerado automaticamente a partir do projeto e entregue junto com o código.
• Compromisso de não incorporar componentes com licenças incompatíveis com o uso pretendido sem aprovação prévia.
• Lista de componentes pagos ou de licença comercial (bibliotecas de relatórios, componentes visuais, SDKs), com quem é o titular da licença. Licença comercial comprada em nome do fornecedor pode não ser transferível.

Componentes que o fornecedor reaproveita

Software houses maduras têm bases de código próprias que aceleram projetos: módulos de autenticação, geradores de relatório, bibliotecas internas de integração. Isso é legítimo e reduz retrabalho. Mas precisa estar claro no contrato, porque o fornecedor normalmente não vai ceder a você a propriedade de algo que usa em todos os clientes.

O arranjo comum e razoável é:

• O que foi desenvolvido especificamente para o projeto é cedido à empresa.
• Os componentes preexistentes do fornecedor permanecem dele, e a empresa recebe uma licença perpétua, irrevogável e sem custo adicional para usar, modificar e manter esses componentes como parte do sistema, inclusive com outro fornecedor.
• Esses componentes são listados no contrato ou num anexo, e o código-fonte deles é entregue junto com o resto.

O que você quer evitar é uma peça central do sistema cujo código só o fornecedor tem e cuja licença termina com o contrato. Essa é a forma mais comum de dependência involuntária.

Documentação e entregáveis de transição

Ter o código não significa conseguir operar o sistema. Quem já precisou assumir um sistema legado sem documentação sabe que o problema raramente é a falta do código; é a falta de tudo em volta dele.

Entregáveis que tornam uma transição possível:

• Instruções para montar o ambiente de desenvolvimento e rodar o sistema do zero, testadas por alguém que não participou do projeto.
• Infraestrutura como código, para recriar o ambiente de produção sem depender da memória de ninguém.
• Pipeline de build e deploy no repositório da empresa, não num servidor do fornecedor.
• Modelo de dados documentado e scripts de migração versionados.
• Registro das decisões de arquitetura, com contexto e motivo.
• Documentação das integrações: com quem o sistema conversa, com quais credenciais e o que acontece quando o outro lado falha.
• Testes automatizados, que funcionam como documentação executável do comportamento esperado.
• Uma cláusula de transição: em caso de término, o fornecedor apoia a passagem de conhecimento para a nova equipe por um período e escopo definidos.

Muitos desses entregáveis nascem num bom discovery de software, que também deve ficar com a empresa mesmo que o desenvolvimento seja feito por outro fornecedor.

Um checklist técnico para revisar antes de assinar

Leve estas perguntas para a conversa com o fornecedor e para a revisão jurídica:

1. Existe cláusula de cessão de direitos patrimoniais explícita, por escrito, dizendo o que é cedido e quando?
2. O repositório, a conta de nuvem, os domínios e as contas de serviços ficam em nome da empresa desde o início?
3. O contrato lista os componentes preexistentes do fornecedor e garante licença perpétua para usá-los e modificá-los?
4. Há compromisso de entregar o inventário de dependências e licenças, e de não usar licenças incompatíveis sem aprovação?
5. Licenças comerciais de terceiros ficam em nome de quem?
6. Quais documentos e artefatos são entregáveis obrigatórios, e em que momento?
7. O que acontece no término do contrato: prazo de entrega de acessos, apoio à transição, destruição das cópias e dos dados em poder do fornecedor?
8. Há cláusula de confidencialidade e de tratamento de dados pessoais coerente com a LGPD, já que o fornecedor provavelmente atua como operador?
9. Se o sistema depende de um produto do fornecedor, o que acontece se ele descontinuar o produto ou encerrar as atividades?

Se o fornecedor resiste a algum desses pontos, não é necessariamente má-fé: pode haver um motivo comercial legítimo. Mas a resposta precisa ser clara antes da assinatura, não descoberta no dia da saída. Esses pontos fazem parte dos critérios que discutimos em como escolher uma software house.

Quando o arranjo pode ser diferente

Nem todo software precisa ser seu. Se você contrata um produto pronto com configuração, a licença de uso é o modelo natural, e o foco do contrato passa a ser portabilidade dos dados, disponibilidade e continuidade. O importante é que a escolha seja consciente e combine com a importância do sistema para o negócio.

Seu sistema, seu repositório

Na Pervian Tech, o repositório, a nuvem e os domínios ficam no nome do cliente desde o primeiro dia, e o código desenvolvido no projeto é cedido a ele, com componentes reaproveitados listados e licenciados de forma perpétua. É a forma como trabalhamos em arquitetura de software: documentação, infraestrutura como código e decisões registradas para que a empresa nunca dependa de uma única pessoa ou fornecedor.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se quiser revisar a situação do seu sistema atual, fale com a gente.