要約

  • 現行のRust商標ポリシーは、名称・ロゴ・出所表示・所属や推薦に見える印象を扱い、Rust Foundationの商標管理とLeadership CouncilによるProject統治を分けている。
  • 許容された言及、書面による許可、公式ソースの指定、Projectの決定、レビュー済みリリース、下流での導入は、同じソフトウェアに関わっていても別個の命題である。
  • 身元と権限のレシートを残せば、新しい認証制度を作らず、特定のcrateや製品を評価せずに、各命題の根拠を追える。

分かりやすい名前は包括的な資格ではない

Rustという名称は、言語、ツール群、そして特定のソースを指し示すために役立つ。そのためには、何を意味しないかも見える必要がある。現行のRust Language Trademark Policyは、オープンソースのRust ProjectがLeadership Councilによって統治され、Rust Foundationがこれを支え、RustとCargoの商標・ロゴを所有し保護すると説明する。この記述は飾りではない。隣接しているが同一ではない役割を示している。

商標の管理が扱うのは、外部の人にどのような身元信号を送るかである。誰が名称やロゴを使い、それが誰の公式性・関係性・推薦を意味するように見えるか。Project統治が扱うのは、チーム、代表、権限、方針、委任である。さらに、特定の成果物については、どのソース、commit、バイナリ、バージョンを指すのか、誰がレビューまたはリリースしたのかという別の問いがある。最後に、利用者や運用者が選択、インストール、配備したかという問いがある。

一つの会社やツールがこれら全てに現れても、問いは一つにならない。「Rustと互換である」は限定された関係の説明である。「公式である」「Projectが選んだ」「本番で稼働している」と言うには、追加の当事者、決定、成果物、日付が必要になる。同じ名称は、それらを自動的には運ばない。

商標ポリシーが守るのは誤った外観を作らないこと

ポリシーの基本ルールは、書面によるFoundationの許可なしに、一般の閲覧者にRust ProjectまたはRust Foundationの公式、関係先、推薦先であるように見せる使い方をしてはならない、というものである。明示的な承認を要しない用法として列挙される場合にも、この条件は残る。これは、ソフトウェアの安全性、品質、採用実績を一律に認定する規則ではなく、公開の身元表示に関する規則である。

同時に、ポリシーは正確な説明を可能にする。ソフトウェアがRustで書かれている、Rustと互換である、Rustのコードを含むと言うことは、事前承認なしにできる。利用または互換性を示す場合にはcrateやリポジトリの名称にRustを使え、公式のCargo拡張であると示唆しない限りcargo-foobarというサブコマンド名も使える。これは開かれた生態系に必要な余地である。

しかし、正確に互換性を述べられることは、Projectがそのツールを選定した、チームがコードをレビューした、あるバイナリが公式リリースになった、という意味ではない。ロゴ付き商品の販売、別の商標の中への組込み、特定のイベント名、許容範囲を超える変更版RustまたはCargoの頒布などは、明示的な承認を要する場合がある。その許可の要否や条件は、その使用についての事実であり、メンテナー権限、投票権、技術判断、導入結果を含む証明ではない。

公式ソースの表示は、バイトの出所についての限定された主張である

ポリシーは、複数のドメインとrust-langのGitHub組織を、Rust Projectの公式ソースコードと関連バイナリの正当な出所として掲げる。同じ箇所で、それらのドメインにある全てが公式またはポリシーの対象であるわけではないとも述べる。この留保が重要である。ドメインは指定された出所を示しうるが、そこに近い全てのページ、ブランチ、issue、ファイルを自動的に公式・レビュー済み・リリース済みにする装置ではない。

公式ソースという記述が答えるのは、Projectが公式のコードやバイナリの出所をどこに置くか、という問いである。どのcommitがレビューされたか、利用者が入手したファイルがどのリリースに対応するか、依存関係が何か、実際にどの環境で動いているかまでは答えない。そこには、成果物の識別子、不変なバージョンまたはダイジェスト、独立したレビュー・リリース・運用の記録が必要になる。

逆も成立しない。商標を使う許可が、第三者のリポジトリをProjectの公式ソースに変えることはない。ポリシーは互換性を正直に表現できるようにしながら、互換なソフトウェア全てをProjectの制度的身元へ吸収しない。この分離があるからこそ、相互運用性の説明と公式性の主張を両立できる。

Projectの権限には別の公開経路がある

Leadership Councilの公開規則は、Project側の経路を示す。すべてのProjectチームは最終的にトップレベルチームの下に置かれ、その各チームがCouncilの代表を一人指定する。Councilの標準的な意思決定方法はconsentであり、内部の運用判断と公共的な方針判断を区別する。Councilの決定者やチーム参加資格、Projectの法務・ライセンス方針、Projectを代表する継続的な約束、法的構造またはFoundationとの関係の重要な変更は、公開方針の手続に属する。

この仕組みは、全ての技術的論点に唯一の答えがあると約束するものではない。しかし、Projectの権限がどこから来るかを見えるようにする。名称の使用が適法であること、イベント名の許可、互換crateの公開だけで、個人や組織がその経路を得ることはない。また、Councilの決定があれば全ての対外的な商標使用が自動的に許されるわけでもない。両者は協力できるが、交換可能な許可証ではない。

FoundationのBylawsも同じ分担を示す。Projectの支援と促進、保守・開発・安全性の支援、技術インフラの管理、商標その他資産の管理と保護が目的として記され、Rust Projectは言語の主要な開発者とされる。支援、インフラ、身元保護は大きな責任であっても、全てのコードレビュー、全ての商標使用、全ての利用者の導入決定を一つにまとめない。

五つの主張を借り物にしないレシート

すべてのRustへの言及を許可申請にする必要はない。だが、複数の主張を一度に行うなら、身元と権限のレシートを保持できるべきである。第一の欄には、正確なマークまたは名称、使用者、用途、公開文言、許可の要否、条件と失効時点を書く。第二の欄には、主張するソース、リポジトリまたはドメイン、成果物名、不変な版またはダイジェスト、そして公式・互換・第三者のいずれとして述べるかを書く。

第三の欄は、Projectの権限を実際に主張する時だけ必要である。関係するチームまたはCouncil手続、公開の決定参照、範囲、日付を置く。第四の欄にはcommit、レビュー記録、リリース責任者、build参照、状態というレビューとリリースの証拠を置く。第五の欄では、試験、調達、導入、本番運用、または主張なしという下流の事実と、誰がそれを訂正できるかを示す。

正確にRustを扱う書籍なら、第一の欄だけで足りる場合がある。公式統合を名乗るツールには、より強い出所と権限の記録が必要になる。本番利用を述べるなら、それ自身の運用証拠が必要である。空欄は正直である。他者の権限を空欄に借りて埋めることが問題になる。

このレシートは新しいRustポリシーでも、パッケージ登録簿でも、導入届でもない。Foundationをソフトウェア承認者にせず、Councilを配布審査機関にせず、既に存在する権限だけを各境界で見えるようにする。そのため、一つの名称、一つのバージョン、一つの決定、一つの導入が変わっても、残りの事実を一緒に書き換えずに済む。

層を潰すと訂正は高くつく

限定された商標許可が技術レビューの印に読まれ、公式らしいURLが現行リリースの証拠に読まれ、コミュニティの催しが統治権限に読まれることがある。その短縮は今日の説明を楽にするが、後の読者から「実際に証明されたのは何か」を奪う。

反復は誤りを増幅する。紹介文が文書へ、文書が調達資料へ、調達資料がProjectまたはFoundationが関係を承認した証拠へと移る。許可が終了し、成果物が置換され、Councilの方針が変わり、利用者が導入をやめたとき、一つの事実の修正が物語全体の否定に見えてしまう。最初から身元、権限、成果物、導入を分けておけば、その負債は生じにくい。

商標は商標について語り、Projectの規則はProjectの決定について語り、成果物の記録は成果物について語り、運用の証拠は運用について語る。この節度はRustという名前を弱めない。誰が本当に決めたのかを、名前の信用で隠せなくする。

情報源

  1. Rust Language Trademark Policy
  2. Rust Language Trademark Policy Updates, Explained
  3. Rust Foundation Bylaws
  4. Rust Project Leadership Council