Os cuidados na contratação de software

Atualmente, há uma série de formas de contratação de software, cada uma com suas particularidades. Não há uma única modalidade que seja a mais recomendada, tudo depende do que o contratante está buscando. Nem sempre ser o dono do software é a melhor solução, visto que a tecnologia fica obsoleta muito rápido e há um custo invisível de atualização ao longo do tempo –  não contabilizado por muitos dos clientes. Logo, como saber qual a melhor forma para o seu tipo de necessidade?

Destacamos que no Brasil a proteção de software é feita pela Lei de Direitos Autorais e pela própria Lei de Software, ambas de 1998. Em outros países, como nos EUA, o software é patente, mas no Brasil isso ocorre só em alguns casos. Em uma contratação, um dos principais pontos que devem ser definidos logo de início envolve a questão dos códigos fontes, ou melhor, se há ou não interesse em o Contratante possuir os mesmos. Há de se considerar se isso é um requisito, como ocorre em situações que envolvam a Administração Pública, ou meramente uma cautela, caso ocorra algum problema com o fornecedor. Neste último caso é possível acordar o acesso ao código fonte e não ter de pagar pela propriedade do mesmo, propriamente dita.

Os contratos relacionados a software requerem muita atenção, pois exigem novos tipos de cláusula, uma redação técnica bem detalhada, bem como, muitas vezes, um SLA (acordo de nível de serviço) especialmente nos formatos em que há “aluguel do software” ou “seu pagamento como serviço”. Também gera discussão a questão da exigência de pagamento do valor adicional ou não pelo que se entenda como melhoria. Normalmente não fica bem claro entre as partes a diferença entre o que é customização, melhoria, manutenção e atualização. Isso deve vir em um glossário aplicável ao contrato, para acabar com qualquer dúvida.

Outro ponto polêmico envolve o fato de o software ser feito por encomenda ou não, principalmente quando há uma grande dose de co-autoria do mesmo, ou seja, quando a especificação do contratante é tão detalhada sobre o seu próprio negócio que o resultado traz um software cujas rotinas representam quase que o “segredo do negócio” da empresa-cliente. Nestes casos, deve-se acordar de início se isso poderá ser incorporarado ao software padrão para oferta a outros clientes (novas versões do sistema).

Se a intenção é ter a propriedade do software ao final, o contratante deve exigir que seja feita a cessão de direitos autorais, bem como toda a equipe desenvolvedora que atua no projeto precisa assinar também essa cessão, para evitar qualquer problema no registro junto ao INPI (Instituto Nacional da Propriedade Industrial) ou mesmo, futuramente, no tocante à legitimidade. Usar equipe freelancer, sem registro CLT, ou sem contrato assinado com esse tipo de cláusula é um grande risco.

Em geral, a contratação de software exige que haja uma determinação clara do que será considerado “qualidade”. Isso porque o software é talvez um dos poucos ativos em que há uma elevada dosagem de teste. É comum o mesmo ter falhas que são resolvidas ou melhoradas ao longo do tempo, após já estar instalado no cliente, bem como ser liberado para uso previamente como versão “beta”, em que justamente se prevê a possibilidade de falhas. Há ainda toda uma sorte de situações de conflito com hardwares e outros softwares, bem como problemas de integração, em que a qualidade passa a ser não apenas no sistema em si, mas daquele que o implementa.

Sendo assim, há garantias distintas, bem como há limites de responsabilidade também distintos. Um problema em um software pode gerar um grande dano material para uma empresa, por isso, a questão da responsabilidade civil, quer seja aplicando-se a previsão do Código de Defesa do Consumidor ou do Código Civl (art. 927) deve ser prevista de forma mais objetiva na minuta. Neste item, a questão do nível de serviço é retomada, visto que a indisponibilidade não deve gerar apenas o não pagamento do que seria devido se o serviço estivesse funcionando a contento, mas sim deve gerar uma penalidade pelo dano que isso acarreta a parte.

++++
Uma das questões mais importantes em contratos de software é a sua gestão. Ou seja, grande parte das situações pode ser resolvida ao longo da contratação, se isso estiver bem documentado. Alterações de escopo, cronograma, tudo isso, ocorre muitas vezes em reuniões ao longo do projeto, na execução, após a assinatura do contrato (se o jurídico for rápido, senão ainda é mais comum estar sem contrato assinado). Logo, a formalização das atas de reunião, o detalhamento de atividades por emails trocados, tudo isso é prova válida para determinar responsabilidade das partes.

Quanto mais aderente a melhores práticas de gestão de projetos estiver o processo, mais protegido juridicamente. Deve haver homologação das etapas, pagamento conforme cumprimento de metas, se possível a prática de SLA compensatório.

Por último, devido a uma série de particularidades, é conveniente inserir uma cláusula para uso de mediação e até mesmo arbitragem na solução dos conflitos oriundos de contratos de software, visto que muitas vezes o trâmite tradicional do judiciário poderá não resolver o problema, ao contrário, devido a sua característica de rivalizar as partes (mais do que tentar um acordo) é possível que o dano seja aumentado, até pela demora da própria Justiça. Um mediador ou árbitro aceito de comum acordo entre as partes, em geral, é mais eficaz, mas deve-se ponderar sobre os custos envolvidos neste procedimento.

Modalidades mais comuns de contratação de software:

Compra (Licença perpétua de aquisição) – modelo tradicional, um dos primeiros a ser utilizado por grandes fornecedores vendem seus sistemas para os clientes como um ativo (o contratante tem o direito ao produto para toda vida, excluindo manutenção e atualizações, que são vendidos como serviços com taxas normalmente anuais);   

Software como Serviço (SaaS) –  há cobrança pelo uso, em geral, número de usuários que acessam (não há compra do software nem sua locação). O cliente não precisa ter nada instalado internamente. Normalmente exige pagamento de hosting e de armazenagem de dados junto no preço. Os clientes têm certo receio de se sair do ar fica sem nada;

Licença de uso – direito apenas de uso por máquina instalada (ou por usuário), incluindo atualizações (mas não há manutenção);

Aluguel (ASP) – o software fica hospedado fora da empresa que paga uma taxa fixa (pode ser mensal ou anual);

Licença de manutenção – empresa paga pelas taxas de correções e de manutenção do software adquirido (é comum quando há a compra de software de caixinha – prateleira – depois serem pagas as novas versões – que são os upgrades, mas é opcional);

Open Source – o usuário não pala pela licença inicial, já que o software é livre. É comum a cobrança por manutenção, bem como há restrições no tocante a exploração econômica do mesmo (pode usar mas não pode revender);

Conjunto de licenças (aquisição, uso e manutenção) – é o formato mais usado atualmente no mercado, cliente tem direito ao pacote completo de licença, pagando uma parte (normalmente a customização), tendo licença de uso de outra parte (seria o standard) e manutenção;

Co-source – ocorre em parceria, quando duas empresas se unem e dividem o custo do desenvolvimento, é um trabalho colaborativo entre cliente e fornecedor, a remuneração ocorre por resultado e ambos podem explorar o software (muito comum em desenvolvimento de plataforma de e-business, deve ficar claro se só podem explorar em conjunto ou em separado e como fica se quiserem cancelar o acordo de parceria);

Desenvolvimento com Autofinanciamento – quem paga pelo desenvolvimento é o cliente, não o desenvolvedor, já que nesse modelo a solução é customizada para atender ao interesse do contratante. O cliente é o dono do software, o desenvolvedor não tem direito sobre o mesmo (é o “sob encomenda”);

Acordo de Nível de Serviço (SLA ou ANS) – é tratado como um contrato, visto sua complexidade técnica e é o principal mecanismo de medição das expectativas entre as partes, do cumprimento do que ficou estabelecido. É uma ferramenta de gestão essencial para contratos de tecnologia. Já é exigido nos contratos com a Administração Pública, inclusive pelo próprio TCU.