パッケージは、元の形のまま保管しておくことが重要です。コードに加えられた変更を検証し、追跡するために使用します。プロバイダがオープンソースを使用している場合、そのコードを製品に統合する製品チームは、使用されているオープンソースについて記述したオープンソース利用申請フォームを提出する必要があります。ツールによってフラグが付けられたファイルまたはスニペットを検査し、解決します。ツールのレポートは、矛盾するライセンスや互換性のないライセンスなどの問題にフラグを付けます。チケットを法的レビュー段階へ進めます。チケット内にサブタスクを作成して、適切なエンジニアリング担当者に割り当てて解決させます。コードを修正する場合も、確認だけで済む場合もあります。サブタスクには、問題の説明、エンジニアリング担当者が実施すべき解決策の提案、完了までのタイムラインを含める必要があります。オフィサーはサブタスクを閉じ、チケットを法的レビューに渡すことができます。レポートを生成してから、以前の問題がなくなったことを確認するという方法もあります。チケットを法務部門の担当者に送ります。チケットに添付する必要があります。チケットに残したコメントなどのレビューを行います。チケットには、既に以下が含まれています。レポート、およびスキャン段階で特定されたすべての問題が解決済みであることの確認。チケットに添付されたライセンス情報のコピー。チケットに添付します。他に、著作権や帰属告知についても取得する必要があります。この情報は、製品ドキュメントに適切な属性の情報を提供します。(懸念事項、新たな疑問点など)。コンポーネントでの使用ライセンスと公開ライセンスについて決定することです。コードが含まれている場合があるため、使用ライセンスと公開ライセンスは、複数ある場合があります。つの結果が得られる可能性があります。チケットのプロセスをコンプライアンスのアーキテクチャ段階へと一歩進めます。パッケージに対するライセンスです。公開ライセンスは、自身がライセンスしているソフトウェアパッケージを公開するライセンスです。ライセンスの下でソフトウェアを再ライセンスする場合があります。コードが含まれる場合を考えます。法的レビュー時、法務専門家は、使用ライセンスと公開ライセンスを次のように決定する必要があります。チケットを再度エンジニアリング担当者に割り当てて、コードを修正させます。パッケージと組み合わされていることが明らかになったとします。コードを削除させます。コードを提供する必要があります。コンポーネントがどのライセンスの下にライセンスされているかを確認します。オフィサーとエンジニアリング担当者が、オープンソース、プロプライエタリ、およびサードパーティのコード間の相互関係を分析します。調べることで実施されます。レビューの結果として、ライセンス義務に関する分析が得られます。コンポーネントにまたがって及ぶ場合もあります。チケットをエンジニアリング担当者に送ります。オフィサーはチケットを承認プロセスの最終段階へ送ります。コンポーネントの使用を承認または却下します。レコードに基づいて行われますが、これには以下が含まれます。発見された問題のリスト、どのように解決されたかの情報、および誰がこれらの問題が適切に解決されたことを検証したか。コンポーネントが他のソフトウェアコンポーネントとどのように関係するかの情報。コンプライアンスに関する法務専門家の意見、および使用ライセンスと公開ライセンスに関する決定。場合、動的および静的リンケージ分析。コンポーネントが使用されなくなった場合など)、承認されます。コンポーネントのライセンス義務のリストを作成して適切な部門に渡し、義務を履行させます。これには、以下が含まれます。使用することが承認されたことを反映するように、ソフトウェア目録を更新します。ユーザー向け通知を更新するために、チケットをドキュメント製作チームに発行します。製品出荷前に配布プロセスを開始します。オフィサーは、すべてのオープンなチケットを追跡し、製品出荷時またはサービス開始時までに完了するようにします。コンプライアンス」を参照してください。開発が開始された時点で発生し、製品の最初のバージョンのリリースまで継続します。段階の承認プロセスを完了させます。終了ではないことをしっかりと覚えておいてください。プロセスを開発する必要があります。このプロセスは、追加機能やバグ修正などを含む新しいブランチに関する開発が始まったときに開始されます。製品の機能が追加されたときにコンプライアンスを維持するためのプロセスです。コンプライアンスの確立に必要な労力と比べると、比較的手間がかかりません。いくつかの問題が生じる可能性があります。コードを正確に特定し、リリース間の次のような差分についてコンプライアンスを検証する必要があります。コンポーネントが導入されている可能性があります。コンポーネントの使用が中止されている可能性があります。コンポーネントが新しいバージョンにアップグレードされている可能性があります。コンポーネントのライセンスがバージョン間で変更されている可能性があります。コンポーネントで、バグ修正や機能/アーキテクチャの変更に伴うコード変更が行われている可能性があります。当然の疑問として、このような変更のすべてを追跡し続けるにはどうすればいいでしょうか?答えは簡単です。ある場合、ツールを使用すると、差分を比較して以下を出力できます。コンプライアンスの実現は比較的容易な作業になります。段階の利用承認プロセスに投入します。コードを再度スキャンするか、以前のスキャンを信頼するかを決定します。レジストリを更新します。プロセスの概要を示します。サーバーに保存されます。ファイルを入力として使用して、差分を比較し、前述の変更リストを作成します。コンポーネントを承認リストから削除します。ソフトウェアを企業に持ち込む際の重要なステップで、慎重に行う必要があります。フォームに入力します。コンポーネントの使用を承認するかどうかを決定することができます。次の表に、オープンソース利用申請フォームで入力を求められる情報を示します。メニューから選択できるため、データを効率よく入力できます。利用フォームに関しては、次のようないくつかの規則があります。:フォームは、特定の製品および特定のコンテキストでのオープンソースの利用に限定して適用されます。コンポーネントの一般的な承認を申請するためのものではありません。フォームは監査活動の基礎です。レビューの結果と一致しているかどうかを検証するために、フォームによって提供される情報を必要とします。コンポーネントの利用計画が変更された場合は必ず、フォームを更新して再提出する必要があります。ボードがフォームを承認する必要があります。パッケージについて、使用を承認する必要があります。コンプライアンスは、ソフトウェアの開発プロセスに不可欠のものです。プログラムがない場合は、ぜひこのガイドをきっかけとして行動を起こしてください。コンプライアンスは、商品で使用されるオープンソースの取り込みと配布を管理する一連の活動で構成されます。特定され、ライセンス義務の履行計画が策定されます。ダウンロードしてください。コンポーネント間の相互作用を示します。以下のアーキテクチャ概略図サンプルでは、次のものが示されています。依存する組み込み環境に適用されます。グループとの協力により作成されました。マネージャーのみなさんに感謝します。Hat、Salesforce、Samsung、およびVMwareです。詳細については、todogroup.orgを参照してください。下でライセンスされています。シリーズなどのコンテンツが追加されるとお知らせします。ご希望のかたはこちらからお申し込みください。さまざまな商標を登録および使用しています。商標一覧はこちらのページでご確認いただけます。