要約

  • RFC 5377が記録したのは、IETFが外向き権利をどうしたいかというrough consensusである。正確な法的文言、表示方式、適用範囲と発効時点はIETF TrustのTrusteesが決める構造だった。
  • 承認、実装、公開、発効、下流利用はそれぞれ別のイベントである。日付を一つに圧縮すると、移行期のContributionにどの条件が適用されたかを検証できない。
  • RFC 8721はIAOC参照を除くことだけを目的にRFC 5377をobsoleteとし、実質的な権限分離を維持した。本稿はガバナンス分析であり、法的助言ではない。

投票が終わってもテンプレートはまだ変わっていない

共同体の議論が終わり、IESGの承認を経てRFCが公開される。その時点で「決定済み」と表示することは正しい。しかし、実際のInternet-Draftテンプレート、RFCの権利表示、Trust Legal Provisions、運用手順まで同じ秒に変更されたと推定するのは正しくない。

RFC 5377は、文書と文書方針の変更がTrusteesの決定に従って効力を持つとした。ここには移行の所有者がいる。共同体は目的を示し、Trusteesは法的メカニズムを選び、いつ適用するかを決める。

この間隔は失敗ではない。正確な文言を準備し、対象を定義し、古いContributionの扱いを決め、表示を更新するための統制面である。問題は、その間隔を記録しないことである。

approvedを自動的にeffectiveへ写すデータモデルは、承認前の状態と施行後の状態しか持たない。どの決定で切り替わったか、移行期の文書がどちらに属するかを説明できない。

四つの時刻を一つにしない

最低でも、合意成立、Trustee決定、法的メカニズム公開、発効という四つの時刻がある。さらに、個々の文書に表示が反映された時刻と、下流利用者が実際に再利用した時刻もある。

合意成立は方向のreceiptである。Trustee決定は権限行使のreceiptである。公開された条項は内容のreceiptである。発効日は適用可能性のreceiptである。下流成果物は実際の行為のreceiptである。

どれも互いに代替しない。例えば新しい条項が公開されても、発効前なら旧制度が適用される可能性がある。逆に発効済みでも、古いテンプレートを使った文書は表示不整合を持つかもしれない。

監査では、対象Contributionの作成日と版、当時有効だった条項、移行規則を結び付ける必要がある。現在のWebページだけでは過去の状態を証明できない。

正確な文言をRFCから外した理由

RFC 5377は、具体的な法的文章をRFC本文に固定する方法の弱点を説明した。文章に問題が見つかった場合、意図が変わっていなくてもRFCを改訂しなければならない。緊急に直すべき法律上の問題が出版プロセスを待つことになる。

そこで文書は、IETFの望む結果を示し、正確な挿入文や他の仕組みの選択と更新をTrusteesに委ねた。安定した意図と保守可能な実装を分離したのである。

この設計では、文言変更が方針変更なのか、同じ方針をより正確に表す修正なのかを記録しなければならない。差分だけでは判断できない。変更理由と権限根拠が必要になる。

柔軟性は、履歴が保存されるときにだけ統制となる。古い版を消して最新ページだけを残せば、後から「当時も同じ意味だった」と主張するしかなくなる。それは証拠ではない。

Trusteesの権限にも入力上限があった

Trusteesは外向きライセンスを決める権限を持っていたが、Trustが受け取っていない権利を与えることはできなかった。RFC 5378が扱う入力側のgrantが、RFC 5377の出力側を制約する。

この関係は、発効日とは別の検査である。正しく承認され、正しく発効した最新方針でも、特定の古い部品について派生物の権利を受け取っていなければ、その権利は出力できない。

したがって、適用システムはContribution単位だけでなく、必要に応じて部品単位のprovenanceを持つ。著者、第三者素材、既存作品、明示的制限、受領日を記録する。

Trustee権限は在庫を管理する。権利在庫そのものを無限にするわけではない。組織上の正当性を所有権の代わりに使わないことが重要である。

完全複製の時刻と引用の時刻

RFC 5377は、RFC全体の複製と翻訳を広く認めたいとした。文脈や意味を失わずに流通させるためである。ここで確認すべきものは、対象版、完全性、必要な表示と翻訳関係である。

引用は別の利用である。未変更の抜粋と適切なIETF・Contributionの帰属が中心になる。引用が行われた時点で有効な条件を確認し、抜粋範囲と最終表示を保存する。

完全複製が認められた日から、すべての散文改変が可能になるわけではない。引用に帰属が付いたから、改変許可まで得たことにもならない。

一つのlicense_okでは、この差を表せない。利用目的と時点が変われば、参照する権利receiptも変わる。

コード部品は実装のために変形される

ABNF、XML Schema、DTD、Relax NG、値表、MIB、ASN.1、古典的プログラムコードは、機械や実装で直接利用される。言語、コンパイラ、ツールに合わせるには変更が必要になることがある。

そのためRFC 5377は、コード部品を抽出・修正・利用できる広い権利をTrustが与える方向を示した。外部の派生作品が追加のライセンス義務を持つことも想定した。

ただし、技術的に見えるという理由だけでコードになるわけではない。RFCは、Trusteesが共通コード部品のリストと、部品をコードとして示す文字表現を用意する案を示した。

この分類にも時点がある。あるリスト版で認識された部品が、以前の版では明示されていないかもしれない。分類規則の更新を過去へ自動適用するなら、その根拠が必要である。

さらに分類は入力権利を増やさない。正しくコードとされた部品でも、派生物を禁止する既存材料なら、Trustが受け取った範囲を越えられない。

普通の文章は同じ発効を共有しなかった

RFC 5377は当時、変更を必要とする形でRFCの普通の文章を利用する一般許可について合意がないと記録した。著者が独立して追加権利を与えることは可能だが、別経路である。

したがって、コード許可の発効を「RFC全体の改変許可」として配布してはいけない。一つの文書内で部品ごとに異なる状態が同時に存在する。

自動抽出では、開始・終了境界、分類根拠、元版hashを残す。コードの隣の説明文まで取り込めば、成果物は許可境界を越える可能性がある。

逆に、普通の文章の制約を理由にコード抽出を全面禁止すれば、相互運用実装を促す政策目的を損なう。細分化は複雑さではなく、両方の誤りを避ける方法である。

古いRFCの発効はさらに複雑だった

新しい外向き方針を古いRFCにもできるだけ適用したいという希望はあった。しかし、過去の権利保有者が追加grantを行わない限り、受領権利は拡大しない。

新方針の発効日は、古い権利の取得日ではない。ここを混同すると、制度が時間を遡って所有者の意思を書き換えたことになる。

古い文書は個別に、受領済み権利、第三者部品、派生物制限を調べる必要がある。追加grantを得る、利用を限定する、部品を置き換える、歴史条件を維持するなどの結果があり得る。

legacy=trueは結論ではない。何が不足し、どの経路で補ったかを記録する調査状態である。

著者の独立ライセンスは別の発効線を持つ

著者は権利を保持し、IETF経路とは別に追加ライセンスを提示できる。その外部ライセンスには独自の版、対象、発効日、条件がある。

Trustの許可と著者の許可を合成して、誰も発行していない第三の条件を作ってはいけない。下流利用者はどちらを根拠にしたかを記録する。

外部リンクだけでは履歴にならない。条項のcapture、issuer、work scope、authorityを保存する。著者がContribution全体のすべての第三者部品を許可できるとは限らない。

片方の条件が変わっても、もう一方が独立して成立するかを判断できるよう、provenanceを分離する必要がある。

RFC 8721の発効は継承の範囲を明示した

RFC 8721は2020年にRFC 5377をobsoleteとした。新文書は、その目的が旧IASAの一部であるIAOCへの参照を除くことだけだったと明記する。

現在のprocess authorityはRFC 8721である。RFC 5377の文書状態は終わった。しかし、共同体方向、Trustee実装、入力権利上限、用途分類、発効決定という実質構造は継承された。

後継文書は、RFC 5377の権限下でTrusteesが作った既存のライセンス文言や材料を出発点にするとも述べる。これはcontinuity receiptであり、すべてをゼロから作り直した証拠ではない。

文書台帳には、obsolete、successor、理由、継承要素を保存する。旧文書を現行と呼ばず、かといって歴史的理由を削除しない。

発効を証明する台帳

再利用判断には次を結び付ける：

  • Contributionと部品のidentity、版、hash；
  • contributor、既存・第三者材料；
  • Trustが受け取ったgrantと制限；
  • 当時のcommunity-direction RFCとstatus；
  • Trustee decisionとauthority；
  • precise legal provisionsの版；
  • publication dateとeffective date；
  • document/component classification；
  • planned downstream use；
  • attributionとnotice；
  • separate author licenceがあればその独立記録；
  • distributed artefactと結果。

この台帳は法的判断を自動化するものではない。判断材料を、後から資格ある人が検証できる形で残す。

不明な日付をRFC公開日で埋めない。不明な入力grantをTrustee権限で埋めない。不明な分類を書式で埋めない。欠けた証拠を欠けたまま表示することが、誤った確実性より強い。