Resumo

  • RFC 1602 imaginava um formulário de licença executável e permanentemente disponível, com proteção caso outro licenciado recebesse termos mais favoráveis. A garantia pública aceita em RFC 1915 não continha esse instrumento.
  • A variance foi exposta à comunidade, passou por Last Call ampliado e podia ser contestada perante o IAB. Esse processo legitimou a decisão do IETF de avançar, não os preços, prazos ou resultados de futuras negociações.
  • A publicação de RFC 1962 e RFC 1968 mostra que CCP e ECP se tornaram especificações. Não comprova patente válida, licença concedida, produto compatível, implantação ou segurança de ponta a ponta.

O congestionamento não estava nos pacotes

CCP e ECP já tinham sido encaminhados pelo grupo de trabalho PPP ao IESG. Um negociava compressão no enlace; o outro, criptografia. As mensagens permitiam propor opções, recusá-las e restaurar o estado quando as pontas perdiam sincronismo. O problema que parou a padronização não era um campo ausente no protocolo.

Motorola avisou ao IETF que as patentes norte-americanas 5,245,614 e 5,130,993 poderiam abranger o trabalho. RFC 1915 registra que o avanço foi interrompido depois da submissão para padronização. Isso prova a existência da alegação e o efeito processual que ela teve. Não prova que as patentes eram válidas, indispensáveis ou infringidas por todas as implementações.

É preciso manter estados diferentes no registro. Alegação de direito, validade jurídica, correspondência técnica, disposição para licenciar, oferta recebida, contrato assinado, implementação compatível e uso em produção não são sinônimos. A aprovação de uma especificação só muda um desses estados: o da especificação.

A fila comum desenhada por RFC 1602

RFC 1602, que então governava o processo, anexava um modelo detalhado. Previa direitos sem custo para a Internet Society no trabalho de padrões e licenças em termos razoáveis para membros da comunidade interessados em implementar. Se alguém recebesse depois condições mais favoráveis, uma cláusula estenderia a melhoria aos licenciados anteriores.

O formulário deveria ficar sempre acessível na Internet. Um implementador poderia examiná-lo, preenchê-lo e entregá-lo ao titular para que se tornasse efetivo. O documento comum não decidiria a validade da patente nem obrigaria todas as empresas a adotar a tecnologia. Criaria, porém, uma entrada observável: versão, escopo, obrigações e método de execução poderiam ser comparados antes de o custo técnico se tornar irreversível.

Esse mecanismo era uma forma de coordenação. Num protocolo, as pontas reconhecem opções a partir de códigos compartilhados. Numa licença pública, organizações reconhecem o ponto de partida a partir do mesmo texto. O preço ainda poderia ser discutido, mas o acesso ao instrumento não dependeria de entrar, sem visibilidade, em uma fila particular.

A garantia que substituiu o formulário

Motorola preferiu emitir uma declaração geral. Prometeu oferecer licenças a qualquer parte em termos razoáveis e demonstravelmente livres de discriminação injusta. Indicou as patentes e um contato, e a declaração foi incorporada ao registro público de RFC 1915.

Havia ganho de transparência: a comunidade podia ler as palavras usadas e saber a quem procurar. Mas uma garantia de que um contrato será oferecido não é o próprio contrato. “Razoável” exige números e contexto. “Não discriminatório” exige comparação entre requerentes. “Disponível” exige observar pedido, resposta, proposta e assinatura ao longo do tempo.

O RFC expôs a falha possível. O titular poderia tratar pedidos separadamente, acelerar alguns e atrasar outros. Assim, a variance não resolveu o acesso; aceitou uma forma de evidência mais fraca para que o processo técnico não permanecesse bloqueado. O risco migrou do documento comum para o comportamento futuro em relações bilaterais.

A alternativa técnica não formou uma saída comum

O grupo considerou alterar os protocolos para evitar as patentes alegadas. A mudança era tecnicamente possível, mas alguns participantes a julgavam significativamente inferior. Houve quem declarasse que implementaria a proposta CCP original, independentemente do que o grupo ou o IESG viesse a padronizar. Outros aceitavam a alternativa apenas porque não viam outro caminho.

Não era consenso aproximado em torno de um desenho melhor. Manter integralmente a exigência de RFC 1602 congelava os documentos. Escolher um desvio indesejado poderia separar a especificação oficial do código efetivamente adotado. A qualidade técnica não anulava um direito alegado, e o direito alegado não tornava melhor um protocolo alternativo.

RFC 1915 escolheu uma intervenção estreita: com base na garantia de 5 de junho de 1995, autorizou as propostas originais a continuar. Não afirmou que a alternativa era impossível, que as patentes seriam confirmadas nem que os termos comerciais já estavam acertados.

A exceção precisava produzir um recibo público

Pouco antes, RFC 1871 acrescentara a RFC 1602 um procedimento de variance. Quando as regras não oferecessem orientação adequada, o grupo responsável apresentaria o problema, o IESG proporia uma solução e um Last Call mais longo abriria a decisão a comentários. O IESG deveria pesar benefícios e custos para a Internet, mérito técnico, alternativas, precedente, efeitos colaterais e a possibilidade de limitar a exceção. Cabia recurso ao IAB.

A publicidade impedia que o desvio virasse atalho invisível. RFC 1915 diz qual requisito não foi cumprido, qual garantia foi aceita, por que o contorno técnico não reunia a comunidade e qual tratamento desigual ainda poderia ocorrer. É um recibo completo da decisão processual.

O recibo não aumenta a competência de quem o emitiu. O IESG podia governar a trilha de padrões do IETF. Não podia decidir a validade de uma patente, assinar em nome de um fabricante, ordenar as respostas futuras do titular ou auditar contratos que não estavam em seu poder. Transparência sobre uma decisão não é prova antecipada sobre todas as transações que ela permite.

A publicação encerrou uma fila

Em junho de 1996, CCP foi publicado como RFC 1962 e ECP como RFC 1968. Os documentos definiram negociação, rejeição, reinicialização e identificação de opções. Também reservaram meios para mecanismos proprietários identificados por organização. Uma opção publicamente descrita ainda podia estar sujeita a licença ou controle de exportação.

Sem método comum, CCP permitia manter o enlace sem compressão. Em ECP, se as pontas não encontrassem criptografia aceitável, poderia ser necessário fechar a conexão. Cada direção era negociada separadamente. O protocolo definia o que fazer diante da falta de acordo; não garantia que um algoritmo estaria disponível para todos.

RFC 1968 ainda limitava a conclusão de segurança. A força dependia do algoritmo e da proteção dos segredos. Segurança completa continuava a exigir mecanismos de ponta a ponta entre hosts. Padronizar a criptografia de enlace não certificava todo o sistema.

A política seguinte redistribuiu a evidência

RFC 2026 substituiu RFC 1602 em outubro de 1996. O Secretariado ainda deveria buscar uma garantia escrita de que qualquer pessoa poderia implementar, usar e distribuir a tecnologia sob termos publicados, razoáveis e não discriminatórios. Em geral, porém, o resultado dessa busca não bloquearia o avanço. O mecanismo específico do formulário executável online também não foi mantido.

O texto posterior acrescentou que o IESG não determinaria expressamente se a não discriminação havia sido cumprida na prática. Implementações independentes e experiência operacional poderiam sustentar uma presunção, ainda sujeita a contestação durante o Last Call.

A ordem cronológica demonstra mudança de política, não que RFC 1915 tenha causado sozinho RFC 2026. O caso mostra uma fronteira: uma instituição técnica pode exigir divulgação, pedir uma garantia, publicar uma exceção e mover seus documentos. Não pode, pelo mesmo ato, observar preços ainda não oferecidos ou transformar futuras negociações em resultados já verificados.

Fontes e limites

Essas fontes oficiais comprovam as regras, a garantia, a variance e os textos publicados. Não comprovam validade ou necessidade das patentes, não revelam os termos de cada negociação e não certificam que um produto específico foi licenciado, era compatível, interoperou, foi implantado ou oferecia segurança de ponta a ponta.