要約

  • RFC 5378 では、Contribution の実投稿者と記名共同貢献者は、投稿の時点で規則を理解し法的拘束力のある合意に入ったものとされ、追加の確認や署名を必要としない。
  • 投稿者は、合理的かつ本人が知る範囲で権利を持つ雇用主やスポンサーなどから必要な許諾を得たものとされるが、投稿イベント自体がその許諾や所有権を独立に証明するわけではない。
  • 基礎となる Contribution の著作権は貢献者側に残り得る一方、IETF Trust は永続的・取消不能・非独占・無償・全世界的・再許諾可能なライセンスを受ける。特許権はその対象外である。

受領システムが知っていること

投稿システムは強い証拠を作れる。誰のアカウントが、どの内容を、いつ、どのポリシーの下で送ったかを固定できる。RFC 5378 はその行為に明確な法的効果を結び付けた。実際に投稿した者と記名された共同貢献者は、規則を読んで理解し、条件に従う合意を結んだものとされる。追加の署名は不要だ。

この仕組みは、開かれた標準化を現実に動かす。IETF の Contribution は完成した Internet-Draft だけではない。会合での口頭発言、ワーキンググループのメール、IETF の活動に向けた電子的な提案も含み得る。入力ごとに個別契約を交渉すれば、議論は止まる。

一方、受領システムが直接知らないこともある。文章が職務として書かれたなら、法や契約によって勤務先が権利を持つかもしれない。過去の文書から取った段落には別の著者がいる。共同執筆者の名前が抜けている可能性もある。サーバーは投稿を観測しても、それらの契約や来歴を自動では読めない。

したがって、受領票の主張は狭く保つべきだ。「この人物がこの条件で投稿した」は言える。「この人物が全断片を所有していた」は、追加資料なしには言えない。強い証拠ほど、証明していない範囲も明確にしなければならない。

許諾は表明されるが、生成はされない

RFC 5378 は権限の問題を投稿者側の表明として扱う。貢献者は、合理的かつ本人が知る範囲で Contribution に権利を持ち得る者、特にスポンサーや雇用主から、合意に入るための必要な許諾を得たものとされる。

さらに、本人の知識と能力の限りで、直接・間接の貢献者が適切に示されていること、機密情報がないこと、権利付与を妨げる既知の制限がないことなどを表明する。「合理的かつ本人が知る」とは、実際に知っている事項だけでなく、その職務なら知っていると合理的に期待される事項も含む。組織が意図的に担当者を無知のままにして責任を避けることはできない。

ただし、この知識基準を全世界の権利調査に読み替えてはならない。IETF 自身、すべての文書について財産権の状態を独自調査する資源がないと説明している。制度は、最も情報に近い人の表明に依存する。

だからこそ、表明は主体付きで保存する必要がある。投稿者が知っていたこと、雇用主が許諾したこと、共同貢献者が確認したこと、第三者素材の出典は別々のレコードである。一つの「権利確認済み」フラグにまとめると、誰の知識がどの結論を支えたのか分からなくなる。

保有と許諾を二者択一にしない

RFC 5378 の入力ライセンスは広い。保護対象となる Contribution について、貢献者と記名共同貢献者は、IETF Trust に永続的、取消不能、非独占、無償、全世界的、再許諾可能な権利を与える。複製、公表、表示、頒布、翻訳に加え、許容された表示で除外しない限り、修正と派生物の作成も含む。

この広さは標準の継続性を守る。著者が離脱しても、会社が変わっても、共同成果を保存し、翻訳し、更新できる。あとから一人が撤回して標準全体を止めることを防ぐのが取消不能性である。

それでも、基礎となる Contribution の著作権は貢献者または雇用主に残り得る。非独占ライセンスは、所有者による利用と Trust による公共的管理を両立させる。RFC という集合著作物・書式の権利と、個々の寄稿部分の権利も同一ではない。

この区別は後段にも続く。Trust は標準化プロセス内外の利用に対して出口ライセンスを用意する。文章、翻訳、派生物、コンピューターが直接処理する Code Components は同じ扱いとは限らない。公開 URL が存在することは、あらゆる再利用の許諾ではない。

Note Well は入口表示であって権利証書ではない

参加者に規則を示す Note Well や文書中の legend は、予告と透明性のために必要だ。しかし RFC 5378 は、書面 Contribution の表示そのものが権利を伝えるのではないと述べる。表示は読者に法的権利と制限を知らせる。

ここを混同すると、正しい文言を貼れば権利問題が解消したように見える。雇用主が許していない素材に適切なフッターを付けても、許諾は生まれない。第三者の文章に IETF の legend を付けても、投稿者の作品にはならない。

入口では適用規則を示す。投稿時には内容とポリシー版を固定する。表明は誰が行ったかを残す。外部権利者の許諾はその権利者に帰属させる。後の利用者は Trust の出口条件に従う。役割を分ければ、問題が起きたときにどこを直すべきか分かる。

古い断片は新しい投稿で権利が増えない

RFC 5378 より前の IETF 素材は、後の制度が求めるすべての権利を伴っていない場合がある。新しい Contribution に古い文章を含めても、新しい投稿者は元の作者が与えなかった権利まで付与できない。

Trust は、その事情を示して特定の派生利用を留保する legend を用意した。これは歴史を消さない修復である。古い素材を全面的に捨てるのでも、新しい容器で権利を洗い替えるのでもない。断片に由来する制約を、後続の利用者が識別できる形で残す。

同じ原則は版管理全体に当てはまる。コピーされた文章には、出典、当時のポリシー、与えられた権利、後の例外が付いて回る。最新版のヘッダーだけを保存しても、内部の権限は説明できない。

特許は別の統治面に残った

RFC 5378 のライセンスは、特許、特許出願その他の類似権利を与えない。特許に関する開示と手続は BCP 79、現在の RFC 8179 に属する。仕様書の文面を複製できることと、記載技術を実施できることは別である。

このため、「IP」という一つの状態は危険だ。著作権の由来、入力ライセンス、貢献者表明、特許開示、Code Component の再利用条件は別々に追跡すべきである。ある経路の適合は、他の経路の許可を意味しない。

採用判断もまた独立している。IETF は Contribution を公表、利用、流通させる義務を負わず、不適合なものの利用をやめられる。投稿が有効でも、標準採用、技術的正しさ、実装、相互運用や運用成果は証明されない。

最小限の証拠鎖

実務では、内容とポリシー版のハッシュ、Contribution となった活動、実投稿者と共同貢献者、間接貢献者、取り込み素材の出典、雇用主・スポンサー・第三者の許諾、制限 legend、Trust が受け取った権利、後の利用者が依拠した出口条項をリンクできる。

全部を一枚の契約にする必要はない。イベントごとの小さな受領票でよい。単純な発言なら記録は軽い。複数企業と古い文書を含む Draft なら追加の証拠が要る。管理負荷はリスクとともに増やし、公開後の知名度で決めない。

分離は回復可能性を高める。出典不明の段落だけを切り離せる。雇用主に後から許諾を求められる。共同著者の表示を修正できる。出口ライセンスに合う利用方法へ戻せる。全体を一つの緑色に塗ると、修正は全否定か無条件容認になってしまう。

本稿は個別案件の法的判断を行うものではない。RFC 5378 自身も、法的解釈を必要とする参加者には専門家への相談を促している。ここで得られる運用上の結論は一つだ。投稿を拘束力ある行為として記録し、その行為では分からない権限を別の証拠で補う。