Detecting and Fixing Violations of Modification Terms in Open Source Licenses during Forking

技術要約：フォーク時におけるオープンソースライセンスの修正条項違反の検出と修正

問題提起
オープンソースソフトウェア（OSS）の開発は、開発者がベースとなるリポジトリをコピーして、独立して修正された新しいバージョンを作成する「フォーク」に大きく依存している。これはイノベーションを促進する一方で、開発者がライセンスの義務を遵守できなかった場合に重大な法的リスクをもたらす。既存の研究は、ライセンスの特定、依存関係間の不整合の検出、およびファイルライセンスの一貫性の発見に焦点を当ててきた。しかし、**修正条項（Modification Terms: MTs）**に関する重要なギャップが残されている。MTとは、元の著作物を修正する際の条件や、修正時に履行すべき義務を規定するOSSライセンス内の特定の条項である。顕著な例として、Apache-2.0のようなライセンスにおける、ファイルが変更されたことを示す「目立つ通知（prominent notices）」を含めるという要件がある。著者らの知る限り、これらの条項を体系的に特徴付けたり、フォークのプロセス中にMTの違反を検出・修正するための自動化メカニズムを提供したりした先行研究は存在しない。

手法
著者らは、2段階のアプローチを提案している。まず、MTを特徴付けるための実証研究を行い、続いてLiVoと名付けられた自動化ツールを開発した。

1. 修正条項（MTs）の実証的特徴付け
著者らは、Open Source Initiative (OSI) によって承認された107のライセンスに対して実証研究を行った。その結果、修正に関する特定の形式の「通知」を要求するMTを明示的に宣言している47のライセンスを特定した。これらの義務をモデル化するために、著者らは以下の3つの次元にわたってライセンスを分析した。

• 修正範囲 ($S_g$): 修正義務の対象となるファイルの種類（例：ソースコード、ドキュメント、設定ファイル、スクリプト）。これらを8つのグループに分類し、半数近いライセンス（44.7%）が「あらゆる」ファイルタイプに適用されることを示した。
• 通知内容 ($C_g$): 通知に求められる情報。これは、日付、作成者、簡潔な記述（ファイルが変更されたことを述べるもの）、および説明的な記述（どのように/なぜ変更されたかの詳細）の4つの要素に分類された。ライセンスは、これらの要件に基づき6つのカテゴリにグループ化された。
• 通知場所 ($L_g$): 通知を配置すべき場所。これは、別個の文書（例：CHANGELOG）または各修正ファイルという2つの要素に分類された。ライセンスは4つのカテゴリにグループ化された。

これらの次元に基づき、47のライセンスは、義務 $O$ を表す3つのタプル $\langle S_g, C_g, L_g \rangle$ を持つ2-タプル $\langle lic, O \rangle$ としてモデル化された。

2. LiVoのアプローチ
LiVoは、フォーク中のMT違反を検出および修正するために設計された自動化ツールである。ベースとなるリポジトリとフォークされたリポジトリを入力として受け取り、以下の3つのステップで動作する。

• ステップ1：義務的修正の検出

  • ファイルマッピング: LiVoは、ベースのリポジトリとフォークのリポジトリ間のファイルをマッピングし、再利用を特定する。ファイルの名称変更、移動、コピーが発生する場合にも対応している（JGitやSagaなどのツールを使用）。
  • ライセンス検出: Ninkaを使用して、ベースリポジトリ内の各ファイルのライセンスを検出する。
  • 義務的ファイルとコミット: 検出されたライセンスの修正範囲に含まれる「義務的ファイル」と、それらのファイルを修正したフォークリポジトリ内の「義務的コミット」を特定する。ベースリポジトリからピックアップされたコミット（既にコンプライアンスを満たしているもの）や、リバート（巻き戻し）されたコミットは除外される。

• ステップ2：通知の抽出

  • LiVoは、フォークリポジトリ内の潜在的な通知ファイル（例：CHANGELOG、RELEASE.txt）を特定する。
  • これらのファイルから「変更履歴（change logs）」を抽出する。抽出ロジックは半構造化テキストを処理し、特定の期間および作成者に関連付けられた変更ブロックを特定する。
  • 各抽出された変更履歴は、タプル $\langle msg, d_s, d_e, a \rangle$ （メッセージ、開始日、終了日、作成者）としてモデル化される。

• ステップ3：違反の検出と修正

  • マッチング: 各義務的コミットに対して、LiVoは抽出されたセット内の変更履歴との照合を試みる。
  • 類似性チェック: TF-IDFを使用して、コミットメッセージと変更履歴メッセージの間の意味的な類似性を測定する。類似度が閾値（経験的に0.3に設定）を超えている場合、内容の要件は満たされているとみなされる。
  • 属性検証: コミットの日付が変更履歴の期間内に含まれているか、およびコミットの作成者が変更履歴の作成者と一致するかを検証する。
  • 分類: コミットは以下のように分類される：
    • OB (Fully Obligated/完全履行): すべての要件を満たしている。
    • VN (Violated - Missing Notice/通知欠如による違反): 一致する変更履歴が見つからない。
    • VD (Violated - Missing Date/日付欠如による違反): 日付範囲の不一致。
    • VA (Violated - Missing Author/作成者欠如による違反): 作成者の不一致。
  • 修正: 違反がある場合、LiVoは正しいメッセージ、日付、および作成者を含む変更履歴のエントリを作成または更新し、適切な通知ファイルに書き込むことで修正を生成する。

主な結果
著者らは、178組のベースおよびフォークリポジトリのペア（GitHubのスター数が多いプロジェクトから選定）を用いてLiVoを評価した。

• 普及率: 分析されたフォークされたリポジトリの21.9%が、そのライセンスにおいてMTを要求していた。
• 違反の深刻度: 分析されたフォークされたリポジトリの51.1%がMTに違反していた。より深刻なことに、**義務的コミット（保護されたファイルを修正するコミット）の95.3%**がMTに違反していることが判明した。最も一般的な違反は通知の欠如（VN）であり、次いで日付の欠如（VD）であった。
• 精度: LiVoは、違反の検出と分類において、マクロ適合率（macro-precision）0.82、マクロ再現率（macro-recall）0.80を達成した。主なエラーの原因は、短いコミットメッセージと変更履歴のマッチングにおけるTF-IDFの意味論的な無理解であった。
• 効率性: 本ツールはリポジトリのペアあたり平均229.8秒を要し、修正検出ステップが実行時間の約92%を占めた。
• 実世界への影響: 著者らは、違反があったリポジトリに対して91件のプルリクエストを提出した。そのうち18件が肯定的な回答を得て、8件がメインブランチにマージされた。一部の開発者は、コミット履歴自体が通知を構成していると主張したり、自身がオリジナルの作成者であると主張したりして当初は抵抗したが、ツールは大多数のケースにおいて適切に問題を特定し、修正を提案することに成功した。

意義と主張
本論文は、以下の事項において初の研究であることを主張している：

1. 大規模なオープンソースライセンスの集合にわたり、修正条項を実証的に特徴付けること。
2. フォーク時のこれらの特定の条項の違反を検出し、修正するための自動化されたアプローチ（LiVo）を提案すること。

著者らは、ライセンスの特定や不整合の検出は成熟した分野であるが、「修正に関する通知を提供する」という特定の義務は見過ごされてきたことを強調している。これに対処することで、LiVoはコンプライアンス違反に関連する訴訟や金銭的損失などの法的リスクを軽減する。結論として、MTの違反は現実世界のシナリオにおいて深刻であり、自動的な検出と修正は実現可能かつ効果的であるが、偽陽性や偽陰性をさらに減らすためには、深層学習を用いた意味的マッチングなどの改善が必要であるとしている。