Desenvolvimento de software: entregar funcionalidade não define titularidade
O contrato de desenvolvimento de software organiza requisitos, metodologia, entregas, aceite, preço, código-fonte, componentes de terceiros, propriedade intelectual, segurança e manutenção. A regra legal sobre direitos do programa deve ser lida junto com o vínculo e a contratação concreta. Pagamento e entrega funcional não resolvem sozinhos titularidade, acesso ao repositório ou continuidade.
“O código é do cliente” parece resolver tudo até o repositório conter bibliotecas próprias do fornecedor, componentes open source e ferramentas que já existiam antes do projeto.
Por Giovanny Maciel, Sócio-fundador
Contrato de desenvolvimento de software precisa separar entrega técnica de titularidade e direito de exploração. Código, bibliotecas, componentes preexistentes, open source, documentação, dados e infraestrutura podem ter origens diferentes. A Lei nº 9.609/1998 contém regras próprias sobre programas de computador, e o contrato deve ser coerente com o modelo de contratação e com quem efetivamente cria o software.
Escopo precisa caber em backlog verificável
“Desenvolver aplicativo conforme necessidades do cliente” não é critério de aceite. Requisitos, histórias, protótipos ou especificações precisam ser versionados. Mudanças entram por processo próprio, com impacto em prazo e preço. Sem isso, cada nova ideia pode ser tratada como obrigação original.
Código novo e código preexistente são patrimônios diferentes
O fornecedor pode reutilizar framework, biblioteca interna, ferramenta e know-how anteriores ao projeto. O cliente, por sua vez, pode exigir titularidade ou licença ampla sobre aquilo que foi criado especificamente para ele. A redação precisa separar essas camadas, em vez de dizer genericamente “todo código pertencerá ao contratante”.
Open source merece inventário: licença, versão e obrigações associadas precisam ser compatíveis com a distribuição pretendida. A licença de software pode ser o instrumento adequado para componentes que não são transferidos.
Entrega inclui conhecimento suficiente para continuidade
Repositório, histórico, documentação, credenciais, pipelines, ambiente e instruções de deploy podem ser tão importantes quanto os arquivos-fonte. Se o cliente recebe apenas um ZIP no final, pode formalmente possuir código e ainda assim não conseguir operar o produto.
Critérios de aceite devem diferenciar bug de mudança de requisito. Defina severidade, correção, período de garantia e suporte posterior quando houver. Isso reduz a tendência de transformar manutenção evolutiva em “correção gratuita”.
O melhor teste é imaginar que a equipe atual deixa o projeto amanhã. Uma nova equipe consegue identificar o que pertence ao cliente, o que é licenciado, como compilar e quais dependências precisam ser mantidas? Se não, o contrato ainda não capturou o ativo que está sendo construído.
Perguntas frequentes
Pagar pelo desenvolvimento significa receber automaticamente todo o código-fonte?
Não se deve presumir. Titularidade, acesso ao código, licença e componentes preexistentes precisam ser tratados expressamente conforme o regime aplicável.
Como tratar bibliotecas open source no projeto?
É recomendável inventariar componentes e licenças e verificar compatibilidade com a forma de uso, modificação e distribuição pretendida.