プラグインを介してクローズソースアプリケーションでGPLコードを使用するのは合法ですか? [閉まっている]
-
02-07-2019 - |
質問
次の手順を検討してください:
0)特定のインターフェース(I)で通信し、複雑なデータ構造を交換し、メモリを共有し、相互に呼び出す、オープンソースのMockプログラムとMockプラグインをリリースします。すべて許可されたライセンスを適用します。
1)インターフェイス(I)で定義された方法でプログラムを操作するために設計されたリリースプラグイン。このプラグインは、サードパーティのGPLカバーコードを使用するため、GPL自体も同様です。元々はMock Programで開発およびテストされています。ソースコードが利用可能なGPLプログラムとして配布されます。
2)インターフェース(I)で定義された方法で任意のプラグインと通信するように設計されたクローズドソースの専有プログラムをリリースします。もともとは、Mockプラグインで開発、テスト、および出荷されています。
3.1)GPLプラグインをダウンロードしてインストール済みプログラムに添付するインストールスクリプトをプログラムに追加します。
3.2)インストールスクリプトの代わりに、GPLプラグインを手動でダウンロードして添付する方法の説明を追加します。
エンドユーザーは、プラグインのGPLでカバーされたコードの恩恵を受ける独自のプログラムを取得します。
質問:
0)それが合法である場合、それは開発者の少しの労力でプロプライエタリなプログラムでGPLでカバーされたコードの利益を得る合法的な方法ではありませんか?
1)それが合法でない場合、GPLv *のどの部分が、誰がどのステップを実行するのを妨げますか?
2)3.1と3.2の間に法的な違いはありますか?
3)モックプログラムとプラグイン、プロプライエタリプログラムとGPLプラグインが一人または別の人によって開発された場合、法的な違いはありますか。意図的かどうか?
4)あなたの意見は何ですか-それは十分に倫理的ですか?
5)そのような戦略の既存のサンプルはありますか?
6)同じ結果を達成するためのより簡単な合法的な方法はありますか?GPLコードの恩恵を受ける可能性が高いと思われる独自のプログラムをリリースしますか?
更新:
文字通り、これは、クローズドソースプログラム用のプラグインを作成してGPLでリリースすると、その組み合わせがプラグインの拡張になるため、GPLの対象になり、クローズドソースプログラムも
ただし、その組み合わせは配布されず、エンドユーザーのマシンで結合されます。 Linuxを自分で修正したように、出荷するまでオープンソースにする必要はありません。この場合、エンドユーザーはプログラムのソースにアクセスせずに変更を加えることができました-彼にとっては良いことですが、これまでのところ違法なことはありません。
GPLでカバーされたプラグインを使用するには、GPLの下でメインプログラムをリリースする必要があります
GPLのよくある質問の一部を見ました。ただし、プラグインは独立して開発し、MockProramに同梱して出荷できます。そして、エンドユーザーがMockProgramからプラグインを取得して独自のプログラムに入れることができるようになりました。その最終ステップまで、GPLとクローズドソースは分離されています。そして、そのステップはエンドユーザーによって行われます。エンドユーザーは、結合された製品を配布しないため、義務はありません。
UPDATE 2
これ
一方が他方を要求するように特別に設計されていると裁判所が判断した場合、トラブルが発生する可能性があります。 Mock ProgramとMock Pluginの性質は、それらが「本物」であるかどうかに関しても役割を果たす可能性があります。プログラムまたはバカ。弁護士に相談してください。
質問3の回答のように見えます。ありがとう。
解決
これは間違いなく倫理的ではありません。たとえばBSDの代わりにGPLを選択すると、私の意図は明確になります。もしあなたが私のコードから利益を得るなら、あなたは貢献するべきです。そして、私のコードを使用しているCOMPLETEシステムへの完全なアクセスを提供することにより、あなたがどのように貢献することを期待するかは非常に明確です。 GPLの中核にある意図は、他の誰かがそのようなシステムに変更を加え、そこから他のものを構築できるようにすることです。
ステップ3.1 / 3.2では、社会学的問題があります。システムの動作が停止したときに、ユーザーは誰に尋ねますか特に問題がGPLプラグインにある場合、GPLプラグインの作成者はそのようなユーザーをサポートしますか? GPLプラグイン開発者は、非倫理的なクローズドソースアプリケーション開発者を楽しませますか?
上記のことを考えると、誰もあなたの質問4、5&を試みません。気付くのに十分な規模の6。また、多くのお金を稼ぐ商用アプリケーションを作成している場合、通常、そのGPLコードをプロジェクトで使用するために著作権所有者からライセンスを取得できます。
質問3に答えるために、もしあなたがGPLコードの唯一の著者であるなら、あなたはそのコードの完全な著作権を持っています。他の人が使用できるようにGPLの下でリリースしていても、GPL以外のプロジェクトで使用するなど、何でも好きなことができます。
他のヒント
これは技術的な質問ではなく、法的質問です。お住まいの地域での実践を許可された弁護士に依頼してください。
プログラムが動的にリンクする場合 プラグイン、およびそれらは関数呼び出しを行います お互いにデータを共有する 構造、それらが形成すると信じています 処理する必要のある単一のプログラム 両方のメインの拡張として プログラムとプラグイン。のために GPLでカバーされたプラグインを使用して、メイン プログラムはGPLの下でリリースする必要があります またはGPL互換のフリーソフトウェア ライセンス、およびGPLの条件 メインプログラムが これらで使用するために配布されます プラグイン。
“対応するソース”オブジェクトコード形式の作業の場合、オブジェクトコードを生成、インストール、および(実行可能な作業の場合)実行し、それらのアクティビティを制御するスクリプトを含む作業を変更するために必要なすべてのソースコードを意味します。ただし、作品のシステムライブラリ、汎用ツール、またはこれらのアクティビティの実行に変更なしで使用されるが作品の一部ではない一般に利用可能な無料プログラムは含まれません。たとえば、Corresponding Sourceには、作品のソースファイルに関連付けられたインターフェイス定義ファイル、および共有ライブラリのソースコード、および親密なデータ通信などによって作品が必要とするように特別に設計された動的にリンクされたサブプログラムが含まれますまたはそれらのサブプログラムと作業の他の部分との間のフローを制御します。
一方が他方を要求するように特別に設計されていると裁判所が判断した場合、トラブルが発生する可能性があります。 Mock ProgramとMock Pluginの性質は、それらが「本物」であるかどうかに関しても役割を果たす可能性があります。プログラムまたはバカ。弁護士に相談してください。
実際にプログラムをリンクしていなければ、できるかもしれません。それらを別々のプロセスにし、ソケットまたは名前付きパイプなどで通信します。
しかし、本当に、最初のポスターに同意します。 GPL以外のプロジェクトでGPLコードを使用する場合、いくつかの適切なオプションがあります。
- この種の問題に精通した弁護士に相談する
- GPLとしてプロジェクト全体にコードをリリースします
- その場所ではGPLコードを使用しないでください
- GPLコードの作成者に連絡し、コードを使用する自由に対する制限が少ないライセンスと引き換えに報酬を提供します。
こちらでよく似た質問をしましたが、開始点からは元の製品を最初からオープンソースにすることを検討しているため、後で販売することができます。
GPLが正しいと言っているわけではありません-私が本当に反対するいくつかの領域(そして、私は本当に理解していない!)がありますが、少なくとも正しい方向への一歩です。
実際には1つの質問に帰着すると思います:-
- あなたのソフトウェアはGPLされたコードが機能するように必要にします。
答えが「はい」の場合、受け入れて先に進みます。 (私の場合のように)答えがノーの場合、これまでのコンセンサスは、GPLについて心配する必要がないということです。