Este texto é uma abordagem dos aspectos contratuais nos projectos de implementação de pacotes de software, do ponto de vista dos negócios e escamoteando, deliberadamente, os aspectos jurídicos e a minúcia das cláusulas.

A pertinência desta questão radica no facto de serem os contratos os instrumentos com que se tenta evitar a disparidade de expectativas dos intervenientes nos negócios; as expectativas inadequadas, ou divergentes, estão entre as principais causas de insucesso e insatisfação (ver o artigo “gerir as expectativas para ter sucesso na implementação dos pacotes de software” publicado em aspetus.com).

Antes de prosseguir convém estabelecer algumas ideias-chave para que esta abordagem não se desligue dos ensinamentos da realidade prática:

1. São raras as situações em que os problemas na execução dos contratos resultam de má-fé de uma ou de ambas as partes.

2. Os contratos são como os seguros; têm que existir mas todos desejam não ter que os invocar já que tal significaria que os riscos temidos se tinham realizado.

3. É muito pouco provável que os contratos sejam a solução para os problemas surgidos durante a execução de um projecto de implementação de pacotes de software. A morosidade do nosso sistema judicial não permite solucionar questões que, pela sua própria natureza, exigem uma resposta em tempo útil. Por isso os contratos constituem apenas um elemento, entre outros, no equilíbrio das relações entre o fornecedor e o cliente.

4. A intervenção dos advogados nos contratos deve ser pedida no momento certo e com objectivos claros. Ao contrário do que costuma acontecer os advogados devem intervir depois das partes terem feito o negócio que se propôem, e que só elas podem determinar. A contribuição técnica dos advogados, muito valiosa, deve consistir em validar os termos em que o contrato se pretende expressar.

5. Um contrato é sempre uma troca entre as partes por isso é fundamental ter uma clara noção daquilo que constitui objecto da referida troca por parte de cada um dos intervenientes ao longo da execução do contrato.

Depois destas questões prévias podemos então avançar para uma análise do enquadramento contratual típico nos projectos de implementação de pacotes de software. Independentemente das designações usadas (como se sabe a caracterização de um contrato pelos tribunais não depende do nome que lhe foi atribuído pelas partes), e do número dos contratos, as relações contratuais compreendem as seguintes componentes:

1. Licença de utilização do pacote de software

2. Manutenção do pacote de software

3. Serviços de implementação

4. Garantias de nível de serviço (associado ao modo ASP)

Vejamos então o que deve ser tido em conta em cada uma destas componentes:

1 - Licença de utilização do pacote de software

Trata-se de um contrato em que o detentor da propriedade intelectual do software, ou um seu representante, autoriza os colaboradores de uma determinada organização a utilizarem o referido software em troca do pagamento de um determinado valor. Tal valor costuma ser dependente do número de utilizadores mas não é essencial que assim seja. O pagamento também pode ter variantes quanto ao momento em que ocorre, podendo ocorrer integralmente no momento do contrato ou ser distribuído ao longo do período de utilização, por exemplo.

Antes de mais, é importante notar que estamos perante a aquisição de um direito de utilização e, portanto, o comprador não se torna proprietário do produto. Por outro lado convém ter a noção de que o software é um produto “industrial”, como um automóvel, e por isso é comprado de acordo com as especificações publicadas. 

Como todos sabemos é impossível testar um carro, antes de o comprar, em todas as situações possíveis, ou verificar que todas as peças estão nos sítios adequados desmanchando, por exemplo, o motor. Com o software seria ainda mais impensável tentar testar todas as suas funcionalidades em todas as circunstâncias imagináveis, dada a enorme dimensão e complexidade de tais produtos. Num caso e noutro o comprador compra na expectativa de que o produto, produzido industrialmente, tenha as características mencionadas nas especificações e se comporte de acordo com os padrões conhecidos em milhares, ou milhões, de produtos da mesma marca e modelo. 

Outra especificidade deste negócio é que o produto, embora industrial, “não se vê” no sentido em que aquilo que se vê é o suporte, um disco ou uma diskette, mas não o produto em si que consiste em “bits e bytes” gravados em tal suporte, o que não ajuda muito. 

As coisas complicam-se quase sempre quando os contratos apresentados pelo fornecedor ao seu cliente obedecem a uma normalização internacional, muitas vezes baseada em filosofia jurídica diferente da nossa. Na medida em que o fornecedor está, através do contrato, a proteger um património vital, a propriedade intelectual do software, os contratos contêm muitas cláusulas que incomodam ou causam perplexidade ao comprador, no caso de este ser alheio a essa problemática a nível internacional, o que o leva a considerar certas disposições como absurdas ou inaplicáveis.

Se não houver algum bom senso, se se quiser esmiuçar os clausulados até à última vírgula, pode muito bem acontecer que se torne impossível concluir o negócio. Os riscos que se correm ao aceitar contratos normalizados pelo fornecedor para licenciar o software não são significativos desde que um advogado, familiarizado com o tema, faça uma reflexão sobre alguma situação mais inadequada à legislação portuguesa.

(página 1 de 3)