web-dev-qa-db-ja.com

MIT vs GPLライセンス

MITライセンスはGPL互換です。 GPLライセンスはMIT互換ですか?つまり、GPLライセンス製品にMITライセンスコードを含めることができますが、MITライセンス製品にGPLライセンスコードを含めることはできますか?

MITライセンスとGPLの主な違いは、MITがGPLがそうであるのに対し、オープンソースの修正を必要としないことです。あれは正しいですか? GPLはMITライセンスよりも制限が厳しいですか?

122
fruzer

MITライセンスとGPLの主な違いは、MITがGPLがそうであるのに対し、オープンソースの修正を必要としないことです。

真-一般に。 GPLを使用している場合、変更をオープンソース化するためにhaveを使用しないでください。配布しない限り、変更して独自の目的に使用できます。しかし...配布する場合、GPLコードを使用しているプロジェクト全体も自動的にGPLになります。つまり、オープンソースである必要があり、受信者はあなたと同じ権利をすべて取得します-つまり、彼らはそれを好転させて配布し、修正し、販売することができます。もはやプロプライエタリです-オープンソースになります。

MITとの違いは、MITライセンスコードを使用している独自コードを実際に配布しても、コードをオープンソースにする必要がないことです。コードが暗号化されているか、バイナリである閉じたアプリとして配布できます。 MITライセンス通知が記載されている限り、MITライセンスコードを含めて暗号化できます。

gPLはMITライセンスよりも制限が厳しいですか?

はい、とてもそうです。

76
Ravi Jayagopal

MITライセンス製品にGPLライセンスコードを含めることはできますか?

あなたはできる。 GPLはMITと同様にフリーソフトウェアです。どちらのライセンスも、「include」が常に双方向であるコードをまとめることを制限していません。

結合された作品(つまり、2つ以上の作品が1つの作品を形成する)の著作権では、1つの作品が他の作品よりも「大きい」場合でもそうでない場合でも違いはありません。

したがって、GPLライセンスコードをMITライセンス製品に含める場合、同時にGPLライセンスコードにもMITライセンス製品を含めます。

セカンドオピニオンとして、 OSIは以下の基準を(より詳細に)リストしました 両方のライセンス(MITおよびGPL)について:

  1. 無料再配布
  2. ソースコード
  3. 派生作品
  4. 著者のソースコードの整合性
  5. 人またはグループに対する差別なし
  6. 努力分野に対する差別なし
  7. ライセンスの配布
  8. ライセンスは製品に固有のものであってはなりません
  9. ライセンスは他のソフトウェアを制限してはならない
  10. ライセンスは技術に中立でなければならない

どちらも組み合わせた作品の作成を可能にします。これはあなたが求めていたものです。

2つの作品を組み合わせることが派生物であると見なされる場合、これは両方のライセンスによっても制限されません。

また、両方のライセンスはソフトウェアの配布を制限していません。

MITライセンスとGPLの主な違いは、MITがGPLがそうであるのに対し、オープンソースの修正を必要としないことです。

GPLでは、変更を行ったという理由だけで変更をリリースする必要はありません。それは正確ではありません。

これを、GPLでのソフトウェアの配布と混ぜることができますが、これは直接尋ねたものではありません。

それは正しいですか-GPLはMITライセンスよりも制限が厳しいですか?

これは私がそれを理解する方法です:

ディストリビューションに関しては、パッケージ全体をGPLの下に置く必要があります。パッケージ内のMITコードはMITで引き続き使用できますが、GPLは、より高い権限によって制限されない限り、パッケージ全体に適用されます。

「制限的」または「より制限的」/「制限的ではない」は、視点に大きく依存します。ソフトウェアユーザーの場合、MITは、GPLで利用可能なソフトウェアよりも制限が厳しいソフトウェアになる可能性があります。具体的には、そのユーザーはMITをより制限的に呼び出します。そう言うのは主観的なことであり、人によってその答えは異なります。

さまざまなライセンスの制限について話すのは主観的であるため、代わりに何を達成したいかについて考える必要があります。

  • 変更の使用を制限したい場合、MITはGPLよりも配布を制限することができ、それがあなたが探しているものかもしれません。
  • ソフトウェアの自由が配布先のユーザーによってそれほど制限されないようにする場合は、MITではなくGPLでリリースすることをお勧めします。

あなたが著者である限り、決定できるのはあなたです。

だから、誰がどのライセンスを選んでいるかにかかわらず、これまでで最も制限的な人は著者です。

45
hakre

GPLはMITライセンスよりも制限が厳しいことは正しいです。

MITライセンス製品にGPLコードを含めることはできません。 GPLとMITコードを組み合わせた複合作品を配布する場合(特定の状況、たとえば「単なる集約」を除く)、その配布はGPLに準拠する必要があります。

GPL製品にMITライセンスコードを含めることができます。結合された作業全体は、GPLに準拠した方法で配布する必要があります。コードのMIT部分に変更を加えた場合、GPLおよびMITコードを含むアプリケーションを配布する場合、それらの変更のソースを公開する必要があります。

あなたがGPLコードの著作権所有者であれば、もちろんその代わりにMITライセンスの下でそのコードをリリースすることを選択することができます-その場合それはあなたのコードであり、あなたは好きなだけのライセンスの下でそれを公開できます。

16
JosephH

IANALですが、私はそれを見ると....

GPLとMITコードを組み合わせることができますが、GPLは汚染されています。これは、パッケージ全体がGPLの制限を受けることを意味します。それはより制限的であるため、商用(またはクローズドソース)ソフトウェアでは使用できなくなります。また、MIT/BSD/ASLプロジェクトがある場合、GPLコードに依存関係を追加したくないことも意味します。

GPL依存関係を追加してもコードのライセンスは変更されませんが、プロジェクトのアーティファクトでできることは制限されます。これは、ASFがプロジェクトのGPLコードへの依存を許可しない理由でもあります。

http://www.Apache.org/licenses/GPL-compatibility.html

5
tcurdt