web-dev-qa-db-ja.com

独自のアプリケーションをGPLソフトウェアと一緒に配布する

最初に、ここには同様の質問がたくさんありますが、この固有のシナリオについて直接的な回答があったものは見つかりませんでした。重複が見つかった場合は、具体的な回答にリンクしてください。また、質問が広すぎるのを避けるために、この特定のシナリオのみを検討してください。

LGPLライブラリを動的にリンクし、GPLライブラリをリンクしない独自のLinuxアプリケーションを想定します。また、GPL化されたバイナリをファイルシステムから標準のOS APIを介して実行し、いくつかのアクションを実行します。

次に、目に見える商標ロゴなどが削除された、カスタマイズされた主流のLinuxディストリビューションを想定します。

次に、ハードウェアを含む自己完結型製品を想定します。たとえば、このカスタマイズされたOSを備えた起動可能なSDカードを備えたRaspberry Piがあるとします。次に、独自のソフトウェアがあり、デバイスのスイッチがオンになったときに起動する必要があります。

この組み合わせを合法的に配布する方法？

より具体的には、（少なくとも）3つの個別の懸念事項があります。

  1. 一般に、カスタマイズされたLinuxディストリビューションのみを合法的に配布する方法は？たとえば、使用されているすべてのデフォルトソースをダウンロードするためのツール、またはどのディストリビューションにツールがあるかパッケージ、配布に含める準備ができているか、ローカルでアーカイブされていますか？

    主流のLinuxディストリビューションの派生物を配布する場合、デフォルトのパッケージのソースを自分で配布する必要はない、または誰かが要求した場合はディストリビューションのソースリポジトリをポイントするだけでよいと考えることもあると思いますが、私はこれがGPLの義務を果たすための法的に有効な方法かどうかはわかりません。

  2. プロプライエタリソフトウェアをディストリビューションに合法的に含めるにはどうすればよいですか？たとえば、プロプライエタリソフトウェアを上記のSDにインストールしておいても大丈夫ですか？同じメディアからアンインストールして、最初の起動時にユーザーにインストールを要求することは問題ありませんか？別のメディアで入手するか、ネットからダウンロードしてインストールする必要がありますか？ 「まあまあ」と「まあまあ」の限界は何ですか？コンセンサスや法的先例さえありますか？

  3. プロプライエタリなアプリケーションからハードコードされたコマンド文字列を使用してGPLプログラムを実行しても問題ありませんか？私の理解では、これは問題なく、派生作業を作成しません。しかし、これが問題である場合、LGPLライセンスのラッパーを作成するのと同じくらい簡単に回避できますか？または、コマンドを変更可能な構成ファイルに含めるだけですか（ライセンスの問題に関係なく、とにかく良いアイデアです）。

注：最初の箇条書きの技術的な側面を除いて、私はここでの回答はいかなる種類の弁護士でもないことを理解していますが、回答は何らかの形でバックアップする必要があります。このサイトは世論調査用ではありません。

licensinggpllinuxclosed-source
6
hyde

だから、いくつかの研究の後、ここに私自身の答えがあります。法的助言ではなく、素人のアドバイスとしても、私はこの問題の専門家ではありません。

  1. 販売する製品を作成する場合は、安全にプレイすることをお勧めします。インストールされているすべてのパッケージのすべてのソースパッケージをダウンロードするのは非常に簡単で、現在のストレージ容量ではスペースをほとんど必要としないため、ダウンロードしない理由はありません。このようなシェルスクリプトはそれを行うはずです。Debianベースのディストリビューションのコマンド例、テストされていないスクリプト：

    # use dpkg to get list of current packages,
# then download source package for each using apt-get
for pkg in $(dpkg --get-selections) ; do
    apt-get source --download-only $pkg
done

    これは、ソースの正しいバージョンを入手するために、物理的に分散されたリリースごとに行う必要があります。一度セットアップした後はそれほどの労力ではなく、費用もごくわずかなので、なぜそれほど安く済むのでしょう...オンラインリリースをローリングするには、ソースパッケージを含む適切なパッケージリポジトリを用意するなど、別のアプローチが適切な場合があります。

  2. および3. FSF GPL FAQの以下のエントリでカバーされています。

    基本的に、私がこれらを理解している限り、製品にGPL/LGPLパーツがあることが明確である限り、ユーザーがGPLパーツを変更できないようにしようとせず（ "tivoization"）、GPLプログラムにアクセスするには、実行パラメータやパイプなど、通常betweenプログラム間で使用されるインターフェイスは問題ありません。

    さらに、これらのFAQエントリは、GPLの作成者によって記述され、ライセンステキストの意図を説明しているため、ほとんどの管轄区域の法廷で重要な役割を果たす可能性があります。裁判の結論は、GPLとLGPLの解釈に関する意見の相違に要約されます。

免責事項を繰り返します。私は弁護士ではなく、この分野の素人でもありません。

6
hyde

  1. 私が正しくGPLを読んだ場合、それはインターネットのダウンロードでのみ許可されており、バイナリをそのまま使用した場合に限ります。そうでなければ、どこかにソースのコピーが必要です。すべてのディストリビューションにはソースのアーカイブがありますが、すべてのバージョンが含まれています。配布するバージョンに対応するバージョンを選択する必要があります。また、すべてのパッケージを配布することはおそらくないでしょう。最近の配布は巨大です。

  2. すべて大丈夫です。例えば。 AndroidデバイスにはGPL Linuxと所有権アプリケーションがプリインストールされており、誰も問題を抱えていません。それらは別のプログラムでなければなりません。

  3. 大丈夫です。彼らはまだ別のプログラムです。大丈夫ではないことについては、LGPLラッパーはあなたを助けません。なぜなら、それは他のライセンスの下のコードが許可されている場合に限って許可されるからです。

2
Jan Hudec