オープンソース協会開源社

以下の記事は、tisonkun が執筆した Book of Night からの抜粋です。

最近、米国の輸出管理規制の影響により、Linux アップストリームは一部の開発者から MAINTAINER 権限を削除し、オープンソース依存関係の新たな再評価が開始されました。

オープンソース精神とコミュニティガバナンスに関する議論は、Wei Sir氏の2つの論文（脚注参照）で明確に述べられています。本稿では主に、ソフトウェアサプライチェーンの観点から「オープンソースソフトウェアへの供給途絶のリスク」に関する懸念について論じています。

簡単に言えば、オープンソースライセンスは、ユーザーに特定のバージョンのソースコードを使用する自由を与えるだけです。さらに、ほとんどのオープンソースライセンスは、メンテナンスやサポートを提供しないこと、また長期にわたる反復的なアップストリームブランチを約束しないことを明示的に規定しています。

多くの人はオープンソースライセンスについて誤った理解を持っています。オープンソースソフトウェアとは、単にソースコードが公開されていること、そしてソフトウェアの目的や使用制限が議論の余地なく利用可能であることを意味すると誤解していることが多いのです。

オープンソース[1]の厳密な定義は、オープンソース・イニシアティブ（OSI）によって提供されています。OSIは、オープンソース・ソフトウェアの配布条件が満たすべきいくつかの標準を定義しており、残りの条件は交渉可能です。MITライセンスを例に挙げ、まずは契約書の原文を読んで、MITライセンスがどのような形でソフトウェアを配布しているかを確認しましょう。

私たちは、Open Atom Foundationの「Source Translation Knowledge」[2]プロジェクトの英語-中国語翻訳結果を採用しました。

著作権 [年] [著作権者]

著作権 [年] [著作権者]

本ソフトウェアおよび関連ドキュメント ファイル (以下「本ソフトウェア」) のコピーを入手したすべての人物は、以下の条件に従い、本ソフトウェアを無制限に使用、コピー、変更、統合、公開、配布、サブライセンス、および/または販売する権利を含むがこれらに限定されない、本ソフトウェアを取り扱う権利を無償で付与されます。また、本ソフトウェアの提供を受けた人物が同様の権利を有することを許可する権利も付与されます。

本ライセンスは、ソフトウェアおよび関連ドキュメント（以下、総称して「ソフトウェア」といいます）のコピーを入手したすべての人物、およびソフトウェアの受領者に対し、以下の条件に従い、ソフトウェアのコピーの使用、コピー、変更、結合、公開、配布、サブライセンス、および/または販売を含むがこれらに限定されない権利を無償かつ無制限に付与します。

上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは大部分に含めるものとします。

上記の著作権表示およびこのライセンス通知は、このソフトウェアのすべてのコピーまたは主要部分に含める必要があります。

本ソフトウェアは「現状有姿」で提供され、明示または黙示を問わず、商品性、特定目的への適合性、および非侵害に対する保証（ただしこれらに限定されない）を含め、いかなる種類の保証もいたしません。いかなる場合においても、著作者または著作権保有者は、契約違反、不法行為、またはその他の行為にかかわらず、本ソフトウェア、本ソフトウェアの使用、またはその他の取り扱いに起因または関連して発生するいかなる請求、損害、またはその他の責任についても責任を負わないものとします。

本ソフトウェアは「現状有姿」で提供され、明示的または黙示的な保証（商品性、特定目的への適合性、非侵害性を含むがこれらに限定されない）は一切ありません。いかなる場合においても、著者または著作権者は、本ソフトウェアまたはその使用もしくはその他の利用に起因または関連して生じる、またはそれらに関して生じるいかなる請求、損害、その他の責任についても責任を負いません。

上記はMITライセンスの原文と翻訳です。

MITライセンスには、すべてのオープンソースライセンスに共通する2つの重要な特徴があります。1つ目は、ライセンスを受けたソフトウェアに、主にソフトウェアの使用、改変、配布の自由など、いくつかの基本的な権利を付与することです。2つ目は、ソフトウェアが「現状有姿」で提供され、メンテナンスや保証サービスは一切提供されないことを強調していることです。MITライセンスは、ユーザーによるソフトウェアの使用から生じるいかなる問題についても責任を負いません。

これら2つの条項はオープンソース精神に基づいており、ソフトウェアの作者は既にコードを無償で公開し、ユーザーが自由に使用、改変、再配布することを許可しているというものです。したがって、ユーザーはソフトウェアの作者に対し、ソフトウェアの継続的なメンテナンスや、ユーザーがソフトウェアを使用することで発生した問題への対応など、追加の責任を負わせるべきではありません。

さらに、 「ソフトウェアは MIT ライセンスの下でライセンスされたオープンソース ソフトウェアである」という単純な理解は、 MIT ライセンスの下で新しいバージョンが継続的にリリースされることを意味しますが、実際には、ソフトウェアの作成者は任意のライセンスの下でコードをリリースする権利を持ち、オープンソース ソフトウェア ライセンスはソフトウェアの特定のリリース バージョンにのみ結び付けられます。

したがって、オープンソースライセンスは本質的に、特定のバージョンのソフトウェアに結び付けられた一連の配布条件に過ぎないことがわかります。言い換えれば、オープンソースライセンス自体はコードのスナップショットに対するライセンスです。この場合、「提供」されるソフトウェアはスナップショットそのものであり、オープンソースライセンスによって付与される一連の基本的権利は取り消し不能です。この観点から見ると、 「オープンソース供給の中断」はこれまで一度も発生していません。複数回のライセンス変更を経てきたRedisを例に挙げると、現在でも世界中のユーザーが3条項BSDライセンスの下でライセンスされた最新バージョン（7.2.5）を自由に使用できます。

オープンソースライセンスによってユーザーに付与される権利や、そのほとんどに含まれる免責事項が実際に発生したことがないにもかかわらず、「オープンソースソフトウェアが遮断されるリスク」について広く懸念されているのは、一体何なのでしょうか。こうした懸念は、オープンソースソフトウェアへの過度な期待から生じる誤解が主な原因であると言えるでしょう。

今日では、オープンソースソフトウェアなしでは現実世界のアプリケーションソフトウェアを実装することはできません。つまり、実際に使用するソフトウェアは、ある程度オープンソースソフトウェアに依存しているということです。例えば、TLSネットワーク通信を伴うアプリケーションの場合、最も一般的に使用されるOpenSSLライブラリはオープンソースソフトウェアです。また、ログを出力する必要があるJavaアプリケーションは、Apache Software FoundationのLog4jなどのオープンソースソフトウェアに依存する可能性が非常に高いでしょう。

ソフトウェアサプライチェーンの観点から見ると、オープンソースソフトウェアはエンドアプリケーションのサプライネットワーク全体に浸透しています。前述の2つのオープンソースソフトウェアは、Heartbleedセキュリティ脆弱性[3]とLog4Shellセキュリティ脆弱性[4]の影響を受けており、数千万ものオンラインアプリケーションに影響を与えています。

幸いなことに、これら2つのソフトウェアプログラムを開発したオープンソースコミュニティは、セキュリティ上の脆弱性に迅速に対応し、即座にパッチを提供しました。これにより、すべてのユーザー企業は、脆弱性の影響を受けているかどうかを自己チェックし、できるだけ早くパッチを適用することができました。

さて、これらのパッチは新しいリリースに同梱されていること、そして上記の議論を踏まえると、この新しいリリースは実際にはオープンソースライセンスの下で提供されていない可能性があります。具体的な例として、ある企業がAkkaを使用して基幹業務システムを開発しており、Akkaを所有する商用企業であるLightbendが今年Akkaのライセンスを変更した場合、その後の多くのAkkaのセキュリティパッチは新しいプロプライエタリライセンスの下でのみリリースされることになります。

これにより、「オープンソースソフトウェアの遮断」のリスクが生じます。つまり、ユーザーがオープンソースソフトウェアを使用していて問題が発生した場合、上流プロバイダーがそれを修正する能力を持っていたとしても、商業上の考慮や法的制約により、ユーザーに修正版を提供しない可能性があります。つまり、オープンソースソフトウェアのユーザーは、オープンソースソフトウェアが常にメンテナンスされ、後続のバージョンが常にオープンソースライセンスの下で提供されるとは想定できないのです。

したがって、企業はソフトウェアを開発および使用する際に、ソフトウェアのオープンソース依存関係を明確にし、どのコア依存関係を維持および保護する必要があるかを判断し、対応する対策を講じる必要があります。

オープンソース ソフトウェア サプライ チェーンの広範な影響を考慮して、ソフトウェアの依存関係を分析するためのさまざまなツールと標準が市場に登場しています。

• サイクロンDX[5]
• フォッサ[6]
• スカノス[7]
• SPDX®[8]
• 清遠SCA[9]

これらのツールのほとんどは、アプリケーションソフトウェアのソフトウェア部品表（SBOM）を生成する機能を備えています。SBOMには、すべてのソフトウェア依存関係の名前、プロトコル属性、コードデジタル署名がリストされます。これは、将来のソフトウェアサプライチェーンにおいて避けられないトレンドとなるはずです。今年のEUサイバーレジリエンス法ではこれが義務付けられており、製造業開発の観点からも、部品表は成熟した産業開発におけるベストプラクティスです。

▲ SBOMの例のフラグメント

アプリケーション ソフトウェアが依存するオープン ソース ソフトウェアを明確に理解したら、次のステップは、重要な依存関係のメンテナンスと保護を取得することです。

前述の通り、ほとんどのオープンソースライセンスはメンテナンスの保証を提供しておらず、中には特定の免責事項や責任制限を定めているものもあります。したがって、オープンソースソフトウェア開発者が熱意を維持し、問題に応じて新しいバージョンをリリースしてくれると単純に期待するだけでは、期待に応えられません。

一方で、オープンソースソフトウェアに完全に依存せずに新しいアプリケーションを開発することは不可能です。実際、新しいアプリケーションの依存関係の大部分はオープンソースです。したがって、いわゆる「オープンソース供給途絶」のリスクを回避するために、企業がすべての依存コードを自ら作成するという負担を負うことは、到底不可能です。そのような開発コストを負担できる企業はどこにもありません。

したがって、オープンソースソフトウェアを使用し、コアとなる依存関係が何らかの形で維持されていることを確認することは、企業ユーザーにとって非常に重要な考慮事項です。オープンソースの依存関係は、以下の4つのタイプに分類できます。

1. 安定した依存関係。これは複雑でも完成度も高くなく、近い将来にイテレーションの必要がない依存関係です。例としては、ハッシュアルゴリズムの実装や特定のデータ構造用のソフトウェアライブラリなどが挙げられます。このような依存関係の場合、下流のユーザーは1つのバージョンに固執するだけで安心できます。実際、最大の懸念は、上流の依存関係が無計画にイテレーションされ、不要な問題を引き起こし、下流のユーザーがそれに追随して障害に遭遇することです。例えば、npmエコシステムの様々なミニライブラリは、過去にインターネット上で大きな混乱を引き起こしました。
2. 信頼できる依存関係。例えば、前述のOpenSSLやLog4Shellは深刻なセキュリティ脆弱性を経験しましたが、ソフトウェア開発においては当然のことです。これらのコミュニティがオープンソースのパッチを迅速にリリースし、下流で利用できるようにしていることは、こうした依存関係の信頼性を証明しています。LinuxやKubernetesのように、基盤となるオープンソースソフトウェアは、広く普及するために高い信頼性が求められる場合が多いです。もちろん、依存関係の信頼性は動的であり、メンテナーの変更（人事異動、死亡）、メンテナンス組織の運用状況、環境の変化などの要因の影響を受けます。
3. 置き換え可能な依存関係。オープンソースの依存関係が不安定（ニーズへの適応や脆弱性の最小化のために継続的な反復作業が必要）かつ信頼性が低い（メンテナンスのための持続可能な上流コミュニティが不足している）場合、企業がこの依存関係を安心して使用する唯一の方法は、置き換え可能であることです。つまり、このオープンソースの依存関係に問題が発生した場合、信頼できる別のオープンソースソフトウェアに置き換えるか、企業の従業員が代替ソフトウェアを作成するか、ベンダーから購入することができます。
4. リスク。上記の3種類の依存関係に加えて、他のすべてのソフトウェアにもリスクが伴います。安定性も信頼性も低く、問題が発生した場合の代替プランも用意されていません。

この分類から、企業がメンテナンスサポート付きのオープンソースソフトウェアを入手するには、従業員がコアとなる依存関係をカバーできるようにするか、ベンダーからメンテナンスサービスや代替ソフトウェアを購入することが積極的な解決策であることが明確に分かります。いずれの場合も、企業はそれに応じた費用を支払う必要があります。

したがって、企業がオープンソース ソフトウェアを安心して使用したい場合、まず理解する必要があるのは、ソフトウェア サプライ チェーンにはオープンソースの依存関係が常に存在し、オープンソースの依存関係サプライ チェーンのセキュリティを確保するにはコストがかかるということです。

これに基づいて、アプリケーションの実際の形式と複雑さに応じてコストが測定され、(1) 保守のためにソフトウェア エンジニアを雇う、(2) サプライヤーからサービスまたはソフトウェアを購入する、(3) オープンソース ソフトウェアの作成者と直接契約を結ぶか、スポンサーシップを提供して、アップストリームの信頼性と持続可能性を確保または促進する、という適切な選択が行われます。

実際、Linux Foundation が最近、Linux プロジェクトの特定の開発者から MAINTAINERS 権限を削除したことは、上で分析した「オープンソース供給の混乱」のリスクとは少し異なります。

まず、現時点での情報に基づくと、Linux Foundationの実際の運用は、米国政府の制裁対象リストを利用し、制裁対象者また​​は制裁対象企業にサービスを提供している者がMAINTAINERリストに掲載されないようにすることです。これは原則として、これらの個人から提出されたコードパッチをLinuxプロジェクトが受け取る能力に影響を与えるものではありません。さらに、制裁対象者および企業は引き続きLinuxソフトウェアを自由に使用できます。サプライチェーンの観点からは、供給途絶の直接的なリスクはありません。

しかし、こうした措置は、一部のダウンストリームユーザーの使用状況に依然として実質的な影響を与えます。例えば、特定のMAINTAINERSを削除すると、一部のLinuxモジュールが実質的にメンテナンスされなくなる可能性があります。そのため、これまでこれらのモジュールを信頼できる依存関係と見なしていたダウンストリームユーザーは、これらのモジュールへの依存関係の取り扱い方を再検討する必要に迫られるでしょう。さらに、制裁措置により企業が重要なオープンソースプロジェクトのメンテナンスを行う従業員を育成できない場合、こうしたプロジェクトの導入コスト評価に深刻な影響を与える可能性があります。これらは、ほとんどの企業が当面遭遇することのない、より複雑な状況であり、この記事ではこれ以上取り上げません。

以下は、Linux Foundation による MAINATINER の削除に関する Wei Sir 氏のコメントです。

• Linux がロシア人メンテナーの一部を排除したことは、オープンソースとフリーソフトウェアの精神に反するのでしょうか?
• Linus は具体的に何を違反したのでしょうか?

さらに、オープンソースに関する人々の誤解のほとんどは、オープンソースのライセンスと定義を読むことで解消できます。日々のやり取りの中で、開発者やソフトウェアユーザーの大多数は、オープンソースライセンスの原文すら読んでおらず、二次情報、インフォグラフィック、あるいは一文や一語の要約に頼って意味を理解していることに気づきました。これは「オープンソースの遮断」のような誤解を招くだけでなく、オープンソースと利益、そしてオープンソースの知的財産権の保護に関する一連の誤解を引き起こす可能性があり、これは最近の別のホットトピックにも見られます。

オープンソースの問題について議論する前に、すべての読者の皆様には、関連資料の原文を読んで理解することをお勧めします。Wei Sir氏によるオープンソースライセンスを分かりやすく解説した一連の記事は、素晴らしい出発点となるでしょう。

スワイプしてすべての参照を表示

[1] オープンソースの定義: https://opensource.org/osd

[2] 「ソース翻訳知識」：https://www.openatom.org/jour...

[3] Heartbleedセキュリティ脆弱性: https://heartbleed.com/

[4] Log4Shellのセキュリティ脆弱性: https://en.wikipedia.org/wiki...

[5] サイクロンDX: https://github.com/CycloneDX

[6] フォッサ：https://fossa.com/

[7] スキャノス：https://www.scanoss.com/

[8] SPDX®: https://spdx.dev/

[9] 清遠SCA: https://www.sectrend.com.cn/

著者 | tisonkun

編集者：李南

関連資料

第 9 回中国オープンソース年次会議とオープンソース協会 10 周年記念カーニバルが成功裏に終了しました。

コンテンツクリエイターの何同雪氏の問題をどう見るべきでしょうか？

オープンソース協会の紹介

2014年に設立されたオープンソース協会（KAIYUANSHE）は、オープンソースの理念に献身的に貢献する個々のボランティアで構成されるオープンソースコミュニティであり、「貢献、合意、そして共同統治」の原則に基づき活動しています。KAIYUANSHEは、「ベンダー中立性、公益性、非営利性」の原則を堅持し、「中国を拠点とし、世界に貢献し、新時代のライフスタイルとしてオープンソースを推進する」というビジョンを掲げています。その使命は「オープンソースのガバナンス、国際的な連携、コミュニティの発展、そしてプロジェクトのインキュベーション」であり、健全で持続可能なオープンソースエコシステムの共創を目指しています。

オープンソース協会は、オープンソースを支援するコミュニティ、大学、企業、政府機関と積極的に連携しています。また、世界的なオープンソースライセンス認証組織であるOSIの中国初の会員でもあります。

2016年以降、中国オープンソースカンファレンス（COSCon）が毎年開催され、「中国オープンソース年次報告書」が継続的に発表されています。また、「中国オープンソースパイオニアリスト」と「中国オープンソースコードパワーリスト」も共同で立ち上げ、国内外で幅広い影響力を発揮しています。