クローズドソースアプリケーションでGPL実行可能ファイル（ライブラリではない）を配布できますか？
GPLソフトウェアをバックグラウンドで使用するクローズドソースのデスクトップアプリケーションを作成したいと考えています。
GPLライブラリにリンクできないことを知っています（libgit.a）。しかし、GPLアプリケーション（git.exe）クローズドソースアプリケーションに入れ、GPLアプリを一時的な場所に解凍し、何らかの形式のIPC（例：コマンドライン引数））を使用してそれを呼び出しますが、これは合法ですか？
- 非GPLアプリケーションがコマンドラインでGPLアプリケーションを呼び出す->間違いなく合法
- 非GPLアプリケーションは、関数呼び出しを使用してGPLアプリケーションにリンクします->間違いなく違法です
- 非GPLアプリケーションは、コマンドラインでGPLアプリケーションをバンドル、配布、および呼び出します->？
GPLアプリケーションを配布してサイレントにするIPC呼び出しは、エンドユーザーに関する限り、機能的にリンクと同じです。GPLは、1つのプロセス内でリンクするか、 IPCリンクを行うには？GitHubのデスクトップクライアントのようなクローズドソースアプリケーションがこれを行うように見えますが、おそらくそれらがどのように機能するのか誤解しています。
注：これは、従来の意味でのライブラリへのリンクではなく、GPLapplicationの埋め込みについて質問するため、このサイトの他のGPLの質問とは異なります。答えはこのケースに固有であり、私にとって非常に役に立ちました。
注2：Modは新しい重複を検出し、今回は正しい-それは実際にこれと同じ質問をしています（詳細は少しごちゃごちゃしていますが）。ただし、最高の answer は忘却に改造されています。重要なポイントはここにコピーされます：
- VMWareサーバーの例は、オブジェクトコードをディストリビューションに含めても問題がないことを示しています。
- プログラムと一緒にインストールします
- 明らかに複合ファイルであり、広く利用可能なツール（ISOイメージ）で分解できる場合は、フッテージ内の複合ファイルにパックします。
短い答え：GPLでソフトウェアをリリースする必要はありません。 GPLソフトウェアとの相互運用性を実現していて、これによってソフトウェアが派生的な作品にならないため、それを行うことができます（ただし、安全をもっと感じたい場合は、Gitを配布しないでください） inside アプリケーションパッケージ、依存関係は問題ありません）。
Dirty workaroundライセンスの問題を回避するには：パッケージをGitから独立させ、 Source Control Integration Layer を使用している場合は、 want GPL（GitHubのソースコードを使用して！）でリリースするには、Git統合モジュールのみ（理論的には抽象化され、SCMと互換性のあるソフトウェア全体ではありません）。
この質問は以前に尋ねられたことに注意してください： 商用アプリケーションでGPLソフトウェアを使用できますか？ しかし、受け入れられた回答に完全に同意しないので、その理由を説明しようとします。 GPLは、虐待や誤用を回避するためにoverprotect自体が必要ですが、その範囲は法律によって設定されており、それらを事前評価することはできません。
長い答え：GPLについての一般的な議論ですが、両方の見方を見つけることができます（派生的な仕事かそうでないか）。私は弁護士ではありません（そしてこの issue は法廷で何度も議論されており、広く受け入れられている有名な回答を得るには不十分です）が、要約してみましょう。
GPLは、GPLに基づく派生物をデプロイする場合、ソースコードを配布するように結び付けます。まず最初に、Gitに GPLリンク例外 があるかどうかを確認します（この場合、自由に使用できます）。主なポイントは、微分作業を定義することです。彼らはこれについて何と言っていますか（FAQからの引用）？
プログラムがプラグインを動的にリンクし、プラグインが相互に関数呼び出しを行い、データ構造を共有する場合、それらは単一のプログラムを形成すると考えられ、メインプログラムとプラグインの両方の拡張として扱う必要があります。つまり、プラグインはGPLまたはGPL互換のフリーソフトウェアライセンスでリリースする必要があり、プラグインを配布する際にはGPLの条件に従う必要があります。
米国の法律の場合、微分作業は次のとおりです。
「派生著作物」とは、1つまたは複数の既存の作品に基づく作品であり、翻訳、編曲、ドラマ化、架空化、映画版、サウンドレコーディング、アートの複製、編纂、凝縮、その他の形式などがあります。作品は、リキャスト、変換、または適応される場合があります。
transformed および adapted を著作権の観点からどのように定義しますか（米国の法律）？
この以前に公開された資料により、著作物は著作権法に基づく派生著作物になります。著作権で保護されるには、二次的著作物がオリジナルと十分に異なり、「新しい作品」と見なされるか、相当量の新しい素材を含む必要があります。既存の作品に小さな変更を加えたり、小さな内容を追加したりしても、その作品は著作権目的の新しいバージョンと見なされません。
独自のアプリケーションにGPL素材を組み込む必要があります。 使用するだけでは不十分作業を derivative として定義します。あなたがそれについて考えるなら、これはかなり明白です（そして重要です！） Gitを使用してソースコードを管理する場合、アプリケーションをGPLでリリースする必要がないためです！
さらに彼らはまたそれを言います：
たとえば、タイトル、短いフレーズ、形式は著作権で保護されていません
すると、あなたは自分の作品に enough GPL素材を含める必要があることも知っています。独自のコードにコピーして貼り付けたコードスニペットは、GPLに関連付けられていません。
米国の法律とGPLは導関数について同意しているようですが、GPLの方がはるかに具体的であることに注意してください。明示的に彼らは関数呼び出しを行う[...]でデータを共有しています構造。プログラムにgit.exeを含めると、関数呼び出しは行われません。 （理論的には）GPLライセンスで完全に許可されています。
実際、彼らは後に明示的に次のように述べています：
プログラムがプラグインを動的にリンクしているが、それらの間の通信が、いくつかのオプションを指定してプラグインの「メイン」機能を呼び出し、プラグインが戻るのを待つことに限定されている場合、それは境界線の場合です。
また、それらは一般的に plugin について話すので、1つの関数だけを呼び出すダイナミックリンクライブラリにも適用できることに注意してください（IMOものみである必要があります） エクスポートされた関数）。
依存コードは派生コードではなく、相互運用性によってコードが派生作業になることはありません。同様の問題について米国の裁判所からの判決もあります： Lewis Galoob Toys、Inc. v。Nintendo of America、Inc。 。
彼らはまた言うことに注意してください：
プログラムがforkとexecを使用してプラグインを呼び出す場合、プラグインは個別のプログラムであるため、メインプログラムのライセンスではそれらの要件はありません。
デプロイメント方法（単一のパッケージまたは依存関係）についての言及はありません。
疑わしいGPLライセンスによると、米国の法律によると、 incorporate GPLマテリアルをGPLライセンスに関連付ける必要があります。問題なく実行できますが、安全にしたい場合は、 dependency （パッケージまたは必須の前提条件）、
これらすべてのハード推論を考えると：
非GPLアプリケーションがコマンドラインでGPLアプリケーションを呼び出す->間違いなく合法
はい、コードとGitの間の connection がユーザーのコンピューターで行われる場合、GPLによる制限は一切受けません。
非GPLアプリケーションは、関数呼び出しを使用してGPLアプリケーションにリンクします->間違いなく違法です
そうでないかもしれない。 main プラグイン関数を1つだけ呼び出すと、GPLの精神に反するため、IMOを避けるべき境界線のケースになる可能性があります。気に入らない場合は使用しないでください。
非GPLアプリケーションは、コマンドラインでGPLアプリケーションをバンドル、配布、および呼び出します->？
法的で依存するコードは派生コードではなく、相互運用性によってコードが派生作品になることはありません。さらに、fork/execを使用する場合、それは派生的な作業または組み合わせた作業ではないことを明示的に述べています（展開に関する言及なし）。
スコットのリンクa lawyer は、この問題をより深い知識とより良い表現で説明しています。その記事からの一節を強調したいと思います（強調は私のものです）：
「この一般公衆利用許諾契約書では、プログラムを所有権のあるプログラムに組み込むことは許可されていません」という表現は、「契約条件の終了」ステートメントの後に続きます。ライセンス自体の一部ではありません。いずれの場合も、ステートメントはライセンスのテキストではサポートされていません。 GPLは、プロプライエタリプログラムの組み込みを禁止していません。 せいぜい、それはプロプライエタリなプログラムがGPLの継承義務に従うことを要求します。
また、 dirty workaround を読み直してください。 safe を感じたい場合は、最初に提案しました。
答え Andriano Repetti はおそらく正しいですが、弁護士に尋ねる必要があります（そして私も弁護士ではありません）、またはおそらくFSFまたはgitsoftwareの著作権者。
一部の人々は、特定のGPLソフトウェアを適応させた場合（およびGPLの下で適応したソースコードを公開した場合でも）、特定のad-hoc、プロトコル（パイプ上のJSONRPCなど）は合法ではありません（AFAIU）。この場合、コードはその派生物です。同じソフトウェアがフリーソフトウェアを含む複数のアプリケーションで使用されている場合、状況はしばしば異なります。
重要なのは、リンクまたは派生著作物は、開発者にとって弁護士や裁判官にとって異なる意味を持つということです。一部の国では、あなたの意図も重要です！
しかし私は弁護士ではありませんであり、あなたは本当に弁護士に尋ねるべきです。また、礼儀としてフリーソフトウェアの作者に尋ねたり、FSF（またはヨーロッパではFSFE、フランスではAPRILまたはAFUL）に尋ねることもできます。
ところで、アプリケーション内にgitの実行可能ファイルを圧縮ファイルに埋め込むことは、ユーザーが[簡単にgitをgitの独自の更新または改善されたバージョンに置き換えることができないため、GPLの精神に反します。ただし、git.exe（おそらくそのgitのソースtarボールを使用して）、インストールする必要があること（および場所と方法）をユーザーに伝えます。彼がgitをアップグレードしたい場合は、簡単にアップグレードできるはずです（その方法を教えてください）。そのような実行可能な埋め込みが合法であっても（そうでないといいのですが）、それを行うことは確かにユーザーにとって不親切です。 gitを使用している場合は、少なくともgitのバージョン範囲と、gitバイナリをアップグレードする方法をユーザーに説明する必要があります。
（ [〜＃〜] melt [〜＃〜] などのGCCプラグインに関する説明とGCCランタイムライセンスの例外およびそれに関する議論が関連する場合があります）
フリーソフトウェアライセンスを使用してソフトウェアを公開することを検討してください。それはより賢明で、あなたにかかる費用が少ないかもしれません。そして、あなたは外部の貢献とフィードバックを得ることができます。