GitHubがオープンソース依存関係のコンプライアンスを維持する方法

毎日、GitHubのエンジニアはGitHubプラットフォーム、内部アプリケーション、そしてオープンソースプロジェクトに新しい依存関係を導入しています。GitHubはオープンソースの拠点であるだけでなく、オープンソースによって支えられているのです！ そして、オープンソースを責任を持って使用する上で重要なのは、依存するプロジェクトを管理するライセンスを尊重することです。

GitHubでは、オープンソースコミュニティと使用する依存関係に対する義務を果たすことに取り組んでいます。ここでは、オープンソースプログラムオフィス（OSPO）が新しいGitHub License Compliance機能を活用して、数千もの依存関係を管理する方法を紹介します。

オープンソースライセンスコンプライアンスプロセスの管理

ほぼすべてのソフトウェアには何らかのライセンス契約が付いています。ライセンスは、義務を遵守することを条件にプロジェクトを使用する許可を与えます。その義務は、ドキュメントに原著作者へのクレジットを記載するようなシンプルなものから、プログラムを出荷する際にすべてのソースコードを配布することを要求するものまであります。また、ライセンスによっては特定の活動や使用カテゴリを制限する場合もあります。

組織には、ビジネスモデル、ソフトウェアエコシステム、配布戦略に基づいて、許容可能なライセンスに関する独自のポリシーがあるでしょう。たとえば、組織が商用、非公開ソースのバイナリアプリケーションを販売しているとします。その場合、独自のコードのオープンソース化を強制する依存関係を防ぎたいと思うかもしれません。

または、オープンソースパッケージとしてリリースする予定のプロジェクトがある場合、商用ライセンスや互換性のないオープンソースライセンスで管理されている依存関係を含めないようにしたいかもしれません。

いずれのシナリオでも、要求される義務を遵守できない場合は、法的または運用上のリスクを避けるために依存関係を避けるべきです。これらのライセンスを後から削除するには、エンジニアリングの労力が必要になる場合があります。エンタープライズソフトウェアでは、コンプライアンス違反のビジネスリスクは大きく、費用のかかる訴訟や評判の損害につながる可能性があります。

従来、ライセンスレビューは手動またはサードパーティ製ソフトウェアで行われてきました。しかし今、GitHubはGitHub Advanced Securityのお客様向けにライセンスコンプライアンス機能を導入し、プルリクエストで直接新しい依存関係をレビューできるようになりました。このレビューにより、依存関係のライセンスがポリシーに準拠していることを確認でき、新しいライセンスや個別のプロジェクトを許可するようポリシーを柔軟に拡張することもできます。

2ヶ月前、GitHubのOSPOはコンプライアンス管理のために構築した内部ツールから新しい機能に移行しました。アーリーアダプターとして、開発チームに迅速なフィードバックを提供し、大規模で動きの速いエンタープライズの複雑なコンプライアンス要件に対応できる機能であることを確認しました。

ポリシー成功のためのセットアップ

GitHubは製品導入前に内部のライセンスコンプライアンスツールを構築していたため、初期ポリシーとして使用できる許容ライセンスのリストがすでに存在していました。多くの依存関係がMIT、Apache 2.0、BSD-3-Clauseなどの一般的な許容ライセンスを使用していることに気づくでしょう。これらはポリシーをシードするのに適した出発点です。当初は組織全体のルールセットで「Evaluate」モードを使用して機能を展開し、マージをブロックせずにプルリクエストに注釈を生成しました。これにより、開発者が生産性を妨げられることなく新しいワークフローに慣れることができました。旧ツールと新ツールを並行して実行することで、動作に相違がないかも確認できました。この運用モードを約1ヶ月続けた後、アラートは主に珍しいライセンス、ライセンス情報がない、または明示的に禁止されているパッケージに限定される状態になりました。

GitHubライセンスコンプライアンスの仕組み

内部では、ライセンスコンプライアンスチェックはルールセットを通じて有効になります。カスタムプロパティでリポジトリをターゲットにし、そのプロパティの値によってライセンスチェックが「Active」モードまたは「Evaluate」モードで有効になります。ルールセットでターゲットにされたリポジトリでは、プロジェクトの依存関係を変更するプルリクエストがスキャンをトリガーし、新しい依存関係ごとに使用されているライセンスを検索します。新しい依存関係のライセンスがすでに許可されている場合、またはパッケージ固有の例外がある場合は、チェックがパスします。直接依存関係または推移的依存関係のいずれかに失敗がある場合、ツールは問題のあるパッケージごとにアラートを表示するコメントをプルリクエストに残します。

開発者はアラートを確認します。依存関係が受け入れられないと判断した場合は、コードを更新するかプルリクエストをクローズして依存関係を削除できます。ライセンスまたはパッケージを許可すべきだと考える場合は、例外リクエストを上げることができ、組織内の特定のチームに通知され、ポリシーを修正するかどうか、どのように修正するかを決定できます。

ライセンスポリシーチームの一日

GitHubのライセンスポリシーチームは、OSPOメンバーとライセンスレビューおよびサプライチェーン分析の専門知識を持つエンジニアで構成されています。世界中に拠点を持つ企業であるため、ポリシーレビューチームはタイムゾーンをまたいでメンバーを配置し、タイムリーにアラートをレビューしています。ライセンリクエストのレビューに関するSLAを正式に策定中ですが、実際には数時間以内に受信したリクエストをトリアージできることがほとんどです。

チームメンバーは新しいレビューリクエストのメール通知を受け取り、保留中のリクエストのバックログを確認できるダッシュボードにもアクセスできます。

リクエストを承認する際には2つの判断ポイントがあります。まず、ライセンスを許可するかパッケージを許可するかを決定します。次に、エンタープライズレベルかリポジトリレベルか、どのスコープで適用するかを決定します。安全なライセンスで、単にこれまで表示されていなかった場合は、エンタープライズレベルで追加し、GitHubのどこでもそのライセンスを持つ依存関係を許可します。一部の商用ライセンスを持つパッケージは、どこでも許可することはできませんが、ソフトウェアの料金を支払ったチームが所有するリポジトリでは許可すべきであるため、それらのポリシー修正はリポジトリレベルで追加されます。パッケージ例外は、通常ライセンスデータが関連付けられていない内部ソフトウェアに役立ちます。ツールはパッケージ例外のワイルドカードマッチをサポートしています。たとえば、@github-ui/* React名前空間内のすべてを許可しているため、それらのパッケージを1つずつ承認する必要がありません。

開発者にとって使いやすくする

このプロセスをサポートするため、GitHub OSPOへの連絡方法や緊急時の「break glass」オーバーライドの使用に関する手順を確立しています。これらの状況は稀ですが、時間的に非常に重要なプルリクエストに対して明確な緊急オーバーライドプロセスは不可欠です。前述の通り、ライセンスポリシーの適用はルールセットで行われ、ルールセットの条件はカスタムプロパティに基づきます。したがって、プロパティの値を切り替えることで、ライセンスアラートによってブロックされている重要な修正がある場合、一時的に適用をオフにできます。これまでこの機能を使用したのは1回だけですが、オプションがあることは非常に役立ちました。

また、開発者がライセンスコンプライアンスの重要性を理解するための内部ドキュメントとトレーニングも提供しています。最終的には、コンプライアンスを確保しリスクを管理することは全員の責任であり、それをできるだけ簡単にするのが私たちの役割です。

まとめ

ライセンスコンプライアンスは、ソフトウェアサプライチェーンの管理において重要な部分です。開発者がGitHubのライセンスポリシーに沿った情報に基づく依存関係の選択を行えるようにすることで、費用のかかる書き換えや潜在的な法的問題を防ぎます。私たちは新しいGitHub License Compliance機能を数ヶ月間熱心に使用し、フィードバックを提供してきました。パブリックプレビューとなった今、より多くの企業がこの機能を採用し、私たちの経験がこれから始める方々への指針となれば幸いです。

GitHub Enterprise Cloudのお客様は、アクティブなGHAS Code Securityライセンスを持つリポジトリ全体でLicense Compliance機能を使用できます。詳細については、About open source license complianceをご覧ください。