This article in English can be found here.
はじめに
こんにちは、忍頂寺と申します。
OpenChan Japan-WGでは、主にTooling-SGなどに参加しています。
本稿は国際規格 ISO/IEC 5230:2020 に相当する OpenChain Spec v2.1 を紹介するシリーズの第4回となります。
(2020.12.14: ISO/IEC にて、進捗(Status)は "Under development", "Life cycle" は "60.00 International Standard under publication" です。)
(2020.12.15: ISO/IEC にて、進捗(Status)は "Published", "Life cycle" は "60.60 International Standard published" です! )
なお、自己認証の手続は"OpenChain Self Certification" でできます。 また、確認項目はGitHubの "OpenChain-Project/conformance-questionnaire"で確認できます。英文や和文などで用意されています。
OpenChain Spec v2.1 §3.3 “Open source content review and approval”
§3.3.1 Bill of Materials
§3.3.1 は、BOM (Bill of Materials) に関する章です。BOMは各ソフトウエアを構成するOSSのリストを指します。OpenChain適合を果たす組織は、このBOMの作成および管理するためのプロセスを整備する必要があります。
ここでの自己認証のための確認項目は次になります：
| Number | Spec Ref | Question Text |
|---|---|---|
| 3.a | 3.1, 3.1.1 | Do you have a documented procedure for identifying, tracking and archiving information about the open source components in a Supplied Software release? (供給ソフトウェアのリリースに含まれるすべてのオープンソースコンポーネントに関する情報を特定し、追跡し、リストとして保管するための手順書がありますか？) |
| 3.b | 3.1, 3.1.2 | Do you have open source component records for the Supplied Software which demonstrate the documented procedure was properly followed? (手順書に適切に従っていることを証明する、各供給ソフトウェアのリリースに関するオープンソースコンポーネントの記録がありますか？) |
§3.3.2 License compliance
§3.3.2は、ライセンスコンプライアンスの実務におけるユースケースに関する章です。バイナリ形式での頒布、ソースコード形式での頒布等の各ユースケースに対応できるよう社内プロセスを整備する必要があります。ユースケースの定義については各組織が自由に設定することができます。BOMの作成やBOMを利用してのオープンソース ライセンス コンプライアンス業務については、ツールによる効率化が検討されています。
ここでの自己認証のための確認項目は次になります：
| Number | Spec Ref | Question Text |
|---|---|---|
| 3.c | 3.2, 3.2.1 | Do you have a documented procedure that covers these common open source license use cases for open source components in the Supplied Software? (各供給ソフトウェアのリリースに関するオープンソースコンポーネントについて、少なくとも次の共通オープンソースライセンスのユースケースを扱った手順を実施していますか？) |
| 3.c.i | 3.2, 3.2.1 | - Distribution in binary form; (バイナリ形態で頒布されている) |
| 3.c.ii | 3.2, 3.2.1 | - Distribution in source form; (ソースコード形態で頒布されている) |
| 3.c.iii | 3.2, 3.2.1 | - Integration with other open source that may trigger additional obligations; (コピーレフトの義務を生じうる他のオープンソースと統合されている) |
| 3.c.iv | 3.2, 3.2.1 | - Containing modified open source; (改変されたオープンソースを含んでいる) |
| 3.c.v | 3.2, 3.2.1 | - Containing open source or other software under incompatible licenses for interaction with other components in the Supplied Software; (供給ソフトウェア内の他のコンポーネントとやりとりする、両立性のないライセンス下のオープンソースやその他のソフトウェアを含んでいる) |
| 3.c.vi | 3.2, 3.2.1 | - Containing open source with attribution requirements. (帰属要求のあるオープンソースを含んでいる) |
次回
次回仕様紹介となる第5回の記事は、小保田さんから 12/18 に公開予定です。お楽しみに！
明日(12/16)は、再び僕の投稿になりますが、ツールに関する情報共有を行っているTooling SGの活動を紹介します。
About me
Hello. I am Takashi Ninjouji.
I mainly participate Tooling-SG of OpenChain Japan-WG.
This article is part 4 of introducing OpenChain Spec v2.1 (functionally identical to ISO/IEC 5280:2020).
(2020.12.14: "Status"is "Under development", "Life cycle" is "60.00 International Standard under publication" at ISO/IEC)
(2020.12.15: "Status"is "Published", "Life cycle" is "60.60 International Standard under published" at ISO/IEC!)
"OpenChain Self Certification" provides the Online Self-Certification. You can see the questionnaire in several languages in this repository: "OpenChain-Project/conformance-questionnaire"
OpenChain Spec v2.1 §3.3 “Open source content review and approval”
§3.3.1 Bill of Materials
§3.3.1 is about the Bill of Materials (BOM), which is a list of OSS that compose a software package, and an organization needs to have a process in place to create and manage that BOM.
Here is the questionnaire for Self-Certification:
| Number | Spec Ref | Question Text |
|---|---|---|
| 3.a | 3.1, 3.1.1 | Do you have a documented procedure for identifying, tracking and archiving information about the open source components in a Supplied Software release? |
| 3.b | 3.1, 3.1.2 | Do you have open source component records for the Supplied Software which demonstrate the documented procedure was properly followed? |
§3.3.2 License compliance
§3.3.2 is about use cases. Internal processes need to be in place for each use case, such as distribution in binary form and distribution in source code form. Each organization can define use cases freely. In order to the efficiency of creation of BOMs and of open source license compliance using BOM, compliance tooling are needed and are discussed along with its development and its workflows as well.
Here is the questionnaire for Self-Certification:
| Number | Spec Ref | Question Text |
|---|---|---|
| 3.c | 3.2, 3.2.1 | Do you have a documented procedure that covers these common open source license use cases for open source components in the Supplied Software? |
| 3.c.i | 3.2, 3.2.1 | - Distribution in binary form; |
| 3.c.ii | 3.2, 3.2.1 | - Distribution in source form; |
| 3.c.iii | 3.2, 3.2.1 | - Integration with other open source that may trigger additional obligations; |
| 3.c.iv | 3.2, 3.2.1 | - Containing modified open source; |
| 3.c.v | 3.2, 3.2.1 | - Containing open source or other software under incompatible licenses for interaction with other components in the Supplied Software; |
| 3.c.vi | 3.2, 3.2.1 | - Containing open source with attribution requirements. |
What is the next?
Kobota-san will introduce part 5 on 12/18. Don't miss it!
In tomorrow's article (12/16), I will introduce the Tooling SG of Japan-WG. This subgroup aims to share information about the compliance tooling and the know-how to use them.