IIFundamentação
II. 1. Tendo presente que o objecto dos recursos é balizado pelas conclusões da motivação apresentada pelo recorrente, não podendo este Tribunal conhecer de matérias nelas não incluídas - a não ser que sejam de conhecimento oficioso - e, que nos recursos se apreciam questões e não razões, bem como, não visam criar decisões sobre matéria nova, sendo o seu âmbito delimitado pelo conteúdo do acto recorrido, então, a questão suscitada no presente é, tão só, a de saber se,
- -recurso da requerente:
- -o ponto 90 contém matéria conclusiva e deve ser tido como não escrito;
- -não obstante, existe erro de julgamento acerca da matéria nele contida;
- -não estão preenchidos dois dos três requisitos cumulativos para que seja possível reconhecer o direito retenção à requerida;
- -existe violação o disposto nos artigos 754.º e 756.º CCivil; - recurso da requerida:
- -saber se a decisão recorrida é nula; - existem erros de julgamento;
- -inexiste a obrigação de entrega de toda a documentação técnica, como foi ordenado;
- -inexiste o requisito da necessidade da mesma entrega;
- -se é caso de aplicação a sanção pecuniária compulsória;
- -em caso afirmativo, se o seu montante diário deve ser reduzido.
II. 2. Vejamos, para começar, no entanto, os fundamentos da decisão recorrida.
II. 2. 1. De facto
Factos indiciariamente provados.
- 1)A Requerente é uma sociedade, de direito angolano, que se dedica à prestação de serviços associados à conceção, desenvolvimento, implementação, assistência, formação e comercialização de Plataformas e Sistemas Informáticos, Portais, Sites Web, bem como a representação de aplicações informáticas e ainda a importação de Data Centers, Equipamentos ou Terminais informáticos conexos. A prestação de serviços de formação profissional, assistência técnica, consultoria e/ou assessoria informática e outras atividades conexas, complementares ou afins;
- 2)A Requerida é uma sociedade de direito português, que se dedica a consultoria e programação informática nacional e internacional e atividades relacionadas. Conceção, desenvolvimento, implementação e gestão de projeto tecnológicos nacionais e internacionais. Comércio por grosso, a retalho, importação e exportação de software e hardware. Formação;
- 3)A Requerente, no dia 7 de Julho de 2014, celebrou com a Requerida um acordo-quadro para a prestação de serviços de desenvolvimento de software, de suporte e assistência técnica;
- 4)Nos termos da cláusula segunda n.º 2 do aludido acordo “Os serviços descritos relacionam-se com os contratos que a Contratante tem em curso com terceiros seus Clientes Grupo G..., Secretariado do Conselho de Ministros, Imprensa Nacional EP, MINJUDH, MININT, EMGFAA entre outros;
- 5)No âmbito do supra referido acordo e dos seus desenvolvimentos, a Requerida desenvolveu e implementou para a Requerente os seguintes programas informáticos:
- a)Plataforma C... para o cliente da Requerente G..., em funcionamento, à data da celebração do acordo na Direção de Economia das Concessões (DEC) da G... e que, em 2019, passaria a integrar a Agência Nacional de Petróleo, Gás e Biocombustíveis (ANPG) nos termos do diploma legal que criou a Agência Nacional de Petróleo, Gás e Biocombustíveis e aprovou o seu estatuto orgânico – Decreto Presidencial n.º 49/19, de 06 de Fevereiro, publicado no Diário da República de Angola, I Série, n.º 015 de 06.02.2019;
- b)Plataforma D... para o cliente da Requerente Serviço Penitenciário do Ministério do Interior – Estabelecimentos Prisionais de Viana, Luanda;
- c)Plataforma E... para o cliente da Requerente G... e respetivos núcleos jurídicos do Grupo G...;
- d)F... que é a plataforma base documental das plataformas C..., D... e E...;
- 6)Programas estes que foram sendo desenvolvidos de acordo com as especificações e requisitos que a Requerente indicou à Requerida;
- 7)Sendo tais programas evolutivos, isto é, os mesmos foram evoluindo de acordo com as necessidades comerciais acordadas pela Requerente junto dos seus clientes;
- 8)Nos termos da cláusula 16ª n.º 1 do supra mencionado acordo “As contraentes obrigam-se a manter sob estrita confidencialidade e por tempo indeterminado quaisquer informações que, na execução do presente Contrato, obtenham acerca do outro, salvo se for dado o respetivo consentimento à divulgação daquelas ou se tais informações se tornarem do domínio público através de publicações ou de qualquer outro meio de divulgação informativa e, ainda assim, desde que tal não constitua violação da obrigação de confidencialidade aqui estabelecida”;
- 9)Mais estabeleceram no n.º 3 da referida cláusula que “O Prestador de Serviços está impossibilitado de contactar os Clientes Finais da Primeira Contraente e de corresponder diretamente a solicitações destes, sem prévia comunicação e autorização expressa da primeira Contraente ou por esta acompanhado ou assistido”;
- 10)Estabeleceram ainda as partes, na cláusula 18ª que “O uso indevido de desenvolvimentos baseados nos projetos adjudicados e pagos por parte da Contratada, sem prévia e expressa autorização da Contratante, que de algum modo criem, no todo ou em parte para terceiros, produtos semelhantes aos contratados pela primeira contraente, implicam o pagamento de uma Cláusula Penal de valor equivalente ao dobro dos valores entretanto liquidados pela primeira contraente;
- 11)No âmbito das funções para que foi contratada, a Requerida adquiriu um profundo conhecimento do modo de funcionamento dos clientes da Requerente;
- 12)Nos termos da cláusula 17º do referido acordo:
- 1.Toda a Documentação Técnica identificada caso a caso e o Código Fonte produzidos e relacionados com o desenvolvimento de software adjudicado por Adenda Contratual, serão propriedade da Contratante, devendo as respetivas versões ser entregues depois da aceitação provisória e antes da aceitação definitiva dos projetos correspondentes;
- 2.Com a declaração de aceitação definitiva ocorre automaticamente a transferência da posse e da propriedade dos elementos fornecidos ao abrigo do contrato para a titularidade da Contratante, incluindo os direitos autorais e outros conexos sobre todas as criações intelectuais abrangidas pelos serviços prestados;
- 3.Pela cessão dos direitos a que alude o número anterior não é devida qualquer contrapartida para além do preço a pagar de acordo com o presente contrato e Planos de trabalhos definidos caso a caso relativos à prestação de serviços de desenvolvimento;
- 4.As demais condições de Propriedade, Direitos conexos, pré-condições com os trabalhos de Desenvolvimento de Software, serão contemplados nos termos e condições específicas de cada Adenda Contratual sempre que tal for o caso;
- 13)A documentação técnica de todos os programas teria de incluir, os seguintes componentes, em suporte físico e digital:
- A)DESCRITIVO FUNCIONAL:
- a)Descrição Funcional do projeto SIGEP / ANI b) Descrição Funcional do projeto C... c) Descrição Funcional do projeto D...
- d)Descrição Funcional do projeto E...
- e)Manual de Troubleshooting do projeto SIGEP / ANI f) Manual de Troubleshooting do projeto C... g) Manual de Troubleshooting do projeto D...
- h)Manual de Troubleshooting do projeto E...; B) APLICAÇÃO E CÓDIGO FONTE:
- a)Código fonte de todos os componentes desenvolvidos, até à última versão em produção, nomeadamente, ..., ..., ..., A..., A....Channel, A....Global, ....Core, ... dos projectos F..., C..., D... e E....
- b)Binários de todos os componentes relativos, até à última versão em produção dos projetos F..., C..., D... e E....
- c)Código fonte dos componentes desenvolvidos, histórico das versões anteriores dos projetos F..., C..., D... e E....
- C)DOCUMENTAÇÃO TÉCNICA:
- a)Manuais de Administração do ambiente de Testes do projeto F... b) Manuais de Administração do ambiente de Testes do projeto C... c) Manuais de Administração do ambiente de Testes do projeto D...
- d)Manuais de Administração do ambiente de Testes do projeto E... e) Manuais de Configuração do ambiente de Testes do projeto F...
- f)Manuais de Configuração do ambiente de Testes do projeto C... g) Manuais de Configuração do ambiente de Testes do projeto D...
- h)Manuais de Configuração do ambiente de Testes do projeto E...
- i)Manuais de Administração do ambiente de Produção do projeto F...
- j)Manuais de Administração do ambiente de Produção do projeto C... k) Manuais de Administração do ambiente de Produção do projeto D...
- l)Manuais de Administração do ambiente de Produção do projeto E... m) Manuais de Configuração do ambiente de Produção do projeto F... n) Manuais de Configuração do ambiente de Produção do projeto C...) Manuais de Configuração do ambiente de Produção do projeto D...
- p)Manuais de Configuração do ambiente de Produção do projeto E...
- q)Manuais de Administração do ambiente de Desenvolvimento do projeto F...
- r)Manuais de Administração do ambiente de Desenvolvimento do projeto C...
- s)Manuais de Administração do ambiente de Desenvolvimento do projeto D...
- t)Manuais de Administração do ambiente de Desenvolvimento do projeto
E...
- u)Manuais de Configuração do ambiente de Desenvolvimento do projeto F...
- v)Manuais de Configuração do ambiente de Desenvolvimento do projeto C...
- w)Manuais de Configuração do ambiente de Desenvolvimento do projeto D...
- x)Manuais de Configuração do ambiente de Desenvolvimento do projeto
E...;
- D)RELEASE NOTES:
- a)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto F...
- b)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto C...
- c)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto D...
- d)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto E...;
- E)HISTÓRICO DOS TICKETS DE SUPORTE:
- a)Histórico dos tickets de suporte e desenvolvimento, que deve incluir o histórico individual de cada ticket desde a abertura do chamado até ao encerramento do mesmo para todas as aplicações em produção (C..., D... e E...);
- F)LICENÇAS:
- a)Chaves e/ou registos de licenciamento de todos os componentes necessários ao correto funcionamento das aplicações em produção em toda a sua amplitude relativos aos projetos F..., C..., D... e E....
- G)MANUAL DO UTILIZADOR:
- a)Manual de Utilizador da aplicação C...;
- b)Manual de Utilizador da aplicação D...;
- c)Manual de Utilizador da aplicação E...;
- H)DOCUMENTAÇÃO DE PROJECTO:
- a)Relatórios de Trabalhos relativos aos projetos F..., C..., D... e E...;
- b)Cronogramas de Atividades relativos aos projetos F..., C..., D... e E...;
- c)Entregáveis das várias fases dos projetos F..., C..., D... e E...
- d)Relatórios Finais relativos aos projetos F..., C..., D... e E...;
- 14)Entre os anos de 2014 e a data de entrada em juízo do presente procedimento cautelar, a Requerida apenas entregou à Requerente, da documentação técnica acima referida, até final de 2016, data em que os desenvolvimentos nas plataformas terminaram, as release notes e os manuais de parametrização;
- 15)Com data de 12 de Abril de 2021, a Requerida, sem o conhecimento da Requerente, remeteu à ANPG – Agência Nacional de Petróleo, Gás e Biocombustíveis, cliente da Requerente, uma missiva, com o seguinte teor:
“… informamos a V.Exas que a B..., Lda deixou de prestar serviços à A..., Lda a partir de 1 de Janeiro de 2021, tendo decidido investir na sua presença direta no mercado angolano, através da criação da sua estrutura local própria.
Neste contexto, manifestamos desde já a nossa inteira disponibilidade para, com a maior brevidade possível, avaliar diretamente com V.Exas. as condições que permitam assegurar a continuidade dos Serviços de Suporte Aplicacional aos vossos Sistemas e Aplicações”;
- 16)Tudo isto, sem que tivesse informado a Requerida, previamente, de qualquer uma destas duas situações;
- 17)O legal representante da Requerida, pela mesma altura, exigiu à Requerente o pagamento da quantia de dois milhões de dólares pelos serviços de transferência de know-how e documentação,
- 18)Com efeito, no dia no dia 30.04.2021, o legal representante da Requerida, remeteu à representante legal da Requerente um email com o seguinte teor: “Não cabe à B... atestar o ownership referido. Pelos nossos serviços de transferência de know-how e documentação, fruto de investimento que a B... fez ao longo de 6 anos do qual não tivemos o devido ressarciamento, e pelo valor desse know-how que é propriedade da B... e faz parte do nosso core business, fixamos em 2 Milhões USD o valor que considerado justo e adequado;
- 19)No dia 17.05.2021, a Requerente interpelou a Requerida, pessoalmente, na sua sede social, através de notificação judicial avulsa, para lhe entregar, no prazo de 48h, a seguinte documentação relativa aos softwares - C..., E..., D...:
▪ Documentação Técnica: Manuais de Configuração;
Ambiente de Testes e Qualificação; Ambiente de Produção;
Manuais de Formação; Manuais de Utilizador;
▪ Documentação de Projeto: Relatórios de Trabalhos; Cronograma de atividades; Relatório Final;
▪ Aplicação e Código Fonte:
Binários de todos os componentes da plataforma; Código Fonte dos componentes desenvolvidos;
- 20)Documentação esta que a Requerida não entregou até à presente data;
- 21)A Requerida, no dia 21.05.2021, comunicou à Requerente que deixava de lhe prestar quaisquer serviços junto dos seus clientes;
- 22)Invocou, para além do mais, a falta de pagamento dos serviços prestados, relativamente às plataformas do MININT em 2019 e do MININT, ANPG e G... em 2020 e 2021, no montante de €350.000,00;
- 23)Tendo ainda comunicado que se recusava a entregar a aludida documentação alegando direito de retenção sobre a mesma, referindo ser-lhe devida a quantia de €252.333,62 pelo desenvolvimento das plataformas;
- 24)Desde o dia 21 de maio de 2021, a Requerida, através da sua atuação omissiva, bloqueou a plataforma D... no cliente da Requerente - Serviço Penitenciário do Ministério do Interior – em funcionamento nos Estabelecimentos Prisionais de Viana;
- 25)A solução denominada D... – Sistema Integrado de Informação do Serviço Penitenciário de Angola, foi concebida de raiz e adequada à realidade da rede penitenciária de Angola e às infraestruturas existentes a nível nacional;
- 26)Conformando-se também com o quadro legislativo e regulamentar vigente em Angola, e aos procedimentos e normas de ação penal e gestão penitenciária em vigor;
- 27)O D... é uma Plataforma Integrada de Informação que incorpora tecnologias de recolha de informação biométrica, biográfica, penal, prisional, digitalização e tramitação documental e processual;
- 28)Bem como a criação de um modelo de estrutura de dados que permite constituir um repositório de informação sobre a população penal, que poderá servir futuramente, ao Serviço Penitenciário em Angola e a todas as entidades que fazem parte e/ou intervêm no Sistema Judiciário e Jurisdicional Angolano (PGR, SIC, PN, Tribunais);
- 29)O D... como Sistema Integrado de Informação do Serviço Penitenciário de Angola está em funcionamento nos dois Estabelecimentos Prisionais de Viana (Luanda), onde foi lançado em 2016, no âmbito de projeto-piloto e suporta todas as atividades operacionais dos Estabelecimentos Prisionais de Viana, em Luanda, relativas à gestão e controlo de reclusos, seja ao nível do respetivo cadastramento/internamento nestes dois estabelecimentos prisionais, como também nas atividades frequentes que implicam a sua movimentação para outros Estabelecimentos da Rede Penitenciária, bem como, de/e para as demais entidades policiais e judiciais (PN, SIC, PGR e Tribunais), consolidando todas as interações decorrentes do processo individual, numa base de dados com um elevado número de indivíduos cadastrados e que, em função da sua dimensão
crescente, assume uma especial relevância no âmbito do combate e controle da criminalidade e de todos os serviços e entidades que, no caso daqueles indivíduos, intervêm no processo penal;
- 30)Por essas razões, tal plataforma é essencial para a gestão dos dois maiores estabelecimentos prisionais de Angola que se situam em Viana, Luanda;
- 31)Perspetivando-se a sua futura expansão a toda a rede penitenciária do país;
- 32)Desde a data supra referida que a plataforma apresenta o seguinte erro: “901
- 33)Erro este que bloqueia todas as funcionalidades da aludida plataforma;
- 34)E que é derivado de um sistema de licenciamento implementado pela Requerida na referida plataforma;
- 35)Esse sistema criou uma rotina informática no programa, rotina esta que ativa ou desativa o mesmo, com base num código de licenciamento;
- 36)Face ao facto da Requerente não ter a documentação técnica da plataforma, na qual se inclui todo o código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida;
- 37)De igual forma, a Requerida não entregou à Requerente o código do licenciamento que lhe permitiria desbloquear as funcionalidades da plataforma D...;
- 38)No dia 25.05.2021, a representante legal da Requerente remeteu um email ao representante legal da Requerida informando-o que a plataforma D... apresentava um erro por alegada falta de licença que impedia a mesma de funcionar, tendo solicitado um prazo máximo de duas horas para que fosse fornecida a informação e dados necessários para a reativação da plataforma D...;
- 39)A Requerida nada fez no sentido de desbloquear ou permitir que fosse desbloqueada a plataforma;
- 40)Com todos os problemas que dai derivam, quer para a Requerente, quer para o cliente desta – Serviço Penitenciário do Ministério do Interior, Estabelecimentos Prisionais de Viana – que se vê impossibilitado de, entre outros, proceder à gestão e controlo de reclusos, seja ao nível do respetivo cadastramento/internamento nestes dois estabelecimentos prisionais como também nas atividades frequentes que implicam a sua movimentação para outros estabelecimentos da rede penitenciária, bem como, de/e para as demais entidades policiais e judiciais;
- 41)Passando todos os registos acima referidos, novamente, a ser efetuados manuscritamente, com todas as ineficiências e os problemas que tal situação atualmente acarreta para os Serviços Prisionais de Viana, dada a impossibilidade de utilizar o sistema informático concebido para isso;
- 42)De igual forma, no dia 1.06.2021, o mesmo problema de licenciamento, fruto da mesma conduta omissiva da Requerida acima referida, foi reportado pela plataforma C..., que corre junto do cliente da A. – Agência Nacional de Petróleo, Gás e Biocombustíveis de Angola;
- 43)Plataforma esta que ficou inoperacional desde essa data;
- 44)O C... é uma Solução Integrada de Gestão de Processos e Documentos que suporta a atividade/core business da Direção de Economia das Concessões (DEC) da Agência Nacional de Petróleo, Gás e Biocombustíveis de Angola – ANPG, constituindo a principal ferramenta e repositório central de todos os processos de gestão e controlo de execução dos contratos de concessão petrolífera a nível nacional;
- 45)Sendo por isso o C... um sistema crítico de suporte ao negócio da ANPG e essencial à gestão de controlo de todas as concessões petrolíferas em Angola;
- 46)A Direção de Economia das Concessões - DEC é o serviço de apoio agrupado da ANPG, que tem a missão de acompanhar a gestão económica das concessões petrolíferas, de forma a defender os interesses do Estado Angolano e na qual está em funcionamento a plataforma C...;
- 47)Desde a data supra referida que a plataforma C... apresenta o seguinte erro: “456 – Erro de configuração” e “272 – Erro de configuração”;
- 48)Erro este que bloqueia todas as funcionalidades da aludida plataforma;
- 49)E que é derivado de um sistema de licenciamento implementado pela Requerida na referida plataforma;
- 50)Esse sistema criou uma rotina informática no programa, rotina esta que ativa ou desativa o mesmo, com base num código de licenciamento;
- 51)Face ao facto da Requerente não ter a documentação técnica da plataforma, na qual se inclui todo o código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida;
- 52)De igual forma, a Requerida não entregou à Requerente o código do licenciamento que lhe permitiria desbloquear as funcionalidades da plataforma C...;
- 53)No dia 1.06.2021, a representante legal da Requerente remeteu um email ao representante legal da Requerida informando-o que a plataforma C... apresentava um erro por alegada falta de licença que impedia a mesma de funcionar, tendo solicitado um prazo máximo de duas horas para que fosse fornecida a informação e dados necessários para a reativação da plataforma C...;
- 54)A Requerida nada fez no sentido de desbloquear ou permitir que fosse desbloqueada a plataforma;
- 55)A mesma situação ocorreu, no dia de 2.06.2021 na plataforma E... – ..., pela mesma atuação omissiva da Requerida;
- 56)O E... - ... é uma solução de gestão e controlo da atividade (Core Business) da Direção de Serviços Jurídicos (DSJ) e constitui a principal ferramenta de gestão de informação jurídica da Direção de Serviços Jurídicos (DSJ) e também o repositório central de todos os processos jurídicos da G... e das suas subsidiárias;
- 57)O E... assenta numa plataforma modular de gestão de processos e documentos (SIGEP);
- 58)A DSJ - Direção dos Serviços Jurídicos e os seus núcleos, existentes em todas as subsidiárias, assentam a sua atividade de tramitação processual na plataforma E..., sendo, como tal, considerada um sistema crítico para a DSJ/G...;
- 59)Neste contexto, o E... é um sistema crítico de suporte ao negócio da DSJ/G...;
- 60)Desde a data referida que a plataforma E... apresenta um erro relativo à falta de licença;
- 61)Erro este que bloqueia todas as funcionalidades da aludida plataforma;
- 62)E que é derivado de um sistema de licenciamento implementado pela Requerida na referida plataforma;
- 63)Esse sistema criou uma rotina informática no programa, rotina esta que ativa ou desativa o mesmo, com base num código de licenciamento;
- 64)Face ao facto da Requerente não ter a documentação técnica da plataforma, na qual se inclui todo o código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida;
- 65)De igual forma, a Requerida não entregou à Requerente o código do licenciamento que lhe permitiria desbloquear as funcionalidades da plataforma E...;
- 66)No dia 2.06.2021, a representante legal da Requerente remeteu um email ao representante legal da Requerida informando-o que a plataforma E... apresentava um erro por alegada falta de licença que impedia a mesma de funcionar, tendo solicitado um prazo máximo de duas horas para que fosse fornecida a informação e dados necessários para a reativação da plataforma E...;
- 67)A Requerida nada fez no sentido de desbloquear ou permitir que fosse desbloqueada a plataforma;
- 68)A plataforma F... é o suporte documental das plataformas C..., D... e E...;
- 69)As plataformas C..., D... e E... não conseguem estar operacionais e funcionais sem a plataforma F...;
- 70)Sendo esta última um sistema crítico das aludidas plataformas;
- 71)Face ao facto de a Requerida não ter entregue à Requerente a documentação técnica da plataforma F..., na qual se incluiu todo o código fonte, esta última vê-se impossibilitada de efetuar a manutenção do aludido sistema informático no sentido de o manter operacional;
- 72)No âmbito da elaboração das plataformas contratadas pela Requerente e da sua manutenção, esta última teve, e poderá ter ainda, acesso às bases de dados que se encontram nessas plataformas C..., D..., E... e F...;
- 73)Bases de dados essas que são propriedade dos clientes da Requerente;
- 74)Bases de dados estas que estão guardadas e acessíveis nas plataformas C..., D..., E... e F...;
- 75)Essas bases de dados têm informação extremamente confidencial e sensível, tal como informação financeira, contratual, registos identificativos pessoais, registos criminais e biométricos de milhares de pessoas, entre outros dados sensíveis;
- 76)Pelo facto da Requerente não ter em seu poder a documentação técnica das plataformas C..., D..., E... e F..., desconhece se existem ou não rotinas informáticas que possam estar a correr em servidores diferentes daqueles dos seus clientes e que impossibilitem o correto acesso e manutenção das referidas plataformas;
- 77)Desconhecendo ainda a Requerente se existirão ou não outras dificuldades, quer ao nível de hardware, quer ao nível de software, que não lhe permitam o total controlo e operacionalidade das plataformas;
- 78)Para além dos serviços identificados no facto 5º, no que se inclui a parametrização das plataformas por forma a condicionar e gerir as suas funcionalidades em função dos interesses dos clientes da Requerente; a Requerida prestou serviços de suporte às aplicações; de manutenção das aplicações e infraestruturas; de desenvolvimento corretivo e evolutivo das mesmas;
- 79)Serviços estes que tinham como objetivo a garantia de disponibilidade e continuidade das plataformas aos clientes da Requerente;
- 80)Para além disso, a Requerida ainda assegurou a gestão do licenciamento das plataformas através da implementação de um motor/aplicação, que é de sua propriedade;
- 81)Este serviço de licenciamento, prestado de forma mensal, tinha como objetivo a renovação das licenças das plataformas junto dos clientes da Requerente;
- 82)Por força da continuidade da prestação de serviços, a Requerida foi procedendo à emissão de faturas parcelares;
- 83)Existe uma grande dificuldade das empresas angolanas em realizarem pagamentos em moeda estrangeira e a entidades estrangeiras;
- 84)Ao longo dos sete anos, a Requerente sempre demonstrou uma enorme dificuldade em proceder ao pagamento dos serviços prestados pela Requerida;
- 85)Sendo que a própria Requerente tinha imensa dificuldade em receber o que era devido pelos seus clientes;
- 86)Em 03.01.2020, o representante legal da Requerida remeteu à representante legal da Requerente um email relativo aos valores da conta corrente no qual refere estarem em dívida, para, além de valores referentes aos serviços prestados até finais de 2016, no valor de € 303.433,62 (Fatura 104/2016), o montante de €190.000,00, relativo ao ano de 2019;
- 87)Em tal email, o representante legal da Requerida referia dificuldades de tesouraria que esta enfrentava, para além da necessidade de manter indicadores económicos que permitissem manter rácios de risco reduzidos junto das entidades bancárias portuguesas, a fim de manter o crédito junto da banca;
- 88)Nesta sequência, a Requerente enviou no dia 11.02.2020 um e-mail no qual refere, entre outros factos, dificuldades em fazer pagamentos em divisa estrangeira e obter recebimentos dos seus clientes;
- 89)A Requerida manifestou, em 2.12.2020, junto da Requerente o esforço que fazia em suportar a dívida que a Requerente ia mantendo;
- 90)A Requerente deve à Requerida valores relativos aos serviços por esta prestados, em montante não concretamente apurado;
- 91)As partes estabeleceram negociações entre si, que se lograram, as quais passavam, para além do mais, pela redução dos valores que a Requerida afirmava estar em dívida;
- 92)Por força do desacordo entre as partes, as licenças, que eram renovadas mês a mês, não foram renovadas;
- 93)E no mês de Maio ou início de Junho, as licenças caducaram, tornando as plataformas inacessíveis;
- 94)Se a Requerente tivesse o código fonte das plataformas, apesar das licenças caducarem, era possível eliminar das mesmas o licenciamento implentado;
- 95)O licenciamento, integrado a pedido da Requerente, tinha por finalidade assegurar o pagamento dos serviços prestados pela Requerente junto dos seus clientes;
- 96)Com efeito, por força dos atrasos nos pagamentos dos seus próprios clientes, a Requerente ameaçava suspender a prestação de serviços, utilizando para tal o licenciamento;
- 97)Chegando mesmo a fazê-lo junto de um seu cliente;
- 98)A Requerente autorizou a importação das bases de dados pela Requerida;
- 99)Ao longo da prestação de serviços nunca existiram cadernos de encargos em sentido próprio;
- 100)Havia um conjunto de requisitos estabelecidos pelo então representante legal da Requerente que definia o que havia sido solicitado;
- 101)Foram entregues à Requerente as release notes e os manuais de parametrização até 2016.
Factos não provados.
- a)Um dos elementos que teria que ser entregue pela Requerida à Requerente, por fazer parte da documentação, era o código fonte do serviço de licenciamento alojado na plataforma AZURE (ucls.azurewebsites.net);
- b)Dos elementos que teriam que ser entregue pela Requerida à Requerente, por estarem incluídos na documentação, faziam parte os manuais de Formação de Formadores das aplicações C..., D... e E... e os manuais de Formação dos Utilizadores das aplicações C..., D... e E...;
- c)Também junto dos demais clientes da Requerente, a Requerida andou verbalmente a transmitir que tinha deixado de prestar serviços à Autora;
- d)Informando-os igualmente que estava disponível para passar a prestar diretamente aos clientes da Requerente os serviços que prestava a esta última;
- e)O representante legal da Requerida exigia o pagamento das quantias a que se alude no facto 17º para que as plataformas informáticas supra referidas não parassem;
- f)A maior parte dos quadros da ANPG estão a trabalhar remotamente e por via da plataforma C...;
- g)Por força do atual estado de pandemia da Covid19, em Angola a grande parte das instituições públicas e privadas estão a funcionar apenas com 50% da sua força laboral e sobretudo em regime não presencial e em teletrabalho;
- h)O E... iria ser objeto de evolução funcional com a integração com demais áreas de negócio e com os sistemas core da G...;
- i)A Requerida geriu o licenciamento quanto à codificação das livrarias e a necessidade de o código fonte integrar aquelas nas plataformas supra identificadas;
- j)A Requerida tem procedido ao armazenamento do código fonte a pedido da Requerente para o que tem de pagar o respetivo licenciamento junto da H...;
- k)Em 3.12.2020, o AA, subscritor do email remetido à representante legal da Requerente, exercia efetivamente funções de diretor executivo da Requerente;
- l)As negociações referidas no facto 91º tinham como única finalidade a liquidação da dívida à Requerida;
- m)O erro ocorrido na plataforma D... nada tem que ver com a gestão do licenciamento – pois que a licença estava válida até ao final do mês de Maio;
- n)Há uma série de razões que poderiam justificar o aparecimento do erro na plataforma D..., mas que só poderia ser identificada após diagnóstico;
- o)Desde o dia 10 de Maio que a Requerida deixou de ter acesso ao canal que possuía para aceder à plataforma D..., donde, o que quer que tenha ocorrido e esteja na origem, nada teve que ver com ação ou omissão da Requerida;
- p)A importação das bases de dados foram apenas e tão só para a produção – aquando da parametrização;
- q)Sendo certo que tal visava permitir a realização dos necessários testes junto dos clientes da Requerente com dados reais, por forma a que aqueles mesmos testes decorressem o mais próximo da realidade;
- r)Sendo que o armazenamento dos dados, permitia depois fazer melhor a gestão dos subsequentes testes;
- s)Sendo certo que a última vez que o fez já foi há mais de ano e meio;
- t)Toda a documentação técnica a que alude a Requerente não existe, nem era suposto que existisse;
- u)Ao longo da prestação de serviços existiram reuniões recorrentes, inicialmente com o Dr. GG e posteriormente com o Eng.º AA, onde se avaliavam as necessidades, com alguma informação a ser remetida de forma não estruturada por parte da Requerente;
- v)Os tickets de suporte foram registados pela Requerente na própria plataforma, onde parte foi diretamente respondida pela Requerida na plataforma ou foi remetida à Requerida por email de forma não estruturada;
- w)O manual de utilizador nunca foi requerido pela Requerente e sempre dependeria da parametrização implementada em cada momento;
- x)Os cronogramas foram já remetidos à Requerente;
Porque tal questão interessa igualmente à decisão do recurso, vejamos, igualmente, o que ali se deixou exarado em termos de fundamentação para suportar aquela decisão sobre a matéria de facto.
No que respeita aos factos que enunciam documentos devidamente identificados, a convicção do tribunal fundou-se no teor dos mesmos, motivo pelo qual nos abstemos aqui de os reproduzir.
A prova dos factos 5º, 7º, 20º, 25º, 26º, 27º, 28º, 29º, 31º, 44º, 53º, 54º, 56º, 57º, 66º, 67º, 68º, 69º e 70º, fundou-se no acordo das partes.
No mais, a convicção do tribunal fundou-se no conjunto da prova produzida, ponderada e valorada de acordo com as regras da experiência comum, considerando-se o teor dos documentos constantes dos autos, concatenados com os depoimentos das testemunhas e o depoimento e declarações de parte prestados, sendo aquele livremente apreciado, na medida em que do mesmo não resultou a confissão de quaisquer factos.
Da prova testemunhal produzida destacou-se, pela sua isenção, imparcialidade e serenidade, o depoimento prestado pela testemunha II, técnico de informática, que trabalhou para a H... em Luanda, a prestar serviços à Requerente desde Maio de 2021 e no sentido de ajudar a desbloquear o acesso às plataformas, que manteve com o casal constituído pelo Dr. GG, entretanto falecido e inicialmente o representante legal da Requerente e ex-marido/companheiro da atual representante legal, e esta, uma relação de amizade, a qual remonta ao início da idealização da plataforma base, e que salvo o período de separação do casal, que se revelou complicado, acompanhou a evolução dos trabalhos.
Pelos mesmos motivos, destacou-se o depoimento da testemunha JJ, consultor na área da informática, que trabalhou para a Requerente entre 2014 a 2017, sendo a sua atividade desenvolvida na área das plataformas aqui em causa, motivo pelo qual demonstrou um profundo conhecimento das mesmas, e que atualmente se encontra igualmente a prestar-lhe apoio, desde Maio de 2021, no sentido de tentar que sejam aquelas desbloqueadas.
A testemunha II referiu que o Dr. GG “desenhou” os requisitos da plataforma base e seus desenvolvimentos até 2016, altura em que o casal se separou.
Referiu que o desenvolvimento das plataformas foi feito à medida e que nasceu com um conjunto de três programadores, contratados pelo Dr. GG.
Porém, como tal solução não produziu os resultados pretendidos, foi desenvolvida pela A..., sendo que toda a plataforma e seus desenvolvimentos veio desenhada a partir dessa génese, após o que passou a Requerida a prestar tais serviços.
Mencionou que na típica atividade de desenvolvimento por encomenda, há um conjunto de elementos que têm que ser entregues ao encomendador, relativamente a cada uma das versões, a fim de lhe permitir, com autonomia e caso assim o pretenda, gerir as plataformas.
Distinguiu com muita clareza a atividade de desenvolvimento e a de suporte, que podem não ser prestados pela mesma entidade, bem como a situação em que no desenvolvimento intervém mais do que uma entidade, recaindo sobre cada uma, relativamente às alterações introduzidas, a obrigação de entrega dos elementos que descreveu, independentemente de assim ter sido acordado.
Quanto à atividade de desenvolvimento e de suporte, referiu quais os elementos que teriam que ser entregues para cada uma delas, os quais são, entre outros, o código fonte desenvolvido, os requisitos funcionais (ou seja, aquilo que foi definido à partida pelo encomendador e que pode ou não tomar a forma de caderno de encargos), os manuais, destacando os de configuração, de administração (que contém a parametrização usada no desenvolvimento da aplicação e que referiu que poderá não existir no caso do técnico que nela esteve envolvido e a conhece mas que, ainda assim, tal manual tem que ser entregue para salvaguardar a intervenção de quem não disponha de tais conhecimentos), o conjunto de ambientes (relacionado com os testes), as release notes (correspondente às alterações que introduzem novas funcionalidades e resolvem problemas), de troubleshooting, os binários, licenciamentos que possam estar a fechar a plataforma (assunto a que infra nos referiremos), a listagem de tickets (respeitantes aos problemas surgidos e forma como foram resolvidos e que poderão servir para aferir do serviço de suporte prestado, da sua qualidade e para analisar futuras alterações a introduzir na aplicação para de vez os resolver), relatórios de gestão (gestão de projeto que acompanha as várias fases).
Descreveu, de forma tecnicamente muito explicita, a função de cada um de tais elementos, destacando obviamente o código fonte, e a importância de cada um deles para que a Requerente possa ultrapassar o problema surgido.
Aliás, não teve dúvidas em afirmar que caso a Requerente tivesse na sua posse tais elementos, a situação surgida teria sido facilmente ultrapassável.
Explicou que o sistema tem implantado um processo de licenciamento, que consiste numa chave de acesso, com processo de validação on line e que mais não é do que um programa de bloqueio das plataformas pelos seus utilizadores, no caso os clientes da Requerente, e que jamais se destinaria a obstaculizar o acesso da própria às mesmas.
Decorreu do seu depoimento que este programa de bloqueio não fazia parte dos serviços de desenvolvimento encomendados, sendo uma ferramenta à parte ou acessória.
Referiu as consequências que o bloqueio está a causar em cada uma das plataformas, a importância extremamente critica destas, e que tais consequências estão a causar prejuízos económicos avultados, quer aos clientes (destacou a G... e a ANPG, quer à própria Requerente, e, ainda, no caso do D... sobre a gestão dos processos dos reclusos.
Mencionou ainda os danos reputacionais que a Requerente está a sofrer e a necessidade que esta teve de contratar uma equipa para tentar solucionar o bloqueio surgido.
Referiu os progressos alcançados por tal equipa, que se resumiram ao acesso aos dados, sem possibilidade da introdução de novos registos, os quais estão manifestamente aquém de tornar as plataformas operacionais.
Esclareceu que a Requerente tem na sua posse as release notes e os manuais de parametrização até 2016.
Porém, referiu que os manuais de parametrização possuídos pela Requerente eram relativos apenas a uma plataforma (salvaguardando que era a ideia que tinha), o que tendo sido melhor explicado pela testemunha JJ, que teve intervenção direta na execução da implementação, afirmando que os manuais em poder da Requerente eram relativos a todas as plataformas, o tribunal acolheu nesta parte, apenas o depoimento desta última testemunha.
A testemunha II referiu que inclusivamente poderá haver elementos que terão que ser entregues mas que se encontrem registados nas próprias plataformas, nomeadamente os tickets, mas como o acesso às mesmas está vedado não é possível chegar a tal conclusão.
Apesar de referir desconhecer quais os valores acordados e pagos pela prestação dos serviços, mencionou que recorreu ao descritivo das faturas para tentar perceber os desenvolvimentos e atividades realizadas mas que estas são tão vagas que se revelaram inconclusivas. Aliás, reforçou que a própria documentação contribuiria de forma decisiva para aferir da correspondência entre os valores que estão a ser exigidos e a sua efetiva prestação.
A testemunha JJ referiu ter um profundo conhecimento das plataformas, por força da atividade desenvolvida, e mencionou que foi o Dr. GG que concebeu a ideia, definindo os seus requisitos e que havia uma espécie de caderno de encargos que consistia numa lista de requisitos funcionais muito detalhado, tendo sido um programa desenvolvido à medida.
Referiu os elementos que neste tipo de projetos são essenciais, habituais e necessários que sejam entregues, de forma exaustiva e com indicação das respetivas utilidades, em termos coincidentes com o depoimento da testemunha supra identificada.
Apesar de mencionar que no caso o manual que contém a parametrização não ter sido necessário, pelo conhecimento profundo que a testemunha tinha das plataformas, certo é que nem por isso teria que deixar de ser entregue para que futuros “operadores” pudessem intervir nas plataformas.
Também esta testemunha não fez referência à necessidade da existência de manuais de formação de formadores.
Assim, com base em tais depoimentos deu-se por não provada a matéria de facto contida na alínea b) do elenco de factos não provados.
Descreveu o historial da génese das plataformas, o seu caráter evolutivo, os seus desenvolvimentos e aplicações, e que os manuais e o código fonte teriam que ser igualmente atualizados segundo as evoluções e alterações introduzidas (o que também foi referido pela testemunha II).
Explicou que as plataformas estão bloqueadas por causa de um mecanismo de licenciamento validado através de um serviço na cloud, que valida a licença que está instalada numa determinada plataforma, afirmando não se recordar quando o mesmo foi implementado e desconhecer o processo de desbloqueio, referindo todavia que será resolúvel rapidamente, desde que a Requerente disponha dos elementos para tal.
Referiu todavia que o mecanismo de licenciamento se destina a proteger a proprietária das plataformas, no caso a Requerente, perante os seus clientes.
Porém, também do seu depoimento não resultou que esse programa de licenciamento resultasse da encomenda da Requerente, o que conjugado com o depoimento da testemunha EE, engenheiro informático da Requerida, responsável pela equipa de suporte, e que afirmou que a solução de licenciamento foi desenvolvida e é propriedade da Requerida, o tribunal deu como prova a alínea a) dos factos não provados.
Descreveu a importância e funções de cada uma das plataformas e as graves consequências advindas da sua inoperacionalidade, quer para os clientes da Requerente e utentes diretos das mesmas, quer para a própria Requerente.
Foi igualmente claro que com o código fonte conseguir-se-ia ultrapassar o bloqueio existente. Porém, neste aspeto, e porque revelou ter maiores conhecimentos técnicos nesta área, acolheu-se apenas o depoimento da testemunha II, que para além do código fonte mencionou a necessidade dos demais documentos elencados na matéria provada.
Mencionou que de todos os elementos que deveriam ter sido entregues pela Requerida apenas possui a Requerente as release notes e os manuais de parametrização até 2016, explicando que os mesmos são necessários sempre que há desenvolvimentos ou evoluções nas plataformas e que estes cessaram em 2016, o que permitiu dar como provado o facto 14º.
Referiu que inexistiam, até à sua saída, manuais de troubleshooting (forma de resolver problemas que são previsíveis que surjam), destacando a sua importância para qualquer pessoa que pretenda operar ou prestar serviços de suporte às plataformas.
Também identificou os avanços conseguidos pela equipa técnica contratada pela Requerente e a sua insuficiência para tornar as plataformas operacionais.
Ainda que com conhecimentos mais limitados, mas muito claro no sentido da falta de documentação que permita ultrapassar o bloqueio existente, por estar igualmente tentar ajudar a Requerente desde Maio de 2021, identificação da documentação e elementos necessários para tal, falta de desenvolvimentos desde finais de 2016/Janeiro de 2017 (sendo que neste caso se acolheu o depoimento da testemunha JJ, que identificou o final do ano de 2016 como correspondendo ao final dos desenvolvimentos) foi acolhido o depoimento da testemunha HH, que esteve em sintonia com os já identificados.
De forma um pouco mais apaixonada, por força de uma maior ligação e envolvimento com a Requerente, por força dos acordos estabelecidos quer pessoalmente, quer através das empresas que representam, mas igualmente elucidativa, depôs sobre os factos que vimos analisando a testemunha DD, cujo depoimento foi acolhido na parte em que corroborou e complementou os depoimentos já mencionados.
Tais depoimentos, por força da sua consistência, permitiram ao tribunal dar como provados os factos 6º (relativo às especificações definidas pela Requerente quanto ao desenvolvimento das plataformas envolvidas), 13º (definição da documentação técnica que teria que ser entregue, independentemente de ter sido ou não requerida ou solicitada, por ser inerente ao serviço prestado), 30º, 33º, 34º, 35º, 36º, 40º, 41º, 43º, 45º, 46º, 48º, 49º, 50º, 51º, 58º, 59º, 60º, 61º, 62º, 63º, 64º, 71º, 76º, 77º e 78º (estes dois com fundamento no depoimento da testemunha II, que referiu ser difícil apurar o que efetivamente contêm as plataformas, o que igualmente se conjugou com as regras da experiência comum, considerando todo o contexto da atuação da Requerida. Ponderou-se, ainda, nesta parte, as declarações de parte prestadas, que com mais pormenor corroboram esses receios que se tiveram por consistentes), 99º, 100º e 102º.
Tais depoimentos permitiram igualmente dar como provados os factos 24º, 37º, 42º, 52º, 55º e 65º, sendo o segmento da atuação omissiva nele contido relativo à falta de entrega à Requerente, para além da documentação técnica já identificada, do código de licenciamento, que não se confunde com o código fonte do programa de licenciamento (este propriedade da Requerida) e que como resultou claro foi instalado para assegurar o recebimento por parte dos seus clientes e protegê-la perante utilizações abusivas das plataformas. Dito de outra forma, tal programa de licenciamento jamais teve como função impedir que, contra a vontade da Requerente, as plataformas ficassem inoperacionais, sendo que em nada se relaciona com os elementos que deveriam ter sido entregues e em que a Requerida alicerça a sua recusa no direito de retenção.
No que ao facto 16º respeita, a sua prova resultou da circunstância de na data em que foi remetido o email identificado no facto 15º ainda não terem cessado as relações contratuais entre as partes e resultar do documento n.º 6 anexo ao requerimento inicial, mais concretamente do email datado de 30.04.2021 que a representante legal manifestou o seu descontentamento por ter tido conhecimento do envio de tal comunicação à ANPG.
A prova dos factos 72º a 77º resultou do acordo da Requerida, que aceitou ter acesso e na sua posse as bases de dados dos clientes da Requerente, pese embora o tenha feito explicando um circunstancialismo que não logrou demonstrar, por insuficiência de prova nesse sentido (cfr, alíneas p) a s) da matéria não provada).
Relativamente ao conteúdo de tais bases de dados e o seu caráter sensível, a convicção do tribunal fundou-se no depoimento das testemunhas referidas e, nessa parte, nas declarações de parte que os corroboraram.
No mais, consideraram-se os depoimentos prestados e a atitude da Requerida perante o cliente da Requerente ANPG, no sentido de lhe passar a prestar diretamente serviços, bem como a pressão que exerceu, pela mesma altura, junto da Requerente e o valor de dois milhões que lhe exigiu, o que é de molde e propício a gerar receios sobre o comportamento daquela.
A prova dos factos 78º a 84º resultou dos elementos probatórios já enunciados, sendo certo que resultou perfeitamente pacífico que a relação estabelecida entre as partes foi para além do contrato-quadro que consta dos autos (a própria representante legal da Requerente aludiu à existência de adendas), bem como a dificuldade, por falta de divisas, em efetuar pagamentos em moeda estrangeira a partir de Angola.
Relativamente à dívida à Requerida, o tribunal convenceu-se que efetivamente, pelo menos em termos perfunctórios, resultou demonstrado que são devidos valores pela Requerente.
Porém, quer por força da dificuldade de pagamento, que muitas vezes tinha que ser realizado através de outras entidades/sociedades/pessoas, quer porque as faturas eram emitidas de acordo com a possibilidade de realizar pagamentos, quer por força das negociações que estavam a ser discutidas entre as partes, nos termos das quais havia uma redução do montante que a Requerida afirmava ser-lhe devido, quer porque os documentos juntos aos autos e, ainda, a falta deles, e por muitas contas que se fizessem não foram conclusivos, quer porque a própria representante legal da Requerente, mesmo nos emails trocados, nunca referiu exatamente que concordava com o valor da dívida indicado, na sua totalidade, quer porque esta variava nos montantes (chegando a afirmar que pretendia dois milhões de dólares), não se pode aferir do seu exato montante.
Para tal contribuiu ainda o depoimento da testemunha DD, que afirmou ter realizado pagamentos à Requerida, sendo certo que perpassou do seu depoimento que começaram a subsistir dúvidas sobre aquilo que era pago, o que se mantinha em dívida e se eventualmente nada era devido (o que também era contraditório com a posição assumida pela representante legal da Requerente nos diversos emails constantes dos autos que assumia existirem dívidas).
Outra testemunha que sobre tal matéria depôs foi o AA, cujo depoimento, infelizmente, não pode de todo ser acolhido na medida em que desde a identificação, já que afirmou estar desempregado, quando na realidade é o representante legal de uma sociedade denominada B..., com autorização da Requerida, e que aos costumes afirmou nunca ter tido nenhum vínculo formal com a Requerente, acabando por reconhecer que desempenhou o cargo de diretor executivo e, ainda, recebeu elevados montantes, e que, apesar disso, perpassou do seu depoimento que estava firmemente empenhado em defender os interesses da Requerida, desconhecendo-se em que momento o passou a fazer, motivo pelo qual se deu como não provada a alínea k) da matéria não provada.
Explicando, o que resultou das declarações de parte e discretamente do seu depoimento, é que a partir de certa altura surgiram negociações por forma a integrar a Requerente, a Requerida e a testemunha num novo projeto que tinha por base as plataformas, mas que acabaram por se gorar, pela recusa da representante legal da Requerente, o que poderá ter gerado ressentimentos que explicará a forma parcial como depôs.
Por essa razão, esse depoimento não pode merecer qualquer credibilidade.
E assim sendo, teve que resultar provado que o valor da dívida ascende a um montante não concretamente apurado.
Quanto ao contexto em que o acesso às bases de dados foi permitido não se duvidou que tal ocorre num contexto de autorização da Requerente.
Resultou também claro, como já mencionado, os fins do licenciamento e a sua utilização por parte da Requerente.
Por fim, há que esclarecer que se a questão do licenciamento nada tem a ver com o código fonte já a resolução do bloqueio que o mesmo gerou, por terem caducado as licenças, tem tudo a ver com o código fonte e demais documentação, porque permitirá extirpar tal elemento estranho das aplicações.
Para além do já mencionado, a não prova dos demais factos fundou-se em insuficiência de prova, quer por força da sua total ausência, quer porque a demais prova produzida, sobretudo testemunhal, foi contrariada pela acolhida, sobretudo pelos dois mais importantes depoimentos prestados, e por essa razão ficou totalmente desvalorizada.
II. 3. Vejamos.
Na apreciação de ambos os recursos seguiremos, como é suposto, de resto, o critério da precedência lógica e processual, donde em matéria de facto abordaremos primeiramente o recurso da requerida e, em matéria de direito, o da requerente.
II. 3. 1. As nulidades, invocadas pela requerida.
A requerida veio arguir a nulidade, parcial, da sentença, com fundamento na alínea c) do n.º 1 do artigo 615.º CPCivil, que prescreve ser nula a sentença quando os fundamentos estejam em oposição com a decisão ou ocorra alguma ambiguidade ou obscuridade que torne a decisão ininteligível, pugnando pela prolação de nova decisão, que esclareça o momento a partir do qual se deve considerar que começa a correr o prazo para proceder à entrega do que foi condenada, devendo, além disso, ainda ser fixado um prazo de 10 dias para o efeito, tal qual foi fixado para a requerente prestar caução.
Fê-lo, como vimos, em requerimento autónomo e repetiu-o nas alegações de recurso, alinhando o seguinte raciocínio:
a decisão recorrida obriga a requerente a prestar caução, no valor de €610.833,62, no prazo de dez dias, e pelo meio que no respectivo apenso venha a ser considerado idóneo e, depois, determina que a entrega ordenada tenha lugar após a efectiva prestação da caução; aqui vislumbrando a primeira ambiguidade:
foi considerado um prazo de 10 dias para a requerente prestar caução, mas não foi determinado qualquer prazo em relação a si, para proceder à entrega da documentação - com a agravante de ter sido fixada uma sanção pecuniária compulsória no valor de €1.500,00 diários, pelo não cumprimento das providências decretadas;
à luz do princípio da igualdade e porque se trata da prestação de um facto, deduz que dispõe, igualmente, de um prazo de 10 dias para proceder à entrega da documentação, contado após a efectiva prestação da caução e, deduz, também, ainda que tal não resulte evidente da decisão recorrida, que a requerente terá que informar a requerida de ter procedido à prestação da caução – isto porque se impõe determinar o momento a partir do qual começa a correr o prazo para proceder à entrega em que foi condenada;
concluindo, assim, que, ainda que se perceba a lógica temporal e sequencial do que cada uma das partes foi condenada, se impõe clarificar tal ambiguidade, de forma a que não restem dúvidas quanto ao sentido da decisão e para se afastar um qualquer litígio ulterior.
Por outro lado, entende, ainda, que o mesmo vício se evidencia, dada a ambiguidade que da decisão recorrida resulta, pois que parecer resultar, por um lado, a obrigação de entrega do código fonte com o mecanismo de licenciamento e, por outro lado e ao mesmo tempo, se reconhece a propriedade do mecanismo de licenciamento (quando a requerente se arrogava proprietária – e era neste pressuposto que exigia a sua entrega).
Para o que alinha o seguinte raciocínio: resultaram provados os seguintes factos: (…)
80) Para além disso, a requerida ainda assegurou a gestão do licenciamento das plataformas através da implementação de um motor/aplicação, que é de sua propriedade
(…)
94) Se a Requerente tivesse o código fonte das plataformas, apesar das licenças caducarem, era possível eliminar das mesmas o licenciamento implementado;
foi condenada a proceder à entrega à requerente, quer em formato físico, quer em formato digital, de toda a documentação técnica relativamente às aplicações, “o que incluiu os códigos fonte, a que alude no facto 13º da presente decisão, com exclusão dos elementos identificados no facto 14º”, sendo certo que neste facto 13.º se inclui
a) Chaves e/ou registos de licenciamento de todos os componentes necessários ao correto funcionamento das aplicações em produção em toda a sua amplitude relativos aos projetos F..., C..., D... e E...
Tudo isto, sem prejuízo do facto 80) dado como provado, ou seja, o licenciamento foi efectuado através da implementação de um motor/aplicação, que é propriedade da requerida;
Isto é, julgou-se como provado que o motor/aplicação que faz a gestão do licenciamento é sua propriedade e, ao mesmo tempo, foi condenada a proceder à entrega do código fonte; donde, a dúvida - o código fonte a entregar deverá conter ainda o motor/aplicação que é sua propriedade ou, deverá o código fonte ser entregue sem o referido motor/aplicação - tanto mais que, depois, se deu como provado que sempre é possível retirar do código fonte o licenciamento implementado.
Como vimos, sobre esta pretensão recaiu, antes de ser ordenada a subida do recurso, despacho a julgar não verificadas qualquer das apontadas causas de nulidade, pois que,
- -quanto ao primeiro ponto, não podendo o principio do contraditório ser postergado, sempre a requerida terá conhecimento dos trâmites do incidente de prestação de caução e, obviamente, da data em que ocorrerá o trânsito em julgado da decisão que a julgar validamente prestada - como tal e face ao decidido, a entrega terá que ocorrer no dia imediatamente seguinte ao do trânsito em julgado da decisão que julgar a caução validamente prestada;
- -quanto ao segundo ponto, haverá apenas que ter em consideração que o único código-fonte cuja entrega está em discussão e foi decidida nos autos é o relativo aos programas de que a requerente é proprietária, sendo que a entrega do código-fonte do programa propriedade da requerida nem sequer poderia ser determinada porque não fazia parte do objecto do litígio - como aliás foi bem compreendido pela requerente e tal qual o expõe.
Entende a requerente não existir a invocada nulidade, por estar, cristalinamente, definido na decisão recorrida, na alínea d) do seu dispositivo que a entrega deverá ter lugar após efectiva prestação da caução, isto é, no momento em que tal caução venha a ser prestada, sendo óbvio que a prestação da caução, a ser realizada, sê-lo-á com conhecimento da requerida, por acontecer à ordem do processo.
Nem a causa da invocada ambiguidade, pois que não se vislumbra da decisão recorrida se o código fonte deve conter o motor de aplicação que é propriedade da recorrente ou não.
Esta questão não se coloca, porquanto o facto do código fonte apontar para um motor de aplicação que é propriedade da requerida, nada tem que ver com o próprio motor de aplicação, que é externo ao código fonte.
Com efeito,
- -o código fonte de um programa é como se fosse o livro de instruções que, devidamente compilado “A1” – através de software próprio que corre essas mesmas instruções - dá lugar a um programa executável;
- -nesse mesmo livro de instruções, a determinado momento, existe uma instrução para se ir ao livro de instruções “B1” – que aqui referimos como sendo o motor/aplicação a que alude o artigo 80.º do rol dos factos provados – para depois se voltar às instruções do livro A1;
- -o que acontece é que o código fonte do seu programa, a determinado momento, indica que para este continuar correr, aquando da sua execução, deverá ir a um determinado local – que será como se fosse outro livro de instruções (B1) – para depois prosseguir para o livro de instruções original (A1) que é novamente o programa da recorrida.
Neste sentido e para melhor esclarecimento, cfr. depoimento prestado pela testemunha EE - no seu depoimento prestado no dia 17-09-2021, entre as 14h44m27s até às 16h33m15s, o qual ficou gravado em suporte digital na aplicação H@bilus, em especial o que resulta entre a 1h37m47s e a 1h43m43s desse mesmo depoimento, no qual é explicado o mecanismo que foi instalado pela recorrente que bloqueia as plataformas da recorrida.
Ora, a requerente em momento algum no presente procedimento cautelar solicitou que lhe fosse entregue pela requerida qualquer código fonte de programas que não são dela – no nosso exemplo o livro B1 - apenas pretende o código fonte dos seus programas, pois, com os mesmos, tem a possibilidade de retirar no seu livro de instruções a instrução que consta para este ir a outro programa antes de voltar a correr.
Isto é, o código fonte do motor de aplicação – no nosso exemplo livro B1 – não precisa de ser entregue, pois é externo ao programa em si, apenas tem de ser entregue a totalidade do código fonte do(s) programa(s) original(ais), que são no nosso exemplo o livro A1.
Não existe, assim, mais uma vez, na nossa modesta ótica, qualquer ambiguidade na douta sentença, tanto mais que a mesma nunca poderia condenar a recorrente a entregar o código fonte de um motor de licenciamento que nunca pediu.
Vejamos.
As causas de nulidade da sentença vêm taxativamente enunciadas por força do disposto no artigo 615.º/1 CPCivil, aplicável a outras decisões, por força do disposto no art 613.º/, onde se estabelece que é nula a sentença:
- -Quando não contenha a assinatura do juiz (al. a)).
- -Quando não especifique os fundamentos de facto e de direito que justificam a decisão (al. b)).
- -Quando os fundamentos estejam em oposição com a decisão ou ocorra alguma ambiguidade ou obscuridade que torne a decisão ininteligível (al. c)).
- -Quando o juiz deixe de pronunciar -se sobre questões que devesse apreciar ou conheça de questões de que não podia tomar conhecimento (al. d)).
- -Quando condene em quantidade superior ou em objecto diverso do pedido (al. e)).
Isto é, estamos perante vícios de formação; vícios de conteúdo; vícios de forma e vícios de limites.
Os vícios determinantes da nulidade da sentença correspondem, assim, a casos de irregularidades que afectam formalmente a sentença e provocam dúvidas sobre a sua autenticidade, como é a falta de assinatura do juiz, ou ininteligibilidade do discurso decisório por ausência total de explicação da razão por que decide de determinada maneira (falta de fundamentação), quer porque essa explicação conduz, logicamente, a resultado oposto do adoptado (contradição entre os fundamentos e a decisão), ou uso ilegítimo do poder jurisdicional em virtude de pretender conhecer questões de que não podia conhecer (excesso de pronúncia) ou não tratar de questões de que deveria conhecer (omissão de pronúncia )
São, sempre, vícios que. encerram um desvalor que excede o erro de julgamento e que, por isso, inutilizam o julgado na parte afectada.
É verdadeiramente impressionante a frequência com quem em sede de recurso, são invocadas nulidades da sentença , denotando um número significativo de situações em que o verdadeiro interesse da parte não é propriamente o de obter uma correcta apreciação do mérito da causa, mas de anular, a toda a força, a sentença com que foi confrontada, nas palavras de Abrantes Geraldes, in CPCivil anotado, Almedina, 2.ªedição 762…
Nos termos do artigo 615º/1 alínea c), a sentença é nula, quando os fundamentos estejam em oposição com a decisão ou ocorra alguma ambiguidade ou obscuridade que torne a decisão ininteligível.
Esta precisa causa de nulidade ocorre quando existe incompatibilidade entre os fundamentos e a decisão, quando a fundamentação aponta em determinado sentido que contradiz o resultado final – situação que, sendo violadora do chamado silogismo judiciário, em que as premissas devem condizer com a conclusão, também não se confunde com um eventual erro de julgamento, que se verifica quando o juiz decide contrariamente aos factos apurados ou contra norma jurídica que lhe impõem uma solução jurídica diferente.
Por outro lado a decisão é obscura quando contém algum passo cujo sentido seja ininteligível e é ambígua quando alguma passagem se preste a interpretações diferentes, cf. ob e loc citados, 763/4.
Entre os fundamentos e a decisão não pode haver contradição lógica. Se na fundamentação, o julgador seguir determinada linha de raciocínio, apontando para determinada conclusão e, em vez de a tirar, decidir noutro sentido, oposto ou divergente, a oposição será causa de nulidade. Esta oposição não se confunde com o erro de subsunção dos factos à norma jurídica, muito menos, com o erro de interpretação desta. Quando embora mal, o juiz entende que dos factos apurados resulta determinada consequência jurídica e este seu entendimento é expresso na fundamentação, ou dela decorre, encontramo-nos perante erro de julgamento e, não perante oposição geradora de nulidade.
Já quando o raciocínio expresso na fundamentação aponta para determinada consequência jurídica e na conclusão é tirada outra, ainda que esta seja a juridicamente correcta, a nulidade verifica-se.
No expressivo dizer de Lebre de Freitas, in CPCivil anotado, Almedina, 4. ª edição, 736/7, que vimos seguindo de perto, a oposição entre os fundamentos e a decisão tem o seu correspondente na contradição entre o pedido e a causa de pedir, geradora de ineptidão da petição inicial,
Neste circunstancialismo, é forçosa a conclusão de que a decisão recorrida não enferma de apontada nulidade.
Com efeito.
Inexiste qualquer ambiguidade no facto de se declarar - que diz a lei do processo - que a caução deve ser prestada em 10 dias e não se referir o prazo dentro do qual a requerida tem que entregar à requerente a documentação que foi condenada a entregar.
Nem, por isso mesmo deve ser fixado - que é o que afinal a requerida pretende - ser fixado igual prazo para o fazer.
O princípio da igualdade mandar tratar por igual e de forma diferente o que é diferente.
Ainda que estejamos perante duas obrigações de prestação de facto e de “facere”, nada impõe que o prazo para entregar aquilo que a decisão judicial manda entregar, corresponda ao prazo de 10 dias, por ser o mesmo que a outra parte tem para prestar caução – tal e qual resulta, de resto, do texto legal.
Donde nenhuma nulidade existe nesta sede.
Nem, como parece medianamente evidente em algum passo da decisão ou do texto da lei, se impõe à requerente que informe a requerida do momento em que prestou a caução - determinante, é certo, para o início da contagem do dito prazo.
Aqui tão, evidente como no segmento anterior, resulta, naturalmente, do texto legal atinente com a normal tramitação do incidente de prestação da caução - em que a requerida, da mesma forma, será parte - que será notificada, tal como a requerente, de resto, da sua tramitação e, mormente do despacho que julgue validamente prestada a caução. Daí, terá – ela e a requerente - a perfeita, cabal e definitiva noção do momento em que é proferida sentença a julgar prestada a caução e do momento em que começa a contar o prazo para interposição de recurso, ou do momento em que ocorrerá o trânsito em julgado da mesma decisão.
Com base nestes elementos, fica a saber qual o prazo em que terá que entregar a documentação – a partir do dia imediatamente seguinte ao do trânsito em julgado da decisão que julgar a caução validamente prestada, como não pode deixar de ser, desde logo, atento o facto de ter sido aplicada a sanção compulsória no valor de €1.500,00 diários, pelo não cumprimento das providências decretadas.
Nada a esclarecer, dado carácter cristalino do que vem de ser dito e que constitui, afinal, a normal decorrência da interpretação para um normal declaratário, quer do texto da decisão recorrida, quer do texto legal.
Isto, naturalmente, se prevalecer a obrigação da prestação de caução por parte da requerente.
Já que doutra forma o prazo se iniciará depois do trânsito em julgado da decisão que decretou a obrigação de entrega, como parece, medianamente, claro e evidente.
Pugnar aqui e agora pela concessão do prazo de 10 dias, revela-se como absolutamente inconsequente e processualmente inidóneo, pois que, tal apenas poderia ser conseguido através da impugnação por via de recurso – caminho que a requerida não seguiu.
Quanto ao mais.
Também se não verifica a outra apontada ambiguidade, que nas palavras da requerida parece resultar, por um lado, a obrigação de entrega do código fonte com o mecanismo de licenciamento e, por outro lado e ao mesmo tempo, se reconhece a propriedade do mecanismo de licenciamento (quando a requerente se arrogava proprietária – e era neste pressuposto que exigia a sua entrega).
Como acertadamente refere a requerida vem provado que,
- -a requerida assegurou a gestão do licenciamento das plataformas através da implementação de um motor/aplicação, que é sua propriedade e,
- -se a requerente tivesse o código fonte das plataformas, apesar das licenças caducarem, era possível eliminar das mesmas o licenciamento implementado.
E, nesta sequência foi condenada a entregar, quer em formato físico, quer em formato digital, toda a documentação técnica relativamente às aplicações, “o que incluiu os códigos fonte, a que alude no facto 13º da presente decisão, com exclusão dos elementos identificados no facto 14º”, sendo certo que neste facto 13.º se inclui
F) LICENÇAS:
a) Chaves e/ou registos de licenciamento de todos os componentes necessários ao correto funcionamento das aplicações em produção em toda a sua amplitude relativos aos projetos F..., C..., D... e E...
Tudo isto, sem prejuízo do facto 80) dado como provado, ou seja, o licenciamento foi efectuado através da implementação de um motor/aplicação, que é propriedade da requerida.
Daqui entende a requerida que julgou-se como provado que o motor/aplicação que faz a gestão do licenciamento é sua propriedade e, ao mesmo tempo, foi condenada a proceder à entrega do código fonte e, então, lhe surge a dúvida - o código fonte a entregar deverá conter ainda o motor/aplicação que é sua propriedade ou, deverá o código fonte ser entregue sem o referido motor/aplicação -tanto mais que, depois, se deu como provado que sempre é possível retirar do código fonte o licenciamento implementado.
Como parece medianamente claro e inequívoco, para qualquer normal declaratário, da conjugação da pretensão da requerente com a oposição da requerida e com base na decisão recorrida, o único código-fonte cuja entrega foi ordenada, não pode ser outro, diferente, nem mais, do que aquele que no processo está em discussão, afinal o reportado aos programas de que a requerente é proprietária.
Qualquer outro diferente traduziria uma condenação além do pedido – contra a qual a requerida, seguramente, não deixaria de aqui reagir, agora, acertadamente, através da invocação da nulidade da decisão, ao abrigo da alínea e) do n.º 1 do artigo 615.º CPCivil.
Em causa está o código fonte dos programas da requerente e, não, o motor de aplicação – realidade exterior àquele.
Improcede, assim, na totalidade, este segmento do recurso.
II. 3. 2. A impugnação da matéria de facto.
II. 3. 2. 1. Recurso da requerida
Defende a requerida que não tem que proceder à entrega de qualquer outra documentação para lá do código fonte, expurgado, naturalmente, do mecanismo de licenciamento (sua propriedade).
Este é, no seu entendimento, grosso modo, o objecto do recurso. Isto é, aceita, parcialmente a decisão proferida, no sentido de proceder à entrega do código fonte.
A razão da sua discordância reside, então, na demais documentação que também foi condenada a entregar – quando sempre alegou que não tinha nem tinha que ter tal documentação.
E porque pretende dar cumprimento à decisão judicial, entregando o código fonte, ao mesmo tempo, está impossibilitada de lhe dar integral cumprimento, por falta da documentação, o que redundará na condenação do valor diário fixado.
Feito este intróito, vejamos então.
Entende estar incorrectamente julgada a matéria de facto constante dos pontos 13), 36), 51), 64) e 71), cujas redacções devem ser alteradas; 37), 52) e 65), que devem ser julgados como não provados, defendendo, ainda, que se julgue como provado um novo facto a aditar e, que tem que ver com o facto t) dado como não provado.
Aqueles pontos são do seguinte teor:
13) A documentação técnica de todos os programas teria de incluir, os seguintes componentes, em suporte físico e digital:
- A)DESCRITIVO FUNCIONAL:
- a)Descrição Funcional do projeto SIGEP / ANI b) Descrição Funcional do projeto C... c) Descrição Funcional do projeto D...
- d)Descrição Funcional do projeto E...
- e)Manual de Troubleshooting do projeto SIGEP / ANI f) Manual de Troubleshooting do projeto C... g) Manual de Troubleshooting do projeto D...
- h)Manual de Troubleshooting do projeto E...; B) APLICAÇÃO E CÓDIGO FONTE:
- a)Código fonte de todos os componentes desenvolvidos, até à última versão em produção, nomeadamente, ..., ..., ..., A..., A....Channel, A....Global, ....Core, ... dos projectos F..., C..., D... e E....
- b)Binários de todos os componentes relativos, até à última versão em produção dos projetos F..., C..., D... e E....
- c)Código fonte dos componentes desenvolvidos, histórico das versões anteriores dos projetos F..., C..., D... e E....
- C)DOCUMENTAÇÃO TÉCNICA:
- a)Manuais de Administração do ambiente de Testes do projeto F... b) Manuais de Administração do ambiente de Testes do projeto C... c) Manuais de Administração do ambiente de Testes do projeto D...
- d)Manuais de Administração do ambiente de Testes do projeto E... e) Manuais de Configuração do ambiente de Testes do projeto F...
- f)Manuais de Configuração do ambiente de Testes do projeto C... g) Manuais de Configuração do ambiente de Testes do projeto D...
- h)Manuais de Configuração do ambiente de Testes do projeto E... i) Manuais de Administração do ambiente de Produção do projeto F...
- j)Manuais de Administração do ambiente de Produção do projeto C... k) Manuais de Administração do ambiente de Produção do projeto D...
- l)Manuais de Administração do ambiente de Produção do projeto E... m) Manuais de Configuração do ambiente de Produção do projeto F... n) Manuais de Configuração do ambiente de Produção do projeto C... o) Manuais de Configuração do ambiente de Produção do projeto D...
- p)Manuais de Configuração do ambiente de Produção do projeto E...
- q)Manuais de Administração do ambiente de Desenvolvimento do projecto F...
- r)Manuais de Administração do ambiente de Desenvolvimento do projeto C...
- s)Manuais de Administração do ambiente de Desenvolvimento do projeto D... ´
- t)Manuais de Administração do ambiente de Desenvolvimento do projecto
E...
- u)Manuais de Configuração do ambiente de Desenvolvimento do projecto F...
- v)Manuais de Configuração do ambiente de Desenvolvimento do projeto C...
- w)Manuais de Configuração do ambiente de Desenvolvimento do projeto D... x) Manuais de Configuração do ambiente de Desenvolvimento do projecto
E...;
- D)RELEASE NOTES:
- a)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto F...
- b)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto C...
- c)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto D...
- d)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto E...;
- E)HISTÓRICO DOS TICKETS DE SUPORTE:
- a)Histórico dos tickets de suporte e desenvolvimento, que deve incluir o histórico individual de cada ticket desde a abertura do chamado até ao encerramento do mesmo para todas as aplicações em produção (C..., D... e E...);
- F)LICENÇAS:
- a)Chaves e/ou registos de licenciamento de todos os componentes necessários ao correto funcionamento das aplicações em produção em toda a sua amplitude relativos aos projetos F..., C..., D... e E....
- G)MANUAL DO UTILIZADOR:
- a)Manual de Utilizador da aplicação C...; b) Manual de Utilizador da aplicação D...;
- c)Manual de Utilizador da aplicação E...; H) DOCUMENTAÇÃO DE PROJECTO:
- a)Relatórios de Trabalhos relativos aos projetos F..., C..., D... e E...;
- b)Cronogramas de Atividades relativos aos projetos F..., C..., D... e E...;
- c)Entregáveis das várias fases dos projetos F..., C..., D... e E... d) Relatórios Finais relativos aos projetos F..., C..., D... e E...;
- 36)Face ao facto da Requerente não ter a documentação técnica da plataforma, na qual se inclui todo o código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida;
- 37)De igual forma, a Requerida não entregou à Requerente o código do licenciamento que lhe permitiria desbloquear as funcionalidades da plataforma D...;
- 51)Face ao facto da Requerente não ter a documentação técnica da plataforma, na qual se inclui todo o código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida;
- 52)De igual forma, a Requerida não entregou à Requerente o código do licenciamento que lhe permitiria desbloquear as funcionalidades da plataforma C...;
- 64)Face ao facto da Requerente não ter a documentação técnica da plataforma, na qual se inclui todo o código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida;
- 65)De igual forma, a Requerida não entregou à Requerente o código do licenciamento que lhe permitiria desbloquear as funcionalidades da plataforma E...
- 71)Face ao facto de a Requerida não ter entregue à Requerente a documentação técnica da plataforma F..., na qual se incluiu todo o código fonte, esta última vê-se impossibilitada de efetuar a manutenção do aludido sistema informático no sentido de o manter operacional.
t) Toda a documentação técnica a que alude a Requerente não existe, nem era suposto que existisse.
Como vimos o julgamento sobre estes factos, 13), 36), 37), 51), 52) 64), 65), 71) e alínea t), tem subjacente a seguinte análise crítica da prova:
- da prova testemunhal produzida destacou-se, pela sua isenção, imparcialidade e serenidade, o depoimento prestado pela testemunha II, técnico de informática, que trabalhou para a H... em Luanda, a prestar serviços à Requerente desde Maio de 2021 e no sentido de ajudar a desbloquear o acesso às plataformas, que manteve com o casal constituído pelo Dr. GG, entretanto falecido e inicialmente o representante legal da Requerente e ex-marido/companheiro da atual representante legal, e esta, uma relação de amizade, a qual remonta ao início da idealização da plataforma base, e que salvo o período de separação do casal, que se revelou complicado, acompanhou a evolução dos trabalhos, tendo dito que, o Dr. GG “desenhou” os requisitos da plataforma base e seus desenvolvimentos até 2016, altura em que o casal se separou;
o desenvolvimento das plataformas foi feito à medida e que nasceu com um conjunto de três programadores, contratados pelo Dr. GG; como tal solução não produziu os resultados pretendidos, foi desenvolvida pela A..., sendo que toda a plataforma e seus desenvolvimentos veio desenhada a partir dessa génese, após o que passou a requerida a prestar tais serviços; na típica atividade de desenvolvimento por encomenda, há um conjunto de elementos que têm que ser entregues ao encomendador, relativamente a cada uma das versões, a fim de lhe permitir, com autonomia e caso assim o pretenda, gerir as plataformas; com muita clareza ser distinta a atividade de desenvolvimento e a de suporte, que podem não ser prestados pela mesma entidade, bem como a situação em que no desenvolvimento intervém mais do que uma entidade, recaindo sobre cada uma, relativamente às alterações introduzidas, a obrigação de entrega dos elementos que descreveu, independentemente de assim ter sido acordado;
quanto à atividade de desenvolvimento e de suporte, quais os elementos que teriam que ser entregues para cada uma delas, os quais são, entre outros, o código fonte desenvolvido, os requisitos funcionais (ou seja, aquilo que foi definido à partida pelo encomendador e que pode ou não tomar a forma de caderno de encargos), os manuais, destacando os de configuração, de administração (que contém a parametrização usada no desenvolvimento da aplicação e que referiu que poderá não existir no caso do técnico que nela esteve envolvido e a conhece mas que, ainda assim, tal manual tem que ser entregue para salvaguardar a intervenção de quem não disponha de tais conhecimentos), o conjunto de ambientes (relacionado com os testes), as release notes (correspondente às alterações que introduzem novas funcionalidades e resolvem problemas), de troubleshooting, os binários, licenciamentos que possam estar a fechar a plataforma (assunto a que infra nos referiremos), a listagem de tickets (respeitantes aos problemas surgidos e forma como foram resolvidos e que poderão servir para aferir do serviço de suporte prestado, da sua qualidade e para analisar futuras alterações a introduzir na aplicação para de vez os resolver), relatórios de gestão (gestão de projeto que acompanha as várias fases);
de forma tecnicamente muito explicita, qual a função de cada um de tais elementos, destacando obviamente o código fonte, e a importância de cada um deles para que a requerente possa ultrapassar o problema surgido;
não teve dúvidas em afirmar que caso a requerente tivesse na sua posse tais elementos, a situação surgida teria sido facilmente ultrapassável;
o sistema tem implantado um processo de licenciamento, que consiste numa chave de acesso, com processo de validação on line e que mais não é do que um programa de bloqueio das plataformas pelos seus utilizadores, no caso os clientes da requerente, e que jamais se destinaria a obstaculizar o acesso da própria às mesmas;
este programa de bloqueio não fazia parte dos serviços de desenvolvimento encomendados, sendo uma ferramenta à parte ou acessória.
o bloqueio está ter consequências em cada uma das plataformas, com importância extremamente critica e, que está a causar prejuízos económicos avultados, quer aos clientes (destacou a G... e a ANPG, quer à própria requerente, e, ainda, no caso do D... sobre a gestão dos processos dos reclusos;
estar a requerente a sofrer danos reputacionais, tendo tido necessidade de contratar uma equipa para tentar solucionar o bloqueio surgido;
os progressos alcançados por tal equipa, que se resumiram ao acesso aos dados, sem possibilidade da introdução de novos registos, os quais estão manifestamente aquém de tornar as plataformas operacionais;
inclusivamente poderá haver elementos que terão que ser entregues mas que se encontrem registados nas próprias plataformas, nomeadamente os tickets, mas como o acesso às mesmas está vedado não é possível chegar a tal conclusão;
apesar de desconhecer quais os valores acordados e pagos pela prestação dos serviços, mencionou que recorreu ao descritivo das faturas para tentar perceber os desenvolvimentos e atividades realizadas mas que estas são tão vagas que se revelaram inconclusivas;
a própria documentação contribuiria de forma decisiva para aferir da correspondência entre os valores que estão a ser exigidos e a sua efetiva prestação;
a requerente tem na sua posse as release notes e os manuais de parametrização até 2016;
os manuais de parametrização possuídos pela requerente eram relativos apenas a uma plataforma (salvaguardando que era a ideia que tinha),
- pelos mesmos motivos, destacou-se o depoimento da testemunha JJ, consultor na área da informática, que trabalhou para a requerente entre 2014 a 2017, sendo a sua atividade desenvolvida na área das plataformas aqui em causa, motivo pelo qual demonstrou um profundo conhecimento das mesmas, e que atualmente se encontra igualmente a prestar-lhe apoio, desde Maio de 2021, no sentido de tentar que sejam aquelas desbloqueadas, tendo dito que, teve intervenção direta na execução da implementação, afirmando que os manuais em poder da requerente eram relativos a todas as plataformas, o tribunal acolheu nesta parte, apenas o depoimento desta última testemunha, dada a sua melhor explicação – em detrimento do da anterior testemunha;
tem um profundo conhecimento das plataformas, por força da atividade desenvolvida, e mencionou que foi o Dr. GG que concebeu a ideia, definindo os seus requisitos e que havia uma espécie de caderno de encargos que consistia numa lista de requisitos funcionais muito detalhado, tendo sido um programa desenvolvido à medida;
neste tipo de projetos são essenciais, habituais e necessários que sejam entregues, de forma exaustiva e com indicação das respetivas utilidades, em termos coincidentes com o depoimento da testemunha anterior;
apesar de mencionar que no caso o manual que contém a parametrização não ter sido necessário, pelo conhecimento profundo que a testemunha tinha das plataformas, certo é que nem por isso teria que deixar de ser entregue para que futuros “operadores” pudessem intervir nas plataformas - também esta testemunha não fez referência à necessidade da existência de manuais de formação de formadores - assim, com base nestes dois depoimentos deu-se por não provada a matéria de facto contida na alínea b) do elenco de factos não provados;
tendo ainda descrito o historial da génese das plataformas, o seu caráter evolutivo, os seus desenvolvimentos e aplicações, e que os manuais e o código fonte teriam que ser igualmente atualizados segundo as evoluções e alterações introduzidas - o que também foi referido pela testemunha II;
as plataformas estão bloqueadas por causa de um mecanismo de licenciamento validado através de um serviço na cloud, que valida a licença que está instalada numa determinada plataforma, afirmando não se recordar quando o mesmo foi implementado e desconhecer o processo de desbloqueio, referindo todavia que será resolúvel rapidamente, desde que a requerente disponha dos elementos para tal;
o mecanismo de licenciamento se destina a proteger a proprietária das plataformas, no caso a requerente, perante os seus clientes - não resultou do que disse que esse programa de licenciamento resultasse da encomenda da requerente, o que conjugado com o depoimento da testemunha EE, engenheiro informático da requerida, responsável pela equipa de suporte, e que afirmou que a solução de licenciamento foi desenvolvida e é propriedade da requerida, o tribunal deu como não provada a alínea a) dos factos não provados;
descrevendo, também, a importância e funções de cada uma das plataformas e as graves consequências advindas da sua inoperacionalidade, quer para os clientes da requerente e utentes diretos das mesmas, quer para a própria requerente;
com o código fonte conseguir-se-ia ultrapassar o bloqueio existente - porém, neste aspeto, e porque revelou ter maiores conhecimentos técnicos nesta área, acolheu-se apenas o depoimento da testemunha II, que para além do código fonte mencionou a necessidade dos demais documentos elencados na matéria provada;
de todos os elementos que deveriam ter sido entregues pela requerida a requerente apenas possui as release notes e os manuais de parametrização até 2016, explicando que os mesmos são necessários sempre que há desenvolvimentos ou evoluções nas plataformas e que estes cessaram em 2016, o que permitiu dar como provado o facto 14;
inexistiam, até à sua saída, manuais de troubleshooting (forma de resolver problemas que são previsíveis que surjam), destacando a sua importância para qualquer pessoa que pretenda operar ou prestar serviços de suporte às plataformas;
tendo identificado os avanços conseguidos pela equipa técnica contratada pela requerente e a sua insuficiência para tornar as plataformas operacionais;
- -ainda que com conhecimentos mais limitados, mas muito claro no sentido da falta de documentação que permita ultrapassar o bloqueio existente, por estar igualmente tentar ajudar a requerente desde Maio de 2021, identificação da documentação e elementos necessários para tal, falta de desenvolvimentos desde finais de 2016/Janeiro de 2017 (sendo que neste caso se acolheu o depoimento da testemunha JJ, que identificou o final do ano de 2016 como correspondendo ao final dos desenvolvimentos) foi acolhido o depoimento da testemunha HH, que esteve em sintonia com os já identificados;
- -de forma um pouco mais apaixonada, por força de uma maior ligação e envolvimento com a requerente, por força dos acordos estabelecidos quer pessoalmente, quer através das empresas que representam, mas igualmente elucidativa, depôs sobre os factos que vimos analisando a testemunha DD, cujo depoimento foi acolhido na parte em que corroborou e complementou os depoimentos já mencionados;
- -estes depoimentos, por força da sua consistência, permitiram ao tribunal dar como provados os factos 13 (definição da documentação técnica que teria que ser entregue, independentemente de ter sido ou não requerida ou solicitada, por ser inerente ao serviço prestado), 36, 51, 64 e 71, tendo permitido, ainda, julgar como provados os factos 37, 52 e 65, sendo o segmento da atuação omissiva nele contido relativo à falta de entrega à requerente, para além da documentação técnica já identificada, do código de licenciamento, que não se confunde com o código fonte do programa de licenciamento (este propriedade da requerida) e que como resultou claro foi instalado para assegurar o recebimento por parte dos seus clientes e protegê-la perante utilizações abusivas das plataformas - dito de outra forma, tal programa de licenciamento jamais teve como função impedir que, contra a vontade da requerente, as plataformas ficassem inoperacionais, sendo que em nada se relaciona com os elementos que deveriam ter sido entregues e em que a requerida alicerça a sua recusa no direito de retenção.
(...)
Por fim, há que esclarecer que se a questão do licenciamento nada tem a ver com o código fonte já a resolução do bloqueio que o mesmo gerou, por terem caducado as licenças, tem tudo a ver com o código fonte e demais documentação, porque permitirá extirpar tal elemento estranho das aplicações.
Para além do já mencionado, a não prova dos demais factos fundou-se em insuficiência de prova, quer por força da sua total ausência, quer porque a demais prova produzida, sobretudo testemunhal, foi contrariada pela acolhida, sobretudo pelos dois mais importantes depoimentos prestados, e por essa razão ficou totalmente desvalorizada.
A isto contrapõe a requerida o seguinte raciocínio:
- facto 13) – que diz respeito aos supostos documentos que a apelante teria que ter já entregue – defende que deve ser retirada a referência a todos os documentos que não foram acordados, devendo a redacção passar a ser a seguinte:
13) A documentação técnica de todos os programas teria de incluir, os seguintes componentes, em suporte físico e digital:
- B)APLICAÇÃO E CÓDIGO FONTE:
- a)Código fonte de todos os componentes desenvolvidos, até à última versão em produção, nomeadamente, ..., ..., ..., A..., A....Channel, A....Global, ... dos projectos F..., C..., D... e E....
- b)Binários de todos os componentes relativos, até à última versão em produção dos projetos F..., C..., D... e E....
- c)Código fonte dos componentes desenvolvidos, histórico das versões anteriores dos projetos F..., C..., D... e E....
- D)RELEASE NOTES:
- a)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto F...
- b)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto C...
- c)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto D...
- d)Descritivo das alterações; correções e novas funcionalidades das várias versões produzidas relativas ao projeto E...;
isto porque muita da documentação que consta do ponto julgado como provado não foi acordada entre as partes, do que constitui exemplo a referente ao
- A)DESCRITIVO FUNCIONAL: C) DOCUMENTAÇÃO TÉCNICA: F) LICENÇAS:
- G)MANUAL DO UTILIZADOR:
- H)DOCUMENTAÇÃO DE PROJECTO:
no que se refere à aplicação do código fonte, alínea a) foi retirada a referência ao mecanismo de licenciamento sua propriedade, ....Core;
mesmo que assim não fosse, sempre um dos documentos que seguramente não deve constar do tem que ver com o licenciamento, alínea F;
a este propósito – sobre a sua propriedade do motor/mecanismo de licenciamento, invoca o depoimento da testemunha EE – que localiza no suporte de gravação.
cfr. aos minutos 51:00 a 52:00 e 55:50 a 56:10 do ficheiro áudio 20210917144426_15995393_2871606 em que se refere à propriedade da ....Core;
ademais, vem provado no ponto 80 que o licenciamento foi efectuado através da implementação de um motor/aplicação, que é sua propriedade – e, como defendeu já, aquando da invocação da nulidade, sendo o mecanismo de licenciamento sua propriedade, ainda que o mesmo esteja, até aqui, alojado no código fonte, não se mostra razoável a condenação na entrega do código fonte com o licenciamento e, muito menos, se mostra equiparável a documentação relativa ao licenciamento com a demais documentação elencada no ponto 13), tanto mais que nada tem que ver o desenvolvimento das aplicações;
considerando que o licenciamento nada tem que ver com o desenvolvimento do projecto e, inclusive, que o mecanismo de licenciamento é sua propriedade, independentemente da supra pugnada versão alternativa do artigo 13), sempre deverá ser retirado do elenco dos documentos constantes do ponto 13;
de resto, as testemunhas arroladas pela requerente depuseram, por um lado, sobre o cenário ideal de como um projecto de arquitectura informática deve ser desenvolvido e, nesse pressuposto, quais os documentos que devem ser entregues pelo “empreiteiro” ao dono da obra, mas, no caso, desenvolvimento por si operado foi tudo menos convencional;
desde logo, porque o código original começou por ser desenvolvido por uma outra empresa – A... – e, assim, invoca os depoimentos das testemunhas EE, minutos 13:00 a 13:20 do ficheiro 20210917144426_15995393_2871606 e AA, minutos 45:00 a 50:45 do ficheiro 20211008101105_15995393_2871606;
a partir daqui todo o contexto de desenvolvimento foi trabalhar sobre uma aplicação já existente, as especificações do que se pretendia do desenvolvimento iam sendo fornecidas - ao contrário do que é habitual em que há um caderno de encargos que particulariza as especificações pretendidas;
do mesmo modo, normal é que haja um cronograma de todo o projecto, em que ambas as partes sabem já, por antecipação, o que entregar e quando entregar e, aqui, nada disto ocorreu: os sucessivos desenvolvimentos iam decorrendo à medida que os clientes da requerente iam solicitando alterações, sendo certo que, não obstante os desenvolvimentos terem terminado em 2017, sempre foi um projecto inacabado e havia a expectativa de ambas, de que novos desenvolvimentos fossem ocorrendo;
comparando o que é norma acontecer e o que aqui aconteceu, anormalmente, no final do projecto, a empresa de desenvolvimento procede à entrega do programa, código fonte e demais entregáveis que foram previamente negociados, estando o dono de obra a proceder à recepção da “obra”, com tudo o que daí advém quanto às reclamações r, no caso, nada disto ocorreu, nada dito foi acordado;
as testemunhas arroladas pela requerente foram depondo sobre generalidades, tanto mais que, sobre o que ocorreu no caso em concreto entre as partes em litígio, nada sabiam, nem podiam saber já que não tinham qualquer relação com qualquer uma das partes;
não deixa de ser esclarecedor o referido pela testemunha HH – cfr. Aos minutos 22:30 – 22:54 do ficheiro áudio 20210917141202_15995393_2871606 - quando refere que se existem duas empresas e a primeira cria uma base de software e a segunda vem “acabar a obra”, não é necessário que esta segunda crie a documentação em falta, a responsabilidade é da primeira empresa;
quanto à atipicidade do trabalho, depôs a testemunha EE – cfr. Aos minutos 14:00 – 15:28 do ficheiro áudio 20210917144426_15995393_2871606, bem como minutos 24:50 a 26:20 e, especialmente, a testemunha AA, cfr. aos minutos 1:10:00 a 1:15:00 do ficheiro áudio 20211008101105_15995393_2871606 em que se refere à ausência de caderno de encargos, precisando, depois, aos minutos 1:15:00 a 1:17:00 que a requerida desenvolveu toda a documentação solicitada pela requerente, cfr. minutos 1:08:30 a :11:55 do ficheiro áudio 20211008150450_15995393_2871606 em que se refere ao manual do troubleshooting, acrescentando que o mesmo nunca foi pedido, tanto mais que o projecto não estava sequer terminado, era um projecto em curso, que nunca chegou a ser concluído cfr. minutos 1:49:10 a 1:52:10 do mesmo ficheiro áudio 20211008150450_15995393_2871606 em que se refere ao acordo-quadro e que nunca ficou definido o que a requerida tinha que entregar;
a este propósito cumpre fazer o seguinte comentário à apreciação que o douto Tribunal fez do depoimento desta testemunha e da credibilidade que à mesma foi reconhecida, já que entende que a mesma depôs de forma serena e séria, demonstrando conhecimento profundo sobre todos os factos e, mesmo quando foi objecto da contradita, foi capaz de contextualizar o e-mail, tendo o seu depoimento sido corroborado pela mais diversa correspondência (e-mails) juntos ao processo - a testemunha foi inquirida durante tantas horas e em todo o seu depoimento sempre pautou as respostas por uma assertividade fora do comum, sem qualquer hesitação, pelo que deveria ter convencido o Tribunal a quo quanto à veracidade, franqueza e credibilidade do seu depoimento;
ainda a propósito da atipicidade deste projeto de desenvolvimento, depôs a testemunha FF Cfr. minutos 03:45 a 4:45 do ficheiro áudio 20211015161438_15995393_2871606 em que se pronuncia sobre os fragmentos de código fonte a que tiveram acesso e sobre o qual trabalharam, Minutos 04:45 a 06:00 do ficheiro áudio 20211015161438_15995393_2871606 em que se refere às reuniões tidas com o Dr. GG e a forma como as especificações eram transmitidas – em contexto de reunião;
este contexto de atipicidade deveria ter afastado o depoimento das testemunhas indicadas pela requerente, já que foram fazendo referências a projectos dentro da normalidade;
sobre os entregáveis e sobre o que foi acordado entre as partes, se pronunciou a testemunha AA. cfr. aos minutos 1:10:00 a 1:15:00 do ficheiro áudio 20211008101105_15995393_2871606 em que se refere à ausência de caderno de encargos, precisando, depois, aos minutos 1:15:00 a 1:17:00 que a requerida desenvolveu toda a documentação solicitada pela requerente, cfr. minutos 1:08:30 a 1:11:55 do ficheiro áudio 20211008150450_15995393_2871606 em que se refere ao manual do troubleshoting, acrescentando que o mesmo nunca foi pedido, tanto mais que o projecto não estava sequer terminado, era um projecto em curso, que nunca chegou a ser concluído cfr. minutos 1:49:10 a 1:52:10 do mesmo ficheiro áudio 20211008150450_15995393_2871606 em que se refere ao acordo-quadro e que nunca ficou definido o que a requerida tinha que entregar cfr. minutos 46:00 a 54:00 do ficheiro áudio 20211015100038_15995393_2871606 em que faz um contexto sobre os entregáveis num projecto normal, acrescentando aos minutos 1:11:00 a 1:13:00 do mesmo ficheiro o que foi acordado e, especialmente, o que não foi acordado;
no mesmo sentido, invoca o depoimento da testemunha EE, cfr. Aos minutos 15:29 – 16:10 do ficheiro áudio 20210917144426_15995393_2871606 em que se refere a toda a documentação gerada, minutos 17:10 a 17:45 em que se refere à desnecessidade do manual de troubleshooting, minutos 19:30 a 19:45 em que se refere ao manual de troubleshooting nunca foi pedido, minutos 21:50 a 23:40 em que se refere aos entregáveis que, no caso em concreto, foi solicitado, a saber, as release notes, as funcionalidades que tinham implementado e manuais de parametrização destas funcionalidades, minutos 26:45 a 27:30 sobre a ausência de qualquer solicitação ou queixa relativa aos documentos em falta, minutos 27:20 a 30:00 em que se refere novamente ao manual de troubleshooting.
Daqui afirma estarem enunciados e justificados quais os entregáveis que as partes acordaram que teriam que ser produzidos por si - além do código fonte, as release notes e os manuais de parametrização.
Quanto aos factos contidos nos pontos 36), 51), 64) e 71), defende que deve ser eliminada a referência à documentação técnica da plataforma, propondo a seguinte redacção:
- 36)Face ao facto da Requerente não ter acesso ao código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida
- 51)Face ao facto da Requerente não ter acesso ao código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida
- 64)Face ao facto da Requerente não ter acesso ao código fonte da plataforma, vê-se impossibilitada de eliminar a rotina informática inserida pela Requerida
- 71)Face ao facto de a Requerente não ter acesso ao código fonte da plataforma F..., esta última vê-se impossibilitada de efetuar a manutenção do aludido sistema informático no sentido de o manter operacional
Os factos contidos nos pontos 36), 51), 64) e 71) dizem respeito, grosso modo, à mesma matéria: por força do mecanismo de licenciamento introduzido no código fonte e por força do período de renovação do licenciamento escolhido pela requerente ter sido de um mês, quando a requerida a informou que deixaria de lhe prestar qualquer serviço (incluindo aqui o da renovação da licença), no final do mês respectivo, porque a licença não foi renovada, foi bloqueado o acesso às aplicações - a requerente solicitou-lhe a introdução de um mecanismo de licenciamento no código fonte e que o mesmo se renovasse mensalmente;
assim, sempre que a licença expirava ou por algum motivo bloqueava, a requerente solicitava-lhe que procedesse à renovação da licença ou ao desbloqueio e, tal assim aconteceu até ao momento em que deixou de lhe prestar serviços, após 21.05.2021 e à medida em que as licenças foram expirando e porque não foram renovadas, foi bloqueado o acesso às aplicações;
isto é o que resulta dos factos contidos nos pontos 21) e 32) a 35) e, este é o motivo – a não renovação do licenciamento – pelo qual as plataformas não estão a funcionar;
neste contexto, o que resulta dos pontos factos 36), 51), 64) e 71) parece induzir que o problema está na ausência da documentação e do código fonte – é certo que tendo a requerente acesso ao Código Fonte e expurgando-o do mecanismo de licenciamento, as plataformas passarão a funcionar – todavia, o problema está sempre no licenciamento e no código fonte e nunca na documentação;
neste sentido, prestou depoimento a testemunha II, cfr. minutos 28:00 a 32:30 do ficheiro áudio 20210910152728_15995393_2871606 em que se refere ao mecanismo de licenciamento e que o simples acesso ao código fonte permitiria eliminar o referido mecanismo, passando as plataformas a funcionar.
Quanto aos factos contidos nos pontos 37), 52) e 65), donde resulta que era possível fornecer um simples código de licenciamento, devem ser julgados como não provados.
Mesmo que tal correspondesse à verdade, o certo é que tal implicaria que a requerida continuasse a prestar serviços à requerente, pois que, pelo menos, mensalmente, teria que estar a renovar as licenças, já para não falar de todas as vezes em que as plataformas ficam bloqueadas – donde, resulta, portanto, que não há o código de licenciamento, como se fosse só um e único código;
o licenciamento é um mecanismo de protecção que carece de ser sempre renovado ou desbloqueado, o que implica, sempre que há um problema ou sempre que a licença termina ou está para terminar, que tenha que ir às instâncias e alterar o respectivo ficheiro, neste sentido, invoca o depoimento da testemunha EE, cfr. aos minutos 54:45 – 55:05 do ficheiro áudio 20210917144426_15995393_2871606 em que se refere à forma como a gestão do licenciamento é operado;
o problema está no código fonte, cfr. neste sentido, a testemunha EE, cfr. Aos minutos 55:10 – 56:30 do ficheiro áudio 20210917144426_15995393_2871606 em que se refere à forma como a gestão do licenciamento é operado
Finalmente, entende que vem julgado como não provado que, t) toda a documentação técnica a que alude a requerente não existe, nem era suposto que existisse.
Entende a requerida que foi produzida prova no sentido de que a documentação técnica pretendida não existe e, não existe porque não era suposto que existisse - aqui se excluindo, naturalmente, a documentação que já foi entregue e o código fonte;
Este facto mostra-se em oposição com o facto do ponto 13) e, nessa medida, os supra mencionados meios de prova (testemunhas AA e EE) permitem que se dê como provado qual a documentação técnica que não era suposto existir;
todavia, num outro prisma está a primeira parte do facto: é que, com a excepção da documentação que já foi entregue, a demais não existe;
o facto vindo de referir resulta, também, do que as testemunhas foram referindo:
- -AA, cfr. aos minutos 1:10:00 a 1:15:00 do ficheiro áudio 20211008101105_15995393_2871606, refere-se à ausência de caderno de encargos, precisando, depois, aos minutos 1:15:00 a 1:17:00 que a requerida desenvolveu toda a documentação solicitada pela requerente, cfr. minutos 1:08:30 a 1:11:55 do ficheiro áudio 20211008150450_15995393_2871606, referindo-se ao manual do troubleshoting, acrescentando que o mesmo nunca foi pedido, tanto mais que o projecto não estava sequer terminado, era um projecto em curso, que nunca chegou a ser concluído cfr. minutos 1:49:10 a 1:52:10 do mesmo ficheiro áudio 20211008150450_15995393_2871606 em que se refere ao acordo-quadro e que nunca ficou definido o que a requerida tinha que entregar cfr. minutos 46:00 a 54:00 do ficheiro áudio 20211015100038_15995393_2871606 em que faz um contexto sobre os entregáveis num projecto normal, acrescentando aos minutos 1:11:00 a 1:13:00 do mesmo ficheiro o que foi acordado e, especialmente, o que não foi acordado;
- -no mesmo sentido, a testemunha EE, cfr. aos minutos 15:29 – 16:10 do ficheiro áudio 20210917144426_15995393_2871606 em que se refere a toda a documentação gerada, minutos 17:10 a 17:45 em que se refere à desnecessidade do manual de troubleshooting, minutos 19:30 a 19:45 em que se refere ao manual de troubleshooting nunca foi pedido, minutos 21:50 a 23:40 em que se refere aos entregáveis que, no caso em concreto, foi solicitado, a saber, as release notes, as funcionalidades que tinham implementado e manuais de parametrização destas funcionalidades, minutos 26:45 a 27:30 sobre a ausência de qualquer solicitação ou queixa relativa aos documentos em falta, minutos 27:20 a 30:00 em que se refere novamente ao manual de troubleshooting.
Daqui, afirma que se impõe se julgue como provado que à data da sentença a requerida, além dos documentos indicados no ponto 14) e do código fonte, não tinha mais algum dos documentos elencados no facto 13) elaborados e produzidos – o que deve ser aditado por se mostrar relevante para o que depois se discutirá a propósito da sanção pecuniária compulsória.
Vejamos.
A questão suscitada pela requerida prende-se essencialmente em saber qual a documentação técnica que está obrigada a entregar.
Enquanto na decisão recorrida se entendeu ser a que consta do ponto 13 dos factos provados, a requerida entende ser só o código fonte.
Como diz a requerente a questão reside em saber o que é, para efeitos da criação e desenvolvimento de um programa de software “feito à medida”, a documentação técnica que deverá ser entregue por parte do seu criador – empreiteiro – à outra parte, o dono da obra.
Da cláusula 17 do contrato, cfr. ponto 12 – não impugnado, resulta que,
- 1.Toda a Documentação Técnica identificada caso a caso e o Código Fonte produzidos e relacionados com o desenvolvimento de software adjudicado por Adenda Contratual, serão propriedade da Contratante, devendo as respetivas versões ser entregues depois da aceitação provisória e antes da aceitação definitiva dos projetos correspondentes;
- 2.Com a declaração de aceitação definitiva ocorre automaticamente a transferência da posse e da propriedade dos elementos fornecidos ao abrigo do contrato para a titularidade da Contratante, incluindo os direitos autorais e outros conexos sobre todas as criações intelectuais abrangidas pelos serviços prestados;
- 3.Pela cessão dos direitos a que alude o número anterior não é devida qualquer contrapartida para além do preço a pagar de acordo com o presente contrato e Planos de trabalhos definidos caso a caso relativos à prestação de serviços de desenvolvimento;
- 4.As demais condições de Propriedade, Direitos conexos, pré-condições com os trabalhos de Desenvolvimento de Software, serão contemplados nos termos e condições específicas de cada Adenda Contratual sempre que tal for o caso.
Donde está, contratualmente, prevista, de resto, a distinção entre a documentação técnica, por um lado e, o código fonte, por outro, como realidades distintas.
Na decisão recorrida, a este propósito, invoca-se o depoimento das testemunhas II e JJ, que trabalharam com as plataformas aqui em causa e, que disseram, de forma tecnicamente muito explicita e desinteressada, qual a documentação técnica dos programas que deveria ser entregue pela requerida à requerente, explicitando, em concreto, a razão pela qual cada um dos elementos da documentação é necessária e qual a sua importância.
De resto, as próprias testemunhas arroladas pela requerida, Eng. EE - que era o responsável para dar suporte às aplicações – e AA, disseram o mesmo – porventura, também, não tendo conhecimento do que em concreto foi contratado, é certo - argumento utilizado pela requerida para descredibilizar os depoimentos das testemunhas arroladas pela requerente.
O primeiro que, para conseguir dar suporte e desenvolvimento a uma aplicação precisa que lhe seja entregue, pelo menos, a seguinte documentação técnica: o código fonte, o código comentado, o manual de administração, o manual de instalação e o manual de utilização, o manual de parametrização, documentação esta que a própria testemunha entende que deveria, no mínimo, ser sempre entregue quando efectuasse um serviço de criação de software para um seu cliente.
E, o segundo que, a documentação técnica de um software deve conter, pelo menos, os seguintes elementos: o código fonte, o código fonte comentado, o manual de instalação, manual de administração, manual de parametrização, todos os elementos da arquitectura de um programa, manual de troubleshooting - logo que as aplicações estejam terminadas – sendo que deverão existir estes manuais para os vários ambientes: de desenvolvimento (testes), qualidade (instalação) e produção.
E, este último, disse mais. Disse, que não ficaram quaisquer desenvolvimentos de software, no caso, por fazer – o que de resto se compatibiliza com o facto de vir provado que os programas estavam em utilização funcional até dia 21 de maio de 2021, D..., cfr. ponto 24; até ao dia 1 de junho de 2021, C..., cfr. ponto 42 e, até ao dia 2 de junho de 2021, E...-F...).
Como refere a requerente a prevalecer o entendimento da requerida traduzir-se-ia, na prática, em que tendo adquirido o software por mais de um milhão de euros, recebia um mero código de instruções (código fonte) e era obrigada a contratar uma terceira entidade para fazer um estudo aprofundado desse mesmo código para decompor essas mesmas instruções e tentar ver – provavelmente através da técnica de experimentação/resultado/problema/solução - como é que o programa se parametrizava, como é que se instalava, como é que se usava e como é que se resolviam os problemas que se viessem a verificar.
E não se diga, como faz a requerida, que pelo facto de os programas em causa terem sido, nos seus primórdios, iniciados por uma outra entidade que não tem obrigação de entregar a documentação em causa, porquanto os programas são unos, não divisíveis, tendo sido desenvolvidos, parametrizados e por si instalados, que lhe deu suporte, durante vários anos, desde a sua instalação até ao ano de 2021.
Ou, que deve ser retirada deste ponto a referência a todos os documentos que não foram acordados, de que seria exemplo o descritivo funcional, a documentação técnica, as licenças, o manual do utilizador e a documentação do projecto.
É certo, cfr, ponto 80, que o licenciamento foi efectuado através da implementação de um motor/aplicação, que é sua propriedade.
Não está em causa.
Está condenada a entregar o código fonte sem o mecanismo de licenciamento, que está ali alojado.
Ou que se não mostra equiparável a documentação relativa ao licenciamento com a demais documentação elencada no ponto 13), tanto mais que nada tem que ver o desenvolvimento das aplicações – como vimos a cláusula 17.ª do contrato prevê a distinção entre toda a documentação técnica e o código fonte.
Ou que não estamos perante um cenário ideal, como transmitido pelas testemunhas arroladas pela requerente - antes perante um desenvolvimento que foi tudo menos convencional,
- -desde logo, porque o código original começou por ser desenvolvido por uma outra empresa – A...,
- -tendo-se trabalhado sem caderno de encargos, sobre uma aplicação já existente, em que as especificações do que se pretendia do desenvolvimento iam sendo fornecidas,
Ou que não havendo cronograma de todo o projecto, as partes não sabiam o que entregar e quando entregar – e que os sucessivos desenvolvimentos iam decorrendo à medida que os clientes da requerente iam solicitando alterações, sendo certo que, não obstante os desenvolvimentos terem terminado em 2017, sempre foi um projecto inacabado e havia a expectativa de ambas, de que novos desenvolvimentos fossem ocorrendo.
Ou que não foi acordado, como normalmente, que no final do projecto, a empresa de desenvolvimento procede à entrega do programa, código fonte e demais entregáveis que foram previamente negociados, estando o dono de obra a proceder à recepção da “obra”.
Nem se diga que estas anormalidades, esta falta de tipicidade, não era do conhecimento das testemunhas arroladas pela requerente.
As testemunhas não falaram de nenhuma situação abstracta, vaga ou genérica. Falaram do seu conhecimento técnico, pessoal, sobre o caso concreto, sobre os seus contornos, características, finalidades, objectivos e situação em concreto em que se actualmente se encontra.
Como, de resto, as testemunhas da requerida.
Isto é, nenhuma delas sabe o que em concreto foi contratado. Sabem, todas, no entanto, quais as finalidades dos serviços prestados e da forma de resolver o impasse a que chegou o funcionamento das plataformas.
Ou que estamos numa situação em que existem duas empresas: a primeira cria uma base de software e a segunda vem “acabar a obra” e, não é necessário que esta segunda crie a documentação em falta, já que a responsabilidade é da primeira empresa.
Ou que a ausência de caderno de encargos haja impedido a requerida de desenvolver toda a documentação solicitada pela requerente
Ou que o manual do troubleshooting nunca foi pedido, tanto mais que o projecto não estava sequer terminado, era um projecto em curso, que nunca chegou a ser concluído.
Ou que no acordo-quadro nunca ficou definido o que a requerida tinha que entregar.
O alegado contexto de atipicidade, de anormalidade, não é, seguramente, de molde, a descredibilizar os depoimentos das testemunhas arroladas pela requerente. Doutra forma, também, ficaria abalada a credibilidade do depoimento das testemunhas da requerida.
Pois que se é certo que fizeram referências a projectos dentro da normalidade – reportada ao fim em vista com a prestação deste tipo de serviços - na falta de caderno de encargos, de cronograma, de acordo quadro, estabelecido, por escrito, de ter iniciado o código original e de o projecto estar inacabado, o certo é que no estado actual em que o mesmo estava, em que a requerente denunciou o contrato teria que estar na posse de todo o manancial de informação, documentação, pressuposta para a sua implementação, para o seu desenvolvimento, para a continuação da prestação de serviços para que contratou com a requerida e, naturalmente, apta a resolver os problemas que fossem surgindo.
Nem se diga que outra anormalidade aqui surge a atinente com a contabilidade com a conta-corrente contabilística, com a forma como as facturas eram, ou não, emitidas e, como os pagamentos eram, ou não, efectuados. E, por quem, já agora.
Para utilizar a expressão da requerida, os entregáveis, dado o seu carácter, absolutamente, essencial e, não acessório, não estavam, naturalmente dependente do acordo das partes, nem podiam estar dependentes do facto de terem sido pedidos, espontaneamente, quando não existiam problemas e tudo parece estar a funcionar como era suposto.
Nem estar dependente - seja lá isso o que for - de o projecto estar terminado, ser um projecto ainda em curso, um projecto que não chegou a ser concluído.
O normal, no silêncio do acordo, é entregar tudo o que se revele como objectivamente necessário para que a requerente possa utilizar o sistema implementado pela requerida, para o bom e cabal exercício das funções a ele inerentes.
Nem se diga que não houve qualquer solicitação ou queixa, extra-judicial, relativa aos documentos em falta.
Não se pode, pois, afirmar, como faz a requerida, que apenas está obrigada a entregar o que as partes acordaram, que teria que ser por si produzido -além do código fonte, as release notes e os manuais de parametrização.
Nem se diga que com a entrega da documentação, a requerida vê reduzida a sua garantia de pagamento – no que pode deixar transparecer um braço de ferro:
a requerida retém documentação que devia entregar com base em alegados créditos e com tal comportamento prolonga a inoperacionalidade das plataformas – o que ela sabe, naturalmente, ser altamente constrangedor para a requerente, que,
- -ou paga – sem ter a garantia da colaboração da requerida para as tornar, duradouramente, operacionais,
- -ou coloca em causa a manutenção dos seus contratos com as entidades que serve, a quem presta serviços.
Donde, carece de fundamento razoável e sério, em face da prova produzida, a impugnação deste ponto.
O que de resto atentaria, contra as mais elementares regras da experiência e do senso comum.
Outra forma de entender a própria natureza do contratado implicaria, a definitiva dependência da requerente no tocante a um contrato de assistência técnica vitalício do dono da obra para com o fornecedor do serviço.
Ou com outra entidade que a pudesse substituir, no acompanhamento e fornecimento de suporte técnico inerente ao funcionamento das plataformas por si implementadas.
Ou, em alternativa, como sugere a requerente, a necessidade de enveredar pelo método da experimentação.
Da mesma forma, em relação aos pontos 36), 51), 64) e 71) onde, se faz, claramente, referência que a falta do código fonte – que é considerado nesse contexto como sendo documentação técnica – é a razão de ser impossibilidade da recorrida de eliminar a rotina informática que impede o funcionamento das plataformas.
Carece, pois de fundamento, também – a par da já analisada acerca do ponto 13 - a alteração destes pontos, com a exclusão da referência, a par do código fonte, da documentação técnica da plataforma.
Quanto aos pontos 37, 52 e 65 - de igual forma, a requerida não entregou à requerente o código do licenciamento que lhe permitiria desbloquear as funcionalidades das plataformas D..., C... e E...;
Cumpre salientar que o bloqueio das plataformas informáticas deriva de um processo de licenciamento implementado pela requerida, que activa ou desactiva o mesmo, com base num código de licenciamento, que não foi disponibilizado à requerente, cfr. pontos 34, 35, 49, 50, 62 e 63, nada tendo a requerida feito para desbloquear a situação, cfr. pontos 39, 54 e 67.
Donde não se pode, defender que afinal o dito código de licenciamento não existe, quando resulta dos depoimentos supra mencionados, das testemunhas II, JJ e EE, que afirmaram que que as plataformas não trabalham devido à falta do mecanismo de bloqueio, cuja forma de funcionamento explicaram.
Está, cremos, que bem patenteada, mais que a importância, a essencialidade, da dita documentação técnica, para o bom funcionamento e suporte das plataformas informáticas.
Só na sua posse a requerente está habilitada a garantir uma correcta e eficiente gestão, utilização, funcionamento, suporte, operacionalidade e desenvolvimento, junto das entidades para quem presta serviços.
Gestão que não pode ser, duradouramente, efectuada apenas e só com o acesso ao código fonte, sem acesso a toda a outra documentação técnica, essencial para o bom desenvolvimento e utilização das ditas plataformas informáticas a salvo de problemas de cibersegurança.
Quanto à derradeira questão atinente com a não prova dos factos contidos no ponto t).
Com se vê a requerida não provou que não tivesse tal documentação.
Mas também, não se coloca a questão de ter de criar uma nova obra científica, para poder, afinal, cumprir com a decisão recorrida
Com efeito, se a requerida desenvolveu e implementou para a requerente todos aqueles programas informáticos, não lhe seria possível fornecer o serviço que forneceu ao longo de diversos anos, se não estivesse na posse de todos elementos necessários para o desenvolvimento e suporte das plataformas, que foram ao longo dos anos, por si arquitectadas, desenvolvidas, instaladas e parametrizadas.
Donde, carece de fundamento a pretensão da requerida de ver afirmado que “à data da sentença, além dos documentos indicados no facto 14) e do código fonte, não tinha mais algum dos documentos elencados no facto 13) elaborados e produzidos“.
II. 3. 2. 2. Recurso da requerente.
Discorda a requerente do facto provado no ponto 90 – “A Requerente deve à Requerida valores relativos aos serviços por esta prestados, em montante não concretamente apurado”.
Este facto foi julgado como provado com base na seguinte fundamentação:
relativamente à dívida à requerida, o tribunal convenceu-se que efetivamente, pelo menos em termos perfunctórios, resultou demonstrado que são devidos valores pela requerente.
Porém, quer por força da dificuldade de pagamento, que muitas vezes tinha que ser realizado através de outras entidades/sociedades/pessoas, quer porque as faturas eram emitidas de acordo com a possibilidade de realizar pagamentos, quer por força das negociações que estavam a ser discutidas entre as partes, nos termos das quais havia uma redução do montante que a requerida afirmava ser-lhe devido, quer porque os documentos juntos aos autos e, ainda, a falta deles, e por muitas contas que se fizessem não foram conclusivos, quer porque a própria representante legal da requerente, mesmo nos emails trocados, nunca referiu exatamente que concordava com o valor da dívida indicado, na sua totalidade, quer porque esta variava nos montantes (chegando a afirmar que pretendia dois milhões de dólares), não se pode aferir do seu exato montante.
Para tal contribuiu ainda o depoimento da testemunha DD, que afirmou ter realizado pagamentos à requerida, sendo certo que perpassou do seu depoimento que começaram a subsistir dúvidas sobre aquilo que era pago, o que se mantinha em dívida e se eventualmente nada era devido (o que também era contraditório com a posição assumida pela representante legal da requerente nos diversos emails constantes dos autos que assumia existirem dívidas).
Outra testemunha que sobre tal matéria depôs foi o AA, cujo depoimento, infelizmente, não pode de todo ser acolhido na medida em que desde a identificação, já que afirmou estar desempregado, quando na realidade é o representante legal de uma sociedade denominada B..., com autorização da requerida, e que aos costumes afirmou nunca ter tido nenhum vínculo formal com a requerente, acabando por reconhecer que desempenhou o cargo de diretor executivo e, ainda, recebeu elevados montantes, e que, apesar disso, perpassou do seu depoimento que estava firmemente empenhado em defender os interesses da requerida, desconhecendo-se em que momento o passou a fazer, motivo pelo qual se deu como não provada a alínea k) da matéria não provada.
Explicando, o que resultou das declarações de parte e discretamente do seu depoimento, é que a partir de certa altura surgiram negociações por forma a integrar a requerente, a requerida e a testemunha num novo projeto que tinha por base as plataformas, mas que acabaram por se gorar, pela recusa da representante legal da requerente, o que poderá ter gerado ressentimentos que explicará a forma parcial como depôs.
Por essa razão, esse depoimento não pode merecer qualquer credibilidade.
E assim sendo, teve que resultar provado que o valor da dívida ascende a um montante não concretamente apurado.
Entende, então a requerente que este ponto, “a requerente deve à requerida valores relativos aos serviços por esta prestados, em montante não concretamente apurado” constitui um facto meramente conclusivo, sem qualquer premissa fáctica que possa permitir que o Tribunal a quo concluísse como concluiu, já que para que alguém possa ser considerado credor de outrem tem de, obrigatoriamente, se provar que alguém não pagou – ou pagou a menos - do que era devido.
Donde, defende que deve o mesmo ser considerado como não escrito e, por essa mesma razão, expurgado do rol dos factos provados, nos termos do disposto no artigo 646.º/4 CPCivil.
Como se refere no acórdão do STJ de 1.10.2019, consultado no site da dgsi que deixa transparecer, de resto, entendimento, senão uniforme, pelos menos esmagadoramente maioritário, sobre esta matéria e porque não conseguiríamos dizer nem mais nem melhor, por ser um dos mais recentes, recorreremos às suas palavras: “A distinção entre matéria de facto e matéria de direito tem sido controversa, quer na doutrina quer na jurisprudência.
O acórdão deste Tribunal e desta Secção, de 9/9/2014, proferido no processo n.º 5146/10.4TBCSC.L1.S1, disponível em www.dgsi.pt., faz um resumo dos entendimentos, até então, adoptados, que aqui reproduzimos deste modo:
“na formulação de Alberto dos Reis, «a) É questão de facto tudo o que tende a apurar quaisquer ocorrências da vida real, quaisquer eventos materiais e concretos, quaisquer mudanças operadas no mundo exterior; b) É questão de direito tudo o que respeita à interpretação e aplicação da lei”, cfr. Alberto dos Reis, Código de Processo Civil Anotado, III, 4.ª edição, Coimbra Editora, Coimbra, 1985, 206-207.
Segundo Karl Larenz in Metodologia da Ciência do Direito, tradução portuguesa, Fundação Calouste Gulbenkian, 1997, 433, a “questão de facto” reporta-se ao que efectivamente aconteceu, enquanto a “questão de direito” se identifica com a qualificação do ocorrido em conformidade com os critérios da ordem jurídica.
Existe, contudo, um continuum entre matéria de facto e matéria de direito e não uma oposição absoluta entre ambos os conceitos, pois na concreta aplicação do direito acaba por verificar-se uma correlatividade entre ambos os elementos, cfr. Castanheira Neves, «Matéria de Facto-Matéria de Direito», RLJ, Ano 129, 162-165.
Há que partir, portanto, da unidade do caso jurídico decidendo e dos problemas jurídicos por si colocados, devendo distinguir-se dois tipos de questões: uma que se refere aos dados pressupostos pelo problema concreto – questão de facto – e outra que tem a ver com o fundamento e o critério do juízo e com o próprio e concreto juízo decisório – questão de direito, ibidem, 166.
Na matéria de facto concorrem não apenas dados empíricos, mas todos os pressupostos objectivos do problema colocado, por exemplo, elementos sócio-culturais e até jurídicos, ibidem, 167.
Contudo, a tradição do nosso pensamento jurídico, no seguimento de Alberto dos Reis, ob. cit., 212, considera que a actividade do juiz se circunscreve ao apuramento dos factos materiais, devendo evitar que no questionário entrem noções, fórmulas, categorias ou conceitos jurídicos, inserindo, apenas, nos quesitos e na matéria de facto assente, factos materiais e concretos.
Continua o autor, afirmando que “tudo o que sejam juízos de valor, induções, conclusões, raciocínios, valorações de factos, é actividade estranha e superior à simples actividade instrutória”, ibidem, 212.
Sobre as consequências para o facto de se verificar que da selecção da matéria de facto constam questões de direito, recorremos ao mesmo acórdão:
“devem estas ser consideradas não escritas (à semelhança do que dispunha o anterior CPC no seu artigo 646.º/4, 1.ª parte, embora o novo CPC não contenha norma correspondente, mas cuja conclusão se impõe por imperativo do disposto no seu artigo 607.º/4, segundo o qual na fundamentação da sentença o juiz declara os “factos” que julga provados, o que significa que deve ser suprimida toda a matéria deles constante susceptível de ser qualificada como questão de direito - conceito que, como vem sendo pacificamente aceite, engloba, por analogia, juízos de valor ou conclusivos.
Se, assim acontecer, deve aproveitar-se a decisão na parte relativa à matéria de facto e considerar-se não escrita na parte relativa à matéria de direito.
Assim, embora só acontecimentos ou factos concretos possam integrar a selecção da matéria de facto relevante para a decisão (“o que importa não poderem aí figurar nos termos gerais e abstractos com que os descreve a norma legal, por que tanto envolveria já conterem a valoração jurídica própria do juízo de direito ou da aplicação deste”, cfr. Anselmo de Castro, Direito Processual Civil Declaratório, III, 268-269, são ainda de equiparar aos factos os conceitos jurídicos geralmente conhecidos e utilizados na linguagem comum, verificado que esteja um requisito: não integrar o conceito o próprio objecto do processo ou, mais rigorosa e latamente, não constituir a sua verificação, sentido, conteúdo ou limites objecto de disputa das partes.
Deste modo, “a linha divisória entre facto e direito não tem carácter fixo, dependendo em considerável medida não só da estrutura da norma, como dos termos da causa; o que é facto ou juízo de facto num caso, poderá ser direito ou juízo de direito noutro. Os limites entre um e outro são flutuantes”, cfr. Anselmo de Castro, Ibidem.
O que num caso pode ser facto ou juízo de facto, noutro pode ser juízo de direito, cfr.Abel Simões Freire, «Matéria de Facto – Matéria de Direito», 2003, ob. cit., 7.
De forma idêntica, adoptando o mesmo critério, tem decidido a jurisprudência, entendendo que são de afastar expressões de conteúdo puramente valorativo ou conclusivo, destituídas de qualquer suporte factual, que sejam susceptíveis de influenciar o sentido da solução do litígio, ou seja, que invadam o domínio de uma questão de direito essencial, cfr. Acórdãos do STJ de 23/9/2009, processo n.º 238/06.7TTBGR.S1; de 9/12/2010, proc. 838/06.5TTMTS.P1.S1; de 15/12/2011, proc. 342/09.0TTMTS.P1.S1; de 11/7/2012, proc. 3360/04.0TTLSB.L1.S1; de 12/3/2014, proc. 590/12.5TTLRA.C1.S1 e de 7/5/2014, proc. 39/12.3T4AGD.C1.S1, todos disponíveis em www.dgsi.pt..
Assim, a natureza conclusiva do facto pode ter um sentido normativo quando contém em si a resposta a uma questão de direito ou pode consistir num juízo de valor sobre a matéria de facto enquanto ocorrência da vida real. No primeiro caso, o facto conclusivo deve ser havido como não escrito. “No segundo, a solução depende de um raciocínio de analogia entre o juízo ou conclusão de facto e a questão de direito, devendo ser eliminado o juízo de facto quando traduz uma resposta antecipada à questão de direito”
Alegadamente a suportar a sua pretensão invoca a requerente o acórdão deste tribunal de 13.3.2013, no processo 400/09.0PAOVR.C1.P1 (e o ali citado acórdão do STJ de 5.2.2009) em que foi relatora a Mma. Juíza Desembargadora Eduarda Lobo e, não como alega, o M.mo Juiz Desembargador Eduardo Lobo – o que desde logo, indesmentivelmente deixa transparecer a falta de cuidado no que ali se decidiu - acessível in www.dgsi.pt.
E o que ali estava em causa eram as expressões, “repentina e inopinadamente”, “apesar da tentativa em se desviar para a faixa contrária não conseguiu evitar a colisão”, “o acidente deveu-se única e exclusivamente à condução desatenta e descuidada do arguido” e, “o arguido agiu livre voluntária e conscientemente sem atender às regras estradais exigíveis”.
Onde, se decidiu que apenas foi considerada conclusiva e tida como não escrita a expressão “o acidente deveu-se única e exclusivamente à condução desatenta e descuidada do arguido”.
Não se conhece, de facto – nem a requerente a vislumbra, pois que a teria seguramente invocado – qualquer decisão que haja entendido que a expressão “fulano deve a sicrano” é conclusiva e tem que se considerar como não escrita.
Mesmo que formada a convicção da existência de uma dívida, apenas falte o convencimento do seu valor em concreto e, se afirma que seja quantia não concretamente apurada.
Esta circunstância não é de molde a impedir que se afirme a existência da dívida, como parece evidente, de resto.
O entendimento da requerente não tem qualquer fundamento nem no texto da lei, nem na razão de ser da aludida proibição.
Não se vislumbra, de resto, como pode a linguagem jurídica traduzir a existência de uma dívida – a não ser adoptando a linguagem comum, corrente.
Nem a própria requerente a vislumbra, como adiante se verá, pois que propõe que se tenha como não escrito o ponto 90, onde se afirma que deve à requerida, para ser substituído por outro onde se afirma que é a requerida que lhe deve a ela, porventura convencida que este já contém matéria de facto, dependendo, assim, em absoluta geometria variável, de quem é a pessoa do devedor e do credor: se for eu, o devedor, é matéria de direito e deve ser tida como não escrita; se for eu o credor, pode prevalecer.
Elucidativo.
Improcede, assim, de forma assaz, manifesta, este segmento do recurso.
Quanto ao essencial.
Entende a requerente que não existe, nem nos factos provados nem na fundamentação, da decisão recorrida, a referência a uma ou mais facturas que fossem devidas, o suposto valor em dívida ou a data de vencimento dessa(s) factura(s), nem, tão pouco, que trabalhos ou serviços estão, alegadamente, por pagar.
Donde não se pode afirmar ser devedora da requerida, pelo contrário, afinal ela é que é credora da requerida, propondo que o ponto 90, passe a ter a seguinte redacção”a recorrida faturou à recorrente a quantia total de € 1.238.403,08 e esta, por si ou por interposta pessoa, pagou àquela a quantia total de €1.560.392,56, pelo que a recorrida é devedora à recorrente da quantia de €321.989,48”.
Esta proposta de redacção no seguimento da sua pretensão de ter como não escrito o actual ponto 90, porque, no seu entendimento, contém matéria conclusiva, se não abala de forma decisiva o mérito da sua pretensão, seguramente, também, aqui, revela alguma ligeireza, contradição e incoerência.
Sustenta, ainda assim, a requerente esta sua pretensão, nos seguintes elementos de prova:
- depoimento da testemunha Eng. DD, que disse que,
o Dr. GG, anterior gerente da A..., entendia que não devia qualquer valor à B..., sendo que a sociedade K... ficou de pagar e pagou todas as facturas da A... a partir de agosto de 2016 até dezembro de 2018; era habitual serem pagos valores através de contas da ... e de outras entidades;
- declarações de parte prestadas pela Dra. CC, que disse que,
a A... para além de fazer pagamentos da sua conta, fazia também pagamentos à B... através de outras entidades, como o Dr. GG, ela própria refere que fez pagamentos por transferência bancária das suas contas do Banco 1... e Banco 2..., tendo inclusive efectuado pagamentos em numerário em Angola; foram efectuados outros pagamentos através das sociedades J..., K... e I..., tendo a mesma confirmado que os pagamentos que foram juntos com o requerimento da recorrente de 07-09-2021, com a referência CITIUS n.º 29832434 foram todos efetuados à B... por conta da A...;
- -prova documental - e-mails – onde a requerente, por diversas vezes, socorria-se de diversas entidades para efectuar pagamentos em seu nome à recorrida, sendo essas entidades, entre outras, I..., SA, também denominada I..., J..., K... e Dra. CC, legal representante da recorrente:
- -e-mail de AA, datado de 03-12-2019, junto com o documento 1 e 2 da oposição apresentada, com a referência CITIUS n.º 29713102, no qual é referido no quadro denominados “VALORES RECEBIDOS PELA B...” a recepção de valores da I..., da Dra. CC e de “Outras Fontes”.
- -e-mail de Eng. BB – legal representante da recorrida - datado de 3-01-2020, junto com o documento 3 da oposição apresentada, com a referência, no qual é referido no quadro denominados “VALORES RECEBIDOS PELA B...” a recepção de valores da I..., da Dra. CC e de “Outras Fontes”
- -e-mail do Eng. BB – legal representante da recorrida -datado de 3-11-2016 e da Dra. CC datado de 02-11-2016, junto com o documento 3 com o requerimento da recorrente de 07-09-2021, com a referência CITIUS n.º 29832434, no qual é referido que foram recebidos valores pela B... da J... (...), da Dra. CC, em numerário e por transferência bancária por conta de pagamentos devidos pela recorrente.
Daqui afirma que, com clareza, todas estas entidades procederam a pagamentos junto da requerida em nome e por conta da requerente, pelo que se torna essencial, verificar, concretamente, que pagamentos foram efectuados por estas entidades, qual a sua influência na conta corrente, no sentido de se poder concluir pela inexistência de qualquer dívida da sua parte:
conforme resulta do documento 2 junto pela recorrente no dia 07-09-2021, com a referência CITIUS n.º 29832434 – que contém um extracto de conta emitido pela própria recorrida em 05-03-2021 – o qual não foi impugnado pela mesma – verifica-se que a mesma facturou um total de €1.238.403,08, entre 06-08-2014 e 18-03-2020, sendo este o valor total que foi debitado pela recorrida à recorrente ao longo de toda a relação contratual;
igualmente, resulta da análise à aludida conta corrente que a requerida confessa, nesse mesmo documento, que a recorrente lhe pagou, pelo menos, €707.769,46, nas datas mencionadas nessa conta corrente;
nesse mesmo documento 2 com a referência CITIUS n.º 29832434, juntou os comprovativos dos pagamentos constantes da aludida conta corrente – com as referências P1 a P22 – documentos estes que, igualmente, não foram impugnados pela recorrida – os quais foram efectuados, directamente, para a conta da requerida, conforme deles resulta;
conforme resulta do documento 2 – que reflecte um conjunto de comprovativos de transferências bancárias e pagamentos efectuados directamente na conta bancária da recorrida, os quais esta não colocou em causa, nem deu qualquer justificação para os mesmos - com a referência CITIUS n.º 29832434 existem diversos pagamentos efectuados pela recorrente à recorrida que não se encontram lançados na conta corrente:
- efectuados pela Dra. CC directamente à recorrida em nome da recorrente,
€20.000,00 no dia 26-04-2017, conforme resulta do pagamento com a referência C1 junto com o documento 2;
€13.596,00 no dia 07-10-2019, conforme resulta do documento 2 junto com a oposição com a referência CITIUS n.º 29713102, no qual é confessado o recebimento deste valor, no quadro denominado “VALORES RECEBIDOS PELA B...”;
€10.000,00 no dia 01-10-2019, conforme resulta do pagamento com a referência C2 junto com o documento 2;
€5.000,00 no dia 29-11-2019, conforme resulta do pagamento com a referência C3 junto com o documento 2
€25.000,00 no dia 03-10-2019, conforme resulta do documento 2 junto com a oposição com a referência CITIUS n.º 29713102, no qual é confessado o recebimento deste valor no quadro denominado “VALORES RECEBIDOS PELA B...” com a referência CD que é relativo às iniciais de Dr. CC.
€60.022,00 no dia 30-10-2015, conforme resulta do e-mail efectuado pelo legal representante da recorrida no dia 3 de novembro de 2016, no qual este refere ter sido pago pela Dra. CC esse valor por conta do projecto MINJDH, pagamento este com referência C4 junto com o documento 2,
tudo num total de €133.618,00.
- efectuados em nome da recorrente por outras fontes e não lançado na conta corrente da recorrida com a recorrente:
conforme resulta do primeiro quadro denominado “VALORES RECEBIDOS PELA B...” do documento 2 junto com a oposição com a referência CITIUS n.º 29713102 a recorrida confessa, igualmente, ter recebido a quantia total de € 20.000,00, em dois pagamentos de € 10.000,00, no dia 02-10-2019 através “Via Transferências Bancárias de Outras Fontes (2x10K);
- efectuados pela sociedade J...:
€46.025,00 no dia 02-02-2015, conforme resulta do pagamento com a referência W1 junto com o documento 2;
€125.000,00 no dia 27-04-2015, conforme resulta do pagamento com a referência W2 junto com o documento 2;
€75.000,00 no dia 09-07-2015, conforme resulta do pagamento com a referência W3 junto com o documento 2;
€93.893,00 no dia 30-10-2015, conforme resulta do pagamento com a referência W4 junto com o documento 2;
€70.000,00 no dia 28-12-2015, conforme resulta do pagamento com a referência W5 junto com o documento 2;
€47.087,08 no dia 03-02-2016, conforme resulta do pagamento com a referência W6 junto com o documento 2,
tudo num total de € 457.005,08.
- efectuados pela sociedade I..., SA:
€50.000,00 no dia 31-07-2019, conforme resulta do pagamento com a referência A1 junto com o documento 2;
€20.000,00 no dia 19-12-2019, conforme resulta do pagamento com a referência A2 junto com o documento 2;
€30.000,00 no dia 29-01-2020, conforme resulta do pagamento com a referência A3 junto com o documento 2;
€20.000,00 no dia 02-03-2020, conforme resulta do pagamento com a referência A4 junto com o documento 2;
€15.000,00 no dia 24-02-2020, conforme resulta do pagamento com a referência A5 junto com o documento 2;
€20.000,00 no dia 26-05-2020, conforme resulta do pagamento com a referência A6 junto com o documento 2;
€25.000,00 no dia 08-06-2020, conforme resulta do pagamento com a referência A7 junto com o documento 2;
€37.000,00 no dia 22-07-2020, conforme resulta do pagamento com a referência A8 junto com o documento 2; e
€25.000,00 no dia 06-08-2020, conforme resulta do pagamento com a referência A9 junto com o documento 2,
tudo num total de, pelo menos, €242.000,00.
Daqui afirma a requerente que afinal, de todos estes pagamentos, em seu nome, pagou a mais, pelo menos, a quantia €852.623,10, o que somado ao valor que já tinha sido creditado pela recorrida à recorrente na conta corrente – que era de € 707.769,46 – se conclui que pagou um total de € 1.560.392,56, enquanto que o total de facturas emitidas pela recorrida à recorrente foi de, apenas, €1.238.403,08, donde, a requerida é devedora da quantia de €321.989,48.
Vejamos.
Continua, nesta sede, a aludida anormalidade e atipicidade das relações contratuais estabelecidas entre a requerente e a requerida.
Esta invoca a existência de serviços por pagar e aquela alega, a que afinal pagou em demasia.
Desta constatação ostensivo é concluir que em sede de conflito judicial, muito difícil será destrinçar a realidade, num procedimento cautelar – em que basta como é sabido, a mera aparência do direito.
Concerteza que na acção principal, esta questão será objecto de mais e de melhor prova, mormente, de aprofundada análise contabilística, às contas de uma e de outra, em vista a apurar se existem serviços por pagar, facturas por liquidar ou se quem pagou mal, afinal terá que pagar duas vezes.
Seja como for, a leitura conjugada da aludida prova, de natureza pessoal e documental, não tem a virtualidade, o efeito, muito menos, exige ou impõe a alteração do decidido.
Improcede, assim, também, este segmento do recurso.
II. 3. 3. Recurso sobre a matéria de direito.
II. 3. 3. 1. Recurso da requerente.
Como vimos, a decisão recorrida determinou que,
- -a requerida proceda à entrega de determinada documentação técnica e suportes digitais;
- -a ter lugar após a requerente prestar caução, no valor de €610.833,62,
- -a requerida se abstenha de praticar qualquer conduta que possa causar danos à requerente e aos clientes da mesma, nomeadamente através da suspensão, alteração, utilização ou comercialização das plataformas C..., E..., D... E F...;
- -o pagamento pela requerida de uma sanção pecuniária compulsória no valor de €1.500,00 diários, pelo não cumprimento do determinado.
E, fê-lo com base na seguinte fundamentação:
Os procedimentos cautelares são meios de tutela cível cuja finalidade é garantir o efeito prático e útil da acção principal, conservando a situação que se verificava aquando do surgimento do litígio a resolver (providências cautelares conservatórias) ou antecipando a realização do direito que se pretende ver reconhecido na acção principal (providências cautelares antecipatórias). O nosso Código de Processo Civil prevê diversas providências cautelares especificadas e residualmente um procedimento cautelar comum, no âmbito do qual podem ser deduzidas providências cautelares não especificadas (art. 362º do CPC), as quais só podem ser decretadas se estiverem preenchidos todos os pressupostos de que dependem, a saber: probabilidade séria da existência do direito invocado (fumus bonus iuris); fundado receio de lesão grave ou dificilmente reparável (periculum in mora); adequação da providência à situação de lesão eminente; não existência de providência que acautele aquele direito; e não ser o prejuízo resultante da providência superior ao dano que com ela se pretende evitar.
In casu, o procedimento requerido é não especificado.
Na situação em apreço, e reduzindo o caso à sua expressão mais simples, a Requerente, proprietária de bases de dados devidamente identificadas e instaladas em diversos clientes seus, cujos desenvolvimentos e implementação foi levada a cabo pela Requerida, no âmbito do contrato-quadro celebrado e acordos subsequentes, vê-se impedida de disponibilizar os respetivos serviços por força de um programa de licenciamento, cuja função era protegê-la junto dos seus clientes, cujas licenças caducaram, e que por não dispor do código fonte nem da documentação necessária, não pode retirar tal programa das suas bases de dados.
Analisemos, passo a passo, cada uma das questões suscitadas, começando pela reclamada entrega do código fonte.
Resulta dos autos que as partes celebraram entre si um contrato-quadro, denominado “acordo-quadro de desenvolvimento de software”, que foi alvo de desenvolvimentos posteriores, e através dos quais a Requerente adjudicou à Requerida a prestação de serviços na área informática, designadamente serviços de desenvolvimento e implementação de programas informáticos, de acordo com as especificações daquela, bem como, numa fase posterior, de serviços de suporte.
O regime de proteção jurídica dos programas de computador foi instituído pelo D.L. 252/94, de 20.10, o qual transpôs para a ordem jurídica interna a Diretiva n.º 91/250/CEE, do Conselho de 14.05, publicada no Jornal Oficial das Comunidades Europeias, L 122/42, de 17/5/1991 e que foi notificada ao Estado Português, para cumprimento, em 15 de Maio de 1991.
De acordo com o nº 3 do art. 3º de tal diploma legal “Quando um programa de computador for criado (…) por encomenda, pertencem ao destinatário do programa os direitos a ele relativos, salvo estipulação em contrário ou se outra coisa resultar da finalidade do contrato”.
A Requerida não colocou em crise, quanto ao código fonte, que a sua propriedade é da Requerente, motivo pelo qual se torna redundante proceder aqui a maiores desenvolvimentos.
O que esta discute de forma muito clara, é o direito a reter tal código, por força dos valores que entende serem-lhe devidos, pelos serviços prestados no desenvolvimento e na atividade de suporte, e que entende ascenderem ao montante de €610.833,62.
Nesta sede, apesar de ser resultado indiciariamente demonstrado que existe uma dívida a seu favor, certo é que o respetivo montante não resultou apurado.
Cabe, assim, apreciar se a Requerida goza de direito de retenção sobre o código fonte dos programas desenvolvidos para a Requerente e, em caso afirmativo, se é lícita a sua recusa a proceder à respetiva entrega.
O direito de retenção constitui uma forma de autotutela de direitos, com uma dupla função (de garantia e coercitiva ou compulsória), e encontra-se previsto, com carácter genérico, no art. 754º do Cód. Civil, podendo ser definido como a faculdade conferida pela lei ao credor de continuar na detenção de uma coisa pertencente a outrem e de não a entregar, como deveria, a outra pessoa enquanto o seu crédito não for satisfeito (cfr. Ac. do S.T.J. de 14.12.2016, disponível na base de dados da dgsi, local a que pertencerá toda a jurisprudência citada na presente decisão sem indicação de origem).
Trata-se de um direito real de garantia.
Estabelece o art. 754º o regime-base ou critério geral do instituto, o qual pressupõe que o titular do direito à entrega seja sujeito passivo de uma relação creditícia cujo credor é obrigado à entrega da coisa, bem como a conexão entre este crédito, seja a título de despesas feitas por causa dela ou de danos por a mesma causados, e a coisa a cuja entrega está obrigado.
São seus requisitos, nos termos das disposições conjugadas dos art.s 754º e 756º do C.C, de caráter cumulativo, os seguintes:
- a)A detenção lícita de uma coisa, suscetível de penhora, por alguém a quem ela não pertence;
- b)Que esse detentor seja credor da pessoa a quem a coisa deve ser entregue;
- c)Que esse crédito resulte de despesas feitas, de boa fé, por causa da coisa que tem que ser entregue ou de danos por esta causados;
- d)Que o titular do direito à entrega não tenha prestado caução.
Ora, dos factos provados resulta que o crédito a que se arroga a Requerida decorre do preço dos serviços prestados no âmbito da relação contratual havida com a Requerente e que teve por objeto os programas ou plataformas informáticas cujo código fonte esta exige que lhe seja entregue.
Mais resulta que nos sete anos em que perduraram as relações contratuais entre as partes que o código fonte esteve sempre com a Requerida e apesar de se desconhecerem os termos acordados para tal situação de facto, nada resultou provado que permita concluir que essa detenção fosse ilícita.
E o certo é que apesar de se não ter apurado o valor exato do crédito, o que em sede própria poderá ser amplamente debatido e determinado, discussão que o procedimento cautelar, por razões óbvias, não permite, tal não obstaculiza a que não tenha que se retirar efeitos do reconhecimento da sua existência.
Isto posto, e assim perspetivado, há que concluir que estão reunidos os pressupostos do direito de retenção.
Porém, e como reverso da medalha, apurou-se que a Requerente, proprietária de várias plataformas informáticas instaladas em vários clientes, viu-se confrontada com a sua inoperacionalidade, o que diretamente lhe causa prejuízos, assim como aos seus clientes.
Obviamente que a questão da inoperacionalidade das plataformas resulta da implementação de um programa de licenciamento pela Requerida, o que foi feita com o acordo da Requerente, e cuja finalidade era, como são todos os licenciamentos inseridos em programas informáticos destinados a serem licenciados a terceiros, a salvaguardar a posição da própria Requerente.
Cessadas as relações contratuais estabelecidas entre as partes e sem que alguma vez a Requerida tivesse fornecido à proprietária das plataformas o código de licenciamento e forma de o ativar e desativar, esta última, por omissão, deixou que as licenças caducassem.
Apurou-se que para retirar tal licenciamento, que a Requerente de todo não deseja manter, face aos elevados prejuízos que daí estão a resultar, é necessário o acesso, para além do mais a que infra nos referiremos, ao código fonte.
Por esta via, logra a Requerente indiciariamente demonstrar o seu direito, cuja probabilidade de sucesso na ação que venha a ser instaurada e de que dependerá a presente providência é elevada (summaria cognitio).
Para além disso, demonstrou que se encontra a sofrer uma grave lesão, quer própria, quer perante os seus clientes, que inclusivamente lhe poderão exigir responsabilidades, lesão essa que o tempo tenderá a agravar exponencialmente, e que por essa razão tem que ser cautelarmente coartada.
Temos assim preenchido o segundo requisito para o decretamento da providência: a demonstração do periculum im mora, ou seja, o agravamento que a natural demora da decisão definitiva inevitavelmente acarretaria para a Requerente e a gravidade e difícil reparação dos danos que tal espera determinaria.
Isto posto, há agora que conjugar a tutela pretendida pela Requerente, de natureza urgente, com o direito reconhecido à Requerida.
Dispõe o art. 374º n.º 2 do C.P.C. que sempre que o julgue conveniente em face das concretas circunstâncias, o juiz pode fazer depender a concessão da providência cautelar da prestação de caução adequada.
Trata-se de uma condição suspensiva ou contracautela para garantia dos danos, constituindo uma válvula de escape que no caso, permite restabelecer um equilíbrio entre os direitos, ainda que sumariamente demonstrados, das partes.
Tanto mais que prescreve o art. 756º alínea d) do C.C. que não há direito de retenção se a outra parte prestar caução, o que vai de encontro ao que vimos afirmando.
Não deixa de ser relevante a circunstância da Requerente ter a sua sede em Angola e aí desenvolver a sua atividade, nem tão pouco, como o afirma a Requerida, constituir o código fonte, pela sua importância, a garantia de que, a ser definitivamente reconhecido o seu crédito, tenha possibilidade de se ver do mesmo ressarcida.
Aqui chegados, e depois de se ter em conta que a Requerente se ofereceu a prestar caução, o que significa que igualmente reconhece que a entrega do código fonte e demais documentação, fragilizará e esvaziará o direito da Requerente, não se tendo determinado o valor do crédito, terá este que corresponder ao montante a que se arroga aquela, ou seja, ao montante de €610.833,62, que corresponde ao valor a cujo pagamento poderá, de forma definitiva, vir a Requerente a ser condenada,
Para o efeito, fixar-se-á o prazo de dez dias para que a Requerente indique o modo pelo qual irá prestar a referida caução, após o que será a mesma prestada em igual prazo.
Relativamente à documentação cuja entrega é pretendida, igualmente demonstrou a Requerente a necessidade de a possuir, face aos obstáculos criados ao acesso à plataforma e a fim de os remover, sendo que igualmente se demonstrou que a Requerida estava obrigada à sua entrega por força e pela natureza dos serviços de desenvolvimento, implementação e suporte que prestou durante anos, e pelos quais pretende ser paga.
Obviamente que de tal documentação será excluída aquela que não se provou fazer parte do conjunto de entregáveis ou, até, que seja necessária para o desbloqueio das plataformas, que se reduz aos manuais de formação de formadores das aplicações identificadas no n.º 8 do art. 13º da petição inicial, bem como aquelas que se provou terem sido entregues, ou seja, as release notes e os manuais de parametrização, cuja existência e necessidade, após 2016, ano em que cessaram os desenvolvimentos, não resultou provada.
Porém, pese embora a Requerida não tenha quanto a esta invocado o seu direito de retenção, certo é que pela forma como a Requerente indissociavelmente fez a ligação entre a documentação e o código fonte, será a entrega que vier a ser determinada, por se nos afigurar ser a solução mais adequada, igualmente subordinada à condição de prestação de caução.
Cabe salientar que quanto ao programa (/motor de licenciamento, estamos manifestamente no âmbito de uma (indesejada) relação de licenciamento de software, estabelecida entre Requerente e a Requerida, motivo pelo qual jamais teria aquela o direito ao respetivo código fonte, por não ser titular do programa.
Porém, é manifesto que lhe assiste o direito às chaves e registos de licenciamento. Também as bases de dados, cujo conteúdo é sensível e pertença de terceiros,
cuja dissipação causará a responsabilização da Requerente perante os seus clientes, terão que ser entregues.
Considerando o conteúdo técnico do código fonte e a fim de prevenir dissensos entre as partes quanto ao que efetivamente foi entregue, será ordenado que fique uma cópia nos próprios autos.
Quanto ao pedido de decretamento da providência no sentido de ser ordenado à Requerida que efetue todas as operações que sejam necessárias para que a Requerente passe a ter o controlo total e integral das plataformas informáticas C..., E..., D... E F... afigura-se-nos que o seu caráter vago e ativo não é compatível com as demais providências decretadas na medida que estas últimas já têm por finalidade permitir à Requerente obter o controlo total das plataformas, sem que se vislumbre, em concreto, quais os atos a praticar ativamente pela Requerida para que tal possa vir a ser assegurado.
Para além disso, tal providência permitiria o acesso da Requerida às plataformas, o que no limite conflituaria com a determinação de se abster de as utilizar.
Por fim, e quanto à sanção pecuniária compulsória requerida, há que tecer os seguintes considerandos:
De acordo com o art. 829ºA do C.C. “Nas obrigações de prestação de facto infungível, positivo ou negativo, salvo nas que exigem especiais qualidades científicas ou artísticas do obrigado, o tribunal deve, a requerimento do credor, condenar o devedor ao pagamento de uma quantia pecuniária”, “fixada segundo critério de razoabilidade”, “por cada dia de atraso no cumprimento ou por cada infração, conforme for mais conveniente às circunstâncias do caso” (nºs 1 e 2). Tal sanção, ordenada e fixada pelo juiz, poderá chamar-se de sanção pecuniária compulsória judicial. Ao invés, a “astreinte” consagrada no n. 4, traduzida num adicional de juros de 5% nas obrigações pecuniárias, “automaticamente devidos”, poderá qualificar-se como sanção pecuniária compulsória legal, na medida em que decorre diretamente da lei (cfr. Calvão da Silva, “Cumprimento e Sanção Pecuniária Compulsória”, pág. 456, e Almeida Costa, “Direito das Obrigações”, 5 edição, pág. 908).
A sanção pecuniária compulsória judicial é a única que nos interessa considerar e distingue-se de qualquer pretensão indemnizatória, emergente da responsabilidade civil do devedor e é dela independente.
Uma vez peticionada pelo credor, cabe ao juiz fixá-la, em função das circunstâncias do caso e segundo critérios de razoabilidade ou de equidade, por forma a cumprir eficazmente a respetiva função compulsória, para o que se levará em linha de conta, nomeadamente, a capacidade económica e financeira do obrigado e a pressão psicológica que a expectativa do agravamento da sanção exerça sobre a sua vontade real, embora condicionada pelo valor que a prestação devida revista para o credor.
Assenta, no entanto, o estabelecimento de uma tal sanção na insuficiência da execução específica prevista no art 827º do C:C: para realizar efetivamente o resultado prático do cumprimento de obrigações infungíveis. E a questão da fungibilidade ou da infungibilidade da prestação resolve-se, em termos práticos, pela possibilidade ou pela impossibilidade de ter lugar o cumprimento por terceiro.
Poderá afirmar-se que, em geral, as prestações de coisas são fungíveis e que mesmo que a coisa a prestar seja infungível, ou seja, insubstituível por outra (cfr. o art. 207º do C.C.), há sub-rogabilidade do devedor sem qualquer prejuízo para o credor, que vê o seu interesse plenamente satisfeito pela entrega da coisa, quer seja feita pelo devedor, quer seja feita por terceiro (Calvão da Silva, Cumprimento…, loc. Cit., nota 665).
A obrigação que sobre a Requerida impende configura uma prestação de coisa, de incontroversa infungibilidade, que jamais poderá ser executada por outrem, com plena satisfação do interesse do credor.
Porém, o montante diário de €30.000,00, pese embora os elevadíssimos prejuízos que diariamente decorrem para a Requerente e seus clientes, afigura-se-nos manifestamente elevado, motivo pelo qual se procede à sua redução para o montante de €1.500,00, o qual, aliado à tutela penal das providências decretadas (art. 375º do C.P.C.), será suficiente para compelir a Requerida ao cumprimento do determinado.
II. 3. 3. 2. Versando o recurso sobre matéria de direito, as conclusões devem indicar, as normas jurídicas violadas; o sentido com que, no entender do recorrente, as normas que constituem fundamento jurídico da decisão deviam ter sido interpretadas e aplicadas, e invocando-se erro na determinação da norma aplicável, a norma jurídica que, no entendimento do recorrente, devia ter sido aplicada – artigo 639.º/1 e 2 CPCivil.
Todas as questões de mérito que tenham sido objecto de julgamento na decisão recorrida e que não sejam abordadas nas conclusões do recorrente, mostrando-se objectiva e materialmente excluídas dessas conclusões, têm de se considerar decididas, não podendo de elas conhecer o tribunal de recurso.
II. 3. 3. 3. Entende a requerente que a questão aqui se coloca em saber se se poderia, ou não, condicionar as providências que se decretou à prestação de caução, no valor de € 610.833,62, em face do disposto no artigo 756.º alínea d) CCivil – que tem subjacente o entendimento de que a requerida podia exercer o direito de retenção sobre a documentação que tem em seu poder.
Entende a requerente que a decisão recorrida viola o disposto nos artigos 754.º e 756.º CCivil, pugnando por que se revogue o decidido no segmento e que determina a prestação de caução como condição para a determinada entrega, por não existir direito de retenção.
Isto porque, considera que não estão preenchidos dois dos três requisitos cumulativos para que se reconhecesse a existência do direito de retenção, no caso,
- -a reciprocidade de créditos e,
- -a conexão substancial entre a coisa retida e o crédito do autor da retenção.
Discorda, também, do facto sem qualquer factualidade para apoiar o valor do direito de retenção da requerida, se fixar a caução a prestar em €610.833,62 - valor invocado pela requerida na oposição – quando, afinal, a decisão recorrida afirma que não se apurou o valor da suposta dívida e quando resulta do ponto 23 que a requerida até só pretendia exercer direito de retenção pelo valor de €252.333,62, relativos a serviços de desenvolvimento das plataformas.
II. 3. 3. 3. 1. O texto legal.
Nos termos do disposto no artigo 754.º CCivil “o devedor que disponha de um crédito contra o seu credor goza do direito de retenção se, estando obrigado a entregar certa coisa, o seu crédito resultar de despesas feitas por causa dela ou de danos por ela causados”.
Por seu lado dispõe o artigo 756.º CCivil, que, “não há direito de retenção:
- a)A favor dos que tenham obtido por meios ilícitos a coisa que devem entregar, desde que, no momento da aquisição, conhecessem a ilicitude desta;
- b)A favor dos que tenham realizado de má fé as despesas de que proveio o seu crédito;
- c)Relativamente a coisas impenhoráveis; Quando a outra parte preste caução suficiente”.
Como vimos na decisão recorrida reconheceu-se o direito de retenção da requerida em relação aos elementos que, depois foi condenada a entregar à requerente, apenas depois de a requerente prestar caução.
Isto é teve-se subjacente o entendimento de que com a prestação de caução se afastava, se extinguia o direito de retenção, ou que, pelo menos, traduziria um pressuposto para o não reconhecimento do direito de retenção.
Como se decidiu no acórdão deste tribunal de 12.10.2009, consultado no site da dgsi, “a prestação de caução prevista no artigo 756.º alínea d) CCivil, além de prefigurar um pressuposto negativo do reconhecimento do direito de retenção, configura também forma de extinção de tal direito mesmo quando já reconhecido judicialmente. A caução é meio idóneo para operar a cessação do referido direito real de garantia, e como tal, o processo especial de prestação de caução constitui meio processual adequado”.
Aí se cita,
- -o Prof. Almeida Costa in Direito das Obrigações, 6.ª ed., 766 e nota, “a prestação de caução é ainda susceptível de caber noutras situações assim como “para afastar um direito da outra parte” – e, de entre as “diversíssimas situações de prestação de caução que ilustram o que expõe e se encontram no Cód. Civil”, aquele autor refere precisamente o artigo 756.º alínea d) no caso do direito de retenção;
- -Pires de Lima e Antunes Varela in Cód. Civil Anotado, vol.I, 4.ª ed., quando se referem à “substituição do direito de retenção pela prestação de caução, a requerimento da outra parte como sendo geralmente admitida pelos autores e legislações” - o que já era defendido na vigência do Código de Seabra por Guilherme Moreira in Instituições, II, n.º175, 527, o que faz pressupor que a prestação de caução se prefigura também como forma de cessação daquele direito;
- -Menezes Leitão in Garantias das Obrigações, 2.ª, Almedina, 245, sobre a extinção do direito de retenção, refere que “uma outra causa de extinção do direito de retenção é a sua substituição por caução, face ao que se dispõe no artigo 756.º alínea d). Uma vez caucionado o crédito, o retentor passa a possuir uma garantia de cumprimento pelo que a retenção da coisa deixa de ser legítima”.
Não oferece, pois, dúvida, que através da prestação de caução se afastará o direito de retenção que foi reconhecido à requerida.
pretensão da recorrente na presente acção em que pretende proceder à prestação de caução se inscreve na previsibilidade da lei para os fins pretendidos, isto é, afastar o direito da outra parte relativamente ao direito de retenção judicialmente reconhecido.
A questão, reside, então, a montante, como alega a requerente, em saber se existe o direito de retenção.
O direito de retenção traduz-se, então, no direito conferido ao credor, que tem a posse de uma coisa e está obrigado a entregá-la a outrem, de a reter enquanto não lhe for satisfeito aquilo que, em ligação com ela, lhe é devido.
O que pressupõe,
- -a posse e obrigação de entrega duma coisa;
- -a existência, a favor do devedor, dum crédito exigível sobre o credor e,
- -a existência de uma conexão causal entre o crédito do detentor e a coisa, ou seja, que este crédito se ache ligado à coisa, visando o pagamento de despesas que o detentor com ela efectuou ou a indemnização de prejuízos que em razão dela sofreu – “debitum cum re junctum”, cfr. Antunes Varela, in, “Obrigações”, II, 92, Almeida Costa, in, “Obrigações”, 3ª ed, 699 e Galvão Telles in “O direito de retenção no contrato de empreitada”, in O Direito, 119, 1987, 15, apud acórdão do STJ de 16.5.2019, consultado no site da dgsi.
Independentemente de se saber se existe, ou não direito de retenção no âmbito do contrato de empreitada, polémica de que se dá devida nota nesta decisão do STJ, naturalmente, que a resposta será afirmativa, desde que se verifiquem os apontados pressupostos legais - o empreiteiro, sendo credor do preço, goza do direito de retenção relativamente à obra.
Aí se cita as palavras do acórdão do mesmo tribunal de 10.5.2001, “o empreiteiro mercê da sua específica posição perante o resultado da obra e a atitude possessória que exerce sobre ela, assume, perante a mesma, uma posição de privilégio garantístico de modo a poder reter a coisa em seu poder, perante terceiros”.
E, se invoca o acórdão do STJ de 29.1.2014 – que doravante seguiremos de perto, mesmo com transcrição - para afirmar que, tendo o empreiteiro por causa da relação contratual - obrigação de “facere” - que estabeleceu com o dono da obra, que realizar despesas para a obtenção do resultado que tem que entregar ou restituir, mal se compreenderia que não tivesse o direito de reter a coisa de que resultaram as despesas efectuadas - quando é certo assistir um tal direito àquele que levou a cabo benfeitorias na coisa.
Necessário será, então, desde logo, que o empreiteiro, ou, mais genericamente, o fornecedor de serviços e bens, forneça, total ou parcialmente, os materiais, pois que assim se manterá deles, proprietário até à aceitação da obra, artigo 1212.º/1 CCivil.
E, se assim é, então, não tem direito de retenção porque lhe assiste o direito, mais profundo, de propriedade.
Fora estes casos, assistir-lhe-à o direito de retenção sobre a obra. Ora, no caso, aceite a obra, até se pode entender que a documentação técnica, reportada às plataformas informáticas que implementou para a requerente e, que a requerida foi condenada a entregar já não é sua propriedade.
Mas o que não se verifica, seguramente, é que o crédito que a requerida invoca a sustentar o direito de retenção, para obstar à sua entrega, à requerente, esteja ligado com a documentação retida, visando o pagamento de despesas que com ela efectuou ou a indemnização de prejuízos que em razão dela sofreu.
E, assim, não obstante a invocação do alegado crédito, que aparentemente existe, atinente com o preço (como se assumiu na decisão recorrida, de resto) da prestação de serviços, não legitima o direito de retenção.
Com efeito, do famigerado ponto 90 resulta que “a requerente deve à requerida valores relativos aos serviços por esta prestados, em montante não concretamente apurado”.
Naturalmente, que pode legitimar o exercício de outro direito, vg. a excepção do não cumprimento, por ser o mais patente e ostensivo, mas não o invocado pela requerida.
E, assim, se fica, desde logo, afastada a possibilidade de ser exercido o direito de retenção, consequentemente, fica afastada a possibilidade de o mesmo ser afastado pela prestação de caução.
Donde, não assistindo à requerida o invocado direito de retenção, da mesma forma, por decorrência lógica, não existe a obrigação de a requerente para o paralisar ter que prestar caução.
Estamos assim perante uma obrigação de entrega, por parte da requerida, não condicionada à prestação de caução, por parte da requerente.
Procede, pois neste segmento o recurso da requerente.
II. 3. 3. 2. Recurso da requerida.
Pretende, ainda, a revogação parcial da decisão recorrida quanto à entrega da documentação em falta, com excepção do código fonte, seja porque não existe a obrigação.
Desde logo, com base na pugnada alteração/modificação do julgamento da matéria de facto - pressuposto que, como vimos, não se verifica - ficando, portanto, com base neste fundamento, prejudicada a sua pretensão.
Mas entende, também, que mesmo que se tenha como provada a obrigação, não se verifica o requisito da necessidade para o decretamento da providência, previsto no art.º 362º CPCivil.
Isto porque se mostra que apenas o acesso ao código fonte é que é essencial e estando as partes a discutir sobre o alcance da obrigação relativa à documentação técnica, não resulta demonstrado o preenchimento do requisito da necessidade exigível para o decretamento da medida cautelar.
Entende a requerida que para lá da entrega do código fonte, não resultou provada a necessidade exigível para o decretamento desta medida cautelar, quando está em causa a entrega de documentação técnica que as partes discutem se deveria ou não existir e, que ela própria, entende ser questão que deveria ter sido deixada para ser decidida na acção principal e, que não se impunha, de todo, uma decisão cautelar a este propósito.
Tanto mais que, conforme também resultou explícito na impugnação da matéria de facto, o que releva mesmo para a requerente é a entrega do código fonte, sem o mecanismo de licenciamento - citando aqui o que disse a testemunha II, que referindo-se ao mecanismo de licenciamento, o simples acesso ao código fonte permitiria eliminar o referido mecanismo, passando as plataformas a funcionar. Se demoraria mais um pouco? Sim. Mas tão só isso. Não seria imediato, mas não era impossível.
Daqui conclui, então, estar evidencia o quão desnecessário se mostra, do ponto de vista cautelar, o decretamento da providência.
Como é sabido, o procedimento cautelar não especificado, artigo 381.º/1 CPCivil, depende da verificação dos seguintes pressupostos,
- -positivos:
- -fumus boni iuris – aparência do direito, i.e., probabilidade séria da existência do direito invocado pela requerente;
- -periculum in mora – fundado receio de que, na pendência de uma acção, esse direito sofra lesão grave e de difícil reparação;
- -adequação da providência requerida à situação de lesão iminente;
- -inaplicabilidade de qualquer uma das outras providências cautelares previstas e,
- -negativo:
- -que o prejuízo resultante da providência não seja superior ao dano que com ela se pretende evitar.
Das normas jurídicas invocadas como violadas, a esta matéria reporta-se, tão só, o artigo 362.º CPCivil.
Desde logo, como é sabido, quem recorre não se pode limitar a proclamar, muito menos, a sugerir ou aventar hipóteses de violações normativas, erros de julgamento, vícios da decisão.
Tem obrigatoriamente, até pelo princípio da lealdade, probidade e honestidade, a que está vinculado, de fazer a crítica das soluções para que propendeu a decisão de que recorre, aduzindo os motivos do seu inconformismo, a base jurídica em que se apoia e o caminho que deveria ter sido percorrido ou que haverá a percorrer.
Não basta alvitrar a violação das normas constitucionais ou legais, necessário era afirmar e tentar demonstrar a incorrecção da aplicação do Direito e o sentido em que as apontadas normas foram interpretadas e o sentido com o qual o deveriam ter sido.
Com efeito, dispõe o artigo 639º/2 CPCivil, que versando o recurso, matéria de direito, as conclusões devem indicar o sentido em que, no entendimento
do recorrente, o tribunal recorrido interpretou a norma, que tem por violada, ou com que a aplicou e o sentido em que ela devia ter sido interpretada ou com que devia ser aplicada.
Ora a esta regra básica, não obedeceu, seguramente, a requerida, que nem sequer situa quais os segmentos concretos da norma que tem por violada.
Norma que inserida em termos sistemáticos no título reservado aos procedimentos cautelares, no capítulo destinado ao procedimento cautelar comum e, que com a epígrafe de “âmbito das providências cautelares não especificadas”, dispõe que,
“1 - Sempre que alguém mostre fundado receio de que outrem cause lesão grave e dificilmente reparável ao seu direito, pode requerer a providência conservatória ou antecipatória concretamente adequada a assegurar a efetividade do direito ameaçado.
2 - O interesse do requerente pode fundar-se num direito já existente ou em direito emergente de decisão a proferir em ação constitutiva, já proposta ou a propor.
3 - Não são aplicáveis as providências referidas no n.º 1 quando se pretenda acautelar o risco de lesão especialmente prevenido por alguma das providências tipificadas no capítulo seguinte.
4 - Não é admissível, na dependência da mesma causa, a repetição de providência que haja sido julgada injustificada ou tenha caducado.”
Se fora de causa, nos termos em que a requerida se exprime estará a questão da probabilidade séria da existência do direito invocado (fumus bonus iuris), parece a requerida enfocar a questão no requisito do fundado receio de lesão grave ou dificilmente reparável (periculum in mora).
Tal é o que resulta de forma directa e imediatamente perceptível da sua alegação de que é desnecessário o decretamento da providência pois que o simples acesso ao código fonte – que ainda não entregou, é certo – como reconhece uma testemunha da requerente, permitiria eliminar o referido mecanismo, passando as plataformas a funcionar, ainda que demorando mais tempo, não seria imediato, mas não era impossível.
E, de por outro lado, entender que a questão deveria ter sido deixada para ser decidida na acção principal e, que não se impunha, de todo, uma decisão cautelar a este propósito.
E, como vimos, para além da verificação do fumus boni iuris, importa que se mostre preenchido o requisito do fundado receio de lesão grave e dificilmente reparável do direito invocado no procedimento cautelar - o periculum in mora.
Obviamente que o critério de avaliação deste requisito não deve assentar em simples conjecturas, antes, em factos que, de acordo com as regras de experiência, aconselhem uma decisão cautelar imediata, como factor potenciador da eficácia da acção pendente ou a instaurar posteriormente.
Não basta a verificação de uma qualquer lesão, exige-se o risco de verificação de uma lesão que, por um lado, evidencie gravidade e, que, por outro, seja dificilmente reparável.
O que significa que não preenche tais requisitos, o caso de lesão sem gravidade, apesar de ser dificilmente reparável ou, de lesão grave mas facilmente reparável.
Como refere Rita Lynce de Faria in A Função Instrumental da Tutela Cautelar Não Especificada, Universidade Católica, 2003, 57 que, para a concretização do que se deve entender por lesão dificilmente reparável podem ser apontados dois critérios:
- -um subjectivo que atende às possibilidades concretas do requerido para suportar economicamente uma eventual reparação do direito do requerente e,
- -um objectivo, aferido em função do tipo de lesão que a situação de perigo pode vir a provocar na esfera jurídica do requerente, o que significa que dependerá da natureza do direito alvo dessa lesão e da sanção que a ordem jurídica impõe para reparação do dano decorrente da lesão.
Cremos bem que dos factos provados - e do enquadramento jurídico levado a cabo na decisão recorrida, que a requerida não coloca em causa, a não ser com esta vaga alusão à desnecessidade do decretamento da providência – estão, no caso, exuberantemente demonstrados os requisitos de que depende a procedência da providência requerida, designadamente, a existência do direito da requerente e a violação desse direito, por parte da requerida, bem como a probabilidade séria e justificada de continuação dessa violação.
Por um lado, a existência do direito, por outro, a gravidade da sua violação, que impede a requerente de o continuar a exercer, na sua plenitude, como é suposto, sem constrangimento, limitação ou restrição, não fora o recurso à providência cautelar, por forma a impedir que a requerida com a sua conduta prolongue e arraste no tempo, aquela lesão.
Ainda, que de forma não tão ostensiva se pudesse entender que a requerida estaria com aquela sua alegação a pretender, ainda que de forma imperfeita, a sugerir a não verificação do apontado requisito de carácter negativo, o certo é que, como facto impeditivo do direito da requerente sobre si impendia, atentas as regras de repartição do ónus da prova, contidas no artigo 342.º CCivil, o ónus de alegar e provar os factos concretos em que o mesmo se concretizaria.
E, como se sabe, não bastaria um ligeiro desequilíbrio entre os dois prejuízos, sempre seria necessário uma forte desproporção entre o sacrifício a impor à requerida e a vantagem que para a requerente advirá do decretar da providência -devendo prevalecer este seu interesse, cfr. Lebre de Freitas, A. Montalvão Machado, Rui Pinto in CPCivil Anotado, 2.º, 36.
Nem o princípio da proporcionalidade – que se poderia ter como integrador da invocada desnecessidade, não se mostra suficientemente fundado em factos ou prejuízos que a lei manda atender para legitimar o seu reconhecimento.
Terá, então, a requerida que sofrer as consequências derivadas do incumprimento do ónus que sobre ela recaía – quanto às razões concretas em que assentaria a violação do artigo 362.º CPCivil - seja o não conhecimento desta questão, pois que não tem o Tribunal de recurso, em casos que tais, que iniciar qualquer manobra exploratória, destinada a suprir as omissões do recurso, descobrindo hipotéticas razões de discordância não enunciadas.
Mas sempre se dirá que este entendimento - a traduzir que fornecido o serviço sem os manuais de instrução - passe a imagem – ainda assim, o dono da obra pode resolver os problemas, que possam surgir, derivados do funcionamento das plataformas, pois que o consegue fazer, ainda assim demorando é um bocado mais, não seria imediato mas não seria impossível – acarretaria, a possibilidade/legitimidade, que da mesma forma, atento o pressuposto equilíbrio inerente às prestações contratuais, também o dono da obra se atrasasse ou recusasse mesmo pagar a partir de determinada momento, com o argumento de que demoraria um bocado mais o prestador de serviços a atingir o objectivo que teve em contratar e que a sua margem de lucro seria atingida, não de imediato, mas não seria impossível.
A absoluta banalização do mal. A absoluta desculpabilização do incumprimento dos contratos.
Mas mais grave do que isso é a tentativa levada a cabo pela requerida para fazer o seu enquadramento legal, colocando em causa a necessidade de o contraente cumpridor exigir que o inadimplente cumpra a sua obrigação – mormente através de uma providência cautelar, já que bem poderia esperar, para o fazer através da acção definitiva.
De uma forma ligeira, é certo, mas que poderá tender a fazer escola. Daqui faz a requerida a ponte para outra questão.
Entende que não fora a especificidade e dificuldade científica, inerente à documentação aqui em causa, e seguramente que a decisão recorrida não teria decretado a medida cautelar, o que significa que, ou se entende que os documentos em falta são de tal forma complexos cuja entrega imediata se torna necessária (mas aí se afasta a aplicação da sanção pecuniária compulsória pelo carácter eminentemente cientifico dos mesmos) ou se entende que não há qualquer complexidade técnico-científica e, dessa forma, se afasta o critério da necessidade de aplicação da medida cautelar.
E, daqui, pretende, em primeira linha, a eliminação, primeiro, ou, redução depois, do valor da sanção pecuniária compulsória em que foi condenada, pelo atraso na entrega de documentação técnico-científica que não tem e, que irá ter que elaborar e que exige, indubitavelmente, qualidades específicas, são documentos complexos, que exigem conhecimento de programação e que, nesta medida, preenchem o requisito previsto na excepção do n.º 1 do artigo 829.º-A CCivil, não devendo, por isso, a sua entrega estar sujeita a sanção pecuniária compulsória.
Assim, discorda da cumulação do preenchimento do requisito da necessidade para o decretamento da medida cautelar e, ao mesmo tempo, da condenação numa sanção pecuniária compulsória, defendendo, por isso, a revogação a aplicação da dita sanção.
Que, de qualquer forma, entende ter sido fixada em valor manifestamente exagerado, excessivo e injusto, não se mostrando nem equitativa, nem razoável, isto em função das circunstâncias do caso concreto, nomeadamente, da circunstância de se encontrar desapossada de uma quantia, ainda que não concretamente apurada e quando a mera circunstância de ser condenada num qualquer valor, ainda que simbólico, será suficiente para a compelir a respeitar a injunção judicial decretada, pugnando, então, pela sua redução, drástica.
Vejamos.
Depois de consagrada no artigo 829.º-A CCivil através do Decreto Lei 262/83, a sanção pecuniária compulsória veio a ser alargada às providências cautelares, primeiro, e à execução de prestação de facto positivo e negativo, depois.
No que aqui releva e em relação às primeiras, o artigo 384.º/2 do CPC, versão 1961 e, actualmente, artigo 365.º/1 do novo CPCivil, determina ser sempre admissível a fixação, nos termos da lei civil, da sanção pecuniária compulsória que se mostre adequada a assegurar a efectividade da providência decretada.
Nos termos do n.º 1 do artigo 829.º-A CCivil, “nas obrigações de prestação de facto infungível, positivo ou negativo, salvo nas que exigem especiais qualidades científicas ou artísticas do obrigado, o tribunal deve, a requerimento do credor, condenar o devedor ao pagamento de uma quantia pecuniária por cada dia de atraso no cumprimento ou por cada infracção, conforme for mais conveniente às circunstâncias do caso.”
Donde, resulta, desde logo, que a sanção pecuniária compulsória só é possível em relação às obrigações de “facere” ou “non facere” infungíveis.
Como se sabe, prestação de facto fungível é aquela que pode ser realizada por pessoa diferente do devedor, sem que daí resulte qualquer prejuízo para o interesse do credor e, assim, nas execuções para prestação de facto fungível, não pode ser fixada qualquer quantia a título de sanção pecuniária compulsória.
A infungibilidade da prestação de facto decorre da impossibilidade de ter lugar o cumprimento por terceiro, em função do interesse concreto do credor.
A sanção pecuniária compulsória, do n.º 1, depende de,
- -um requisito material - só pode funcionar nas obrigações de prestação de facto infungível, positivo ou negativo, mas que não exija especiais qualidades científicas ou artísticas e,
- -de um requisito formal - requerimento do credor interessado, não podendo ser aplicada oficiosamente pelo Tribunal.
E, tem uma dupla finalidade, de moralidade e de eficácia:
- -reforçando a soberania dos Tribunais, o respeito pelas suas decisões, o prestígio da justiça e,
- -favorece o cumprimento das obrigações de prestação de facto ou de abstenção infungíveis.
A propósito da excepção à regra aqui prevista, importa salientar, que como parece, medianamente claro e evidente, estamos perante mais um erro de enfoque da requerida.
Com efeito, a ressalva das obrigações de facto infungíveis que, exigem especiais qualidades científicas ou artísticas, não assume a leitura que a requerida faz nem tem o sentido que lhe empresta.
Como referem Pires e de Lima e Antunes Varela in CCivil anotado, “é uma restrição difícil de justificar, desde que o fim da sanção compulsóroa é vencer a resistência da vontade do obrigado e se não trata de separar os casos em que é, daqueles em que não é, possível recorrer, na execução, à prestação do facto por terceiro à custa do devedor. E, não se compreende facilmente por que razão devam estar isentos deste específico instrumento de coerção os monstros sagrados da área científica ou artística e, apenas eles”.
O que vale por dizer que estamos perante obrigações infungíveis a prestar pelo pelo médico, pelo arquitecto, pelo engenheiro, pelo pianista, pelo pintor, pelo escultor.
O que nada tem a ver com a situação dos autos, em que em causa está a requerida que se dedica a consultoria e programação informática nacional e internacional e actividades relacionadas, concepção, desenvolvimento, implementação e gestão de projecto tecnológicos nacionais e internacionais, comércio por grosso, a retalho, importação e exportação de software e hardware e, formação, que celebrou com a requerente um acordo-quadro para a prestação de serviços de desenvolvimento de software, de suporte e assistência técnica, no âmbito do qual desenvolveu e implementou vários programas informáticos, estando agora em questão a entrega da documentação técnica e dos suportes digitais inerentes e necessários para assegurar o seu regular, normal, cabal e correcto funcionamento.
O que nada tem que ver, naturalmente, com as especiais qualidades científicas, exigidas pela excepção à apontada regra.
Não é pois caso de excepção à regra da fixação da dita sanção, a pedido do credor.
Acerca do quantitativo.
“A sanção pecuniária compulsória será fixada segundo critérios de razoabilidade (...)”, n.º 2 do artigo 829.º-A.
Esta sanção pecuniária não funciona como indemnização, pois não se destina a indemnizar o credor pelos prejuízos que o inadimplemento da prestação eventualmente lhe venha a causar.
A sua função é prevenir o ilícito no futuro, evitando o não cumprimento violador da ordem jurídica. Funciona como meio de coerção, destinado, fundamentalmente, a compelir o devedor à realização da prestação devida. Através da aplicação da sanção pecuniária compulsória, fica o devedor a saber, de antemão, qual a consequência para o não acatamento da decisão condenatória de que foi alvo.
Na fixação da sanção deve-se observar um critério de razoabilidade, tendo em consideração cada dia de atraso no cumprimento ou cada infracção, conforme for mais conveniente às circunstâncias do caso. Trata-se de uma sanção marcadamente preventiva, imposta e fixada “ex ante”, visando primariamente compelir o obrigado ao cumprimento.
Esta sanção deve ser fixada num valor que tenha a virtualidade, o efeito de constituir um sério aviso, que tenha a aptidão de demover o devedor da resistência de cumprir.
Não faz, por isso sentido a aplicação de um valor meramente simbólico, que não teria a virtualidade de satisfazer nem a natureza, nem a finalidade da sanção.
Em sede de avaliação das circunstâncias do caso concreto, há que ter presente os interesses materiais em jogo, traduzidos nos valores envolvidos na relação comercial entre as partes, ao longo dos anos - o que deixa sugerida a capacidade económica e financeira, desde logo, da requerida - e, no tempo que já mediou entre a paralisação das plataformas pela aludida falta de documentação técnica, sendo razoável supor, dada a posição assumida pela requerida, que a mesma se venha a manter, em manifesta violação dos direitos da requerente, resulta manifesta a fixação de uma sanção pecuniária compulsória, a fim de compelir a requerida ao cumprimento da sua obrigação.
Circunstâncias que aliadas à natureza e finalidade da sanção, impõem a fixação de um valor que se mostre, naturalmente, sob pena de absoluta inutilidade e desperdício, adequado e eficaz, apto, por isso, a dissuadir a requerida do incumprimento e, a pressioná-la respeitar a decisão aqui proferida.
Em face do que vem de ser dito, cremos razoável, adequada e equitativa a sanção no valor fixado, de €1.500,00 diários, como meio de assegurar o respeito pelo decidido.
Improcede, assim, também, este segmento do recurso.
III. Sumário – artigo 663.º/7 CPCivil.
………………………………………
………………………………………
………………………………………