オープンソースライセンスの比較

簡単な説明 :この詳細なガイドでは、効果的なオープンソースライセンスの比較について説明します。 ここで説明しているオープンソースライセンスでは、プロジェクトに適したオープンソースライセンスを選択するのに役立ちます。

それで、あなたはしばらくそのクールな新しいプロジェクトに取り組んでいます - そしてクローズドソースからオープンソースへの重要な動きをする準備ができています。

GitHubやBitbucketにリポジトリをプッシュする前に、ソースやコミット履歴を消去するよりも、それほど多くの作業はありません…。ライセンスの問題が発生するまでは…。 たくさんの選択肢があります。 どれを選ぶ? 結局のところ、 本当にライセンス必要ですか。

後者の質問に対する簡単な答えは簡単です。はい、あなたは本当にライセンス必要です。 あなたが必要とするライセンスに関しては、私はもっと短い答えさえすることができます: それは依存します。

しかし、あなたがあなたのプロジェクトに真剣であるならば、あなたはおそらくもう少し詳細が欲しいです。 だから先読みしてください - そして覚えておいてください:あなたは今、聖戦領域に入っています!

ライセンスが必要ですか? 結局、ライセンスとは何ですか?

ライセンスとは、一部の著作物(「ライセンサー」)の所有者が他の人々(「ライセンシー」)に付与し、ライセンシーがどのようにライセンサーの著作物を使用することを許可するかを規定する公式の許可です。

これは契約の形をとり、双方は同意しなければなりません。 今日では、承認はかなり暗黙のうちに行われます。いくつかのWork を使用するだけで、あなたはその使用許諾に同意すると評されます。

明確にするために、自分作品を公開するときには、ライセンサーがあなたです 。 ライセンシー、あなたのコードを使っている人は誰でも 。 大まかに言って、これには2つの主なカテゴリが含まれます開発者エンドユーザーです。

そして、あなたの作品を修正することによって、さらにいくつかの語彙を修正するために、ライセンシーは派生作品と呼ばれるものを作成しています。 大きい作品であなたの作品を使用することが、その作品を派生作品として認定するかどうかにかかわらず、すべてのライセンスが同意するわけではありません。 以下に示すように、いくつかのライセンスは特にこれらの問題に対処しています。

ライセンスの目的は何ですか?

基本的に、ライセンスはライセンサーとライセンシーが両者の 権利と義務について合意するための方法です。 ライセンスに関連する権利と義務は、法律で許可されている範囲内であれば、何でもかまいません。 たとえば、ライセンサーは、自分の作品を使用するときに自分の名前を引用するようにライセンシーに要求することがあります。 または彼女の作品をコピーすることを承認することはできますが、それを変更することはできません。 あるいは、派生著作物を元の著作物と同じ条件で公開することを要求することさえあります。

一方、ライセンスはライセンシーも保護するための方法です。 彼があなたの作品をどのように使うことができるかを明確に述べることによって、彼はあなたが突然あなたの作品を使ったことに対してロイヤリティや他の形の報酬を求めるのを見る危険がありません。 あなたの作品の採用に重要な何か。

だから、ライセンスはあなたの仕事を保護します。 ライセンサーを保護します。 しかし、あなたも守ります。 私はあなたを意味します。 例えば、彼女の仕事によって引き起こされた潜在的な損害に対するライセンサーの責任を制限することによって。

そして、ライセンスをまったく使用しないとどうなりますか?

著作物に明示的に関連付けられたライセンスがない場合は、作者の管轄についての「デフォルト」の著作権が適用されます。 言い換えれば、「ライセンスの欠如」を、私たちがあなたの仕事に必要なことをするための暗黙の助成金として決して考えないでください。 これは正反対です。具体的なライセンスがない限り、あなた(作者)は法律で許可されているようにあなたの権利を放棄することはありませんでした。

しかし、常にライセンスが権利義務を管理することを忘れないでください。 多くのライセンステキストに、製品に提供されている保証についての免責事項がすべて大文字で書かれているのはなぜでしょうか。 これは、暗黙の保証またはユーザーの想定から作品の所有者を保護するためのものです。 あなたが欲しい最後のことはあなたの仕事のオープンソースをリリースした結果として訴えられることです!

カスタムライセンスを使用できますか?

はい、できます。 しかし、あなたはおそらくそうすべきではありません。

契約であるため、ライセンスは(ほとんどの管轄区域では、それらすべてが)領土法より優先することはできません。 そのため、グローバル化した世界でライセンスの権利を強制することは困難です。 裁判官の前に「標準的な」免許証を弁護するほうがおそらく簡単だろう(私はそう難しいことではない)。 事実、そのような事件はすでにいくつかの法域で擁護されており、先例として引用されるかもしれません。 明らかに、カスタムライセンスではできないことです。

さらに、カスタムライセンス(バニティーライセンスとも呼ばれる)は他のライセンスとの互換性がなくなる可能性があり、合法的に言えば作品の互換性が悪くなります。

複数のライセンスを使用できますか?

はい。 マルチライセンス - 特にデュアルライセンス - はそれほど珍しいことではありません。 あなたがあなたの自由な仕事の周りにビジネスを築きたいとき、これは特に本当です。 その場合、あなたのプロジェクトはおそらくFOSSライセンスと商用ライセンスの両方の下でリリースされるでしょう。

マルチライセンスのもう1つの用途は、作品をさまざまな条件で公開されている作品と組み合わせること、またはさまざまなユーザーのニーズや要件を満たすことによって互換性を高めることです。 これが、いくつかのプロジェクトがいくつかのFOSSライセンスの下でリリースされている理由です。

ただし、注意が必要です。すべてのライセンスが互換性があるわけではありません。 繰り返しますが、そのようにしたい場合は、よく知られている互換性のあるライセンスを使用することで、ホイールを再発明することをお勧めします。

後でライセンスを変更できますか?

はい。 著作権者はライセンス条項に責任があります。 あなたが唯一の貢献者である限り、ライセンスを変更することはかなり簡単です。 しかし極端な例を挙げると、Linus Torvaldが別のライセンスでLinux Kernelをリリースしたいのなら、彼はおそらく最初にそのプロジェクトへの何千もの貢献者の合意を必要とするでしょう。 実際には不可能なこと。

もっと適度な大きさのプロジェクトでは、それを行うことができます。 そして実際、それはあなたが以下のいくつかの例で見るようにありました。

どのオープンソースライセンスを使うべきですか?

さて、今、あなたは標準ライセンスを使うべきだと確信しています。 しかし、どちらを選ぶべきですか? 最終的な選択はあなた次第です。 そしてあなたの選択であなたを助けるためにウェブ上で利用可能な非常によく作られた比較器があります。 私のお気に入りを引用するだけです:

  • //oss.ly/licdif
  • //choosealicense.com/ / //choosealicense.com/appendix/
  • //opensource.org/licenses
  • //tldrlegal.com/

しかし、法務と同様に、最終的な答えは、ライセンスの正式なテキストを読み、理解することです。 それは専門の弁護士の助けを必要とするかもしれません。 私は違います。

しかし、私ができることはあなたの最初のステップを導くためにあなたに最も一般的なライセンスのいくつかの紹介を提供することです。

GNU一般公衆利用許諾契約書(GPL)

GPLは最も人気のあるオープンソースライセンスのひとつです。 それはいくつかのバージョンがあります - しかし、新しいプロジェクトのために、あなたはこの文書を書いている時点での最新のGPL 3を考慮すべきです。

強力なコピーレフトをサポートしているGPLは、おそらく最も保護的なフリーソフトウェアライセンスです。 それはあなたの見方によっては称賛されたり批判されたりすることがあります。 GPLが派生的著作物であるという背後にある中核的概念は、GPLの下でも発表されなければなりません。

  • 強いコピーレフト
  • この作品は商業用途に適しています。
  • ライセンシーは作品を修正することができます。
  • ライセンシーは派生物とともにソースを公開する必要があります。
  • 派生物も同じ条件でリリースする必要があります。

人気のあるプロジェクト

GPLはFree Software Foundationのプロジェクトのための自然なライセンスです。 あらゆるLinuxシステムの中心にGNUツールを含めること。 大規模なプロジェクト、つまり商用のプロジェクトは、GPLを他の1つ以上のライセンスと組み合わせて使用​​する傾向があります。

  • インクスケープ(ベクター製図):GPLv2
  • Drupal(ウェブコンテンツ管理システム):GPLv2
  • MariaDB(データベース):GPL v2
  • MySQL(データベース):GPLと商用ライセンス
  • Qt(クロスプラットフォームアプリケーションフレームワーク):LGPL、GPL、およびCommercial - モジュールとサービス契約レベルに応じて

GNU劣等一般公衆利用許諾契約書(LGPL)

GPLは、派生著作物を同じ条件でオープンソースにリリースすることを強いるという意味で非常に制限的です。 これは特に大規模ソフトウェア用のブロックを構築しているライブラリにとっての懸念です。GPLの下でライブラリをリリースすることで、そのライブラリを使用しているすべてのアプリケーションもGPLとしてリリースされるように強制します。 LGPLが対処しているもの

図書館の場合、FSFは3つのケースを区別します。

  • あなたのライブラリは、フリーではない標準と競合する標準を実装しています。 その場合、あなたのライブラリを広く採用することはフリーソフトウェアの原因となります。 FSFは、その場合にはかなり寛容なApacheライセンスを提案しています(この記事の後半で説明します)。
  • あなたのライブラリは既に他のライブラリによって実装されている標準を実装しています。 その場合、フリーソフトウェアがコピーレフトを完全に放棄することによる利益はありません。 だからFSFはLGPLをお勧めします。
  • 最後に、あなたの図書館が他の図書館や他の標準と競合しない場合、FSFはGPLを推奨します。

FSFの主張は大部分が倫理的および哲学的です。 実際には、開発者は他の懸念を抱くかもしれません。 特に彼らが許諾された仕事に基づいて事業を発展させることを計画するならば。 繰り返しになりますが、デュアルライセンスは検討すべき選択肢です。

  • 弱いコピーレフト(動的にリンクされたライブラリにバインドされている)
  • この作品は商業用途に適しています。
  • ライセンシーは作品を修正することができます。
  • ライセンシーは派生物とともにソースを公開する必要があります。
  • あなたが作品を修正した場合、あなたは同じ条件の下で修正した作品をリリースしなければなりません
  • この作品を使用する場合、あなたは同じ条件で派生作品をリリースする必要はありません。

人気のあるプロジェクト

  • OpenOffice.org 3(office suite):LGPLv3 - しかしApache OpenOffice 4はApache License 2.0に切り替えた。
  • GTK +、GIMPツールキット(GUIツールキット):LGPLv2.1
  • CUPS(クロスプラットフォーム印刷システム):Apple製オペレーティングシステムを除くGPLまたはLGPLv2 - コンポーネントによって異なります。
  • WineHQ(Windows互換レイヤー):LGPLv2.1
  • GNU Aspell(スペルチェッカー):LGPLv2.1

Eclipse Public License(EPL 1.0)

LGPLよりもコピーレフトが弱いため、非EPLコードが「独立しコードであれば、EclipseライセンスはEPLおよび非EPL(独自のものであっても)ライセンスコードからなるソフトウェアのサブライセンスおよび構築を可能にするため、ビジネスフレンドリーです。 ソフトウェアのモジュール」

さらに、その著作物を含む商業的提供物によって引き起こされた訴訟/損害の場合には、EPLはEPLコード寄稿者に対して追加の保護を追加します。

  • 弱いコピーレフト(ソフトウェアの「モジュール」にバインド)
  • この作品は商業用途に適しています。
  • ライセンシーはその作品を修正することができます。
  • あなたが作品を修正する場合、あなたは同じ条件の下で修正された作品をリリースしなければなりません
  • この作品を使用する場合、あなたは同じ条件で派生作品をリリースする必要はありません。
  • ソフトウェアの商用ディストリビュータは、オリジナルのEPLコントリビュータを、そのコマーシャル提供によって引き起こされた訴訟/損害から保護または補償しなければならない。

人気のあるプロジェクト

明らかに、EPLはEclipse Foundationのプロジェクトに対する自然なライセンスです。 人気のあるEclipse IDEを含みます。 しかしそれはそれ以上の人気を得ました - 特にJavaの世界では:

  • Clojure(プログラミング言語)
  • Graphviz(Graph visualization package)
  • Jetty(アプリケーションサーバー):Jetty 7以降のデュアルライセンスEPL1.0 / Apacheライセンス2.0
  • JUnit(Javaユニットテストフレームワーク)

Mozilla Public License(MPL)

Mozilla Public Licenseは、Mozilla Foundationによって開発されたソフトウェアに使用されるライセンスです。 しかし、それは確かにその分野に限定されません。 MPLは、厳密なライセンス(GPLなど)と寛容なライセンス(MITライセンスなど)の間の妥協の一歩となることを目指しています。

MPLでは、「ライセンス単位」はソースファイルです。 ライセンサーは、MPLの対象となるファイルに対するユーザーの権利とアクセスを制限することを許可されていません。 しかし、同じプロジェクトに独自の非MPLライセンスファイルを含めることもできます。 MPLライセンスファイルへのアクセスが許可されていれば、結果のプロジェクトは任意のライセンスでリリースできます。

  • 弱いコピーレフト(個々のファイルにバインド)
  • この作品は商業用途に適しています。
  • ライセンシーは作品を修正することができます。
  • ライセンシーは、著作物に対して適切な帰属を提供する必要があります。
  • ライセンシーは、異なる条件で派生作品を再配布することができます。
  • ライセンシーはMPLライセンスのソースを再ライセンスすることはできません
  • ライセンシーはMPLライセンスのソースコードを派生物と共に配布しなければなりません。

人気のあるプロジェクト

  • Mozilla Firefox(Webブラウザ)、Mozilla Thunderbird(電子メールクライアント):MPL
  • LibreOffice(オフィススイート):MPL 2.0
  • H2データベースエンジン(データベース):MPL 2.0およびEclipse License 1.0
  • カイロ(2Dグラフィックエンジン):MPL 1.1またはLGPLv2.1

Apache License 2.0(ASL 2.0)

ASLによって、私たちは寛容な無料ライセンスの領域に入っています。 しかしFSFでさえ場合によってはApacheライセンスを提案しています。 Apache Licenseは派生著作物を同じ条件で配布することを要求しないため寛容です。 言い換えれば、これはコピーレフトのないライセンスです。

ASLは、Apache Software Foundationのプロジェクトに使用される唯一のライセンスです。 ビジネスに優しいと考えられているので、その組織の外で広く採用されています。 エンタープライズグレードのプロジェクトがASLの下でリリースされることは珍しくありません。

  • 非コピーレフト
  • この作品は商業用途に適しています。
  • ライセンシーは作品を修正することができます。
  • ライセンシーは、著作物に対して適切な帰属を提供する必要があります。
  • ライセンシーは、異なる条件で派生作品を再配布することができます。
  • ライセンシーは、派生物とともにソースコードを配布する必要はありません。

人気のあるプロジェクト

  • Android(オペレーティングシステム):いくつかの例外を除いてASL 2.0(特にLinuxカーネルに関して)
  • Apache httpd(Webサーバー):ASL 2.0
  • Apache Spark(クラスタコンピューティングフレームワーク):ASL 2.0
  • Spring Framework(Javaベースのエンタープライズアプリケーションのためのフレームワーク):ASL 2.0

MITライセンス

これはとても人気のあるライセンスです。 おそらく最も人気のあるものです。 MITライセンスは、再利用にほとんど制限を加えることなく、GPLから独自のライセンスまで、他のライセンスと簡単に関連付けることができます。

  • 非コピーレフト
  • この作品は商業用途に適しています。
  • ライセンシーは作品を修正することができます。
  • ライセンシーは、著作物に対して適切な帰属を提供する必要があります。
  • ライセンシーは、異なる条件で派生作品を再配布することができます。
  • ライセンシーは、派生物とともにソースコードを配布する必要はありません。

人気のあるプロジェクト

  • node.js(JavaScriptランタイム環境):MITライセンス
  • jQuery(クライアントサイドJavaScriptライブラリ):MITライセンス(2012年まで、デュアルライセンスMIT / GPL)
  • Atom(テキストエディタ):MITライセンス
  • AngularJS(JavaScriptアプリケーションフレームワーク):MITライセンス
  • SQLAlchemy(Python用のSQLツールキットとオブジェクトリレーショナルマッパー):MITライセンス

BSDライセンス

BSDライセンスには3つの種類があります。 オリジナルの4条項ライセンス、「改訂版」の3条項ライセンス、および「簡易版」の2条項ライセンス。 精神的にすべてがMITライセンスに非常に近いです。 実際、2条項BSDライセンスとMITライセンスの間には、実際上ほとんど違いがありません。

3条項および4条項BSDライセンスでは、名前の再利用と広告に関する要件がさらに追加されています。 これはあなたがあなたの製品やブランド名を保護したい場合に考慮すべき点です。

  • 非コピーレフト
  • この作品は商業用途に適しています。
  • ライセンシーは作品を修正することができます。
  • ライセンシーは、著作物に対して適切な帰属を提供する必要があります。
  • ライセンシーは、異なる条件で派生作品を再配布することができます。
  • ライセンシーは、派生物とともにソースコードを配布する必要はありません。
  • ライセンシーは、派生的著作物を支持するために元の著者名または商標を使用することはできません(3節および4節BSD)
  • ライセンシーは、本作品の機能または使用について言及しているすべての広告資料で、原作者を承認する必要があります(4条項BSD)。

人気のあるプロジェクト

  • Django(Web ramework):三条項BSD
  • Redis(データストア):3節BSD
  • Ruby(プログラミング言語):2条項BSDとカスタムライセンス
  • Nginx(Webサーバ):2節BSD
  • NetBSD(オペレーティングシステム):2節BSD - 2008年までの4節BSD

オープンソースライセンスの最後の言葉

ここまで来たらおめでとう! あなたは今それを理解しています、 ライセンスは本当に巨大複雑なトピックです。 しかし、プロジェクトに適したライセンスを選択し、その選択を早めに行うには時間がかかります。 後で多くの問題を解決できるので、著作権や法的な互換性の問題に対処するのではなく、プロジェクトに費やす時間とエネルギーを使うことができます。

そのトピックにアクセスしやすくするために最善を尽くしたとしても、さまざまなライセンスの詳細を要約するのは必ずしも容易ではありません。 そしてここに提示されているいくつかの主要なライセンスを超えて、多かれ少なかれ一般的に使用されている他の多くのものがあります。

それで、 あなたの好みのライセンスが何であるか、そしてその理由を私達に伝えるために下記のコメント欄を使うことを躊躇しないでください。 あるいは、私が忘れていたかもしれないいくつかの重要な特徴を述べるために!

推奨されます

Zorin OS 12レビュー:私の経験から学ぶ
2019
NVIDIAは32ビットオペレーティングシステムのサポートを終了します
2019
Linus Torvaldsがマイクロソフトに参加してWindows 9プロジェクトを統括
2019