アプリケーションでGPL、LGPL、MPLライセンスパッケージを使用して、クローズドソースにすることはできますか？

会社がBusyBoxを使用し、Gpl + Lgpl + Mplパッケージを使用しているのを見ました。そして、彼らはそこで実行されている独自のアプリケーションを持っています。彼らのアプリケーションはクローズドソースパッケージです。

デバイスを購入しますが、そのソースはクローズドです。GPLとLGPL + MPLの混合がクローズドソースになるのはなぜですか？

ルールだと思った？または私が間違っているか、この次の情報が間違っていますか？：

GPL：アプリケーションで使用する場合は、GPLの下でアプリケーションをリリースする必要があります。Linux CDを販売するように販売できないというわけではありませんが、ソースコードも無料でリリースする必要があります。それはあなたのために働くかもしれませんが、おそらくそうではありません。

LGPL：アプリケーションで使用する場合、クローズドソースのプロプライエタリライセンスアプリケーションを使用できます。ただし、LGPLライブラリを変更する場合は、アプリケーションがクローズドソースのままであっても、LGPLで変更をリリースする必要があります。

GPL FAQによると、クローズドソースおよびオープンソースのソフトウェアの「集合体」を販売することはまったく問題ありません。同社がLinuxをコンパイルし、LGPLライブラリのみを使用してその上に独自のプログラムを構築し、その製品をすべてのGPL / LGPLソースを公開しながら販売した場合、それらはGPLに違反していません。

ここでのポイントは次のとおりです。GPLは、同じコンピューターで実行され、クローズドソースプログラムと通信/対話するだけのプログラムには拡張されません。BusyBoxのようなオープンソースのウィンドウマネージャーは、もちろん、クローズドソースのウィンドウを管理できます。経験則として、GPLはライセンスされたコードのアドレス空間まで到達します。

IANAL、しかしこれは私が学んだことです。私はそれのいずれかが間違っているかどうかを知ることに非常に興味があります：

LGPL：静的にリンクする場合アプリケーション内で、コンパイル済みアプリケーションを配布する場合、GPLの下でソースをbinaryを受信するすべてのユーザーにリリースする必要があります。

GPLはクローズドソースと互換性がありません。GPLライセンスのパッケージ/モジュールを使用してソースを閉じた場合、一般的な場合、GPL条件に違反することになります。

明確なケースがあり、それからいくつかの泥だらけのケースがあります。そのため、弁護士があなたがケースを提示するというより多くの意見を得るでしょう。

あなたのルールは私の理解と一致しますが、変化するのは「使用」の正確な定義です。ライセンスの基礎となる著作権システムは「使用」ではなく「派生作品の作成」に関するものであり、さまざまなプログラムで作られたシステムはさまざまなプログラムが十分に結び付けられているため、システム全体はそれらのいずれかの派生物ですが、ライブラリに動的にリンクされた別の単一プログラムは、ライブラリが明確に定義されたプロトコルを実装し、置き換えられる可能性があるため、ライブラリの派生物ではありません単純なGPL化されたラッパーを使用して、アプリケーションが提供するインターフェイスに一致させる方法）。弁護士にあなたのケースに特有のアドバイスを求めてください。裁判官の前で、著作権者の誰かがいない場合

^{（この回答はこの質問を意図したものではありませんが、についてのより具体的なものgitであり、この質問が実際に許すよりも詳細に特定のケースをカバーしています。詳細については、コメント599873を参照してください。問題が解決するまで。）}

• GitはGPLv2でカバーされていますます。
• 一般に、FSFのライセンスに関して質問がある場合、その方法は次のとおりです。
  • ライセンス自体（ドアストッパーではありませんでは非常にわかりやすいものです。学習に費やした時間は10倍になります。）
    • ただし、GPLv2では（v3とは対照的に）、米国の法律からいくつかの用語が採用されているため、本文では定義されていません。（実際、彼らは異なる管轄区域でわずかに異なることを意味することが判明しましたが、FSFはこれを深刻な問題であると報告しませんでした）
  • ライセンスに関するFSF FAQ、特にGPLv2に関するFAQ、
  • FSF機能を含む、ウェブ上のその他の関連資料。しかし、彼らの権威に注意してください
  • 最後の手段（弁護士なし）として、FSF自体（もちろん法律事務所ではないため、司法権に関係なく一般的な解説のみを提供します-リクエストを自由に無視できます）。他の場所ではまだ回答されていない合理的な問い合わせには回答しますが、しばらく時間がかかります）。

• あなたの場合、関連資料は次のとおりです。
  • GPLv2＃section2：

    b）配布または公開する作品、全体または一部にプログラムまたはその一部が含まれる、またはその一部である作品は、本ライセンスの条件に基づいて、すべての第三者に無償でライセンス供与される必要があります。
    <...>
    これらの要件は、変更された作品全体に適用されます。その作品の識別可能なセクションがプログラムから派生せず、それ自体が独立した別個の作品であると合理的に考えることができる場合、本ライセンスおよびその条件は、それらを別個の作品として配布する場合、それらのセクションには適用されません。ただし、プログラムに基づく作品である全体の一部として同じセクションを配布する場合、全体の配布はこのライセンスの条件に従う必要があります。他のライセンシーに対する許可は全体に適用されるため、それぞれに適用されます。誰がそれを書いたかに関係なく、すべての部分。
    
    したがって、このセクションの目的は、権利を主張したり、完全にあなたが書いた作品に対するあなたの権利に異議を唱えることではありません。むしろ、その意図は、プログラムに基づいて派生物または集合作品の配布を管理する権利を行使することです。
    
    さらに、プログラムに基づいていない別の作品とプログラム（またはプログラムに基づいた作品）をストレージまたは配布媒体のボリュームに単に集約しても、他の作品はこのライセンスの範囲に含まれません。

  • GPLv2 FAQ #NFUseGPLPlugins：

    プログラムがプラグインを呼び出す方法に依存します。プログラムがforkとexecを使用してプラグインを呼び出す場合、プラグインは別個のプログラムであるため、プラグインのライセンスはメインプログラムに関する要件を作成しません。

そのため、作品を「含む」gitことはできませんが、作品が使用する別個のエンティティとして含めることはできます。VMWareの例では、後者にはディストリビューションまたはディストリビューション内の複合ファイル（以前のISOイメージ）にパッケージ化されていることが示されています。

違いは何ですか？結論を出すまでに時間がかかりました。最後に、段落が「それは請求権に...意図はない...むしろ...プログラムに基づく派生物または集合著作物の分布を制御する」ことを私に確信させた作品であれば区別があります著作権法に基づくGPLの一部の派生物と見なされます。 この最後のものでは、GPLはあなたを助けることができません- あなたは適用可能な著作権法を調べるか、他の足跡をたどる必要があります。

• 具体的には、VMWareサーバーの例は、オブジェクトコードをディストリビューションに含めても問題ないことを示しています。
  • プログラムと一緒にインストールしてください
  • 明らかに複合ファイルであり、広く利用可能なツール（ISOイメージ）で分解できる場合は、フッテージ内の複合ファイルにパックします。
• ただし、インストーラー内でソースを配布することはできません-ユーザーもそれを分解することに問題がない限り