web-dev-qa-db-ja.com

Gitサブモジュールのライセンスに問題はありますか？

たとえば、MITライセンスのプロジェクトでは、GNUツールチェーン（もちろんGPLです））の一部をサブモジュールとして含めることで、ユーザーのビルドプロセスを簡略化したいと考えています。

  • MITプロジェクトをGNUツールチェーンの「派生作品」にすることと解釈できますか？
  • プロジェクトをGitサブモジュール（またはいくつかの同様のメカニズム-おそらくそれをダウンロードするBashスクリプトだけ）として含めることは、そのプロジェクトを「再配布」することとしてカウントされますか？
  • Makefileがサブプロジェクトもビルドした場合はどうなりますか？

私の意見では（そしておそらくほとんどの人の意見では）、これらの質問に対する答えは明らかに「ノー」です。私は、著作権法の私たち自身の解釈について議論するよりも、この問題を取り巻く先例や規範を聞くことに興味があります。互換性のないライセンスの下にサブモジュールがあるオープンソースプロジェクトを知っていますか？故意にそれらを避けた人、そしてなぜ彼らがそうしたのを知っていますか？

単にGit以外の人々を明確にするために：サブモジュールは実際のコンテンツを含ませず、別のリポジトリへの「ポインタ」のようなものです。私が挙げた例では、MITプロジェクトを複製してgit submodule init、GitはGNUコードをGNUリポジトリから自動的にダウンロードします。

licensingversion-controlgit
7
Brendan

Android Open Source Projectほとんどexactlyは、私の例で使用したケースを反映しています。ソースの大部分は Apacheライセンス ですが、Gitサブモジュールと同等のメカニズムを使用して GNUツールチェーン を提供します。

2
Brendan

Git-submodules自体に重要な法的資料が見つかるのではないかと思います。 1つの角度は、より大きなコミュニティ/より長い歴史/より多くの先例を持つ別のシステムに類推することです。そのために、「gitサブモジュール」を定義しましょう-実際には、次の2つです。

  1. 他のソフトウェアパッケージの名前/アドレスをリストするファイル形式（ ".gitmodules"）。 （簡潔にするために、これらのファイルを「マニフェスト」と呼びましょう。）
  2. ファイル形式を読み取ってソフトウェアをダウンロードするツール。

次に、これらの基準を満たす別のプロジェクトを選択しましょう。たとえば、Debianのパッケージマネージャーは次の両方を提供します。

  1. 他のソフトウェアパッケージの名前/アドレスをリストするファイル形式。 （簡潔にするために、これらのファイルを「マニフェスト」と呼びましょう。）
  2. ファイル形式を読み取ってソフトウェアをダウンロードするツール。

（パフォーマンス上の理由から、Debianのパッケージマネージャーのファイル形式ははるかに複雑/微妙です。これは、典型的なDebianデプロイメントが数千のサーバーに分散された数千のパッケージで機能するためです。一方、一般的なgit-submodulesデプロイメントはおそらく数十のパッケージと少数のサーバー。dpkg/ aptの初期の履歴を確認すると、パフォーマンスが設計上の中心的な問題であり、大きな成果であったことがわかります。ただし、一般的な「情報」レベルでは、形式は似ています。 ）

Debianプロジェクトは、FOSSコミュニティ内で、debian-legalが特に​​長い歴史を持ち、ソフトウェアの混合から生じるライセンス問題を評価することで高い評価を得ているため、特に有用な例です。

それで、Debianプロジェクトを見ると、互換性のないライセンスを持つパッケージを参照するマニフェストを公開していることがわかりますか？はい。たとえば、PHP4はFSFがGPLと互換性がないと判断する「PHPライセンス」の下でライセンスされました（ https://www.gnu.org/licenses/license-list.html ）。ここにマニフェストがあります：

http://archive.debian.org/debian/pool/main/p/php4/php4_4.0.3pl1-0potato3.dsc

これは「バイソン」に「ビルド依存」があることに注意してください。バイソンはGPLの下でFSFによってライセンスされたツールです。

ユーザーが「apt-build install php4」と入力すると、結果として「php4」と「bison」がダウンロードされ、両方が同じコンピューター/ファイルシステムにロードされます。 GPLに違反していますか？いいえ、どうしてですか。これらのポイントのいずれかは、個別に説得力がある必要があります。

  1. パッケージの組み合わせは、Debianのプロセスを通じて承認されています。
  2. ソフトウェアをダウンロードしただけで、ソフトウェアの変更や再配布は行っていません。 GPLでは、これは大きな違いです。
  3. GPLは、変更/派生を単なる集約から明確に区別し、単なる集約の下でのウイルス性を否認します。
  4. マニフェストはbisonを「Depends」ではなく「Build-depends」として示しています-つまり、bisonはphp4の処理に役立つビルドツールです（テキストエディターのように）。 php4にはバイソンコードは含まれていません（リンクもされていません）。実行時には、bisonを実行せずにphp4を実行できます。

ここでDebianのパッケージマネージャをgit-submodulesと交換した場合、突然「OK」から「violation」に変わりますか？いいえ、それはばかげています-同じコードの組み合わせと同じライセンスの組み合わせと同じコンパイル手順です。変更されたのはダウンロードツールだけです。

（注：これは、特定の依存関係を持つgit-submodulesの特定の使用法が受け入れ可能または受け入れられないことを意味するものではありません。Debianからの例では、いくつかの重要な要素が特定のライセンスとパッケージに固有でした。なんでも。）

6
Tim Otten