A segunda consideração diz respeito à importância da informação e, nesse contexto, à questão de saber se são informações "que prejudicam significativamente as expectativas razoáveis da outra parte em relação à transação" (Friedman e Cohen (vol. 2), na p. 194); veja também Recurso Civil 8227/20 Kassirer v. Amsalem nos parágrafos 35-36 (12 de julho de 2023)).
A terceira consideração diz respeito à natureza da relação entre as partes. Nesse contexto, Friedman e Cohen observam que uma relação de confiança estabelece uma relação que pode estabelecer obrigações de divulgação. Foi observado, entre outras coisas, que a jurisprudência também impôs um dever de confiança a uma pessoa cujo conselho e opinião o outro se baseava devido ao trust especial que adquiriu para si, bem como às partes de uma transação conjunta (ibid., p. 207). O grau de confiança e importância que deve ser atribuído a ele é derivado das circunstâncias factuais do caso concreto (veja Recurso Civil 230/80 Fender, Open and Building Investment Company em Tax Appeal v. Castro, IsrSC 35(2) 713, 723-724 (1981)).
Do geral ao específico: Froimovich enganou Werber sobre a maturidade do sistema
- A base factual, conforme detalhado acima, leva à conclusão de que Froimovich enganou Werber sobre um assunto relevante na transação.
- Froimovich não colocou Werber no processo de desenvolvimento do software de forma casual antes de entrar no acordo (incluindo sem uma caracterização ordenada e estruturada, sem gerenciamento de versões e alterações, sem um ambiente de desenvolvimento separado e sem testes automatizados). Também não divulgaram a Werber o risco significativo que era claro para Shmulik próximo ao lançamento, como mencionado, em relação à expectativa de muitas falhas devido ao processo ruim de desenvolvimento de software e sua baixa qualidade. Shmulik também não corrigiu o mal-entendido criado por Werber, que decorria das representações incorretas que ele apresentou - como se o trabalho no local estivesse quase concluído em janeiro e fevereiro; Na época, ele apresentou que apenas era necessário o "polimento", ao contrário da situação real em que o desenvolvimento do sistema só começava em janeiro e um trabalho significativo era realizado no final de abril e depois. Shmulik também fez Werber entender - incorretamente - que muito dinheiro havia sido investido no desenvolvimento do site, ao contrário da realidade e de uma forma que incutia confiança na qualidade do software, além da grande confiança que Schwerber depositava em Shmulik enquanto confiava em seu profissionalismo como um homem de software respeitável, como Omri também testemunhou (p. 62 da transcrição, parágrafos 13-18).
- Bugs e falhas de software são, claro, previsíveis e também podem ser considerados completamente inevitáveis (ou a um custo razoável), mesmo que o desenvolvimento seja em alto nível. Assim, negociar por um desenvolvedor de software que não está disposto a assumir a responsabilidade de que o software é perfeito ou que foi desenvolvido segundo um padrão aceito que não é suficientemente definido é legítimo. O que está errado na conduta de Froimovich é que as mensagens de Shmulik plantaram Borber com a compreensão de que o desenvolvimento do sistema foi concluído meses atrás e que, nos últimos meses, eles têm trabalhado apenas no polimento, e que muito dinheiro foi investido no desenvolvimento de uma forma que incutiu a compreensão de que este é um sistema de alta qualidade e que o software está pronto para ser lançado. Isso embora, na realidade, o processo de desenvolvimento tenha sido casual e partes significativas foram desenvolvidas "em cima da hora" (ao contrário do que foi apresentado) e sem realizar testes suficientes. Também está claro que, durante as negociações com Werber, dias antes do lançamento, Shmulik estava ciente da baixa qualidade do software e, apesar disso, ele "correu" para o lançamento enquanto "constantemente descobria novos problemas." Assim, a conclusão provável é que estava claro para Shmulik que problemas eram esperados no sistema após o lançamento, além dos inevitáveis falhas ou bugs. No entanto, Shmulik optou por não compartilhar essas informações materiais com Werber.
- De fato, como se devêm da análise das alegações e evidências acima, muitas das alegações de Werber sobre deficiências concretas no sistema em relação ao que foi apresentado (funções que não existiam) não foram aceitas. Mesmo as falhas descobertas não esperam ser complexas de lidar. A falha na exibição de leads para os profissionais de marketing, que foi fundamental para a confiança dos profissionais de marketing, foi resolvida em um tempo relativamente curto, e também parece que não foi complicado de corrigir. As outras falhas apontadas por Werber também não parecem complexas e parecem ter sido corrigidas em pouco tempo.
No entanto, a principal dificuldade, como já foi mencionado, não é a complexidade das falhas concretas (das quais Shmulik presumivelmente não tinha conhecimento) e a imaterialidade da maioria das deficiências funcionais do software. A dificuldade na conduta de Froimovich é que ele não compartilhou informações com Werber sobre a fragilidade do sistema e sua possibilidade de falhas caso seja lançado conforme planejado, considerando a natureza precária do processo de desenvolvimento e, consequentemente, sua baixa qualidade. O simples fato de não haver um padrão aceito para sistemas WordPress, como o perito testemunhou no contra-interrogatório (p. 75 da transcrição, parágrafos 8-12), não diminui a existência de indicadores de qualidade e desenvolvimento profissional, como indica a opinião do especialista. É possível aceitar a alegação de Froimovich de que, como parceiros do empreendimento, eles tinham interesse no sucesso e também supor que acreditavam que os problemas descobertos seriam solucionáveis e que, em sua visão, era correto avançar com o processo de lançamento, mas mesmo que acreditassem assim, não podiam não divulgar a informação a Werber antes da entrada de Werber no empreendimento, investindo uma quantia significativa.