OpenChain 仕様書
第2.0版
ソフトウェアソリューションを構成する
オープンソースへの信頼を確立するために
**
**
目次
免責事項（Disclaimer） 3
本文書は、The Linux FoundationにおけるOpenChainプロジェクトの英文ドキュメントから翻訳された公式翻訳版です。ただし翻訳版と英語版との間で何らかの意味の違いがあった場合には、英語版が優先されます。
また、OpenChainは世界中のメンバー企業が参加するプロジェクトではありますが、資料の細部では必ずしも各国の法令を検討していない可能性もあります。本翻訳資料を日本で活用する際には、各企業の法務部門を加えた検討が不可欠です。
This is an official translation from the OpenChain Project. It has been translated from the original English text. In the event there is confusion between a translation and the English version, The English text shall take precedence.
Copyright © 2016-2019 Linux Foundation®.
本仕様書の利用は、Creative Commons Attribution 4.0 International (CC-BY 4.0) ライセンスの下で許諾されます。ライセンスの写しは https://creativecommons.org/licenses/by/4.0/ で確認できます。
この仕様書は、オープンソースライセンスに対する質の高いコンプライアンスプログラム（以下では、プログラムと略します）の基幹要件を定義しており、オープンソースソフトウェアで構成されたソフトウェアソリューションを相互に取り交わす組織（主として、企業として運営される組織を想定しています）の間に信頼構築の基礎を提供することを目的としています。組織のプログラムが本仕様に適合することにより、一つ一つのソフトウェアソリューションに必要とされるコンプライアンス関連資料（法的通知、ソースコードなど）を確実に生成するようにプログラムが設計されていることを保証します。OpenChain の仕様はプログラムの「どのように」や「どのような時に」ではなく、「何」と「なぜ」の側面に焦点を当てています。これは、さまざまな市場に存在するさまざまな規模の組織において、規模、目標、スコープに合ったポリシーとプロセスを具体化できるような柔軟性をもたらすためです。例えば、OpenChain 適合プログラムは、組織の単一の製品ラインに対して適用することも、あるいは、組織全体に対して適用することもできます。
このセクションはすべてのOpenChainユーザに向けて仕様の背景を提供しています。セクション2は、本仕様書全体で使用される主要な用語を定義しています。セクション3は、適合を達成するためにプログラムが満たすべき要件を定義しています。各要件はそれを満たすために生成されなければならない1つ以上の証跡となる資料（例えば、記録として残される書類）で構成されています。証跡となる資料を公開する必要はありませんが、機密保持契約 (NDA) の下で、他者に提供することを選択することはできます。
この仕様書は、オープンイニシアティブとして開発され、150以上のコントリビュータからフィードバックが寄せられています。開発履歴の詳細は仕様書用のメーリングリスト、および、Frequently Asked Questions (FAQ)でご覧いただけます。
原文における英語のアルファベット順。本文中では、斜字体で表記しています。
コンプライアンス関連資料（Compliance Artifact）— 供給ソフトウェアに対応してプログラムが生成する資料の集合。以下を1つ以上含むが、これらに限定されるものではない：ソースコード、帰属告知、著作権表示、ライセンスの写し、改変告知、書面による申し出、オープンソースコンポーネント部品表、およびSPDX ドキュメント。
確認ライセンス（Identified License） – 供給ソフトウェアを構成するオープンソースコンポーネントに適切なライセンス確認手法を適用することにより存在が確認されたオープンソースライセンスの一覧 。
OpenChain適合（OpenChain Conformant） – 本仕様書のすべての要件を満たすプログラムのこと。
オープンソース（Open Source）— Open Source Initiative（OpenSource.org）によって公開されているOpen Source DefinitionやFree Software Definition （Free Software Foundationによって公開）、または同様のライセンスの1つ以上のライセンスに従うソフトウェアのこと。
プログラム（Program） – 組織のオープンソースライセンスコンプライアンス活動を管理するポリシー、プロセス、および要員の集合。
ソフトウェアスタッフ（Software Staff） － 供給ソフトウェアについて、定義、コントリビュート、または使えるように準備する責任を持つ組織の従業員または契約者のこと。組織にも依存するが、スタッフには（必ずしも限定されないが）ソフトウェア開発者、リリースエンジニア、品質管理技術者、プロダクトマーケティング担当者、プロダクト管理者などが含まれる。
SPDX － Linux FoundationのSPDX（Software Data Package Exchange）ワーキンググループによって作られ、ソフトウェアパッケージのライセンスおよび著作権情報を交換することを目的としたフォーマット標準のこと。SPDX 仕様の詳細はwww.spdx.orgを参照のこと。
供給ソフトウェア（Supplied Software）– 組織が第三者 （他の法人または個人）に対して提供するソフトウェアのこと。
証跡となる資料（Verification Material）– 与えられた要件を満足することを示す確証のこと。
- ポリシー
供給ソフトウェアに対するオープンソースのライセンスコンプライアンスを管理する文書化されたオープンソースポリシーが存在していること。このポリシーは組織内で周知されていなければならない。**
証跡となる資料
-
1.1.1 文書化されたオープンソースポリシー。
-
1.1.2 ソフトウェアスタッフがオープンソースポリシーの存在を認識する文書化された手続き（例えば、トレーニング、社内 wiki、またはその他の実践的なコミュニケーション手法を通じて）。
** **
論拠
オープンソースポリシーを作成・記録するステップが取られ、ソフトウェアスタッフがその存在を認識することを確かなものにします。ポリシーに含めるべき内容についての要件はここで提示されませんが、他のセクションではポリシーに関する要件が課される場合があります。
1.2 力量
組織は以下を行うこと。
-
当該プログラムの遂行とその効果に影響を及ぼす役割、および、その役割に対応した責任を特定する
-
それぞれの役割を果たす担当者の必要な力量を決定する
-
これらの担当者が適切な教育、トレーニング、経験に基づいて十分な力量を持っていることを確認する
-
状況に応じて、必要な力量を獲得するための措置を講じる
-
文書化された記録を力量のエビデンスとして保持する
証跡となる資料
-
1.2.1 プログラム参加者の役割とその責任の文書化されたリスト。
-
1.2.2 各役割の力量を特定する文書。
-
1.2.3 それぞれのプログラム参加者の力量の評価を文書化したエビデンス。
論拠:
このようなプログラムを担う参加者が各々の役割とその責任を果たす十分な力量を有していることを確かなものとするためです。
1.3 認識
組織はこのプログラムへの参加者が以下を認識していることを確認すること。
-
オープンソースポリシー
-
関連するオープンソースの目標
-
プログラムの有効性に対する参加者の貢献
-
プログラム要件を守らないことの意味
証跡となる資料
- 1.3.1プログラムの目的、プログラムにおける参加者の貢献、プログラムの不適合の意味を含む各プログラム要員の認識度を評価したエビデンスとしての文書。
論拠:
プログラム要員がプログラムにおけるそれぞれの役割と責任を果たす十分な認識レベルを有していることを確認するためです。
1.4 プログラムのスコープ
いろいろなプログラムは異なったレベルのスコープによって運用される。例えば、プログラムが、単一の製品ライン、部署全体、あるいは、組織全体を統制する可能性がある。それぞれのプログラムに対してスコープの指定を明記する必要がある。
証跡となる資料
- 1.4.1 プログラムのスコープと境界を明確に定義する文書。
論拠:
組織に必要なスコープに最適なプログラムを構築するための柔軟性をもたらすためです。ある組織は、特定の製品ラインのためのプログラムを整備することを選択するかもしれません。一方、他の組織は組織全体の供給ソフトウェアを管理するプログラムを導入するかもしれません。
1.5 ライセンス義務
確認ライセンスをレビューし、それぞれのライセンスが付与する義務、制約、および、権利を判断するプロセスが存在すること。
証跡となる資料
- 1.5.1. それぞれの確認ライセンスが付与する義務、制約、および、権利をレビューし、文書として記録するための手続き文書。
論拠
組織が利用する可能性のあるさまざまなユースケースに合わせて確認ライセンスの義務をレビューし、特定するためのプロセスが存在することを確かなものとします。ユースケースの要件は、3.2にて定義しています。
2.1 アクセス
外部からのオープンソースに関する問い合わせに効果的に対応するプロセスを保持すること。また、第三者がオープンソースのコンプライアンスに関する問い合わせを行うことができる手段を公開すること。
証跡となる資料
- 2.1.1 第三者によるオープンソースのライセンスコンプライアンスに関する問い合わせを可能とする公開された方法。（例えば、公開された連絡先メールアドレス、または Linux Foundation のオープンコンプライアンスディレクトリを通じて。)
- 2.1.2 第三者によるオープンソースのライセンスコンプライアンスに関する問い合わせに応答するための内部手続き文書。
論拠
第三者がオープンソースのコンプライアンスに関する問い合わせを行い、組織が効果的に応答できる合理的な方法があることを確かなものとします。
2.2 十分なリソース配分
プログラムの関連業務を確認し、リソースを確保すること。
-
プログラムの関連業務の確実な実行のために役割を決定すること。
-
プログラムの関連業務に十分なリソースを配分すること。
-
業務を実行する時間
-
十分な予算を確保
-
-
ポリシー、および、支援業務に関してレビューとアップデートのプロセスが存在すること。
-
オープンソースのライセンスコンプライアンスについて法務的な指導が必要な時に専門家にアクセスできること。
-
オープンソースのライセンスコンプライアンスの問題が発生したときに、それを解決するためのプロセスが存在していること。
証跡となる資料
-
2.2.1 当該プログラムの役割に携わる担当者、グループ、および、部署の名称を記載したドキュメントが存在する。
-
2.2.2 プログラムの役割に適切な要員配置と十分な予算確保が行われている。
-
2.2.3 内部、および、外部で発生するライセンスコンプライアン問題に対応するための法務の専門家が特定できる。
-
2.2.4コンプライアンスの組織内責任者をアサインする手続き文書が存在する。
-
2.2.5 コンプライアンスに違反する状況の調査や是正措置を行うための手続き文書が存在する。
論拠
(i) プログラムの遂行責任者が十分に支援され、リソース配分が行われること、および、(ii) オープンソースコンプライアンスのベストプラクティスの変更に対応して、ポリシーおよび支援プロセスが定期的に更新されることを確かなものとします。
3.1部品表（Bill of Materials）
供給ソフトウェアを構成するオープンソースコンポーネント（および、確認ライセンス）を含む部品表を作成し、管理するプロセスが存在すること。**
証跡となる資料
-
3.1.1 供給ソフトウェアを構成するオープンソースコンポーネントの特定、追跡調査、レビュー、承認、および、情報保管のための手続き文書が存在する。
-
3.1.2供給ソフトウェアに対して手続き文書が適切に運用されたことを示すオープンソースコンポーネントの記録が存在する。
論拠
供給ソフトウェアを構成するオープンソース部品表を作成、管理するプロセスが存在することを確かなものとします。部品表はそれぞれのコンポーネントのライセンス条項を体系的にレビューし、承認するために必要となります。そのようなレビューによって、供給ソフトウェアの頒布のさいに適用される義務や制約を理解することができます。
3.2 ライセンスコンプライアンス
当該プログラムは、供給ソフトウェアのソフトウェアスタッフが利用する可能性のあるさまざまなオープンソースライセンスのユースケースに対応することが求められる。ユースケースとしては、以下が含まれる（ただし、下記リストはすべてを網羅したものではなく、また、すべてのユースケースにあてはまるものではないことに注意。）
-
バイナリ形態での頒布
-
ソースコード形態での頒布
-
コピーレフトの義務が発生する可能性のある他オープンソースとの統合
-
改変されたオープンソースを含んでいる
-
供給ソフトウェア内のコンポーネントとやりとりするオープンソース、ないしは、他のソフトウェアを含んでおり、それらが両立性のないライセンス下にある**
-
帰属要求[1]のあるオープンソースを含んでいる
証跡となる資料
- 3.2.1 供給ソフトウェア内のオープンソースコンポーネントに応じ、さまざまなオープンソースライセンスのユースケースを取り扱うための文書化された手続き。
論拠
当該プログラムが組織内のさまざまなオープンソースライセンスのユースケースを取り扱ううえで十分頑強であり、さらに、このような活動をサポートする手続きが存在し、かつ、それに従っていることを確かなものとします。
4.1 * コンプライアンス関連資料*
供給ソフトウェアのコンプライアンス関連資料を作成するプロセスが存在すること。**
証跡となる資料
-
4.1.1 確認ライセンスの要件に従って供給ソフトウェアに応じたコンプライアンス関連資料を準備し、また、頒布するプロセスを記述した手続き文書。
-
4.1.2 供給ソフトウェアのコンプライアンス関連資料のコピーを保管するための手続き文書。保管された資料は、供給ソフトウェアの最終提供以降、適切な期間[2]、あるいは、確認ライセンスの要件として定められた期間（どちらか長い方）保持することを計画。手続きが適切に守られていることを示す記録の存在。
論拠
確認ライセンスの要件に従い、供給ソフトウェアに付随するコンプライアンス関連資料の準備に商業的に妥当な努力が払われることを確かなものとします。
5.1 コントリビューション
組織がオープンソースプロジェクトへのコントリビューションを考慮する場合、以下を行うこと。
-
オープンソースプロジェクトへのコントリビューションを管理するポリシー文書が存在する
-
ポリシーが組織の内部で周知される
-
ポリシーを実装するプロセスがある
証跡となる資料
-
5.1.1 文書化されたオープンソースコントリビューションポリシー。
-
5.1.2 オープンソースコントリビューションを管理する手続き文書。
-
5.1.3すべてのソフトウェアスタッフがオープンソースコントリビューションポリシーの存在を認識する文書化された手続き （例えば、トレーニング、内部 wiki、その他の実践的なコミュニケーション方法を通じて）。
論拠
組織がオープンソースのコントリビューションを許可する場合、コントリビューションポリシーの開発と実装に向けて十分に検討することが望まれます。オープンソースコントリビューションポリシーは、オープンソースポリシー全体の一部としても、あるいは、独自のポリシーとしても作成できます。
6.1 適合
当該プログラムがOpenChain適合とみなされるためには、この仕様書の提示する要件をプログラムが満足していることを組織として明確に宣言する必要がある。
証跡となる資料
- 6.1.1 要件1.4 で指定したプログラムがこの仕様書のすべての要件を満たしていることを明確に宣言する文書。
論拠
組織がOpenChain適合であるプログラムを有していることを宣言するとき、それはこの仕様書のすべての要件を満たしていることを確かなもとするためです。要件のサブセットのみを満たしていることは十分とはいえません。
6.2 期間
本仕様書のこのバージョンに対応したOpenChain 適合のプログラムは、適合認証の取得日から18ヶ月間有効であるものとする。適合認証の登録手順はOpenChain プロジェクトのWebサイトを参照のこと。
証跡となる資料
- 6.2.1当該プログラムが、過去18ヶ月以内に適合認証を取得し、本仕様書の第2版のすべての要件を満たしていることを明確に宣言する文書。
論拠
組織が継続してプログラムの適合性を主張しようとするなら、最新の仕様書に準拠した状態を保つことが大切です。この要件は組織が継続してプログラム適合性を主張するさいに、プログラムの支援プロセスや制御が損なわれることを防ぎます。
本仕様書がグローバルに採用されることを促進するために、私たちは本仕様書を多言語に翻訳する取り組みを歓迎します。OpenChainはオープンソース プロジェクトとして機能するため、各種翻訳は時間と専門的知見をコントリビュートすることに前向きな方々によって、CC-BY-4.0ライセンスとプロジェクトの翻訳ポリシーの下で推進されます。そのポリシーおよび現在入手可能な翻訳版の詳細については、OpenChainプロジェクトの仕様書Webページでご確認ください。
[1] 訳注：Wikipedia「帰属」より引用。「ある著作物（works）を利用（use）する場合、その著作物の著作者への謝辞（acknowledge）やクレジットの掲載を要求することを指す用語である。または別の著作物に表示すること（appear in works）自体を指す。」
[2] 原注：製品ドメイン、地域や国による制度の違い、あるいは、顧客との契約によって決まる。