web-dev-qa-db-ja.com

トライアルウェアでオープンソースライブラリを使用できますか?

私は自分のウェブサイトで配布したい小さなJavaプログラムを書きました。次のライセンスを宣言するいくつかの外部ライブラリを使用しました:Apache License(2.0)、LGPL、そして1つのAPIはライセンスを宣言しないでください。ただし、オープンソースです。

私は自分のプログラムの開発に多くの時間と労力を費やしてきました。だからこそ、寄付者だけが(寄付の多かれ少なかれ)最大限に活用できるようにソフトウェアを配布することを考えました。非寄付者は時々ナグ画面を表示し、寄付を提案します。同時にダウンロードするのではなく、一度に1つのファイルしかダウンロードできません。 (ええ、私のプログラムはいくつかのダウンロードを行います)

法的な問題を起こさずにそれを行うことはできますか?プロジェクトの完全なソースを配布したいのですが、シリアルnrチェックでパーツを削除してソフトウェアを再配布するだけなので、寄付者以外の機能の制限が役に立たなくなります。

どのライセンスでプログラムを配布する必要がありますか?

6
user778440

まず第一に:あなたはあなたの「コスチューム」を嘘をつくべきではありません。寄付者だけがすべての機能を使用できる場合、それは寄付ではなく、通常の支払いです。

LGPLは、フリーでないアプリケーションでの使用を厳密に許可しています。Apacheライセンスはわかりません。少なくとも、APIライセンスをクリアする必要があります。 「そのオープンソース」と言っても、それを使って何ができるかはわかりません。メンテナにメールして聞いてください。

もちろん、私はあなたのアプリケーションを知りません。たぶん、それをいくつかの部分に分割することができます。1つはOSSライセンスの下で公開され、もう1つは有料のものです。

7
KingCrunch

法的な問題を起こさずにそれを行うことはできますか?

確かに、オープンソースは無料という意味ではありません(多くの場合そうですが)。

しかし、GPLライセンスを使用することはできますできません。平均的なシェアウェアライセンスを使用するだけです。

http://en.wikipedia.org/wiki/Donationware#Notable_examples

2
Hovertruck

LGPLで編集されたライブラリに動的にリンクしている限り、プログラムで何でもできますalmoust 、それを売るか、それにしつこいスクリーンを置くことを含みます。 Apacheライセンスは、LGPLよりもはるかに厳格ではありません。 LGPL-ed APIに静的にリンクする場合でも、それを配布できますが、ソースコードを使用する必要があります。ソフトウェアを購入する人にソースを提供する必要があります。したがって、ソースなしでプログラムをだれにも渡すことはできません。したがって、しつこい画面は意味がありません。プログラムを取り出して再コンパイルできます。これの良い例はFlowPlayerです。

独自のルールを使用したい場合は、新しいライセンスを作成することをお勧めします。

EDIT:Javaの場合、静的または動的なリンクなどはありません。すべてがある程度動的にリンクされますが、完全にはリンクされません。 。ライセンスの作成者であるDaveTurner said として、Java( 'import'キーワードの使用)で使用されるリンク方法は、のセクション6に該当します。 license 。これは、使用したライブラリのバージョンを変更する方法をユーザーに提供し、変更をデバッグするためにリバースエンジニアリングする必要があることを意味します。したがって、ソースを提供する必要はありません。プログラムの内部について説明する必要もありませんが、ユーザーがそれをリバースエンジニアリングすることを拒否することはできません(これはほとんどの独自ライセンスと矛盾します)。ライブラリのソースを提供する必要があります。したがって、基本的にプログラムをプログラマー以外の人、またはプログラムを逆コンパイルしてしつこいものを取り除くほど賢くない人。

よくわかりませんが、他の人もあなたのプログラムの修正バージョンを公開できると思います。たとえば、コーダーはあなたの限定バージョンを取得し、逆コンパイルし、すべての制限を削除し、コンパイルして、あなたの作品を公開します。誰もそれを気にしないという考えに騙されないでください、私はこのようなことをしました(私はLGPL-edプログラムを変更して再公開したので、私はそのようなことを書きました) 。お金があれば、人々は十分遠くまで行くことができます。

リバースエンジニアリングされた場合にコードのどの部分を変更できないかを指定できる独自のライセンスを作成することもできます(例:ユーザーは製品をリバースエンジニアリングできますが、セクションを変更することはできません*ここにマークを挿入*)でマークされたコードでは、このようにブロックして、しつこい/制限を取り除きます。

簡単な答えは、細字部分を確認することです。ライセンスを使用する場合は、コードをオープンソースにする必要があると主張するライセンスがあります。

これが当てはまらない限り、あなたは情報源を提供する義務も、無料で提供する義務もありません。

0
BugFinder

これらの2つのライセンスdoを使用すると、ほぼすべてのライセンスで派生アプリケーションを再配布できますが、同時に、これらのライセンスの条件を尊重する必要があります。

つまり、LGPLライセンスのある作品の場合、ソースコード全体を利用できるようにする必要がありますおよびそれに加えた変更。 LGPLライブラリを変更することはできますが、それらの変更はソース形式で配布する必要があります。ただし、LGPLライブラリにリンクする場合は、リンクされた作品をLGPLにする必要はありません。選択したライセンスの下で配布できます。

動的リンクまたは静的リンクの両方が許可されていますが、アプリケーションのユーザーがLGPLライブラリを自分のものと交換できる必要があります。ダイナミックリンクは通常、これを簡単にするために使用されます。静的リンクを使用していて、ソースコードを配布したくない場合は、誰かが自分のコードをリンクできるように、そのコードのコンパイル済みオブジェクトファイルを配布する必要があります。

Apacheライセンスは、LGPLよりもさらに制限が少なくなっています。 Apacheコードを取得してアプリケーションに直接埋め込むか、リンクすることができます。それでも、選択したライセンスの下でコードを配布できます。

@Hovertruckは、GPLを使用できないと誤解しています。実際、使用できます。 LGPLは、GPLに基づく作業の再ライセンスを明示的に許可します。また、GPLの下でApache派生作品のライセンスを取得することもできます。

使用できるライセンス戦略は、アプリケーションの「縮小」バージョンをApacheライセンス(または他の同様のもの)で配布し、よりコンパイルされたバージョンを選択したプロプライエタリライセンスで配布することです。

0
Mark H