概況
- 1996年の RFC 2026以来、IETF のポリシーは、知的財産情報を特許の有効性を判断するよう IETF に求めるのではなく、情報に基づく技術的選択へのインプットとして扱ってきた。現在の BCP 79である RFC 8179は、合理的に可能な限り早期に関連する開示を行うことを要求し、参加者、雇用主、スポンサーに義務を課し、正式な貢献が行われる前の予備的な開示を奨励している。
- タイミングは実質を変える。作業グループ採用前に開示された請求項は代替案と比較できるが、ラストコール後や展開後に開示された同じ請求項は、設計作業、実装、調達、トレーニング、相互運用性へのコミットメントを頓挫させる可能性がある。RFC 3669、6701、6702は、遅延開示が再設計を強制し、出版を遅らせ、作業を脱線させ、展開された機器を脅かす可能性があることを明示的に認識している。
- 正式な掲示だけでは十分ではない。実装者には、ドラフトとバージョン、RFC、特許権者と支配下の関連会社、特許ファミリー、影響を受けるセクション、開示日と更新日、ライセンスの姿勢、および廃止履歴によって検索可能な記録が必要である。結果がないことは、関連する権利が存在しないという保証として決して示されてはならない。なぜなら、IETF は特許検索を実施せず、第三者が後で開示する可能性があるからである。
コンセンサスは投資スケジュールでもある
ラフコンセンサスは通常、技術的異議を解決する方法として説明される。しかし、それは投資の連続でもある。グループがドラフトを採用する前に、参加者は問題の説明やアーキテクチャの比較に時間を費やす。採用後、編集者はテキストを統合し、レビュアーはひとつの方向に集中する。実装者はコードを作成し、相互運用イベントは前提をテストし、運用者は展開を予測し始める。製品チームはスタッフを割り当て、ハードウェアを予約し、依存関係を交渉し、リリース計画を立てるかもしれない。
各段階で、再選択の実質的な自由が狭まる。早期に却下された代替案は紙面上では存在し続けるかもしれないが、その作者は去っているかもしれない。テストインフラは今や選択された設計を前提としているかもしれない。コードインターフェースはパケットフォーマットやステートマシン周りで固まる。セキュリティ分析が蓄積される。他の作業グループが依存関係を作る。選択された提案の明らかな技術的優位性は、選択後に行われた投資の産物でもある。
特許情報はその投資の予想コストを変える。ロイヤリティフリーのコミットメントは、技術的比較をほぼそのままにするかもしれない。合理的な条件を交渉するという約束は、価格、範囲、相互主義、防御的停止、オープンソース配布との互換性について不確実性を生み出す。ライセンスの拒否、あるいは全くライセンス保証がない場合、それ以外では優れた必須メカニズムが一部の実装者にとって使用不可能になる可能性がある。
同じ情報でも、それがいつ現れるかによって制度的価値が根本的に異なる。採用前であれば、設計に影響を与えられる。コンセンサス後であれば、サンクコストに対する課税として機能する。展開後であれば、相互運用性を壊さずに切り替えられないユーザーに対するレバレッジになる。
したがって、適時性は事務的なエチケットではない。それは、作業グループが情報に基づいた選択をしたのか、それとも退出コストが高くなってから初めて価格を知ったのかを決定する。
RFC 2026 は開示を情報に基づく選択の一部とした
RFC 2026は1996年10月に発行され、インターネット標準化プロセスの第3版を定めた。その知的財産セクションは3つの永続的な考えに基づいていた：IETF は特定の権利主張が有効かどうかを判断しない；正当化される場合には既知の権利の対象となる技術を使用することを選択できる；標準化作業は実装を制約する可能性のある権利に関する情報を持つべきである。
この責任の配分は制度的に賢明である。作業グループは特許裁判所ではない。請求の解釈、有効性、所有権、侵害を管轄を超えて決定的に判断することはできない。すべての法的問題が裁定されるのを待つことは、タイムリーな標準化を不可能にする。しかし、裁定を拒否することは、知ることを拒否することを意味しない。参加者は、開示された請求項と表明されたライセンスポジションによって生じる実質的なリスクを比較できる。
この区別は、エンジニアリングと法律の両方の能力を保護する。IETF は、権利が絡んだ設計が依然として好ましいか、権利のない代替案が十分か、機能をオプションにすべきか、展開の証拠がリスクを正当化するかを問うことができる。特許権者は法的権利を保持し、ライセンスの意図を説明できる。実装者は法的助言が必要かもしれないという通知を得る。
1996年のポリシーはまた、現代の説明責任の問いに対する開始日を提供する。開示が情報に基づく選択に必要であることを知っている標準化団体は、最終的な公開だけを評価するのではなく、情報が代替案がまだ現実的であった時点でグループに届いたかどうかを問わなければならない。
RFC 8179は現在 RFC 2026を更新し、RFC 5378の著作権ルールとともに、古いセクション10を置き換えている。統治テキストは変わったが、中心的な制度的取引は変わっていない：コンセンサスによる特許判断はなく、回避可能な無知による正当な技術的选择もない。
BCP 79 はタイミングを中心に据える
RFC 8179、現在の BCP 79の声明は、IETF の目的は作業グループと参加者に潜在的な知的財産制約について可能な限り早期に可能な限り多くの情報を提供することであると述べている。これは単に RFC の発行前に開示することを要求するだけではない。貢献者自身が作成した書面による貢献については、既に十分な開示がファイルされていない限り、貢献が提出または行われた後、合理的に可能な限り早期に開示されなければならない。
義務は後の知識に適応する。貢献者が後になって新しい出願やポートフォリオ内の関連特許について知った場合、その情報が合理的かつ個人的に知られるようになり次第、開示が義務付けられる。他人の貢献をカバーする関連権利を知っている参加者も同様に行動する必要がある。参加者は、正式な貢献を待つのではなく、技術が真剣に議論されているときに予備的な開示を行うことが強く推奨される。
この構造は、標準化の決定が公開から始まるわけではないことを認識している。設計は問題の説明、会議でのプレゼンテーション、個人ドラフト、デザインチーム、またはリストでの議論の中で勢いを得ることができる。正確な文言が採用されたドラフトに現れるまで待つと、グループは利用可能性について誤った仮定の下で代替案を比較することになるかもしれない。
ポリシーは口頭での貢献もカバーしている。開示の対象となる口頭での貢献を行う参加者は、その口頭での宣言を合理的に可能な限り詳細に添えるか、適切な宣言をファイルしなければならない。これは、提案を書く前にマイクでアーキテクチャに影響を与えることで開示の時計を回避することを防ぐ。
「合理的に可能な限り早期に」は必然的に判断を必要とする。固定された日数ではない。しかし、それは知識と貢献に固定されており、コンセンサスが確実になるまで待つという便利さではない。情報が選択を形成するのに十分早期に届くという統治目的が解釈を支配すべきである。
知識の境界は必要であり、悪用される可能性がある
RFC 8179は普遍的な特許検索を課していない。合理的かつ個人的に知られている権利に適用される。これには実際の知識と、その職務のために合理的に知っていると期待されるものが含まれる。この文言は、組織が意図的に貢献者を無知に保つことで開示を回避することを防ぎながら、エンジニアが世界中のすべての特許ポートフォリオを調査できないことを認識している。
この境界は不可欠である。強制的な検索義務は技術参加を法的調査に変え、特許部門を持つ企業を特権化し、貢献者を不可能な完全性の主張にさらすことになる。IETF はまた、すべての関連権利を特定する責任を否認している。そのデータベースは開示記録であり、クリアランス意見ではない。
しかし、その境界は予測可能な盲点を生み出す。参加者は大企業のポートフォリオがドラフトにどのようにマッピングされるかを知らないかもしれない。異なる事業部門は連絡を取り合っていないかもしれない。特許弁護士は出願を知っているかもしれないが、標準エンジニアは知らないかもしれない。後日の買収によりポートフォリオが新たな管理下に入るかもしれない。非参加者は作業を監視し、設計が成熟した後にのみ開示するかもしれない。これらの状況はいずれも既存の IETF 記録を検索しても解決されない。
したがって、ガバナンスは2つの声明を区別しなければならない。「開示は見つからなかった」は特定の時点でのデータベース結果を説明する。「関連する IPR は存在しない」はデータベースがサポートできない法的かつ事実上の結論である。インターフェース、ラストコール通知、実装ガイダンスは、この区別を顕著に保つべきである。
非検索ルールはまた、組織的調整の重要性を高める。標準参加に資金を提供する雇用主は、貢献者が既知の出願や特許が開示を必要とするかどうかを尋ねるための信頼できるルートを持つべきである。そのルートが遅延の言い訳になってはならない。予備的な声明は、詳細とライセンス条件がまとめられている間に、可能性のある制約を特定できる。
雇用主は開示義務の内部にある
IETF は貢献者を個人として扱うが、BCP 79はその義務を雇用主およびスポンサーに明示的に関連付けている。貢献者は、その貢献をカバーするか、最終的にカバーする可能性があると考える適格な権利を開示しなければならない。これには、雇用主またはスポンサーが実装に対して主張する可能性があると合理的かつ個人的に知っている権利が含まれる。他人の貢献に取り組んでいる参加者にも同様の義務がある。権利所有者は個人に代わってファイルすることができる。
範囲は形式的な所有権を超える。RFC 8179は、直接的または間接的に所有される権利、参加者または雇用主がライセンスまたは主張できる権利、直接的または間接的な経済的利益を生み出す権利、および貢献者が発明者として名前が挙げられている出願を対象としている。これは、狭い所有権ラベルが情報目的を損なうのを防ぐ。
雇用主が開示を禁止する場合、ルールは直接的である：その人物は、雇用主またはスポンサーが開示を行わない限り、関連する IETF 活動に貢献または参加してはならない。機密性を、それを選択している人々から既知の制約を隠しながら標準を形成するために使用することはできない。
このルールは強力であるが、公的記録外の事実に依存する。作業グループは通常、エンジニアがいつ特許ポジションを知ったか、職務が何を合理的に知らしめたか、または弁護士が承認を遅らせたかどうかを見ることができない。遅延開示は、無実、過失、組織的断片化、または戦略的である可能性がある。動機はタイミングだけから推測できない。
それでも機関は効果を評価できる。開示日を貢献、採用、コンセンサス、ラストコール、承認、実装マイルストーンと比較できる。予備的な警告が可能だったかどうかを問うことができる。どの技術的決定を再検討すべきかを特定できる。説明責任は情報に基づく選択への害から始まり、非難ではなく公正な記録を通じて責任を検討すべきである。
未公開出願は意図された不透明期間を生み出す
特許制度はすべての出願を出願時に公開するわけではない。米国特許商標庁は、例外を除き、公開は通常、最初の有効な出願日または優先日から18ヶ月後に行われると説明している。特定の出願人は、法定条件が満たされた場合に非公開を請求できる。他の管轄区域や国際ルートには独自のルールがある。
標準への影響は、私的知識と公的検索可能性の間のギャップである。貢献者または雇用主は、未公開出願が提案をカバーする可能性があることを知っているが、独立した実装者はそのクレームを調査できない。BCP 79はこれを想定している。開示は未公開出願に基づいていると述べ、合理的に利用可能な範囲で影響を受ける IETF 文書とバージョンを特定できる。記録は後日、出願が公開されたり、放棄されたり、特許として発行されたりしたときに更新されなければならない。
これは沈黙ではなく予備的開示の理由である。作業グループにはクレームの詳細が欠けるかもしれないが、不確実性の存在を考慮できる。ライセンスの姿勢を求めたり、代替案を比較したり、メカニズムを必須にしないようにしたり、不可逆的な設計決定を延期したりできる。
未公開出願の通知は、機密のクレームを明らかにせずに開示できるものについて正確であるべきである：権利者、影響を受けるドラフトとバージョン、潜在的に影響を受けるセクション、予想される更新イベント、利用可能なライセンスコミットメント。ポートフォリオに権利が含まれる可能性があるというだけの裸の声明では、アーキテクチャを導くには情報が少なすぎる。
不透明期間はまた、特許庁検索が IETF 開示に代われない理由を説明している。専門の検索者でも合法的に未公開の出願を取得することはできない。参加者のタイムリーな義務は、私的組織知識と公的技術選択の間の架け橋である。その架け橋が公開後にしか開かれなければ、コンセンサスはすでに18ヶ月分の追加投資を吸収しているかもしれない。
検索可能性は実質的な標準の保護手段である
IETF は、開示の提出、発見、一覧表示、更新、検索のための公開IPR 開示施設を維持している。公開記録は開示日を特定し、更新を以前の声明にリンクできる。特定のフォームでは、権利者、特許または出願情報、影響を受ける貢献、ライセンス宣言を求める。
このインフラが重要なのは、開示が検索不能では通知なしに近いからである。ドラフトを評価する作業グループ参加者は、持株会社の正確な綴りを知っていたり、何千もの無関係なエントリを手動でスキャンする必要があってはならない。公開後に到着する実装者は、RFC から関連する開示とその完全な更新履歴に移動できるべきである。
検索可能性には時間的次元がある。ユーザーは現在の声明が何を言っているかだけでなく、採用時、ラストコール時、承認時に作業グループが何を知っていたかを知る必要がある。更新されたライセンスコミットメントは、より制限的な以前の立場を黙って上書きすべきではない。廃止されたドラフト名は、それに対してファイルされた開示にまだ解決されるべきである。文書の分割、名称変更、置き換えはチェーンを保持すべきである。
検索可能性にはエンティティの次元もある。特許権者は合併し、権利を譲渡し、子会社を使用し、法的名称の変形でファイルする。現在の所有者による検索は、前身の下でファイルされた開示を見逃すかもしれない。特許ファミリーには複数の管轄区域の関連出願が含まれる可能性がある。開示は、後でワーキンググループドラフトになり、さらに RFC になる個人ドラフトの1バージョンをカバーするかもしれない。
目標は Datatracker を特許意見サービスに変えることではない。それは、機関が管理する識別情報と文書変更をまたいで IETF 自身の通知を発見可能にすることである。実装者は、答えを既に知らなくても開示履歴を再構築できるべきである。
具体性が開示の設計指針としての有効性を決める
RFC 8179は、合理的に利用可能な範囲での情報を要求する：発行された特許または公開された出願番号、または出願が未公開であるという表示；公開記録のための発明者名；影響を受ける IETF 文書または活動；および特定のインターネットドラフトバージョン。対象範囲が明らかでない場合、影響を受けるセクションを特定することが役立つ。
これらのフィールドは決定に対応する。バージョンリンクにより、参加者はどの技術的文言が通知を引き起こしたかを見ることができる。セクションの特定は、周辺的な最適化と核心的な必須メカニズムを区別する。特許ファミリー情報により、弁護士と実装者は関連するクレームを調査できる。ライセンス声明は、制約が許容可能かどうかを判断するのに役立つ。
曖昧さはすべての実装者に作業を移す。「IPR が適用される可能性がある」は、複数の企業やオープンソースプロジェクトに弁護士を雇い、権利者に連絡し、同じ条件が提供されるかどうかを推測することを強いる可能性がある。大規模ベンダーはそのコストを吸収できるかもしれない。小規模実装者はサポートを断念するか、管理されていないリスクの下で出荷するかもしれない。標準は形式的に開かれたままであるが、実践的な実装は集中する。
したがって、包括的開示は BCP 79の下で制限されている。すべての貢献に権利が存在する可能性があるという一般的な主張は、特定の開示義務を満たさない。すべての適格権利をロイヤリティフリーかつその他合理的で非差別的なベースでライセンスするという一般的なコミットメントは、他の条件が開示されている場合にはルールを満たすことができる。なぜなら、それはポートフォリオ全体にわたって使用可能な制約を提供するからである。
具体性は技術的結果に対して測定されるべきである。早期の未公開出願通知は公開クレーム番号を含むことはできないが、それでもドラフト、バージョン、影響を受けるメカニズム、権利者、ライセンスの姿勢を特定できる。後の発行特許更新は、利用可能になったものを追加すべきである。基準は完全な法的分析ではなく、情報に基づく技術的および実装上の選択のための十分に構造化された情報である。
ライセンスの姿勢は特許番号よりも重要なことが多い
特許識別子は可能性のある権利を明らかにする。それは実装の経済的条件を明らかにしない。したがって、RFC 8179は、すべての実装者がロイヤリティフリーで権利を取得できるか、支払いを含む可能性のある合理的かつ非差別的な条件の下で権利を取得できるか、または非保証コミットメントを通じてライセンスを必要とせずに権利を取得できるかどうかの開示を奨励している。最大ロイヤリティを含むより詳細な条件が提供される場合がある。
違いは運用上重要である。ロイヤリティは高価値のハードウェアには管理可能であり、自由に配布されるソフトウェアには prohibitive になる可能性がある。相互主義はある企業には受け入れられるかもしれないが、別の実装者のポートフォリオやコミュニティライセンスと互換性がないかもしれない。防御的停止は後の紛争後にリスクを導入する可能性がある。利用分野の制限は実装を断片化する可能性がある。「合理的な」条件を交渉するという約束は、小規模プロジェクトに参入価格を伝えないかもしれない。
BCP 79はすべての開示でライセンス詳細を必須にしていない。完全な宣言を待つと最初の通知が遅れる可能性があることを認識し、権利者は最初に開示し、ライセンス情報が利用可能になったときに更新できる。この順序は正しい：不確実性は、弁護士がポリシーを終えるまで隠されたままではなく、早期に可視化されるべきである。
しかし、作業グループはライセンス情報の欠如を中立的な立場ではなく不確実性として扱わなければならない。広範な実装に依存する技術的選択は、クレームが開示されたという理由だけで許容可能な条件を想定できない。グループは明確化を求めたり、代替案を比較したり、権利が絡んだメカニズムを必須にするのを延期したりできる。
RFC 8179は、技術的優位性がコストを正当化する場合、作業グループがクレームの対象となる技術を採用する裁量を与えている。その裁量は、コスト情報が選択が固まる前に到着する場合にのみ意味を持つ。コンセンサス後の特許番号と展開後のライセンス交渉は、以前の決定環境を再現しない。
作業グループのライフサイクルは繰り返し開示の機会を提供する
RFC 6702は、議長とエリアディレクターが参加者に IPR を思い出させることができるいくつかの瞬間を特定している：最初の公開討論、プレゼンテーション、ワーキンググループ採用の要請、ワーキンググループラストコール、エリアディレクターレビュー、IETF ラストコール。著者とリストされた貢献者からの確認と、ラストコール通知内の関連声明へのリンクを保存することを推奨している。
これらは冗長な形式ではない。各マイルストーンは異なるリソースをコミットする。プレゼンテーションは注意を集めることができる。採用は集合的な編集とレビューを1つの文書に移す。ラストコールは主要な設計作業が完了すべきであることを示す。IESG レビューはより広範な精査をもたらすが、作業グループが多額の投資を行った後に行われる。公開は実装と依存関係を奨励する。
すべてのゲートでの開示チェックは、変化した事実を捉えることができる。企業は採用後に新しい出願を提出するかもしれない。ドラフト改訂は既存のポートフォリオでカバーされるメカニズムを導入するかもしれない。権利者は出願を公開したり、ライセンスの姿勢を変えたりするかもしれない。新しい貢献者が元の著者には利用できなかった知識を持って参加するかもしれない。
チェックは構造化された形式で記録されるべきである。誰が、いつ、どのドラフトバージョンについて尋ねられ、どの開示がリンクされたか？応答がない場合は、権利が存在しないという保証に変換されるべきではないが、作業を進める前に議長に見えるべきである。既知の不確実性が残る場合、シェパードレポートはグループがそれをどのように評価したかを説明できる。
最も価値のあるゲートは、提案が真剣な候補となる最も早いゲートである。後のリマインダーは依然として必要であるが、貢献者や実装資金を失った代替案を回復することはできない。繰り返しは新しい知識から保護する；最終ゲートでの最初の開示を正常化すべきではない。
RFC 3669 は方向転換のコストを記録している
RFC 3669は、知的財産問題に関する IETF 作業グループの経験を文書化している。その IP ストレージの例は特に関連性が高い。グループは、当初知られていたクレームを考慮した後、Secure Remote Password 技術を必須として選択していた。さらに2つの可能性のあるクレームが後で発見され、具体的なライセンス情報を得るのは困難であった。グループは最終的に、他の理由で既に選択していたにもかかわらず、その技術を使用しないことを決定した。
教訓は、特許が必ずしも有効であったとか、当初の技術的選択が無責任であったということではない。教訓は、後の権利情報が実行可能な決定を変えたということである。メカニズムの選択と統合に既に費やされた作業は、不確実性を消すことはできなかった。グループは方向転換のコストを支払った。
RFC 3669はまた、異なる結果を記録している。一部のグループは、適切な代替案が存在しなかったか、特許が満了に近かったため、権利が絡んだ技術を受け入れた。他のグループは、クレームリスクを評価したり、ライセンスの明確化を求めたり、実質的な重複は可能性が低いと結論付けて継続したりした。IETF の強みは、絶対的な禁止ではなく、文脈に基づいた裁量である。
その裁量はタイミングに依存する。グループは、技術的優位性、可用性、ライセンスリスク、代替案を理解した上で、クレームを意識的に受け入れることができる。好ましいアーキテクチャが独自のコードとサポートを蓄積した後にクレームが現れた場合、同じ決定を意識的に行うことはできない。
したがって、歴史的事例はガバナンスの証拠として読まれるべきであり、 folklore ではない。それらは、知的財産情報が必須ステータス、プロトコル選択、展開の信頼性を変える可能性があることを示している。また、検索可能な記録に決定日が必要な理由も示している。将来の実装者は、権利ポジションが関連する技術的コミットメントの前または後に考慮されたかどうかを見ることができるべきである。
RFC 6702 はコンセンサスの歪みを名指しする
RFC 6702は遅延開示について異常に直接的である。開示システムはコミュニティコンセンサスの正確な発展に不可欠であると述べている。情報は見過ごし、遅延の試み、またはコンセンサスの出現を妨害する試みにより遅れて到着する可能性があることを認識している。動機に関係なく、不遵守は仕様を遅らせたり頓挫させたりする可能性がある。
文書は特に、ワーキンググループラストコールのような重要な決定後の開示は再考を必要とする可能性があると指摘している。グループは、より負担の少ないライセンスを持つ以前に拒否された代替案に戻るかもしれない。そのような修正は必要であるが、情報がより早期に提供されていれば遅延は回避可能だった。
この分析は、最終的な掲示が問題を治したという狭い防御を防ぐ。開示データベースは今日完全かもしれないが、グループが決定を下した時点ではコンセンサス記録は不完全だった。制度的レビューは、知識のタイムラインと決定のタイムラインを比較しなければならない。
また、動機が救済策を飲み込むことを防ぐ。議長は、技術的選択を再開する前に戦略的隠蔽を証明する必要はない。最初の質問は、新しい情報が実装リスクを実質的に変えるかどうかである。もしそうなら、グループは新しい事実の下で代替案を評価すべきである。責任と制裁は、通知と証拠をもって別途検討できる。
この設定でのコンセンサス捕捉は、数的ではなく時間的である可能性がある。提案は、権利がないかのように早期評価の利益を得る；制約は競合他社が勢いを失った後にのみ現れる。連携したブロックがなくても、タイミングはグループを、同等の情報では行わなかったであろう選択に固定する可能性がある。
制裁だけでは失われた選択肢を回復できない
RFC 6701は、参加者が IETF IPR ポリシーに違反した場合に利用可能な措置を説明している。潜在的な対応は、警告や公的通知から、編集上の役割からの排除、文書の拒否や非推奨、投稿権限の制限まで及ぶ。文書は比例的な判断を強調し、IETF の行政措置と機関外の法的権利および救済措置を区別している。
制裁は説明責任、抑止、将来の作業の保護に役立つ。開示義務を無視した参加者が影響を受ける文書を引き続き管理することを防ぐことができる。公的通知はパターンを明らかにする可能性がある。拒否は耐え難い制約を埋め込むことを避けることができる。
しかし、罰則は以前の選択セットを回復しない。去ったエンジニアは戻ってこないかもしれない。代替実装は放棄されたかもしれない。製品リリースは既に選択されたメカニズムに依存しているかもしれない。下流の標準がそれを組み込んでいるかもしれない。グループは再設計できるが、コストは遅延開示を引き起こさなかった貢献者と実装者の間で分散されたままである。
RFC 6701はこの非対称性を認識している。遅延開示は、初期の個人ドラフトよりも公開された RFC に付随する場合により破壊的であり、展開された機器を脅かす可能性があると説明している。作業グループの再設計は違反者に対する制裁として扱われるべきではなく、グループが負う有害な副作用である。
これが、予防が執行を支配しなければならない理由である。明確なリマインダー、予備的声明、検索可能なリンク、雇用主の調整、マイルストーンチェックは、ラストコール後の再建よりもコストがかからない。制裁は有罪の違反には依然として必要であるが、コンセンサス後に罰則に依存する機関は、損失の多くを無実の実装者に既に転嫁している。
第三者は IETF の義務に違反せずに遅れて開示できる
すべての遅延クレームが参加者の不正行為を反映するわけではない。特許権者は IETF に参加していないかもしれない。組織は数年後に大規模なポートフォリオで関連権利を発見するかもしれない。所有権が変わるかもしれない。第三者は、所有していない権利を IETF に通知できる。RFC 8179は自発的な開示を奨励し、関連情報がいつでも到着することを許可している。
この開放性は、代替案が有用な警告を抑制するため必要である。また、どのチェックポイントも最終的な完全性を証明できないことも意味する。公開時の開示の欠如は、将来のクレームが現れないという保証ではない。RFC 8179はそう明示的に述べている。
第三者通知は独自のガバナンスリスクを生み出す。根拠のない申し立てはグループを混乱させたり、提案に対して戦略的に使用されたりする可能性がある。RFC 3669は、権利者が行動しない場合にグループに通知するルートを保持しながら、予備的な調査と実質的なコミュニケーションを推奨している。IETF は単に投稿することによってクレームを検証するわけではない。
したがって、対応は通知、技術的リスク、法的判断を分離すべきである。記録は、誰が通知を提出したか、どの権利と文書セクションが特定されたか、権利者との連絡が試みられたか、作業グループが何をすることを決定したかを示すべきである。弱い第三者声明は、再設計ではなく監視を正当化するかもしれない。信頼できるライセンス結果を伴う特定の通知は、即時レビューを必要とするかもしれない。
第三者開示は非難されることなく遅れる可能性があるため、標準は可能な限り可逆性を持って設計されるべきである。オプションのメカニズム、ネゴシエートされた機能、モジュール式依存関係、文書化された代替案は、ロックインを減らすことができる。そのようなアーキテクチャは常に可能とは限らないが、権利の不確実性は運用上の不確実性と同じ復元力分析に属する。
デル命令は採用後のレバレッジが重要である理由を示す
IETF だけが特許情報の遅延が問題となる標準設定ではない。1996年、米国連邦取引委員会のデルコンピュータ命令は、別の組織と特定の事実記録に対処した。委員会は、デルが VL バス標準の開発中に相反する権利がないと証明し、採用後に特許を行使しようとしたと述べた。命令は、提示された状況下での執行を制限した。
このケースは BCP 79を解釈するための権威ではなく、その法的基準はすべての遅延 IETF 開示に一般化されるべきではない。制度的な一点で有用である：採用は、特許権者のレバレッジを変える依存関係を生み出すことができる。委員会の説明は、標準化団体が選択中に競合を知っていれば、異なる非専有設計を選択できたであろうことを強調した。
その反事実は情報に基づくコンセンサスにとって中心である。害は単なる驚きではない。それは、選択するのが最も安かった時点での代替案の喪失である。製造業者、ソフトウェアプロジェクト、ユーザーが1つの仕様で調整されると、スイッチングコストにより、後のライセンス要求はオープンな設計競争よりも強力になる可能性がある。
IETF の開示ルールは、機関を反トラスト機関や特許裁判所に変えることなく、そのリスクを軽減するように設計されている。早期通知は参加者に意識的に選択する機会を与える。検索可能な記録は実装者に依存関係を評価する機会を与える。明確なタイミング証拠は、裁判所や他の権限ある機関が後の紛争を評価することを可能にし、作業グループに法律を決定するよう求めることはしない。
限定された教訓は予防的である：既知の重要な制約が不必要に不可視のままである間、標準は不可逆的な依存関係を獲得すべきではない。
サンクコストはソースコードをはるかに超えて広がる
「サンクコスト」というフレーズは、ソフトウェアの書き換えについての開発者の不満に聞こえるかもしれない。制度的損失はより広い。技術的サンクコストには、アーキテクチャ分析、プロトタイプ、テスト、セキュリティレビュー、相互運用作業、文書化、バグ修正が含まれる。組織的コストには、編集者の時間、会議の議題、問題のトリアージ、議長の判断、クロスグループ調整が含まれる。
実装者は製品コストを負担する：ハードウェア決定、アプリケーションインターフェース、適合スイート、トレーニング、調達、サプライヤー契約、認証、顧客コミットメント。運用者は監視、インシデント対応、移行手順を構築するかもしれない。オープンソースコミュニティは依存関係の周りでメンテナーを再編成するかもしれない。大学は出現しつつある標準を教えるかもしれない。規制当局や調達機関がそれを参照するかもしれない。
オプションコストもある。1つの設計が注目を集めている間、代替案は貢献者と関連性を失う。コンセンサス後の特許開示は、選択された設計にライセンス価格を追加するだけではない。より安価な代替案には、それを完了できる活発なコミュニティがもうないことが明らかになるかもしれない。
これらのコストは不均等に分布している。大規模な特許保有ベンダーは弁護士とクロスライセンスのためのポートフォリオを持っているかもしれない。小規模実装者は、機能からの期待収益よりも大きな取引コストに直面するかもしれない。オープンソースプロジェクトはユニットあたりのロイヤリティを全く受け入れられないかもしれない。ユーザーは、残っているすべてのベンダーが交渉できたとしても、競争の減少を受け継ぐ。
遅延情報を評価する作業グループは、これらの層を目録化すべきである。再設計が高価であるという事実は、自動的に権利が絡んだメカニズムを保持する理由にはならない。その論理は遅延を報いることになる。また、グループは連続性の害を無視すべきではない。法的な不確実性、実装の可用性、移行の安全性、長期的な集中を、理由のある記録の下で比較すべきである。
早期警告に法的結論は必要ない
貢献者は、特許がドラフトをカバーすることを証明できないため、ためらうことがある。BCP 79は、信念に基づくしきい値を使用し、予備的開示を許可することでこれに対処している。目的は、有効性や侵害の認証ではなく、潜在的な制約の通知である。
IETF はこの境界を強化している。開示された権利の有効性や範囲について立場を取らず、独立してそれらを特定しない。開示はそのソースからの情報である。作業グループは、裁判所が決定することを宣言せずに、リスクとライセンスの姿勢を考慮できる。
この境界は、すべての開示インターフェースと会議リマインダーで見えるべきである。参加者は、法的クレームを認めたとして扱われることなく、未公開出願や不確実なポートフォリオ関係を報告できるべきである。第三者は、疑念を制度的承認に変換することなく、通知の理由を特定すべきである。実装者は、記録がデューデリジェンスの出発点であり、法的クリアランスではないことを理解すべきである。
早期警告は段階付けできる。構造化された記録は、権利者開示、貢献者の予備的通知、特定された公開クレームを伴う第三者通知、一般的な声明を区別するかもしれない。ライセンス情報が利用可能かどうか、権利者がエントリを確認したかどうかを示すことができる。これらのカテゴリは、不確実性を抑制せずに参加者の注意を割り当てるのに役立つ。
間違った基準は、開示前に法的確実性を要求し、その後で通知が遅れたと批判する。正しい基準は、知識が向上するにつれて、迅速で範囲が限定された情報と更新を要求する。法的中立性を維持しながら、技術的選択を保護する。
開示時計はタイミングを検証可能にする
「合理的に可能な限り早期に」は1つの普遍的な期限に還元することはできないが、開示時計を通じて検証可能にすることができる。記録は、最も早期の関連貢献、最初の真剣なワーキンググループ議論、採用要求、採用決定、主要設計選択、ワーキンググループラストコール、IETF ラストコール、承認、公開、実装報告、および各開示または更新を並べて配置すべきである。
時計はまた、関連する場合、述べられた知識イベントを特定すべきである：出願の提出、公開、ポートフォリオでの発見、権利の取得、または参加者の影響を受ける議論への参加。権利者は特権的なアドバイスを明らかにする必要はないが、遅延声明は、新たに発見された権利と遅延報告を区別するのに十分なタイミングを説明すべきである。
いくつかの測定値が続く。開示遅延は、トリガーとなる貢献または述べられた知識と正式な掲示の間の間隔である。決定遅延は、掲示と次の不可逆的なマイルストーンの間の間隔である。更新遅延は、未公開出願、発行特許、変更された所有権、ライセンスポジションがどの程度迅速に反映されるかを測定する。検索品質は、通常のユーザーが現在の RFC またはドラフトから声明を見つけられるかどうかを測定する。
これらは診断指標であり、自動的な有罪スコアではない。後から参加したエリアディレクターは、ラストコールでクレームを合理的に知るかもしれない。貢献者は、ポートフォリオレビュー後にのみ特許を発見するかもしれない。貢献前の開示でも、役立つには曖昧すぎるかもしれない。文脈は依然として必要である。
利益は制度的記憶である。議長は、記憶から議論する代わりに、グループがいつ何を知っていたかを示すことができる。実装者は、採用中に権利ポジションが安定していたかどうかを判断できる。レビュアーは、繰り返される組織的失敗を特定し、リマインダーや調整を改善できる。
「十分に検索可能」には実装者のテストが必要
データベースは、検索ボックスがあれば形式的に検索可能である。合理的に勤勉な実装者が技術的成果物から始めて関連する権利記録を再構築できる場合にのみ、十分に検索可能である。
主要なパスは、すべてのインターネットドラフトバージョンと RFC から、特定の開示および一般的声明（廃止および更新されたエントリを含む）に至るべきである。逆リンクは、開示をすべての特定されたドラフト、名称変更された文書、後継ドラフト、RFC、影響を受ける作業グループに接続すべきである。検索は権利者名の異形を正規化し、歴史的アイデンティティを消去せずに譲渡や更新を公開すべきである。
特許および出願番号は管轄区域ごとに正規化され、ファミリー関係は法的結論ではなく情報リンクとして表示されるべきである。影響を受けるセクションとメカニズムは検索可能であるべきである。ライセンスの姿勢は、構造化カテゴリと元の宣言を使用すべきである。ユーザーは日付でフィルタリングし、採用時、ラストコール時、または公開時点の記録を表示できるべきである。
すべての結果は出典を示すべきである：提出者、権利者、提出日、更新チェーン、該当する場合の確認ステータス、および項目が特定、予備的、第三者、または一般的であるかどうか。空の結果には常に、IETF 特許検索は実施されておらず、後の開示が可能であるという警告が伴うべきである。
アプリケーションプログラミングインターフェースへのアクセスと耐久性のあるエクスポートにより、オープンソースプロジェクト、ベンダー、研究者が変更を監視できる。通知は、新しいまたは更新された声明がドラフトまたは RFC に添付されたときに、文書著者、議長、既知の実装者、購読者に届くべきである。目的は侵害の予測ではない。それは、実装リスクを負っている人々への IETF 自身の情報のタイムリーな配信である。
遅延開示には救済措置の段階が必要
情報が重要な決定後に到着した場合、最初の対応は記録を保存し、必要なものだけを一時停止すべきである。議長は開示を正確な文書とバージョンにリンクし、影響を受けるメカニズムを特定し、作業グループと既知の実装者に通知し、利用可能なライセンスの明確化を要求すべきである。グループは、新しい情報が選択に重要かどうかを判断すべきである。
クレームが使用可能な代替案を持つオプション機能に影響する場合、警告と文書更新で十分かもしれない。公開前に必須メカニズムに影響する場合、グループは決定を再開したり、再設計したり、必須ステータスを変更したり、進捗を延期したりできる。RFC が公開されているが展開が限られている場合、更新、置き換え、または実装ガイダンスが害を封じ込めることができる。広く展開されている標準は、段階的な移行と慎重な調整を必要とする。
責任レビューは別途進めるべきである。開示は必要だったか？参加者は合理的にいつ知ったか？雇用主が開示を妨げたか？予備的通知は可能だったか？リマインダーに正確に回答されたか？影響を受ける人は通知と説明の機会を必要とする。RFC 6701の下での制裁は、知識、効果、意図、協力、再発に比例すべきである。
救済措置は、サンクコストに自動的に決定させてはならない。遅延が出口を高価にしたという理由だけで技術を保持することは、遅延開示のインセンティブを生み出すだろう。同時に、展開された相互運用性を突然壊すことは、クレームよりもユーザーに害を及ぼす可能性がある。理由のある決定は、各オプションのコストを誰が負担するか、集中度やライセンスの不確実性が時間とともにどのように変化するかを特定すべきである。
公的な結論は、事実と未解決の法的問題を区別すべきである。IETF は、開示がラストコール後に到着し、再設計を引き起こしたと述べることはできるが、特許が有効であるとか、参加者が法的に責任があると宣言することはできない。
予防には混乱のない責任の共有が必要
参加者は BCP 79で定義された開示義務を負う。雇用主とスポンサーは、標準エンジニアが関連する既知の権利を迅速に特定できる内部ルートを必要とする。議長とエリアディレクターは、実際の決定時点でリマインダーを発行すべきである。事務局は、耐久性があり、リンクされ、検索可能な記録を維持すべきである。実装者は、沈黙をクリアランスとして扱うのではなく、展開に比例したデューデリジェンスを実行すべきである。
これらの責任は補完的である。議長のリマインダーは参加者の義務を免除しない。公開データベースは特許検索を実施しない。実装者の法的レビューは、既知の権利者を早期通知から免除しない。IETF の有効性判断の拒否は、作業グループが実装リスクが低い代替案を好むことを妨げない。
雇用主は、エンジニアに予備的開示を提出する明確な権限を与え、ライセンスコミットメントを早期に公開し、譲渡と出願を更新することで、責任ある参加を示すことができる。作業グループは、権利の不確実性が解決されるまで交換可能なままのアーキテクチャを好むことができる。ツールは、IPR ステータスを専門家の隅に置くのではなく、通常の文書ビューに添付できる。
同じ組織が技術を提案し、唯一の実装を提供し、開示された権利を保持する場合、独立したレビューが重要である。そのパターンは提案を失格にはしない。それは、別の実装、明示的なライセンス分析、代替案との文書化された比較の必要性を高める。
共有された目的は情報に基づく選択である。各主体が他の誰かがリスクの不在を認証したと想定すると、責任は混乱する。システムは代わりに、どの主体がどの情報を提供し、どの不確実性が残っているかを正確に示すべきである。
情報に基づくコンセンサスは依存の前に存在しなければならない
IETF は、2つの単純化された立場を拒否するため、洗練された知的財産フレームワークを持っている。特許技術は自動的に禁止されない；それが利用可能な最良の設計かもしれない。開示はクレームを有効にしない；IETF は特許裁判所ではない。作業グループは技術的裁量を保持し、権利者は正当な権利を保持する。
そのバランスは、情報が依存関係の後にのみ到着する場合に崩れる。グループは、リスクが不可視のときに技術的優位性とライセンスリスクを比較検討できない。実装者は、必須インターフェースが固定された後にモジュール式代替案を選択できない。後日の公開掲示は将来の通知を改善するかもしれないが、以前のコンセンサスを情報に基づいたものにはしない。
統治テキストは既に解決策を特定している。RFC 8179は合理的に可能な限り早期の行動を要求し、予備的開示を奨励している。RFC 3669はグループに重要な選択のたびに尋ねるよう指示し、遅延クレームのコストを記録している。RFC 6702は早期情報を正確なコンセンサスに結び付けている。RFC 6701は標準作業と展開された機器への混乱を認識している。Datatracker は公開開示記録を提供している。
残された課題は、タイミングと検索可能性を存在と同じくらい可視化することである。すべての重要な技術的マイルストーンは、その時点で利用可能な権利情報を示すべきである。すべての現在の RFC は完全な開示履歴に解決されるべきである。すべての更新は以前の声明を保持すべきである。すべての空の検索は、沈黙がクリアランスではないと警告すべきである。ライセンスの不確実性は、採用後の私的交渉に延期されるのではなく、真の制約として扱われるべきである。
コンセンサスは、参加者がコミットメントの前に真の代替案を比較できるときに正当性を得る。特許開示がアーキテクチャ、コード、展開が依存関係を生み出した後に到着する場合、機関は遅延した書類を受け取っただけではない。開示が保護するように設計された選択の一部を失ったのである。