Código-fonte do sistema ou do aplicativo: de quem é e o que pôr no contrato

A cena se repete com uma frequência que assusta. A empresa encomendou um sistema ou um aplicativo, pagou, usa todo dia, e um dia precisa de uma mudança pequena. O desenvolvedor não responde, a agência fechou, ou o preço do ajuste veio numa conta que não faz sentido. Aí alguém pergunta o óbvio: vamos levar para outro fornecedor. E descobre que não há o que levar.

O código está no computador de quem desenvolveu. O aplicativo está publicado na conta de desenvolvedor da agência. O servidor está no cartão de crédito de um freelancer. A senha do banco de dados nunca foi passada para ninguém. A empresa pagou pelo sistema, mas o que ela tem na mão é só o acesso de usuário, e acesso de usuário pode ser desligado.

Este guia é para quem já tem um sistema ou app rodando, ou está prestes a contratar um: o que precisa estar no nome da empresa, o que a lei diz sobre a propriedade do código, as cláusulas que valem a pena no contrato e como fazer uma conferência rápida hoje, antes que alguém precise dela.

O que é o código-fonte, e por que ele vale mais que o aplicativo instalado

O aplicativo que aparece no celular, ou o sistema que abre no navegador, é o resultado final. O código-fonte é o conjunto de arquivos de onde esse resultado sai: as instruções escritas pelos programadores, as regras de negócio, as telas, as integrações e a estrutura do banco de dados.

A diferença importa porque só o código-fonte pode ser alterado. Com o aplicativo instalado não dá para corrigir um erro, mudar uma regra de desconto ou adaptar uma tela. É como ter a casa pronta sem a planta: dá para morar, mas qualquer reforma vira adivinhação.

Por isso a pergunta certa nunca é só "o sistema funciona?". É também "se o fornecedor sumir amanhã, outra equipe consegue continuar daqui?". A resposta depende de a empresa ter, ou não, o código e tudo o que está em volta dele.

O que a lei diz sobre quem é dono

No Brasil, programa de computador é regulado pela Lei 9.609/1998, a Lei do Software. O artigo 4 diz que, salvo estipulação em contrário, os direitos sobre o programa desenvolvido durante um contrato pertencem ao contratante quando a atividade do contratado era justamente desenvolver aquele programa.

Parece resolver, mas o detalhe está nas três primeiras palavras. "Salvo estipulação em contrário" quer dizer que o contrato pode dispor de outro jeito, e muitos contratos de desenvolvimento dispõem. É comum encontrar cláusulas em que a agência mantém a propriedade do código e concede à empresa apenas uma licença de uso, às vezes atrelada à mensalidade.

Nada disso é ilegal nem necessariamente ruim. Há casos em que a licença faz todo sentido, como veremos adiante. O problema é quando a empresa assina achando que está comprando e na verdade está alugando. Leia a cláusula de propriedade intelectual antes de assinar, e em contratos grandes vale passar por um advogado: este texto explica o terreno, não substitui orientação jurídica.

Ser dono do código não basta: o que precisa estar no nome da empresa

Mesmo com o contrato perfeito, a empresa pode ficar refém se tudo o que está em volta do código estiver no nome de outra pessoa. Um sistema ou aplicativo moderno é feito de várias peças, e cada uma tem um titular.

• O repositório. O lugar onde o código fica guardado, com o histórico de cada alteração, geralmente em serviços como GitHub, GitLab ou Bitbucket. Deve estar numa conta ou organização da empresa, com o fornecedor como colaborador convidado.
• O domínio. O endereço onde o sistema roda, como sistema.suaempresa.com.br, precisa estar num domínio registrado no CNPJ da empresa, e não do fornecedor.
• A hospedagem. O servidor ou a nuvem onde o sistema funciona. Se a conta for do fornecedor, a empresa não tem como tirar uma cópia, restaurar backup ou mudar de lugar sem pedir licença.
• O banco de dados. É onde estão os clientes, os pedidos e o histórico. A empresa precisa ter acesso de administrador, ou no mínimo um backup completo regular entregue a ela.
• As contas de serviços externos. Envio de e-mail, SMS, mapas, gateway de pagamento, notificações. Cada integração tem uma conta e uma chave, e todas devem estar no nome da empresa.

A lógica é a mesma do e-mail de funcionário que sai da empresa: o que é da operação precisa estar em conta da empresa, com o acesso das pessoas concedido e revogado por ela. Quando a conta é pessoal, ela vai embora junto com a pessoa.

O caso dos aplicativos: a conta na loja é o ponto mais esquecido

Aplicativo de celular tem uma camada a mais, e é nela que acontece a maior parte das surpresas. Para aparecer na App Store e no Google Play, o app precisa ser publicado por uma conta de desenvolvedor, e o dono dessa conta é o dono do app na loja.

Se a agência publicou o aplicativo na conta dela, é o nome dela que aparece como desenvolvedor, são as avaliações dela, e é ela quem decide sobre atualizações. Transferir um app entre contas é possível nas duas lojas, mas depende de quem está com a conta atual concordar e executar o processo. Com fornecedor que sumiu, isso não acontece.

O caminho é a empresa criar as próprias contas desde o começo:

• Apple Developer Program, com anuidade de US$ 99, em nome da empresa. A conta de organização pede o número D-U-N-S, um cadastro gratuito que pode levar alguns dias para sair, então vale pedir cedo.
• Google Play Console, com taxa única de US$ 25, também como organização, com verificação dos dados da empresa.

Depois de criadas, a empresa convida o fornecedor como membro da equipe, com permissão para publicar. Ele trabalha normalmente, e se a relação acabar, basta remover o acesso. O app, as avaliações e os downloads continuam onde estavam.

Esse cuidado pesa no custo de manter um aplicativo, porque as lojas exigem atualizações periódicas para acompanhar novas versões do sistema operacional. App que ninguém consegue atualizar acaba saindo da loja, mesmo sem ninguém ter tomado essa decisão. Se a empresa ainda está decidindo o formato, vale ler também sobre aplicativo ou site que instala no celular, que dispensa a loja e boa parte dessa burocracia.

Sinais de que a empresa não controla o próprio sistema

Nem sempre é fácil perceber a dependência enquanto tudo funciona. Alguns sinais aparecem antes do problema:

1. Ninguém na empresa sabe onde o sistema está hospedado. Nem o nome do serviço, nem de quem é a conta.
2. A fatura do servidor não chega para a empresa. Ela está embutida na mensalidade do fornecedor, sem detalhamento.
3. Pedir um backup completo do banco de dados gera resistência, demora ou vem com cobrança à parte.
4. O aplicativo aparece nas lojas com o nome da agência como desenvolvedora.
5. Só uma pessoa do fornecedor mexe no sistema, e quando ela está de férias, nada anda.
6. Não existe documentação, nem mesmo um arquivo explicando como instalar o sistema do zero.

Dois ou três desses sinais não significam que o fornecedor esteja agindo de má-fé. Muitas vezes é só falta de processo. Mas significam que a empresa está exposta, e que a conversa sobre isso fica muito mais fácil enquanto a relação está boa.

Licença de uso também pode ser uma boa escolha

Vale o contraponto, porque nem todo sistema precisa ter o código entregue. Existem dois modelos diferentes, e cada um tem seu lugar.

Sistema sob medida

Feito para a empresa, com as regras dela. Aqui a empresa deveria ter a propriedade do código, ou no mínimo acesso garantido a ele, porque ninguém mais no mundo usa aquele sistema. Se o fornecedor desaparece, não há alternativa pronta no mercado para migrar.

Plataforma pronta com personalização

Um produto que o fornecedor vende para muitos clientes, configurado para cada um. Aqui a licença é natural: o fornecedor não pode entregar o código de um produto que atende outras empresas. A proteção da empresa, nesse caso, está em outro lugar:

• Exportação completa dos dados, a qualquer momento, em formato aberto como planilha ou CSV.
• Domínio próprio, para que clientes e links continuem funcionando se a empresa trocar de plataforma.
• Prazo de aviso antes de encerramento do serviço ou mudança de preço.

O erro não é escolher licença. É pagar preço de sob medida e receber condições de plataforma, ou achar que está num modelo quando o contrato diz outro.

As cláusulas que valem a pena no contrato

Antes de assinar, ou ao renovar, confira se o contrato responde estas perguntas por escrito:

• Propriedade intelectual: o código desenvolvido pertence à empresa contratante, ou ela recebe licença? Se for licença, ela é perpétua ou depende da mensalidade?
• Entrega do código: o código é entregue ao final de cada etapa, com acesso ao repositório, ou só no fim do projeto?
• Componentes de terceiros: quais bibliotecas ou módulos do próprio fornecedor ficam dentro do sistema e sob qual licença? É comum a agência reutilizar partes próprias em vários projetos.
• Contas e acessos: domínio, hospedagem, banco de dados, lojas de aplicativo e serviços externos ficam em nome de quem?
• Documentação mínima: como instalar, como publicar uma atualização e quais são as integrações. Não precisa ser um livro, mas precisa existir.
• Saída: se o contrato acabar, em quanto tempo o fornecedor entrega tudo e com qual suporte de transição?

Em projetos maiores, existe ainda o depósito do código-fonte com terceiro, conhecido como escrow: uma cópia atualizada fica guardada com uma entidade neutra e é liberada para a empresa em situações definidas, como falência do fornecedor. Para a maioria das pequenas e médias empresas, porém, o repositório na conta da própria empresa resolve o mesmo problema de um jeito mais simples e barato.

Como fazer a conferência hoje

Se a empresa já tem um sistema ou app em uso, dá para descobrir em uma tarde onde ela está. Faça a lista abaixo e preencha com nomes e contas reais:

1. Domínio: em nome de qual CNPJ ou CPF está registrado?
2. Hospedagem: qual serviço, e quem recebe a fatura?
3. Repositório: onde está o código, e a empresa tem acesso de leitura, pelo menos?
4. Banco de dados: quando foi o último backup completo que a empresa recebeu ou conseguiu baixar?
5. Lojas de aplicativo: qual nome aparece como desenvolvedor?
6. Serviços externos: e-mail transacional, pagamento, mapas e notificações estão em qual conta?

Com a lista pronta, a conversa com o fornecedor fica objetiva: o que está fora do nome da empresa passa para ela, com o fornecedor mantido como colaborador. Fornecedor sério costuma receber esse pedido bem, porque ele também ganha clareza sobre o que é responsabilidade de quem. Se a lista mostrar um sistema que ainda roda em planilha disfarçada, vale ler sobre a planilha que virou sistema da empresa antes de contratar o próximo passo.

O mesmo raciocínio vale para site, e-mail e redes

O sistema interno e o aplicativo são só a parte mais cara de um princípio que vale para toda a presença digital. Site hospedado em conta de terceiro, e-mail em domínio emprestado, perfil de rede social sem recuperação: todos têm o mesmo ponto fraco, e o texto sobre a conta do Instagram bloqueada mostra como isso aparece no dia a dia.

A presença digital da empresa tem que ser dela. Domínio, site, e-mail e sistema sob controle próprio, com fornecedores trabalhando dentro das contas da empresa, e não a empresa trabalhando dentro das contas dos fornecedores. Uma boa parceria técnica não depende de prender o cliente, e a hospedagem com backup que a própria empresa consegue restaurar é parte disso.

Por onde começar

Pegue o sistema ou aplicativo mais importante da empresa e faça a conferência da lista acima esta semana. Se algum item estiver no nome de outra pessoa, resolva enquanto a relação com o fornecedor está boa: é uma conversa de meia hora agora e pode virar um projeto inteiro de reconstrução depois.

A NSWeb desenvolve sistemas online e aplicativos sob medida com esse princípio desde o começo: código em repositório da empresa, contas de loja no nome dela, hospedagem com backup e documentação de entrega. Fale com a gente pelo formulário de contato, seja para um projeto novo, seja para conferir onde está o sistema que a sua empresa já usa.

Perguntas frequentes