オープンソース コードの使用

オープンソースプログラムオフィスの最も重要な責務の 1 つは、オープンソースコードを商用製品のプロプライエタリなソースコードやサードパーティソースコードと統合する際に、組織が確実に法的義務を果たすようにすることです。

開発者がオープンソースコードをどのように使用できるかのガイドライン、およびオープンソースコードの出所がどこで、どのようにライセンスされ、最終的にどう使用されるかを追跡する詳細なプロセスを確立する必要があります。このガイドでは、オープンソースコードを使用、リリース、配布するためのベースラインコンプライアンスプログラムについて説明します。

内容

コードの追跡とレビューの必要性
コンプライアンスにおける役割と責任
オープンソースコード利用のためのシンプルなポリシー
5 段階のコードレビュープロセス
バージョン 1.0 後のプロセス
オープンソース利用申請フォームサンプル
結論
アーキテクチャ概略図テンプレート

ガイド一覧 » GitHub上で貢献する »

このガイドの貢献者

Ibrahim Haddad Samsung Research America社 R&D 担当 VP 兼オープンソースグループ長

セクション 1

コードの追跡とレビューの必要性

単純な話として、開発者がオープンソースコードをどこでどのように使用しているかを把握してない企業は、適用されるオープンソースライセンスに違反する恐れがあります。これは、弁護士費用の点でも、失敗の修正に費やされるエンジニアリング時間の点でもコストがかかる結果になる可能性があります。また、オープンソースの法的義務を無視することは、オープンソースコミュニティ内で企業の評判を損なうことにもなります。

オープンソースプログラムオフィスは、オープンソースの使用、配布、リリースに関わるポリシーおよび意思決定の一元化を支援し、コードの出所と使用を追跡して、組織がコンプライアンス義務に違反しないようにします。

オープンソースプログラムは包括的なコンプライアンスプログラムを含み、法務専門家の協力を得て開発されていることが理想的です。このガイドでは、コンプライアンスプログラムの重要な側面、つまりオープンソースコードを使用、リリース、配布するためのポリシーとプロセスについて説明します。

「うまく設計されたオープンソースコンプライアンスプロセスは、オープンソースライセンス条項の遵守を確実にすると同時に、企業が自身の知的財産およびサードパーティサプライヤの知的財産を意図しない漏洩やその他の結果から保護するのにも役立ちます。」
Ibrahim Haddad – Samsung Research America 社 R&D 担当バイスプレジテント兼オープンソースグループ長

オープンソースコンプライアンスプログラムを維持することにより、企業は次のようなメリットを得ることができます。

技術的優位性の確保 。なぜなら、オープンソースライセンスに準拠したソフトウェアポートフォリオは容易に提供、テスト、アップグレード、維持できるからです。
重要なオープンソースコードの特定 。複数の製品や組織の部署にまたがって使用されているコードや、オープンソース戦略にとって特に重要で有益なコードを把握できます。
オープンソースコンポーネントの使用に関するコストとリスクの実証 。コードのレビューを複数回にわたって行うことによって、容易に把握できます。
コミュニティの信頼の構築 。コンプライアンスに関する問題が生じた場合、このようなプログラムにより、継続して誠意をもって行動する姿勢を示すことができます。
起こりうる買収、売却、あるいは新製品/サービスのリリースなどへの備え 。これは、あまり一般的ではないメリットですが、このような取引を完了させるうえで、コンプライアンス保証は必須です。
サプライチェーン内の信頼関係の構築 。OEM や下流ベンダーとのやり取りを通じて、ソフトウェアサプライチェーン全体のコンプライアンスを強化できます。

セクション 2

コンプライアンスにおける役割と責任

オープンソースプログラムでは、オープンソースコンプライアンスの確保を目的とする専任のオープンソースコンプライアンスチームを作る必要があります。

この中核チームは、監査チームまたはオープンソースレビューボード (OSRB: Open Source Review Board) とも呼ばれ、エンジニアリングと製品チームの代表者、1 人以上の法務専門家、およびコンプライアンスオフィサー (通常、オープンソースプログラムマネージャー) で構成されます。

ドキュメント製作、サプライチェーン、経営企画、IT、ローカライゼーション、オープンソース戦略全体を監督するオープンソース執行委員会 (OSEC: Open Source Executive Committee) など、他のさまざまな部門の人々も、拡張チームのメンバーとしてオープンソースコンプライアンスの取り組みに継続的に貢献します。ただし、中核チームと異なり、拡張チームのメンバーは、OSRB から依頼された作業に基づいてパートタイムベースでコンプライアンスに取り組むだけです。

OSRB は、オープンソースコンプライアンス戦略を策定し、企業が日常的に規則をどのように実施するかを決定する一連のプロセスを作成する責任を担っています。この戦略は、コンプライアンス確保のために何をすべきかを決定し、従業員がオープンソースソフトウェアとどのように向き合えばよいかについて一連の統治原則を提供します。これには、オープンソースの承認、取得、使用のための正式なプロセス、およびオープンソースを含むソフトウェアまたはオープンソースライセンスの元で許可されたたソフトウェアのリリース方法が含まれます。

セクション 3

オープンソースコードを利用するためのシンプルなポリシー

利用ポリシーは、オープンコンプライアンスプログラムの中で不可欠なコンポーネントです。利用ポリシーに含まれる一連の規則は、オープンソース戦略文書 (既にお持ちでは？) に含まれ、誰でも入手して簡単に参照できるようになっています。

利用ポリシーは、製品を支えるすべてのソフトウェア (プロプライエタリ、サードパーティ製、オープンソースを問わず) の監査、レビュー、承認が完了することを推進するものです。また、さまざまなソフトウェアコンポーネントを使用することで生じたライセンス義務を履行するための活動を製品が顧客の元に届く前に完了するようにします。

この利用ポリシーは長い文書や複雑な文書である必要はありません。良く出来たオープンソース利用ポリシーには、次の 6 つのシンプルな規則が含まれます。

技術者は、オープンソースコードを製品に統合する前に OSRB から承認を得る必要があります。
サードパーティから受け取ったソフトウェアは、監査を受けて、含まれているオープンソースコードを特定する必要があります。これにより、製品出荷前にライセンス義務を確実に履行することができます。
すべてのソフトウェアは、すべてのプロプライエタリソフトウェアコンポーネントも含めて、監査およびレビューを受ける必要があります。
製品は、顧客が受け取る前にオープンソースライセンス義務を履行する必要があります。
ある製品で特定のオープンソースコンポーネントの使用が承認されても、その同じオープンソースコンポーネントを別の方面で使用することが承認されたことにはなりません。
変更されたコンポーネントはすべて承認プロセスを経る必要があります。

セクション 4

5 段階のコードレビュープロセス

利用ポリシーを策定したら、そのポリシーを容易に適用できるプロセスを作成する必要があります。さらに、開発者がオープンソースの利用とオープンソースプロジェクトへの貢献を円滑に行えるようにする必要があります。

「コードのレビュープロセスがあまりに面倒なものだと、イノベーションのスピードが落ちたり、開発者にプロセス全体を回避する格好の口実を与えることになります。」
Ibrahim Haddad – Samsung Research America 社 R&D 担当バイスプレジテント兼オープンソースグループ長

プロセスではまず、対象となっているソフトウェアパッケージのソースコードをスキャンします。次に、発見された問題を特定および解決し、法的レビューとアーキテクチャレビューを行ったのち、利用承認に関する決定を行います。

下の図は、コンプライアンス利用プロセスを単純化して図示したものです。実際には、プロセスはその性質上、かなり反復的です。以下の各段階は説明することを目的としており、企業特有の必要性やオープンソースプログラムの構成に応じて変更が必要なことに注意してください。

プロセスの各段階を順を追って説明しましょう。

第 1 段階：ソースコードのスキャン

ソースコードのスキャン段階では、専門のソフトウェアツールを使用して、すべてのソースコードがスキャンされます (このようなツールは、いくつかのオープンソースツールの他に、数多くの商用ベンダーから提供されています)。

この段階は、通常、技術者がオンラインの利用フォームを提出することで開始されます (以下のサンプルの利用フォームと利用規則を参照)。このフォームには、対象となっているオープンソースコンポーネントに関するすべての情報を含め、ソースコードリポジトリシステム内のソースコードの場所を指定します。

フォームを提出すると、JIRA、Bugzilla などのシステムにコンプライアンスチケットが自動的に作成され、決められた監査スタッフにソースコードスキャン要求が送られます。

対応する利用フォームの提出なしにオープンソースソフトウェアコンポーネントがプラットフォームに統合されることがないようにするため、プラットフォームの定期的なフルスキャンも数週間ごとに行う必要があります。

何らかの問題が見つかった場合は、JIRA チケットが自動的に発行され、監査スタッフに割り当てられます

ソースコードのスキャンが開始される要因には、次のようなものがあります。

利用フォーム (通常はエンジニアリングスタッフが入力) の受信。
定期的にスケジュールされているプラットフォーム全体のスキャン。このようなスキャンは、利用フォームが提出されないままソフトウェアプラットフォームに密かに入り込んだオープンソースコードを発見するのに非常に役立ちます。
以前に承認されたソフトウェアコンポーネントの変更。多くの場合、技術者はまず、OSS コンポーネントの特定のバージョンを評価およびテストし、その後、新しいバージョンが利用可能になると、それを採用します。
サードパーティソフトウェアプロバイダからのソースコードの入手。プロバイダがオープンソースを公開しているかどうかは問いません。
作成者やライセンスが不明なソースコードの Web からのダウンロード。ソースコードにオープンソースコードが組み込まれているかどうかは問いません。
新しいプロプライエタリソフトウェアコンポーネントのビルドシステムへの組み込み。エンジニアリング担当者がオープンソースコードを借用し、それをプロプライエタリソフトウェアコンポーネントで使用したかどうかは問いません。

コードのスキャンが終了すると、スキャンツールは、以下の情報を提供するレポートを生成します。

使用されている既知のソフトウェアコンポーネント。ソフトウェア部品表 (Bill Of Material: BOM) とも呼ばれます。
有効なライセンス、ライセンステキスト、義務の概要
法務専門家による確認が必要なライセンスとの矛盾点
ファイル目録
ライセンスが識別されたファイル
依存関係
コードの一致
ライセンスの識別が保留されたファイル
ライセンスの識別が保留されたファイル中のマッチしたソースコード

ダウンロードしたオープンソースパッケージに関する注意

Web からダウンロードしたオープンソースパッケージは、元の形のまま保管しておくことが重要です。このパッケージは、後の段階（出荷の前）で元のパッケージと変更後のパッケージの間の差分を調べることにより、ソースコードに加えられた変更を検証し、追跡するために使用します。

サードパーティソフトウェアプロバイダがオープンソースを使用している場合、そのコードを製品に統合する製品チームは、使用されているオープンソースについて記述したオープンソース利用申請フォームを提出する必要があります。サードパーティソフトウェアプロバイダがソースコードを提供せず、バイナリしか提供しない場合は、製品チーム、またはサードパーティソフトウェアプロバイダとの関係を管理するソフトウェアサプライヤマネージャーは、提供されたソフトウェアにオープンソースが含まれていないという確証 (たとえば、スキャンレポート) を得る必要があります。

第 2 段階: 特定および解決

特定および解決段階では、監査チームが、スキャンツールによってフラグが付けられたファイルまたはスニペットを検査し、解決します。

たとえば、スキャンツールのレポートは、矛盾するライセンスや互換性のないライセンスなどの問題にフラグを付けます。問題がない場合、コンプライアンスオフィサーはコンプライアンスチケットを法的レビュー段階へ進めます。

解決すべき問題がある場合、コンプライアンスオフィサーはコンプライアンスチケット内にサブタスクを作成して、適切なエンジニアリング担当者に割り当てて解決させます。コードを修正する場合も、確認だけで済む場合もあります。サブタスクには、問題の説明、エンジニアリング担当者が実施すべき解決策の提案、完了までのタイムラインを含める必要があります。

すべての問題が解決したら、コンプライアンスオフィサーはサブタスクを閉じ、チケットを法的レビューに渡すことができます。あるいは、まずソースコードの再スキャンを指示し、新しいスキャンレポートを生成してから、以前の問題がなくなったことを確認するという方法もあります。すべての問題が解決されたと納得できたら、コンプライアンスオフィサーは、レビューと承認のためにコンプライアンスチケットを法務部門の担当者に送ります。

法的レビューに向けた準備として、オープンソースソフトウェアに関連するすべてのライセンス情報 (COPYING、README、LICENSE ファイルなど) をコンプライアンスチケットに添付する必要があります。

第 3 段階: 法的レビュー

法的レビュー段階では、法務専門家 (通常、オープンソースレビューボード (OSRB) のメンバー) がスキャンツールによって生成されたレポート、ソフトウェアコンポーネントのライセンス情報、エンジニアリング担当者や監査チームのメンバーがコンプライアンスチケットに残したコメントなどのレビューを行います。

法的レビュー段階に到達したコンプライアンスチケットには、既に以下が含まれています。

ソースコードスキャンレポート、およびスキャン段階で特定されたすべての問題が解決済みであることの確認。
チケットに添付されたライセンス情報のコピー。通常、コンプライアンスオフィサーは、ソースコードパッケージで入手できる README、COPYING、および AUTHORS ファイルをコンプライアンスチケットに添付します。ライセンス情報 (OSS コンポーネントでは、通常、COPYING ファイルまたは LICENSE ファイルで確認できます) の他に、著作権や帰属告知についても取得する必要があります。この情報は、製品ドキュメントに適切な属性の情報を提供します。
コンプライアンスチケットに関するコンプライアンスオフィサーからのフィードバック (懸念事項、新たな疑問点など)。
監査チームに対するエンジニアリング担当者からのフィードバック、またはこのパッケージを内部で追跡/維持する技術者 (パッケージ所有者) からのフィードバック。

この段階の目標は、コンプライアンスに関する法務専門家の見解をまとめ、対象となっているソフトウェアコンポーネントでの使用ライセンスと公開ライセンスについて決定することです。ソフトウェアコンポーネントには複数のライセンスの下で利用できるソースコードが含まれている場合があるため、使用ライセンスと公開ライセンスは、複数ある場合があります。この段階では、次の 3 つの結果が得られる可能性があります。

問題なし

ライセンスに関して問題がない場合、法務専門家は、ソフトウェアコンポーネントの使用ライセンスと公開ライセンスを決定し、コンプライアンスチケットのプロセスをコンプライアンスのアーキテクチャ段階へと一歩進めます。

使用ライセンスは、受け取ったソフトウェアパッケージに対するライセンスです。公開ライセンスは、自身がライセンスしているソフトウェアパッケージを公開するライセンスです。場合によっては、使用ライセンスが再ライセンス (BSD など) を許可するパーミッシブライセンスであることがあり、その場合、企業は、自身のプロプライエタリライセンスの下でソフトウェアを再ライセンスする場合があります。さらに複雑な例として、ソフトウェアコンポーネントにプロプライエタリソースコード、ライセンス A でライセンスされたソースコード、ライセンス B の下で利用できるソースコード、ライセンス C の下で利用できるソースコードが含まれる場合を考えます。

法的レビュー時、法務専門家は、使用ライセンスと公開ライセンスを次のように決定する必要があります。
使用ライセンス = プロプライエタリライセンス + ライセンス A + ライセンス B + ライセンス C 公開ライセンス = ?

問題あり

互換性のないライセンスを持つソースコードの混在など、ライセンスに関する問題が見つかった場合、法務専門家は、それらの問題にフラグを付け、JIRA のコンプライアンスチケットを再度エンジニアリング担当者に割り当てて、コードを修正させます。

たとえば、法的レビューにより、非公開の知的財産がオープンソースコードパッケージと組み合わされていることが明らかになったとします。法務専門家は、これにフラグを付け、コンプライアンスチケットを再度エンジニアリング担当者に割り当てて、オープンソースコンポーネントからプロプライエタリソースコードを削除させます。エンジニアリング担当者がオープンソースコンポーネントにプロプライエタリソースコードを保持することを主張する場合、オープンソース執行委員会 (OSEC) は、オープンソースライセンスの下でプロプライエタリソースコードを提供する必要があります。

不明

ライセンス情報が不明確だったり、利用できない場合は、法務専門家またはエンジニアリングスタッフメンバーがプロジェクト管理者またはオープンソース開発者に問い合わせて、曖昧さを解決し、その特定のソフトウェアコンポーネントがどのライセンスの下にライセンスされているかを確認します。

第 4 段階：アーキテクチャレビュー

アーキテクチャレビューでは、監査チームまたはオープンソースレビューボードのコンプライアンスオフィサーとエンジニアリング担当者が、オープンソース、プロプライエタリ、およびサードパーティのコード間の相互関係を分析します。これは、以下に示すアーキテクチャ概略図 (以下の例を参照) を調べることで実施されます。

オープンソースコンポーネント (そのまま使用、または変更)
プロプライエタリコンポーネント
サードパーティソフトウェアプロバイダ起源のコンポーネント
コンポーネントの依存関係
通信プロトコル
特に、特定のソフトウェアコンポーネントが別のオープンソースライセンスによって管理されている場合、そのコンポーネントがやり取りするまたは依存する、その他のオープンソースパッケージ。

アーキテクチャレビューの結果として、ライセンス義務に関する分析が得られます。ライセンス義務は、オープンソースからプロプライエタリまたはサードパーティソフトウェアコンポーネントに及ぶ場合があり、また、複数のオープンソースコンポーネントにまたがって及ぶ場合もあります。

コンプライアンスオフィサーが問題 (たとえば、GPL ライセンスされたコンポーネントにリンクしているプロプライエタリソフトウェアコンポーネント) を発見した場合、コンプライアンスオフィサーは解決のためにコンプライアンスチケットをエンジニアリング担当者に送ります。問題がない場合は、コンプライアンスオフィサーはチケットを承認プロセスの最終段階へ送ります。

第 5 段階：最終レビュー

最終レビューは、通常、監査チームまたはオープンソースレビューボード (OSRB) の対面での会議で行われ、この会議で、チームはソフトウェアコンポーネントの使用を承認または却下します。

チームの決定は、ソフトウェアコンポーネントの完全なコンプライアンスレコードに基づいて行われますが、これには以下が含まれます。

スキャンツールによって生成されたソースコードスキャンレポート。
発見された問題のリスト、どのように解決されたかの情報、および誰がこれらの問題が適切に解決されたことを検証したか。
アーキテクチャ概略図、および対象ソフトウェアコンポーネントが他のソフトウェアコンポーネントとどのように関係するかの情報。
コンプライアンスに関する法務専門家の意見、および使用ライセンスと公開ライセンスに関する決定。
組み込み環境 (C/C++) の場合、動的および静的リンケージ分析。

ほとんどの場合、最終レビューに到達したソフトウェアコンポーネントは、何らかの条件が見つからない限り (ソフトウェアコンポーネントが使用されなくなった場合など)、承認されます。承認されると、コンプライアンスオフィサーは、承認されたソフトウェアコンポーネントのライセンス義務のリストを作成して適切な部門に渡し、義務を履行させます。これには、以下が含まれます。

特定の OSS ソフトウェアコンポーネントのバージョン x を製品 y のバージョン z で使用することが承認されたことを反映するように、ソフトウェア目録を更新します。
製品またはサービスでオープンソースが使用されていることを反映するように製品ドキュメントのエンドユーザー向け通知を更新するために、チケットをドキュメント製作チームに発行します。
製品出荷前に配布プロセスを開始します。

OSRB 承認後に実施される手順

コンプライアンスオフィサーは、すべてのオープンなチケットを追跡し、製品出荷時またはサービス開始時までに完了するようにします。

詳細な利用プロセスと想定されるシナリオについては、電子書籍「企業におけるオープンソースコンプライアンス」を参照してください。

セクション 5

バージョン 1.0 後で実行すべきこと

初期のコンプライアンス (ベースラインコンプライアンスとも呼ばれる) は、開発が開始された時点で発生し、製品の最初のバージョンのリリースまで継続します。コンプライアンスチームは、ベースラインソフトウェアに含まれるすべてのオープンソースコードを特定し、すべてのソースコンポーネントに対して上述の 5 段階の承認プロセスを完了させます。

「オープンソースコンプライアンスはバージョン 1.0 で終了ではないことをしっかりと覚えておいてください。」
Ibrahim Haddad – Samsung Research America 社 R&D 担当バイスプレジテント兼オープンソースグループ長

製品出荷後は、ソースコードをチェックするインクリメンタルコンプライアンスプロセスを開発する必要があります。このプロセスは、追加機能やバグ修正などを含む新しいブランチに関する開発が始まったときに開始されます。

インクリメンタルコンプライアンスは、ベースラインバージョン 1.0 に製品の機能が追加されたときにコンプライアンスを維持するためのプロセスです。

Incremental Compliance

インクリメンタルコンプライアンス

インクリメンタルコンプライアンスは、ベースラインコンプライアンスの確立に必要な労力と比べると、比較的手間がかかりません。しかし、いくつかの問題が生じる可能性があります。バージョン 1.0 とバージョン 1.1 の間で変更されたソースコードを正確に特定し、リリース間の次のような差分についてコンプライアンスを検証する必要があります。

新しいソフトウェアコンポーネントが導入されている可能性があります。
既存のソフトウェアコンポーネントの使用が中止されている可能性があります。
既存のソフトウェアコンポーネントが新しいバージョンにアップグレードされている可能性があります。
ソフトウェアコンポーネントのライセンスがバージョン間で変更されている可能性があります。
既存のソフトウェアコンポーネントで、バグ修正や機能/アーキテクチャの変更に伴うコード変更が行われている可能性があります。

当然の疑問として、このような変更のすべてを追跡し続けるにはどうすればいいでしょうか？答えは簡単です。部品表比較ツール (BOM 比較ツール) の利用です。バージョン 1.1 の製品の BOM とバージョン 1.0 の製品の BOM がある場合、ツールを使用すると、差分を比較して以下を出力できます。

バージョン 1.1 で追加された新しいソフトウェアコンポーネントの名前

更新されたソフトウェアコンポーネントの名前
使用が中止されたソフトウェアコンポーネントの名前

この情報を入手できれば、インクリメンタルコンプライアンスの実現は比較的容易な作業になります。

新しいソフトウェアコンポーネントを 5 段階の利用承認プロセスに投入します。
変更されたソフトウェアコンポーネントのソースコードの差分を 1 行ごとに比較し、ソースコードを再度スキャンするか、以前のスキャンを信頼するかを決定します。
使用されなくなったソフトウェアコンポーネントを削除して、ソフトウェアレジストリを更新します。

下の図に、インクリメンタルコンプライアンスプロセスの概要を示します。各製品リリースの BOM ファイルはビルドサーバーに保存されます。BOM 比較ツールは、それぞれが異なる製品リリースに対応する 2 つの BOM ファイルを入力として使用して、差分を比較し、前述の変更リストを作成します。

この段階でコンプライアンスオフィサーは、当該リリースのすべての新しいソフトウェアコンポーネントに対して新しいコンプライアンスチケットを作成し、変更されたソースコードについてはコンプライアンスチケットを更新し、場合によってはプロセスを再度通過させ、最後に、ソフトウェアレジストリを更新することにより、使用が中止されたソフトウェアコンポーネントを承認リストから削除します。

インクリメンタルコンプライアンスプロセスの例

オープンソース利用申請フォーム

オープンソース利用申請フォームの記入は、開発者がオープンソースソフトウェアを企業に持ち込む際の重要なステップで、慎重に行う必要があります。

開発者は、特定のオープンソースコンポーネントを使用する承認を求めるオンラインフォームに入力します。

このフォームはいくつかの質問で構成されており、監査チームまたはオープンソースレビューボードは、これらの質問から得られる情報により、提案されたオープンソースコンポーネントの使用を承認するかどうかを決定することができます。

次の表に、オープンソース利用申請フォームで入力を求められる情報を示します。

通常、これらの値はプルダウンメニューから選択できるため、データを効率よく入力できます。

OSRB 利用フォームに関しては、次のようないくつかの規則があります。例えば：

フォームは、特定の製品および特定のコンテキストでのオープンソースの利用に限定して適用されます。これはすべての製品のすべてのユースケースについて、オープンソースコンポーネントの一般的な承認を申請するためのものではありません。
フォームは監査活動の基礎です。レビューチームは、実装がフォームで示されている利用計画や監査およびアーキテクチャレビューの結果と一致しているかどうかを検証するために、フォームによって提供される情報を必要とします。
当該オープンソースコンポーネントの利用計画が変更された場合は必ず、フォームを更新して再提出する必要があります。
エンジニアリング担当者がオープンソースを製品ビルドに統合する前に、監査チームまたはレビューボードがフォームを承認する必要があります。
オープンソース執行委員会は、ライセンス条項が特許ライセンスの付与または特許の非係争を要求しているすべてのオープンソースパッケージについて、使用を承認する必要があります。

セクション 6

オープンソース利用申請フォームサンプル

オープンソース利用申請フォームサンプルのPDFはこちら

セクション 7

結論

オープンソースコンプライアンスは、ソフトウェアの開発プロセスに不可欠のものです。製品でオープンソースソフトウェアを使用しているにも関わらず、確立されたコンプライアンスプログラムがない場合は、ぜひこのガイドをきっかけとして行動を起こしてください。

本質的に、オープンソースコンプライアンスは、商品で使用されるオープンソースの取り込みと配布を管理する一連の活動で構成されます。コンプライアンスのデューデリジェンス (適正評価) の結果、製品で使用されるすべてのオープンソース (コンポーネントおよびスニペット) が特定され、ライセンス義務の履行計画が策定されます。オープンソースコンプライアンスに関する詳細なガイドについては、無料の電子書籍「企業におけるオープンソースコンプライアンス」(Ibrahim Haddad 著) をダウンロードしてください。

セクション 8

アーキテクチャ概略図テンプレート

オープンソースレビュープロセスのアーキテクチャレビュー段階で使用されるアーキテクチャ概略図に、プラットフォーム内のさまざまなソフトウェアコンポーネント間の相互作用を示します。以下のアーキテクチャ概略図サンプルでは、次のものが示されています。

モジュールの依存関係
プロプライエタリコンポーネント
オープンソースコンポーネント (変更されたものと元のままのもの)
動的リンクと静的リンク
カーネル空間とユーザー空間
共有ヘッダーファイル
通信プロトコル
特に、対象となっているソフトウェアコンポーネントが別のオープンソースライセンスによって管理されている場合、そのコンポーネントがやりとりまたは依存するその他のオープンソースコンポーネント

このアーキテクチャ概略図のテンプレートは、C または C++ に依存する組み込み環境に適用されます。