Boa noite amigos
Dando continuidade à tradução de “A Formal Language for Analyzing Contracts”. Essa é a segunda parte, a primeira vimos no último versículo.
Semântica
Cada palavra e frase em nossa linguagem tem um significado padrão claro. Como resultado, podem ser elaborados contratos que estarão muito menos sujeitos a disputas sobre interpretação. Por outro lado, a linguagem não é muito boa para expressar muitos conceitos subjetivos e ambíguos que muitas vezes são necessários em contratos. Nem é bom, em seu estado atual, referir-se a jurisdições ou doutrinas da lei. A linguagem é, no entanto, muito diferente de uma linguagem de programação tradicional. Os termos contratuais são definidos em termos de eventos que acionam seu desempenho. Tais eventos incluem datas e horários, escolhas feitas pelas partes, violações observáveis do contrato e assim por diante.
Nossa linguagem não é uma linguagem de marcação. Não se trata de manipular texto para fins de elaboração de contratos. Não se trata de estruturar texto, especificar formulários de preenchimento, definir formatos de dados estáticos ou tarefas semelhantes de linguagens como HTML ou XML. Para essas tarefas, deve-se usar uma linguagem de marcação ou uma linguagem de programação de manipulação de texto (por exemplo, Perl), não essa linguagem. Nossa linguagem faz algo muito diferente. Ela modela a dinâmica da execução do contrato – quando e sob quais condições as obrigações devem ser executadas.
As palavras e frases do idioma não consistem em instruções seguidas na página de uma etapa para a outra. Em vez disso, um contrato é lido (tanto por humanos quanto por computador), seguindo definições aninhadas de termos contratuais à medida que se expandem e observando eventos nas declarações when [quando] e vendo o que eles acionam. Se o redator precisar construir explicitamente um cronograma passo a passo do calendário, isso poderá ser feito usando eventos controlados pelo calendário ou palavras como for [para] e then [então].
A linguagem incentiva a composição de contratos. Contratos, direitos e obrigações podem ser aninhados. Chamamos essas estruturas aninhadas de clauses [cláusulas]. Os contratos e cláusulas envolvem duas partes, o Holder [Titular], de cujo ponto de vista lemos o contrato, e uma Counterparty [Contraparte]. Os acordos de várias partes podem ser elaborados compondo vários contratos de duas partes.
Exemplo – Contratos Futuros
Nosso primeiro exemplo é um contrato financeiro bem conhecido, o futuro. Um futuro é uma obrigação por parte do Titular do contrato futuro de comprar uma certa quantidade de uma determinada mercadoria em um determinado mês, e a obrigação por parte do futuro redator do contrato, a Contraparte, de entregar esses bens. Para fins de introdução deste contrato, damos-lhe a forma abstrata na qual os analistas financeiros geralmente lidam com ele, deixando de fora detalhes importantes que descrevem os terceiros que atuam como intermediários confiáveis para definir “pacotes justos” de mercadorias, e também deixamos de fora muitos detalhes sobre a entrega real.
future(rightA=”1 round lot pork bellies”,
rightB=”$1,500.00″,
p = “for delivery in July 2002”) =
when withinPeriod(p)
to Holder rightA with to Counterparty rightB
then terminate
Como essa linguagem ainda não está sendo interpretada por computador, a sintaxe foi projetada mais para legibilidade humana do que para computador. Serei um pouco rápido e flexível com a sintaxe, e você também pode. Geralmente uso tabs em vez de colchetes {} para estruturar as cláusulas de uma maneira que parece natural e legível para mim – e espero que para você – mas que pode confundir um computador. Sinta-se livre para desenvolver seu próprio estilo.
As três principais linhas do contrato, na forma name(parameters) [nome(parâmetros)] = nos dizem que estamos definindo uma named clause [cláusula nomeada]. A cláusula nomeada pode definir um contrato inteiro ou apenas uma cláusula em um contrato maior. Podemos passar os nomes de outras cláusulas nomeadas, listas de eventos e outros tipos de informações que a cláusula nomeada precisa – esses são os parâmetros.
when withinPeriod(p) significa “quando o primeiro evento do calendário ou relógio gerado durante o período p”. O redator pode, em outro lugar, definir com que frequência esse evento “tick tack do relógio” ocorre. O primeiro tique taque de relógio após o início do período, neste caso, o primeiro dia de entrega programado no mês de julho, aciona a cláusula entre colchetes {}. Agendas mais sofisticadas são possíveis, como aquelas que minimizam os custos de entrega da Contraparte, entregando a diferentes Titulares em dias diferentes em julho. Felizmente, podemos ocultar esses detalhes de agendamento dentro do evento de calendário e agendar mecanismos do iterador, deixando o redator livre de se preocupar exatamente quando os mercados estão abertos, em que dias são finais de semana ou feriados ou dias bissextos, etc. O cronograma de entrega da contraparte pode ser negociado ou esse detalhe pode ser deixado para a contraparte. No contrato acima, as restrições na entrega são que elas ocorram em julho e somente em conjunto com o pagamento do Titular.
A cláusula mais interna diz para trocar rightA por rightB. Esta cláusula é dividida em um direito do titular e um direito da contraparte. A cláusula certa Holder rightA significa “O titular tem o direito de executar a rightA”, nesse caso, a entrega das barrigas de porco. A cláusula Counterparty rightB significa “A contraparte tem direito de desempenhar o rightB”, que aqui é o pagamento de 1.500 dólares. with indica uma troca simultânea – as duas transações devem ocorrer juntas, talvez intermediadas por um agente de garantia para fazer cumprir as condições de entrega e pagamento.
Fim da segunda parte, no versículo seguinte veremos a terceira. Deus os abençoe!
