|
著者 | 千山 校正：Yun Zhao オープンソースをめぐる法的な議論は、オープンソースライセンスやソフトウェアの著作権に焦点が当てられることが多く、商標の問題はあまり注目されていません。実際、オープンソースソフトウェアとその派生製品における商標の使用は、しばしばグレーゾーンに存在します。 最近、Rust Foundation は更新された商標ポリシーに関するフィードバックを求めていましたが、これは予期せず Rust コミュニティで大きな論争を巻き起こしました。 画像出典: Rust 商標ポリシーコメントフォーム (google.com) 特に、新たな草案では、Rust関連のツールやRustで書かれたソフトウェアの名称に「Rust」を使用することが禁止され、ドメイン名やサブドメインにも具体的な制限が課されています。これに対し、「コミュニティの善意とRust言語の発展を損なうため、財団がコミュニティの意見に耳を傾け、この方針を撤回することを期待する」と率直に表明する声も上がっています。 1. イベント トラッキングは商標の使用を制限しますが、コミュニティの反対者はそれを不合理だと言います。Rust Foundationが設立された当初、MozillaはRust商標の所有権をこの新しく設立された財団に移管しました。2022年8月以降、この組織はRust商標に関する新たなポリシーの策定に取り組んでいます。 Rust Foundationは今年4月7日、新しいポリシーの草案を公開し、Googleドキュメントを通じて4月16日を締め切りとしてフィードバックを募集しました。フォームの締め切り後、Rust Foundationのスタッフがすべてのフィードバックを確認し、今後の更新作業を進めます。 草案では、Rust Foundationの商標ポリシーは、RustプロジェクトとRustコミュニティの成果を保護し、虚偽の表示やポリシー違反によってRust言語の価値が下がったり、価値が薄められたり、誤用されたりしないようにすることを目的としていると述べられています。しかし、コミュニティの大多数はこれを受け入れていません。 新しいポリシー案によると、商標は「Rust」、「Cargo」、「Clippy」のワードマーク、Rustのロゴ、そして「当社のウェブサイトとパッケージの独自のスタイル」を対象としています。ここで「Clippy」はRustのリンティングツールを指します。 既存の商標ポリシーと比較して、新しい草案はRustの商標に対してはるかに厳しい制限を課しています。例えば、物議を醸している第4.3.1条では、Rustツールチェーンで使用されるツール名、Rust言語で記述されたソフトウェアプログラム、またはRustソフトウェアと互換性のあるソフトウェアプログラムにはライセンスが必要となる場合があると規定されていますが、代わりに略称「RS」を使用できるとされています。 さらに、特別な許可なしに商標権の侵害とみなされるその他の商標の使用には、イベントや会議、ドメイン名、サブドメインが含まれます。 Reddit フォーラムでは、一部の開発者が関連トピックで、特定のルールが完全に「現実離れしている」とコメントしました。 セクション4.3.1では、「<フォーマット>-rust」、「rust-<既存のライブラリ>」、「<操作>-rust」といったライブラリ名の使用が禁止されているようです。私の意見では、これはintellij-rust、rust-rocksdb、Steven Fackler氏のopenssl-rustとrust-postgres、rust-libp2p、Stepan Koltsov氏のrust-protobuf、その他数十の真剣で尊敬されるプロジェクト、そして数百もの小規模プロジェクトに大きな負担をかけることになるでしょう。 さらに、開発者は、「cargo」サブコマンドの通常の命名スキームを禁止し、ドメイン名の一部として「rust」または「cargo」を使用することを禁止する規則についても不合理性を表明しました。 画像ソース: Rust 商標ポリシー フィードバックフォーム: r/rust (reddit.com) このコメントは広く支持を集めました。多くのネットユーザーが、これらの物議を醸す条項について困惑を表明しました。あるユーザーは、「Rust Foundationは何よりもまずコミュニティ志向でなければなりません。これらの規則は、通常のコミュニティ活動を制限する以外に何の目的があるのかわかりません」と述べています。 2. 財団の回答: Rust が商標であるべきかどうかについては、私たちの答えは「はい」です。Rust Foundationは、その権限を制限し、商標ポリシーの濫用を防ぐよう求める多くの開発者の声に応え、4月12日に公式ブログで「商標ポリシー草案に関する声明」を発表しました。 画像出典: 商標ポリシー草案に関するメモ | Inside Rust Blog (rust-lang.org) Rust Foundation は、新しい商標ポリシーを策定する目的とアプローチを明確にしました。 草案が発表されて以来、このポリシーは完全に財団によって策定され、Rustプロジェクトとコミュニティに押し付けられているという一般的な印象を受けています。しかし、これは事実ではありません。 このポリシー草案の目的は、不適切な場面で脅迫したり過度な制限を課したりすることではなく、既存のポリシーを明確にし、コミュニティからのフィードバックを取り入れ、Rustブランドの将来的な発展を守ることです。「財団は、プロジェクトリーダーの同意と関与なしに、このようなポリシーを一方的に採用することはできず、またそのような意図もありません。」 しかし、Rust Foundationは妥協のない姿勢も表明しました。「Rustを商標にすべきかどうかという問いについては、Rust 1.0以前と同様に、私たちの答えは『イエス』です。さらに、Rustとは何か、そして何ではないのかを定義する権利を大幅に放棄することなく、可能な限り寛容なポリシーを策定することを目指しています。」 商標問題がオープンソースコミュニティ内でガバナンス紛争や訴訟に発展する可能性があることは否定できません。そのため、一部のオープンソースライセンスでは、この問題に関して比較的シンプルな規定を設けています。 例えば、BSD-3条項ライセンスでは、著作権者や貢献者の氏名を、事前の書面による同意なしに派生ソフトウェア製品の宣伝や推奨に使用してはならないと規定されています。つまり、受領者がソフトウェア商標（氏名）を自己宣伝のために使用する権利を明示的に制限することで、貢献者の関連商標を使用する「フリーライド」行為を防止しているのです。 Rust Foundationのアドバイザーであるアマンダ・ブロック氏は、海外メディアの質問に答えて次のように述べています。「この強化されたポリシーの必要性は、オープンソースコミュニティの私たち全員、つまりオープンソースプロジェクトやビジネスの構築を目指すすべての人にとっての教訓です。商標はオープンソースライセンスから意図的に除外されており、場合によってはライセンスから剥奪されることもあります。商標の目的は、元のブランドを保護し、使用を通じて事実上の『認証』を作成することです。」 3. 過去の商標紛争：DebianによるRustの商標権侵害の背景Rust Foundationの声明は根拠のないものではありません。昨年7月、DebianはRustの商標権を侵害し、大きな騒動を引き起こしました。 この事件は、「Debianバグ報告ログ」という件名のメールから始まりました。Debian Rustのメンテナーによって投稿されたこのメールには、DebianがRustの商標ポリシーに違反しており、重大な結果を招く可能性があると記載されていました。 当時、Mozilla は商標を品質と安全性の保証とするために、Rust の商標ポリシーに関して次のように規定しました。「パッチを配布する前に、当社からの明示的な許可を得る必要があります。」 言い換えれば、RustまたはCargoのパッチを配布し、それらをRustまたはCargoと呼ぶ前に、Rustコアチームから明確な書面による許可を得ることが必須条件です。Debianにはそのようなパッチが数十個ありますが、Rustから許可を得たものはありません。 この事件に関して、議論の中で二つの大きな陣営が浮上した。 一部の開発者は、これはセキュリティ上の問題であるため、コンパイラとしては妥当なポリシーだと考えています。「アップストリームから提供されていないコンパイラのパッチバージョンをリリースする場合は、ユーザーにその旨を必ず伝え、信頼するかどうかを判断できるようにする必要があります。」 別の開発者グループは、オープンソースプロジェクトで商標ポリシーを強制することはオープンソースの精神に反すると考えています。「もしこの商標ポリシーが商用Rustディストリビューションに適用されるなら、著作権制限は理にかなっているでしょう。商標の誤用は、消費者にRustプロジェクトが推奨しているという誤解を招きかねないからです。しかし、Debianはオープンソースであり、使用するパッチは公開されています。Debianはこれらのパッチが公式のアップストリームパッチであると主張していません。」したがって、DebianプロジェクトがRustの評判を傷つけたり、法的に認められる悪意を持っていると結論付けるのは妥当ではありません。 もちろん、双方にはそれぞれ独自の立場があり、その立場を主張する理由があります。しかし、今回の事件は、商標がオープンソースライセンスとは独立して存在することをも示しています。オープンソースライセンスでは、受領者がコードを自由に使用、改変、複製、再配布することが認められますが、商標の場合は全く異なります。 これまで目にしたオープンソースライセンスをざっと思い出してみると、具体的なライセンスの種類に関わらず、ソフトウェアを商標として使用する権利を付与しているライセンスはほぼ存在しないことに気づくでしょう。もっと率直に言えば、商標はソフトウェアの配布と上流の作者に結びついており、誰でも自由に使用できるパブリックドメインとは異なり、商標の使用にはより慎重な配慮が求められ、参入障壁も高くなります。では、なぜでしょうか？ 4. コインの表裏：オープンソースの世界における「商標」の是非。結局のところ、商標に対する制限には 2 つの目的があります。1 つ目は、社会資本が上流コミュニティに確実に還流されるようにすること、2 つ目は、サプライヤーによる悪意のある混乱に対抗することです。 1) オープンソースソフトウェアのメンテナーや財団の観点から見ると、商標権を保持することで、オープンソースの価値によって生み出される社会資本が、オープンソースの作者や上流コミュニティに確実に還元されます。例えば、ソーシャルメディアを通じて共有されるソフトウェアに関するユーザー体験や評価は、莫大な社会資本を生み出し、最終的にはリーナス・トーバルズ氏とLinuxコミュニティに還元されます。これは、ある程度、フィードバックループ型のエコシステムを形成しています。 2) 前述の通り、商標の濫用は消費者に誤解を与える可能性があります。商標ポリシーを通じてこのような悪質な行為を防止することは、ソフトウェアの品質とセキュリティを確保するために不可欠です。これは、悪意のある行為者が商標に関連する内容ではなく、商標の所有権を混同している場合があるためです。そのため、一部のオープンソースライセンスでは、オープンソースソフトウェア自体が使用されている場合でも、ソフトウェア商標（名称）を派生ソフトウェア製品の推奨に使用できないことを明示的に規定しています。 しかし、オープンソースソフトウェアにおける商標問題に関しては、オープンソース開発者や財団が権利を保有し、契約に基づいて保護している場合に加え、企業向けソフトウェアのオープンソース化という重要なシナリオがあることに留意することが重要です。この場合、企業がソフトウェアの著作権と商標権を所有します。これは「疑似オープンソース」の出現につながる可能性があります。 通常、ソフトウェアが正当なオープンソースとみなされるためには、そのライセンスがオープンソース・イニシアティブ（OSI）によって承認されている必要があります。OSIは、ソフトウェアが自由に使用、変更、共有できることを保証します。いわゆる「疑似オープンソース」とは、真にオープンではないライセンスの下でリリースされたソフトウェアを指します。 典型的な例としては、企業がオープンソースソフトウェアのライセンス契約を変更し、オープンソースライセンスからプロプライエタリライセンスに切り替えるケースが挙げられます。例えば、MongoDBはGNU Affero General Public License（AGPL）からServer-Side Public License（SSPL）に切り替えましたが、これはOSIの承認を受けておらず、ユーザーに大きな不利益をもたらしました。 このアプローチの問題は、企業が以前のオープンソース コミュニティの共同作業を活用し、現在は同じ商標公開ソフトウェアの後継バージョンを使用していることです。 この種のソフトウェアは、コードの確認や貢献が可能であることからオープンソースとして販売されていますが、ライセンスは単一の企業によって厳格に管理されています。真のオープンソースプロジェクトと比較すると、コードで実現可能な範囲での自由度は明らかに低く、コミュニティからのサポートもほとんど受けていません。 このような状況では、ユーザーは単一のベンダーに縛られ、リスクが増大します。ベンダーはライセンス価格をいつでも変更でき、ユーザーがアクセスできる機能を選択でき、さらには倒産すれば跡形もなく姿を消すことさえあります。もちろん、「企業は自社開発ソフトウェアの著作権と商標を本質的に所有している」と主張する人もいるかもしれませんが、真実は誰の目にも明らかです。 まとめると、オープンソース財団のような組織が商標を保有し、契約に基づいて権利を守ることは理解できますが、商標ポリシーの濫用による不都合を回避するために、コミュニティ開発者の意向を尊重する必要があります。企業がオープンソースであり、商標の使用権を保有している場合は、「疑似オープンソース」の罠に陥らないよう注意し、ソフトウェアライセンスがOSI認証を受けているか、また、単一企業主導ではなく強力なコミュニティによってサポートされているかを検討し、ジレンマを回避する必要があります。 参考リンク:https://www.tisonkun.org/2022/12/03/why-branding-is-important/ https://devclass.com/2023/04/11/dont-call-it-rust-community-complains-about-draft-trademark-policy-restricting-use-of-word-marks/?td=rt-3a https://www.twelvet.cn/news/2183.html https://sdtimes.com/open-source/beware-of-fake-open-source/ https://www.sohu.com/a/568928742_115128 https://blog.rust-lang.org/inside-rust/2023/04/12/trademark-policy-draft-feedback.html https://www.reddit.com/r/rust/comments/12e7tdb/rust_trademark_policy_feedback_form/ |
