web-dev-qa-db-ja.com

GPLおよびMITライセンスを正しく使用するにはどうすればよいですか？

私たち自身の Alaukik を置くように頼まれたので afewscripts GPL-Licenseの下でそれをやっているのだろうかと思いました正しく。私に関係する点は次のとおりです。

  1. プロジェクトにライセンス全体を含める必要がありますか、または# Copyright by John Doe, 2011 Licensed under the MIT license: http://www.opensource.org/licenses/mit-license.phpのようなコメントで法的に十分ですか？
  2. 実名を含める必要がありますか、それとも電子メールまたはその他のエイリアスは法的に防水ですか？
  3. 年は重要ですか？一定期間が過ぎるとほとんどの国で著作権が失効するので、「はい」と思います。そうしないとどうなりますか？
  4. MITでGPLを使用する必要がありますか？私はMITの方がより寛容であり、スクリプトがクローズドソースソフトウェアで使用されているかどうかは気にしません。

更新：

「 独自のソフトウェアにGNUライセンスを使用する方法 」に非常に良いページがあります。 gnu Webサイトでは、 プロジェクトにライセンスを適用する方法 （ ™Flimm ）の提案も行っています。これはGPLの多くをカバーしています。

一番下の行-ライセンスの選択：
フリーソフトウェアをサポートする場合は、フリーライセンスをあまり使用しないでください。プロプライエタリな使用を許可しないことで、フリーソフトウェアがプロプライエタリなプログラムよりも優位になります。理論的には、一部のライセンスでは、コードの再利用には元のコードを使用する必要があります。しかし、再利用は証明するのが難しく、一部の企業はあなたを信用しないかもしれません。ただし、ソフトウェアを可能な限り広めたい場合、つまり、ソフトウェアを使用するプロプライエタリ製品を気にしない場合は、MITまたはLGPLを使用します。 疑わしい場合は、より制限の厳しいライセンスを使用して行を追加し、ライセンス条件以外での使用をケースごとに許可することを検討してもよいと言います。これあなたの仕事にふさわしいプロジェクトを持つ商用ユーザーがチャンスを得る方法。

下段-著作権紛争：
あえて情報を含めて、本当に簡単に証明できるようにします。頭の後ろで所有権をめぐる訴訟を起こします。貧しい人々の著作権は、ソースの印刷されたコピーを自宅の住所に郵送することです。封筒が壊れていない場合、消印は裁判所での有効な証拠であり、日付と確認済みの住所を提供します。あなたを特定するためのあなたのフルネームの代わりに電子メールは大丈夫で十分な証拠である必要がありますが：申し訳ありませんよりも安全です。

licensegpl
31
con-f-use

これに接頭辞を付ける必要があります。私は著作権の弁護士ではありません。何か心配な場合は、連絡してください。 FSFの人々があなたを助けることができるかもしれません。

ライセンスの全文を含める必要があります。プロジェクトのルートにあるLICENSEファイルに貼り付けただけでも。あなたがそうしなければすぐに悪いことは起こらないと思いますが（長期的には著作権です）、あなたのライセンスへのしっかりした言及がないことは悪いことかもしれません。

明示的であることは、それほど時間を要しません。

編集：実際には、WARRANTYセクションは、選択したライセンスに関係なく、保護のために含める価値があります。それを含めないことは保証を意味すると言う証拠はありませんが、繰り返しますが、申し訳ありませんが、安全です。

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

著作権表示（© <date> <name>）はほとんどの場所で法的にもう必要ありませんが、それを含めないことは誰にも役立ちません。あなたが著作権を所有していることを証明するのに苦労するだろうし、異なる条件の下でそれをライセンスしたい人々にとってそれはずっと難しいだろう。私は間違いなくそこに置きます...しかし、これは実際にはBSD/MITスタイルのライセンスの問題ではないと思います。

ハンドルまたはニックネームの使用に関しては、他のメディアでは何世紀にもわたって偽名を使用しています。訴訟になった場合、あなたがその人であることを証明する必要があるので、明らかにこれは少し難しくなるかもしれませんが、乗り越えられないわけではありません。

MITに行く場合は、法的手段がほとんどないため、これらの問題はおそらく当てはまりません。

著作権表示の年は必須ではありませんが、数十年後に誰かを訴えたければ、それがいつ作成されたかを証明する必要があります。難しいかもしれません。固定通知はあなたを助け、数秒しかかかりません。

ここで明確にする必要があります。

  • GPLは商用の再配布を許可しますが、コピーを購入する人は誰でも（変更を加えて）ソースコードを入手できる必要があります。
  • LGPLはソフトウェアライブラリに適しています。これらは、ソース全体を再配布する必要なく、独自のプロジェクトに含めることができます。ソース配布を行う必要があるのは、コードを編集し、それでも変更をリリースするだけでよい場合です。
  • MITコードは自由に再ライセンスできます。誰かがあなたのコードを逐語的に受け取り、GPL、独自のライセンスなどの下で再リリースすることができます。

「GPL vs MIT」は永遠の戦いです。最も便利なものではなく、実際に最も幸せなものを選んでください。悪意のある人々がコードを取得して悪意のあるまたは有利な目的で使用することに満足していない場合は、GPLのような手段がある場所で何かを使用してください。もしあなたが本当に気にせず、自分でGPLコードを使用していないなら、MITのようなもっと寛大なライセンスでいいでしょう。

バイラルにオープンソースのライセンスは、あなただけのものではないことを忘れないでください。彼らはあなたの作品を保証します。コードを維持することに興味がないのにコードをダンプしている場合でも、GPLはコードを自由に残せるというより良い希望を与えます。

これらの決定を急ぐ必要もありませんが、正しい決定を下しているかどうかを本当に知るために、最悪の可能性のあるケースを考えなければなりません。これらのライセンスのいずれかでリリースされたら、それで完了です。

28
Oli

GPLv2ライセンスの最後に、 ライセンス条項をプロジェクトに適用する方法 に関するガイドがあります。 FSFはその文書を作成し、それを可能な限り法的に有効にするために多大な努力を注いだので、私は彼らのアドバイスに従います。

GPLライセンスを使用する場合は、「バージョン2以降」の条項を必ず含めてください。これにより、後で頭痛の種が減り、GPLv2プロジェクトがGPLv3と互換性を持つようになります。

Oliが言ったように、著作権を保持するためにファイルのヘッダーに本名やメールを合法的に使用する必要はありませんが、後であなたや他の人を頭痛から守ることを強くお勧めします。

GPLライセンスとMITライセンスを決定することは、倫理的かつ戦略的な決定であり、どちらかを支持する多くの議論があります。

7
Flimm