要約

  • RFC 1602 は、合理的な条件で許諾するという一般的な表明だけでなく、実装者が閲覧し実行できるオンラインのライセンス書式と、後の有利な条件を既存契約にも反映する仕組みを想定していた。
  • RFC 1915 は、公開された保証を代替として受け入れる例外を認め、CCP と ECP の停止を解いた。しかし IESG が承認したのは標準化手続の進行であり、将来の価格、回答速度、申請者間の同等性ではない。
  • RFC 1962 と RFC 1968 の刊行は仕様書の完成を示す。特許の有効性、ライセンス取得、製品適合、相互接続、配備、エンドツーエンドの安全性を示すものではない。

停止の理由を細く読む

PPP ワーキンググループは二つの制御プロトコルを IESG に送っていた。CCP はポイント・ツー・ポイント回線で圧縮方式を協議し、ECP は暗号化方式を協議する。オプションの提示、受諾、拒否、状態のリセットを記述する技術文書だった。

その後 Motorola は、米国特許 5,245,614 と 5,130,993 が作業に関係する可能性を IETF に知らせた。RFC 1915 によれば、文書が標準化に提出された段階で進行が止まった。ここから確認できるのは、権利主張と当時の手続要件が工程を停止させたことだ。特許が有効であること、すべての実装が権利範囲に入ることを IETF が判断したわけではない。

証拠を一列にまとめてはいけない。権利主張、法的有効性、技術との対応、許諾意思、具体的な提示、署名済み契約、適合する実装、運用環境への導入は、それぞれ別の出来事である。一つの RFC が公開されたからといって、残りの出来事が過去形になるわけではない。

RFC 1602 が求めた共通面

当時適用されていた RFC 1602 のモデルは具体的だった。標準化活動のため Internet Society に無償の権利を与え、標準を実装するコミュニティの構成員にも合理的な条件でライセンスを提供する構成を示した。後で他者により有利な条件を与えた場合、既存ライセンスにも同じ改善を及ぼす条項も含まれていた。

特に重要なのは、ライセンス書式をインターネット上で常時入手可能にする点である。実装者は同じ文面を事前に読み、記入し、権利者へ届けて発効させられる。共通書式は特許紛争を消さないが、どの版の、どの範囲の、どの手順による許諾なのかを比較可能にする。

この仕組みは小さな相互運用性だった。プロトコルが機械同士の選択手順をそろえるように、書式は組織同士の入口をそろえる。価格が安いことまでは保証しない。それでも、同じ入口が本当に与えられたかを監査するための基準を残す。

提出されたのは書式ではなく保証だった

Motorola は RFC 1602 の書式を提供する代わりに、一般的な保証を公表する道を選んだ。いかなる当事者にも合理的で、不公平な差別がないと立証できる条件でライセンスを提供する、という内容だった。対象となり得る特許と連絡先も示され、RFC 1915 の公開記録に収められた。

これは何もない状態より強い証拠である。誰が約束し、どこに申請するかは明確になった。しかし、将来の契約文をいま閲覧できる状態とは異なる。「合理的」を検証するには金額、計算単位、制限が必要であり、「非差別的」を検証するには複数の事例を比較する必要がある。「利用可能」かどうかには、申請から回答、提示、締結までの時刻も関係する。

RFC 1915 はこの弱点を隠していない。権利者が申請を別々に扱い、ある申請を進めながら別の申請を遅らせる危険を明記した。例外は不確実性の解消ではなく、不確実性を認めた上で標準化を待たせないという選択だった。

回避案は実装を一つにしなかった

ワーキンググループは、主張された特許を避けるためプロトコルを変更する案も検討した。技術的には可能だったが、一部の参加者は元の設計より明らかに劣ると考えた。ワーキンググループや IESG が別案を標準化しても、元の CCP を実装すると述べた者もいた。別案を受け入れた者も、技術的に優れているからではなく、ほかに出口が見えないためだった。

規則をそのまま適用すれば仕様は停止する。回避だけを優先すれば、標準文書と実際に走るコードが分裂しかねない。どちらも、特許の法的問題とプロトコルの技術的選択を同時には解かなかった。

RFC 1915 は、1995 年 6 月 5 日付の保証を根拠に元の提案を進めるという、より限定された判断をした。回避案が不可能だとも、特許が必須だとも、将来の許諾条件が合意済みだとも述べていない。

例外を公開するための手続

RFC 1871 は少し前に RFC 1602 へ variance 手続を加えていた。既存ルールが指針を与えない、または適切に機能しないとき、限定的な逸脱を認める仕組みである。担当ワーキンググループが問題を提示し、IESG が解決案を示し、延長された Last Call でコミュニティが意見を述べる。

IESG は、インターネット全体への利益と規則から外れる費用、技術的価値、代替案、先例、波及効果を検討し、例外をできるだけ狭くする必要があった。異議は IAB に申し立てられた。

この公開性によって RFC 1915 は手続の領収書になった。満たされなかった条件、採用した代替証拠、技術的回避の難しさ、残る危険を追跡できる。そこから IESG が自らの標準化工程を進める権限を行使したことは確認できる。

確認できないものも明確だ。IESG は特許庁でも裁判所でもなく、各社の購買部門でもない。将来の全契約を閲覧し、回答期間や条件の等しさを認定する権限も資料も持たない。公開された手続が正当であることと、非公開の取引がすべて公平であることは別の命題である。

仕様の完成が証明した範囲

1996 年 6 月、CCP は RFC 1962、ECP は RFC 1968 として刊行された。二つの文書はオプション交渉、拒否、リセット、アルゴリズム識別を定義した。組織識別子を使う独自方式のための枠もあった。公開されたアルゴリズムであっても、ライセンスや輸出の制限が付く可能性は残った。

CCP で共通の圧縮方式がなければ、圧縮せずにリンクを続けられる。ECP で双方が受け入れる暗号方式が見つからなければ、リンクを閉じる必要が生じ得る。方向ごとに異なる選択も可能だった。制御プロトコルは、合意がない場合の振る舞いを定義するが、合意そのものを生成しない。

RFC 1968 は安全性の境界も限定した。保護は具体的なアルゴリズムと秘密情報の管理に依存し、完全な安全性にはホスト間のエンドツーエンド機構がなお必要である。リンク暗号の規格化を、システム全体の安全証明として読むことはできない。

後の方針は別の証拠配置を選んだ

1996 年 10 月、RFC 2026 が RFC 1602 を置き換えた。事務局は引き続き、誰もが公開された合理的かつ非差別的な条件で技術を実装、利用、配布できるという書面保証を得るよう努める。しかし、その試みの結果は通常、標準化の進行を止めないものとされた。オンラインで実行可能な書式という RFC 1602 の詳細な仕組みも引き継がれなかった。

さらに RFC 2026 は、IESG が非差別性の実現を明示的に判定することはないとした。独立した複数実装や運用経験が推定を支え得る一方、Last Call で異議を出す余地は残った。

この順序は方針変更を示すが、RFC 1915 が RFC 2026 を単独で生んだとは示さない。より確かな結論は、技術機関が開示を求め、保証を公開し、例外を審査し、自らの文書を前進させられるということだ。その権限だけで、将来の二者契約をすでに検証済みの公共事実にはできない。

出典と証拠の限界

これらの公式資料は、公開された方針、保証、例外、プロトコル本文を裏づける。特許の有効性や必須性、各交渉の価格と結果、特定製品の許諾、適合、相互接続、配備、エンドツーエンドの安全性までは裏づけない。