私はソフトウェアの記事で古いJoelのいくつかを読んでいて、 Project Aardvarkの仕様に出くわしました。ある特定のセクションが、私の目に留まりました。
ライセンス
VNCはGPLです。VNCに基づいて構築している2つのコンポーネント、ヘルパーと犠牲者は、GPLの下で再リリースする必要があります。
これはそれほど大したことではありません。コードは私たち自身の使用のために高度に最適化され、リフレクターが機能する必要がありますが、GPLではリリースされません。
GPLがこの種のことを正確に許可していないことをどこかで読んだと確信しているので、これは私を驚かせましたか？
それはリフレクターと他のすべてとの関係に依存します、そして私はプロジェクトについて何も知らないのでそれについてコメントすることはできません。
GPLは著作権法に依存しています。著作権法で許可されていることをしている場合は、GPLに注意を払う必要はありません。したがって、GPLはGPLされたソフトウェアの派生物に適用されますが、ソフトウェアを分離することはありません。何がデリバティブと見なされ、何が分離するかについてはいくつかの議論がありますが、私は弁護士ではなく、立場もありません。
明らかなことの1つは、プログラムがGPLされたプログラムにリンクしていないが、そのプログラムの横にあり、標準のプロセス間通信を介して通信する場合、それは独自の別個の作業であり、GPLの対象ではないということです。
したがって、リフレクターがリンクされている場合、GPLの対象となります。独自の別個のプロセスとして実行される場合、そうではありません。
依存関係がクローズドソースであるGPLソフトウェアはたくさんあります。たとえば、Windowsで実行されているすべてのGPLソフトウェア（つまり、Windows API DLLのリンク）について考えてみます。
したがって、はい、クローズドソースの依存関係を使用することが許可されています。それにもかかわらず、Davidが指摘しているように（コメントに感謝します）、システムライブラリと他の依存関係には違いがあります。GPLは次のように述べています（私が強調しています）：
オブジェクトコード形式の作業の「対応するソース」とは、オブジェクトコードを生成、インストール、および（実行可能な作業の場合）実行し、それらのアクティビティを制御するスクリプトを含む、作業を変更するために必要なすべてのソースコードを意味します。ただし、これらのアクティビティの実行に変更されずに使用されるが、作業の一部ではない、作業のシステムライブラリ、汎用ツール、または一般に利用可能な無料のプログラムは含まれません。たとえば、対応するソースには、作業のソースファイルに関連付けられたインターフェイス定義ファイル、共有ライブラリのソースコード、および作業が必要とするように特別に設計された動的にリンクされたサブプログラムが含まれます。仕事の他の部分。
つまり、この「リフレクター」が「汎用ツール」として数えられるかどうかということになると思います。それがGPLされたソフトウェアに含めることだけを目的として書かれたのであれば、これはノーだと思います。VNCから派生したソフトウェア製品がなくても有用な目的を果たす場合は、「はい」の可能性があります。
http://www.gnu.org/licenses/gpl-faq.html
標準のIANAL免責事項。GPLは著作権法に基づいて施行されているため、そのバイラル条項は、二次的著作物を作成している場合にのみ適用されます。ソースコードをGPLされたプログラムに変更することは、二次的著作物を作ることとして数えられます。静的リンクも同様です。ダイナミックリンクについては議論の余地があります。単にGPLのプログラムを呼び出したり、腕の長さでプログラムと通信したりするだけでは、間違いなくそうではありません。肝心なのは、この場合の「依存関係」の意味に本当に依存するということです。
まず、私を含め、インターネット上の人々から得た法的アドバイスに基づいてビジネス上の決定を下さないでください。
これは、GNUライセンスに関するよくある質問で対処されていると思います。フリーでないライブラリを使用するフリーソフトウェアを作成できますか？
互換性のないライセンスを使用するライブラリとGPLコードを組み合わせることに制限はないようですが、完全に無料のソフトウェアを使用するインセンティブを説明するために最善を尽くしています。