MONOLITH LAW OFFICE+81-3-6262-3248Dias da semana 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Quais são os casos em que a responsabilidade por atos ilícitos se tornou um problema no desenvolvimento de sistemas?

IT

Quais são os casos em que a responsabilidade por atos ilícitos se tornou um problema no desenvolvimento de sistemas?

Entre os problemas legais no desenvolvimento de sistemas, a maioria das disputas sobre a localização de vários direitos e obrigações é baseada na existência de um “contrato” previamente estabelecido. No entanto, as obrigações legais não se baseiam necessariamente na existência de um “contrato” previamente estabelecido. A responsabilidade legal por atos ilícitos é um exemplo típico. Este artigo apresenta o conceito de “ato ilícito” que não se baseia num contrato, e explica a relação entre a lei de atos ilícitos e os projetos de desenvolvimento de sistemas.

A ligação entre projetos de desenvolvimento de sistemas e atos ilícitos

Questões de “incêndio” e “responsabilidade” no desenvolvimento de sistemas são pontos de discussão no conteúdo do contrato.

Várias responsabilidades envolvendo o desenvolvimento de sistemas

Quando falamos de tópicos relacionados ao desenvolvimento de sistemas, a “lei” geralmente vem à mente quando o projeto “incendeia” ou quando há algum tipo de disputa entre o usuário e o fornecedor.

https://monolith.law/corporate/collapse-of-the-system-development-project[ja]

O artigo acima explica que, apesar da diversidade de casos de “incêndio”, é possível organizá-los de forma relativamente simples através de um diagrama simples quando observados sob um quadro legal.

Além disso, quando se enfrenta um caso específico de “incêndio” e se busca resolver o problema através de alguma medida legal (como um processo ou mediação), a questão de quem tinha qual obrigação (= responsabilidade) se torna um problema. Para uma discussão sobre “responsabilidade”, que está particularmente relacionada ao projeto de desenvolvimento de sistema, consulte o artigo abaixo.

A maioria das responsabilidades é determinada com base no contrato

Deixaremos os detalhes dos tópicos de “incêndio” e “responsabilidade” do desenvolvimento de sistemas para outros artigos, mas o ponto importante aqui é que a maioria das opções legais tomadas em situações de disputa relacionadas ao desenvolvimento de sistemas (como a rescisão do contrato ou a reivindicação de danos) são baseadas no conteúdo do contrato. Por exemplo, se considerarmos exemplos comuns de problemas relacionados ao desenvolvimento de sistemas, como “responsabilidade por inadimplemento” e “responsabilidade por defeitos”, isso se tornará claro.

  • Responsabilidade por inadimplemento → Por exemplo, atrasos na entrega (= atraso no cumprimento) ou a inacababilidade do próprio sistema (= impossibilidade de cumprimento). Em primeiro lugar, quando é o prazo de entrega e quais são os requisitos do sistema a serem criados são determinados de acordo com o contrato.
  • Responsabilidade por defeitos → Por exemplo, quando um bug é descoberto após a entrega ou quando se descobre que há um grande problema com a velocidade de processamento. Novamente, a questão aqui é a discrepância entre o conteúdo do contrato e o que o sistema deveria ser originalmente.

A responsabilidade por atos ilícitos não se baseia em contratos

Por outro lado, ao contrário da “inadimplência” e da “garantia de defeitos”, que se baseiam em contratos, a responsabilidade por atos ilícitos não pressupõe a existência de um contrato. Isso não se aplica apenas ao desenvolvimento de sistemas, mas a todas as disputas em que o Código Civil está envolvido.

Para começar, o que é um ato ilícito? É definido no Artigo 709 do Código Civil, conforme estabelecido abaixo.

Artigo 709

Aquele que, por intenção ou negligência, viola os direitos ou interesses protegidos por lei de outra pessoa, é responsável por compensar os danos causados.

A frase “de outra pessoa” é uma palavra-chave importante. Não se limita apenas à outra parte na relação comercial, mas inclui todas as “outras pessoas” além do próprio indivíduo.

O exemplo típico de um ato ilícito é um acidente de trânsito. Se você atropelar alguém em um acidente de trânsito por causa de uma distração, será responsável não apenas criminalmente, mas também civilmente. A responsabilidade civil mencionada aqui é a responsabilidade por atos ilícitos. Em outras palavras, mesmo que você não tenha um contrato com a vítima do acidente de carro para “não bater o carro”, você ainda tem uma ampla responsabilidade em relação a “outras pessoas”.

Quais são as situações em que a conduta ilegal se torna um problema no desenvolvimento de sistemas?

Quais são os casos em que a responsabilidade por atos ilegais no desenvolvimento de sistemas é questionada?

É raro a responsabilidade por atos ilícitos ser questionada no desenvolvimento de sistemas

No entanto, em várias disputas sobre o desenvolvimento de sistemas, muitas pessoas podem achar difícil imaginar algo como “responsabilidade que não pressupõe uma relação contratual”, semelhante a um “acidente de carro”. Na verdade, não há muitos exemplos em casos judiciais anteriores sobre o desenvolvimento de sistemas onde a responsabilidade por atos ilícitos foi reconhecida.

Isso não é nada surpreendente. Em vez disso, considerando que os projetos de desenvolvimento de sistemas avançam com a cooperação mútua entre o usuário e o fornecedor, pode-se dizer que é natural. A maioria das disputas relacionadas ao desenvolvimento de sistemas resulta de problemas de definição de papéis que pressupõem uma relação contratual, como o “dever de gestão do projeto” e o “dever de cooperação do usuário”.

Por exemplo, o seguinte artigo mostra como organizar um caso quando o “usuário quer interromper o projeto”.

https://monolith.law/corporate/interrruption-of-system-development[ja]

Aqui, mesmo que seja o usuário que propôs a interrupção, a importância de o fornecedor refletir sobre suas próprias falhas é explicada. Além disso, a organização legal de problemas como “atraso na entrega” também é realizada no seguinte artigo. Novamente, pode-se ver que o problema é apenas a definição de papéis entre o usuário e o fornecedor.

https://monolith.law/corporate/performance-delay-in-system-development[ja]

Olhando assim, as características de um projeto de desenvolvimento de sistemas parecem ser simbolizadas pela proximidade da relação entre o “fornecedor que gerencia o projeto” e o “usuário que coopera com ele”. E é essa proximidade da relação contratual que, ironicamente, às vezes se torna a causa de disputas. Portanto, neste sentido, casos em que a responsabilidade por atos ilícitos é um problema em disputas sobre o desenvolvimento de sistemas podem não ser facilmente chamados de “pontos típicos” nessa área.

Caso em que a responsabilidade por atos ilícitos foi questionada antes da celebração do contrato

No entanto, existem casos em que a responsabilidade por atos ilícitos foi reconhecida do lado do fornecedor. O caso citado na sentença abaixo é um em que, devido à falta de fornecimento adequado de informações do fornecedor para o usuário, as discrepâncias na compreensão de ambos tornaram-se cada vez mais evidentes à medida que o projeto avançava, resultando na eventual falha do projeto. Neste caso, a falta de explicação do fornecedor na fase inicial de planeamento e proposta foi a razão para a falha do projeto, e como estas são realizadas “antes” da celebração do contrato, mesmo na prática, a questão era se a responsabilidade poderia ser perseguida com base em atos ilícitos, e não em responsabilidades contratuais. (As adições e alterações para negrito na parte sublinhada foram feitas pelo autor para facilitar a explicação.)

Na fase de planeamento e proposta, são definidos os principais aspectos relacionados com a concepção e viabilidade do projeto, tais como a definição dos objetivos do projeto, os custos de desenvolvimento, o âmbito e o cronograma de desenvolvimento, e também os riscos associados ao projeto são determinados de acordo com isso. Portanto, a análise de projeto e risco exigida do fornecedor na fase de planeamento e proposta é indispensável para a execução do desenvolvimento do sistema. Assim, o fornecedor deve considerar e verificar a funcionalidade do sistema que propõe, o grau de satisfação das necessidades do usuário, o método de desenvolvimento do sistema, a estrutura de desenvolvimento após a encomenda, etc., mesmo na fase de planeamento e proposta, e deve explicar ao usuário os riscos esperados a partir disso. Esta obrigação do fornecedor de verificação e explicação é posicionada como uma obrigação sob a lei de atos ilícitos com base no princípio da boa fé no processo de negociação para a celebração do contrato, e pode-se dizer que o apelante tem tal obrigação como fornecedor (a obrigação de gestão de projeto nesta fase).

Tribunal Superior de Tóquio, 26 de setembro de 2013 (Heisei 25)

Em outras palavras, embora fosse difícil construir uma teoria de perseguição de não cumprimento de obrigações impostas com base em um contrato, uma vez que se tratava de um assunto “antes” da celebração do contrato, esperava-se uma resolução justa ao reconhecer a violação de obrigações com base em atos ilícitos.

A ligação entre atos ilícitos e as obrigações de gestão de projetos

É importante notar que o desenvolvimento de sistemas é um processo colaborativo entre o fornecedor e o utilizador, cada um com a sua própria perspetiva. As obrigações que o fornecedor, como especialista em desenvolvimento de sistemas, tem são chamadas de “obrigações de gestão de projetos”. Uma explicação completa sobre o que são as obrigações de gestão de projetos pode ser encontrada no seguinte artigo.

https://monolith.law/corporate/project-management-duties[ja]

Neste julgamento, não só se questionou se “existem situações em que a responsabilidade por atos ilícitos pode ser um problema no desenvolvimento de sistemas”, mas também se “as obrigações de gestão de projetos se aplicam mesmo antes da celebração do contrato”. Este ponto de vista atraiu uma certa atenção.

O que é o Princípio da Boa Fé?

Além disso, no texto da sentença, surge a expressão “obrigação sob o princípio da boa fé”, que é baseada no seguinte artigo:

Artigo 1º, parágrafo 2, do Código Civil Japonês (Lei Civil Japonesa)

O exercício de direitos e o cumprimento de obrigações devem ser realizados de boa fé e com honestidade.

Este é um princípio geral no Código Civil Japonês, que se aplica a todas as resoluções de disputas que utilizam este código. A teoria jurídica relativa a direitos e obrigações deve ser desenvolvida com base na “boa fé” e “honestidade”.

Considerando o caso desta sentença, se o fornecedor argumentasse que “na fase de planeamento e proposta, uma vez que o contrato não foi celebrado, não há obrigação de fornecer uma explicação prévia”, isso seria uma falta de honestidade fundamental e não seria apoiado como uma teoria jurídica válida.

Resumo

Termos importantes como “ato ilícito”, “obrigação de gestão de projeto” e “princípio da boa fé” foram mencionados, mas a conexão geral não é tão complicada. No contexto do desenvolvimento de sistemas, existe um conceito chamado “obrigação de gestão de projeto”, que representa as responsabilidades e deveres abrangentes que o fornecedor tem, e estes são geralmente derivados do contrato.

Contudo, as obrigações legais não são formalmente determinadas com base no conteúdo do contrato acordado previamente, mas também são avaliadas individualmente, incorporando elementos como o “princípio da boa fé”. E a própria perseguição da responsabilidade civil, que não pressupõe uma relação contratual, é algo que é previsto desde o início pela construção teórica do “ato ilícito”.

Juntamente com o facto de que as obrigações legais não pressupõem necessariamente apenas uma relação contratual, deve-se entender o fluxo geral.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Retornar ao topo