A resposta curta
Na maioria dos casos, quando o desenvolvimento do sistema é o próprio objeto do contrato, a lei brasileira do software tende a colocar os direitos com quem contratou. Essa regra vale salvo estipulação em contrário, então quem decide de verdade é o contrato, e ele precisa dizer isso por escrito.
Ter o direito no papel também não basta. Na prática, o software só é seu quando você tem o código em um repositório sob o seu controle, a documentação para outra equipe entender o sistema e os acessos à infraestrutura onde ele roda. Este texto é um guia prático, não um parecer jurídico: revise o contrato com um advogado de sua confiança.
O que a Lei 9.609/1998 diz sobre a propriedade do software
A Lei 9.609/1998, conhecida como lei do software, trata o programa de computador como obra protegida pelo regime de direito autoral. A proteção existe independentemente de registro. O registro no INPI é opcional e serve como prova de autoria e de data, não como condição para ter o direito.
Para o caso que interessa aqui, a lei traz uma regra de partida: salvo estipulação em contrário, os direitos sobre o programa desenvolvido durante um contrato de prestação de serviços cuja finalidade é justamente esse desenvolvimento pertencem a quem contratou. A mesma lógica vale para o empregador em relação ao empregado contratado para desenvolver software.
O ponto que mais gera conflito está na expressão "salvo estipulação em contrário". O contrato pode dispor de outro jeito, e muitos dispõem, às vezes em uma cláusula genérica que ninguém leu com atenção. Também há zonas cinzentas que a regra geral não resolve sozinha: ferramentas e componentes que o fornecedor já tinha antes do projeto, bibliotecas de terceiros e produtos próprios do fornecedor que foram adaptados para você.
Cessão ou licença: qual a diferença na prática
Quase todo contrato de software cai em um de dois modelos, ou numa combinação deles. Na cessão, os direitos patrimoniais sobre o código passam para você. Na licença, o fornecedor continua dono e autoriza o uso, dentro das condições que o contrato fixar.
| Ponto | Cessão de direitos | Licença de uso |
|---|---|---|
| Quem fica com o código | Você, como titular dos direitos patrimoniais | O fornecedor, que autoriza o uso |
| Acesso ao código-fonte | Entregue a você, com o histórico de versões | Depende do contrato; muitas vezes não é entregue |
| Trocar de fornecedor | Outra equipe pode assumir o sistema | Exige negociar com o fornecedor ou recomeçar |
| Quando costuma fazer sentido | Sistema feito para a sua operação, que você quer evoluir com liberdade | Produto que o fornecedor vende para vários clientes |
| O que conferir no contrato | Escopo da cessão e o que fica de fora, como componentes prévios | Prazo, usuários, atualizações, suporte e o que acontece se o contrato acabar |
Nenhum dos dois é errado em si. Licenciar um produto pronto pode ser a melhor escolha quando o processo é padrão, como discutimos em software pronto ou sob medida. O problema aparece quando você paga por um sistema feito para a sua operação e descobre, no fim, que só ganhou o direito de usar.
Um arranjo comum e razoável é a combinação: você recebe a cessão do que foi construído para o seu projeto e uma licença permanente e gratuita para usar os componentes que o fornecedor já tinha e reaproveita em outros clientes. O importante é que isso esteja escrito, com a lista do que é cada coisa.
O que o contrato de desenvolvimento precisa dizer
Antes de assinar, confira se o contrato responde a estas perguntas sem deixar margem para interpretação:
- Quem é o titular do código. A cláusula precisa dizer se há cessão dos direitos patrimoniais, a partir de quando ela vale (na entrega, a cada pagamento ou ao final) e se abrange também documentação, design e banco de dados.
- O que fica de fora. Componentes que o fornecedor já tinha, bibliotecas de terceiros e produtos próprios devem estar listados, com a licença que você recebe para cada um.
- Quando e como o código é entregue. O ideal é o código ficar no seu repositório desde o começo, e não ser entregue de uma vez só no encerramento.
- O que acontece no fim do contrato. Prazo de transição, apoio para passar o sistema a outra equipe, devolução de acessos e exportação dos dados em formato aberto.
- Confidencialidade e dados. Quem pode acessar os dados da operação, para que finalidade e como isso conversa com a LGPD.
Esses pontos valem para qualquer fornecedor. Quando você ainda está escolhendo quem vai desenvolver, eles entram na lista de perguntas do guia sobre como contratar uma software house.
O que pedir na entrega do sistema
Propriedade que não se exerce não protege ninguém. Se o fornecedor sumir amanhã, a pergunta é simples: outra equipe consegue colocar o sistema no ar, entender o código e continuar o trabalho? Para isso, a entrega precisa incluir:
- Repositório de código. Em uma conta da sua empresa, com o histórico completo de versões, e não um arquivo compactado enviado por e-mail.
- Documentação técnica. Como o sistema está organizado, como instalar, como publicar uma versão nova e quais integrações ele usa.
- Registro de decisões. Por que cada escolha importante foi feita, quais riscos foram aceitos e o que ficou para depois.
- Acessos administrativos. Hospedagem, banco de dados, domínio, e-mail transacional e serviços de terceiros em contas suas, ou com você como administrador.
- Infraestrutura descrita. Quais ambientes existem, como são configurados e onde ficam as cópias de segurança.
- Credenciais e chaves. Guardadas em um cofre de senhas sob o seu controle, com a lista do que cada uma faz.
No nosso método de trabalho, decisões, critérios de aceite, versões e riscos ficam documentados ao longo do projeto, e não só no final. É isso que faz o conhecimento do sistema não depender da memória de ninguém, nem da nossa.
Bibliotecas de terceiros e código aberto
Nenhum sistema moderno é escrito do zero. Frameworks, bibliotecas e componentes de código aberto fazem parte de quase todo projeto, e isso é bom: são peças testadas por muita gente. Mas elas não passam a ser suas. Cada uma tem a própria licença, e você recebe o direito de usá-la nos termos dessa licença.
A maior parte das licenças mais usadas, como MIT, BSD e Apache, é permissiva: permite usar e modificar inclusive em software fechado, pedindo basicamente que o aviso de licença seja mantido. Outras, como a família GPL, impõem condições sobre a distribuição do software que as incorpora. Para um sistema que roda só dentro da sua operação, isso costuma ter pouco impacto, mas vale saber quais estão no projeto.
O pedido razoável ao fornecedor é uma lista das dependências principais com as respectivas licenças, e o compromisso de não incluir componentes cuja licença conflite com o uso que você pretende dar ao sistema.
Como evitar ficar refém do fornecedor
Ficar refém raramente acontece por má-fé. Acontece por acúmulo: o código fica na conta do fornecedor, a hospedagem está no cartão dele, só uma pessoa sabe publicar uma versão nova e nada disso foi escrito. Quando a relação acaba, ou quando essa pessoa sai, o sistema vira uma caixa-preta.
Algumas práticas simples evitam isso desde o primeiro dia. Abra o repositório e as contas de infraestrutura no nome da sua empresa e dê acesso ao fornecedor, e não o contrário. Peça para ver a documentação em cada entrega, e não só no encerramento. Prefira tecnologias de mercado, com comunidade e profissionais disponíveis, a soluções proprietárias que só o fornecedor domina.
Se você já está nessa situação, com um sistema antigo que ninguém mais entende, o caminho costuma ser uma avaliação técnica antes de qualquer decisão. Falamos disso no guia sobre como modernizar um sistema legado, e é o mesmo cuidado que aplicamos quando assumimos a manutenção de um sistema feito por outra equipe no nosso trabalho de desenvolvimento de software sob medida.