(The English version follows the Japanese text.)
こんにちは！
再び登場の遠藤です。
最近お気に入りの駅弁は「～わさびとだしで味わう～炙りノルウェー産サーモンハラスの親子重」です！
本日はLF Community DayでOpenChain Specを紹介しましたので、そのエッセンスを共有します。
OpenChain Specの逐条解説的なことは過去のアドベントカレンダーでしっかりと解説されているので（下の方にリンク貼っておきます）、
今回は「そもそもなぜこの標準ができたのか？」「どうしてこのようなこのような構造の標準になっているのか」
を解説したいと思います。
そもそもなぜこの標準ができたのか？
OpenChainの"Chain"はサプライチェーンから由来します。
現在のシステム・ソフトウエア開発においては一つの最終製品を作るために、
多くのサプライヤ・ベンダーによって供給されるソフトウエアを組み合わせるケースも多いです。
また、殆どの場合それらのソフトウエアにはオープンソースソフトウエア(OSS)が含まれています。
最終製品をお客様に提供する最終製品ベンダーはオープンソースライセンス条件を遵守するために、お客様に対して著作権表示やソースコード提供などの適切な情報開示を行う必要があります。
ここで、大きな課題になるのが、最終製品に含まれるOSSを特定すること、
すなわち、全てのサプライヤ・ベンダーから製品に利用しているOSSに関する情報を入手することです。
簡単に言えば、「伝言ゲーム」を完遂する必要があるのです。
この伝言ゲームを行うためには、このゲームの参加者が「自分の伝えるべきこと＝自分の使っているOSSを明確にできる能力があること」が大前提となります。
ただ、各社にとっては決して簡単なことではありません。
そこで、まずは各社がOSSを適切に取り扱うことができるようになることを支援するためOpenChain標準は用意されているのです。
サプライチェーンの標準であるのに、サプライチェーン単位で認証を取得するのではなく、個社が認証を取得するというのはこのような理由があるからです。
どうしてこのようなこのような構造の標準になっているのか？
まず、本題に入る前に、組織がOSSを利用するためのプロセスを簡単に説明します。
STEP1:対応要否の判断 今回のユースケースがライセンス条件に関わるものなのかを判断します。単なる試用で、組織外に頒布しない場合などは対応が必要がない場合もあります。
STEP2:SBOMの作成 対象となるソフトウエアが使っているOSSのリスト(SBOM)を作成して、どのようなライセンスが含まれるか確認します。
STEP3:利用可否判断 各OSSのライセンス条件が自分たちが遵守できるものかどうか判断します。難しいOSSについては、他のOSSや自主開発のコードへの置き換えなどを検討します。
STEP4:ライセンス条件履行 著作権表示やソースコードの提要などのライセンス条件の履行を行います。
これを前提にOpenChain Specを見ていきましょう！
この標準の中心部分は赤枠で囲った3.2 Management Programです。
この中の3.1はSTEP2 SBOMの作成、1.3はSTEP3 利用可否判断、4.1 ライセンス条件履行にそれぞれ対応します。
つまり、上記のような基本的なOSS利用プロセスが標準の根幹となっているのです。
他の項では、上記のプロセスを実施するためのポリシーや教育の整備、責任者や外部窓口を決めておいて下さいねということです。また、コントリビューションについても、会社としてのポリシーやプロセスを持っておいてねと書いてあります。
その他、認証に関わる細かい点などもありますが、意外と非常なシンプルな構造であることがご理解いただけたのではないでしょうか？
OpenChainの標準は1人のスタートアップから大企業まで対応できるようになっています。
ですので、シンプルで必要十分な標準となっているのです。
各業界で導入が進むOpenChanin
下の図で示しますように業界を問わず、OpenChainの適合を宣言する会社は増えています。
もちろん、認証の取得や宣言は任意ではありますが、OSSを適切に使うことは全ての組織に必要なことだと思いますので、是非ご参考にして頂けると幸いです。
OpenChain Japan WGでは認証取得についての悩み事の解決もお手伝いできると思いますので、関心ある方はお気軽にコミュニティに参加ください。
ご参考：過去のOpenChain Spec解説記事
OpenChain: spec v2.1 の紹介 第1回 / Commentary of spec v2.1 vol.1, §3.1.1-3.1.3
https://qiita.com/tech_nomad_/items/3abd930ebd07c121a003
OpenChain: spec v2.1 の紹介 第2回 / Commentary of spec v2.1 vol.2, §3.1.4-3.1.5
https://qiita.com/n-shima/items/2633debf188bbc447b42
OpenChain: spec v2.1 の紹介 第3回 / Commentary of spec v2.1 vol.3, §3.2
https://qiita.com/hiromotai7/items/c2948a72109db38de617
OpenChain: Spec v2.1 の紹介 第4回 / Commentary of Spec v2.1 vol.4, §3.3 “Open source content review and approval”
https://qiita.com/TakashiNinjouji/items/4b8329972e0a642d3e1b
OpenChain: spec v2.1 の紹介 第5回 / Commentary of spec v2.1 vol.5, §3.4
https://qiita.com/nori0428/items/c8d3db517d73b140e705
OpenChain: spec v2.1 の紹介 第6回 / Commentary of spec v2.1 vol.6, §3.5
https://qiita.com/ogojo/items/849336fdefec80d9c590
OpenChain Spec v2.1の紹介 第7回 / Introduction to OpenChain Specification v2.1 Section 3.6
https://qiita.com/nobuoimada/items/2f5d8b3bc5c78f258851
English Version (Machine Translation)
Hello!
It's Endo again.
My recent favorite ekiben is the “Grilled Norwegian Salmon Belly Oyako-don with Wasabi and Broth”!
Since I introduced the OpenChain Spec at LF Community Day, I'll share its essence here.
Detailed explanations of each clause of the OpenChain Spec have already been thoroughly covered in past Advent calendars (links below),
so this time I'd like to explain “Why was this standard created in the first place?” and “Why does it have this particular structure?”
Why was this standard created in the first place?
The “Chain” in OpenChain originates from the supply chain.
In modern system and software development, it is common to combine software supplied by numerous vendors and suppliers to create a single final product.
Furthermore, in most cases, this software includes open source software (OSS).
The final product vendor providing the end product to customers must ensure compliance with open source license terms by disclosing appropriate information to customers, such as copyright notices and source code provision.
Here, the major challenge lies in identifying the OSS contained within the final product—
that is, obtaining information about the OSS used in the product from all suppliers and vendors.
Simply put, it requires completing a “game of telephone.”
For this game to work, it is essential that each participant has the capability to clearly identify what they need to communicate—namely, the OSS they are using.
However, this is by no means an easy task for each company.
This is why the OpenChain standard exists: to support companies in becoming capable of handling OSS appropriately.
This is also why, despite being a supply chain standard, certification is obtained by individual companies rather than the supply chain as a whole.
Why has this particular structure become the standard?
Before diving into the main topic, let's briefly outline the process organizations follow when utilizing OSS.
STEP1: Determine Need for Action Determine whether the current use case involves license conditions. If it's merely a trial and not distributed outside the organization, action may not be required.
STEP2: Create an SBOM. Generate a list (SBOM) of the OSS used by the target software to identify which licenses are included.
STEP3: Determine Usability. Assess whether the license terms of each OSS can be complied with. For problematic OSS, consider alternatives like other OSS or in-house developed code.
STEP4: License Condition Compliance Fulfill license conditions such as copyright notices and source code disclosure.
With this in mind, let's take a look at the OpenChain Spec!
The core part of this standard is section 3.2 Management Program, highlighted in red.
Within this, section 3.1 corresponds to STEP 2 SBOM creation, section 1.3 to STEP 3 Usage Feasibility Assessment, and section 4.1 to License Condition Compliance.
In other words, the fundamental OSS usage process outlined above forms the backbone of the standard.
Other sections cover establishing policies and training to implement these processes, designating responsible parties and external points of contact. It also states that companies should have policies and processes for contributions.
While there are other details related to certification, you can see that the structure is fundamentally very simple, right?
The OpenChain standard is designed to accommodate everyone from startups to large enterprises.
Therefore, it is simple and provides a necessary and sufficient standard.
OpenChain Adoption Across Industries
As shown in the figure below, companies declaring OpenChain compliance are increasing across all industries.
While certification and declaration are voluntary, we believe proper use of OSS is essential for all organizations. We hope you find this information useful.
The OpenChain Japan Working Group can assist with any concerns regarding certification acquisition. Interested parties are welcome to join our community.
For Reference: Past OpenChain Spec Commentary Articles
OpenChain: Introduction to spec v2.1 Part 1 / Commentary of spec v2.1 vol.1, §3.1.1-3.1.3
https://qiita.com/tech_nomad_/items/3abd930ebd07c121a003
OpenChain: Introduction to spec v2.1 Part 2 / Commentary of spec v2.1 vol.2, §3.1.4-3.1.5
https://qiita.com/n-shima/items/2633debf188bbc447b42
OpenChain: Introduction to Spec v2.1 Part 3 / Commentary of Spec v2.1 vol.3, §3.2
https://qiita.com/hiromotai7/items/c2948a72109db38de617
OpenChain: Introduction to Spec v2.1 Part 4 / Commentary of Spec v2.1 vol.4, §3.3 “Open source content review and approval”
https://qiita.com/TakashiNinjouji/items/4b8329972e0a642d3e1b
OpenChain: Introduction to Spec v2.1 Part 5 / Commentary of Spec v2.1 vol.5, §3.4
https://qiita.com/nori0428/items/c8d3db517d73b140e705
OpenChain: Introduction to Spec v2.1 Part 6 / Commentary on Spec v2.1 vol.6, §3.5
https://qiita.com/ogojo/items/849336fdefec80d9c590
Introduction to OpenChain Specification v2.1 Section 3.6
https://qiita.com/nobuoimada/items/2f5d8b3bc5c78f258851