オープンソースライセンスの開発者ガイド

公開: 2022-03-11

すべてのオープンソースライセンスが同じというわけではありません。それらのいくつかは、ソフトウェアのユーザーと開発者に特許ライセンスを付与することをソフトウェアサプライヤーに義務付けています。他のライセンスでは、ライセンスされた製品またはライブラリを使用する開発者が、同じ条件でこの製品またはライブラリのソースコードを提供する必要があります。他の人は、いかなる種類の保証も懸念もなしに、単にコードを提供します。この記事では、ソフトウェアユーザーとソフトウェア開発者の観点から、最もよく使用されるオープンソースライセンスの主な違いを強調します。

難解さをわかりやすく説明する-オープンソースライセンス

つぶやき

1984年にRichardStallmanが無料のオペレーティングシステムを作成するためのGNUプロジェクトを開始したとき、彼はソフトウェアを開発者、エンジニア、ユーザーの間で共有する必要があるという考えを取り戻しました。そして彼らは、科学が通常行われているのと同じ方法で、共同でそれを改善することができるはずです。

このオプションは、ほとんどのソフトウェア企業や開発者がプログラムを配布および販売するために選択したライセンスソフトウェアの通常の概念とは対照的です。 30年以上経った今日でも、オープンソースソフトウェアは業界の幅広いセクターをゆっくりと征服し続けています。Linux、Android、Apache、Gitは、これらのカテゴリの主要なオープンソース製品の例です。

オープンソースまたは自由ソフトウェア？

この記事では、ソフトウェアまたはライセンスを指すときに、「オープンソース」および「無料」という用語を同義語として使用します。私の意見では、両方の用語は同じ考えを表しています。「オープンソース」はそれを実用的かつ技術的な方法で表現し、「無料」を使用することで、概念の哲学的および政治的意味に焦点を当てます。

残念ながら、英語の「無料」という言葉は、「自由」に関連する形容詞であることに加えて、「無料」を意味します。これが私が通常「オープンソース」と言うことを好む理由です。

オープンソースソフトウェアの共通の特性

あなたはすでにオープンソースソフトウェアが何であるかについておおよその考えを持っていると思います。ただし、さまざまなライセンスの詳細について説明するので、最初に、オープンソースソフトウェアを定義する特定のプロパティについて説明する必要があります。

まず第一に、私は弁護士ではなく、これは法律上の助言ではありません。疑問がある場合は、私が話しているライセンスの実際のテキストと、あなたの法律顧問を参照してください。

オープンソースイニシアチブによると、すべてのオープンソースソフトウェアは、そのユーザーと開発者（ライセンシー）にいくつかの権利を与えるライセンスの下で配布されます。完全なリストはオープンソースの定義で調べることができますが、基本的な要約は次のとおりです。

ソフトウェアの無料再配布：ソフトウェアは、製品として販売または配布するか、ソフトウェアパッケージに含めることができます。これは、使用料を支払うことなく行うことができます。
ライセンスされたソフトウェアのソースコードは、ディストリビューションに含まれているか、少なくともソースコードを入手するための広く知られている手段があります。このソースコードは、ソフトウェアの修正バージョンの開発に使用できます。
派生作品の作成は許可されており、ライセンスにより、元のソフトウェアと同じ条件およびライセンスで配布することが許可されています。元のソフトウェアのライセンスによっては、これらの派生作品を名前やバージョン番号を変更して元のソフトウェアと区別する必要がある場合や、ソースコードパッチの形式でのみ配布できる場合があります。
このソフトウェアは、あらゆる個人またはグループの人々が、あらゆる分野の取り組みで、制限なく使用できます。

ただし、ソフトウェアライセンスは、著作権所有者によって付与されたアクセス許可の使用または配布についてのみ説明していることに注意する必要があります。オープンソースライセンスでは、ソフトウェアまたは派生した作品を自由に再配布できますが、暗号化ソフトウェアの輸出が禁止されている国では、その許可が制限される場合もあります。同様に、オープンソースライセンスでは、あらゆる目的でソフトウェアを使用できますが、それは、オープンソースライセンスソフトウェアを使用して銀行に侵入できるという意味ではありません。ソフトウェア特許はこの別の例です。一部のオープンソースライセンスは、特許を自由に使用する許可を与えていますが、すべてではありません。

では、製品やプロジェクトの開発にオープンソースソフトウェアを使用できますか？基本的には、使用するソフトウェアのライセンスと最終製品のライセンスによって異なります。独自のコードをオープンソースとして公開する場合や、使用するライセンスを決定する場合にも、さまざまなライセンスが重要になります。

コピーレフト

オープンソースライセンスに関する非常に興味深い概念の1つは、著作権の反対である、通常はコピーレフトと呼ばれるものです。著作権が知的財産（ソフトウェアを含む）のコピーまたは配布から保護するために使用される場合、コピーレフトは、オープンソースの知的財産およびソフトウェアをオープンソースとしてコピーまたは配布できるようにするために使用されます。

その強さによると、コピーレフトには2種類あります。

強力なコピーレフト：他の強力なコピーレフトライセンス作品から派生した作品、またはこれらの作品にリンクされた作品は、強力なコピーレフトライセンス、またはまったく同じライセンスを継続する必要があります。つまり、これらのオープンソース作品は将来閉鎖することはできません。
弱いコピーレフト：弱いコピーレフトライセンス作品を使用している、またはそれにリンクされている作品は、クローズドソースライセンスであっても、他のライセンスの下でライセンスされる可能性があります。この場合、コピーレフトは元の弱いコピーレフトライセンス作品にのみ影響します。

コピーレフトのないオープンソースライセンスもあります。それらは、派生ソフトウェアの将来のオープン性を単に気にしません。

寛容性

それらの許容度に応じて、ライセンスは次のように分類することもできます。

厳格なライセンス：強力なライセンスソフトウェアをクローズドソースと、またはよりパーミッシブライセンスされたソフトウェアと混合できない場合。
パーミッシブライセンス：製品が通常、クローズドソースソフトウェア、または完全にオープンソースライセンスのソフトウェアと混合できる場合。

通常、強力なコピーレフトライセンスも厳格であり、弱いコピーレフトライセンスはより寛容ですが、そのようにする必要はありません。

オープンソースライセンスの違い

多くのオープンソースライセンスが存在します。オープンソースイニシアチブはすでに80以上を承認しています。一部は冗長であり、他のものと同等と見なすことができます。その他は、ソフトウェア発行者の利益（NASAライセンスなど）、または特定の環境や目的（Educational Community License、Open Font Licenseなど）に固有のものです。

このライセンスの急増は、基本的なオープンソースプロパティに追加され、他の使用を許可または禁止するライセンスの特定の条件に基づいています。これらの追加条件の例には、次のものが含まれます。

コピーレフトの種類：弱いまたは強いまたは存在しない。
寛容のタイプ：寛容または厳格。
ソースコードまたはユーザーインターフェイスに著作権表示を追加する義務。
ライセンシーへの自動特許付与。
ライセンシーとして、ソフトウェアの配布先だけでなく、ソフトウェアのユーザーも考慮します（したがって、この種のオープンソースソフトウェアを使用するクラウドでサービスを使用するユーザーは、次のソースコードをダウンロードすることを選択できます。ソフトウェア）

異なるライセンスを持つコードの混合の問題

異なるライセンスを持つコードを混在させると、興味深い課題が発生する可能性があります

すでに述べたことによると、一部のライセンスはパーミッシブであり、ユーザーはコードを異なるライセンスのソースコードと組み合わせることができます（おそらく追加の条件があります）。この場合、この種のオープンソースライセンスソフトウェアとクローズドソースソフトウェアを混在させることができます。この種のライセンスの例はMITライセンスです。

他のものはより制限的であるため、ソースコードは同様の方法でライセンスされたコードとのみ組み合わせることができ、最終結果は同じ元のライセンスでライセンスされる必要があります。この種のライセンスの例は、General Public License（GPL）です。

たぶん、ライセンスされたコードを2つの異なる制限付きオープンソースライセンスと組み合わせたいと思うでしょう。オープンソースの自由を利用して、ソフトウェアを好きなように使用できます。ただし、最終的なプログラムは、相互に互換性のない2つのライセンスで配布する必要があるため、再配布することはできません。

この状況の一例はZFSでした。 ZFSは、2005年にOpenSolarisに組み込まれた非常に高度で革新的なファイルシステムです。これは、Common Development and Distribution License（CDDL）の条件に基づいてライセンスされたオープンソースソフトウェアです。これはオープンソースコードですが、Linuxのソースコードは別の制限的なオープンソースライセンスであるGeneral Public Licenseの条件の下で配布されているため、Linuxカーネルに統合することはできません。ライセンスの競合のため、ZFSサポートでコンパイルされたLinuxカーネルのバイナリを配布できません。

この種の競合は、いずれかのオープンソースプログラムの所有者全員がライセンスの変更、またはソフトウェアライセンスに例外条件を追加することに同意した場合にのみ解決できます。例：多くのGPLライセンスプログラムはOpenSSLライブラリにリンクされています。 OpenSSLライブラリの配布は、広告資料および再配布にフレーズを表示することを要求するライセンスが付与されています。これらの追加条件はGPLと互換性がなく、OpenSSLを使用するGPL製品の開発者は、OpenSSLとのリンクを特に許可する例外をライセンスに含めています。

オープンソースライセンスの特徴

次に、最も人気のあるオープンソースライセンスを分析し、それらの機能の違いに注目し、それらをいつ使用するかどうかについての簡単なガイドを示します。 Black Duck Knowledgebaseによると、使用頻度の高いものから低いものへと並べ替えました。

GNU General Public License（GPL）

GPLは最も人気のあるオープンソースライセンスです。これは、GNUプロジェクトのライセンスとしてFSFによって作成されたものであり、Linuxカーネルのライセンスでもあります。

その差動特性：

強いコピーレフト。
非常に厳格なライセンス。
これは通常、「ウイルス」ライセンスと呼ばれます。コードをGPLでライセンスされている別のコードにリンクし、結果を配布する場合は、製品全体をGPLライセンスである必要があります。
これは「包括的」ライセンスでもあります。ソフトウェアを開発していて、GPLの下でライセンスを取得したい場合は、このソフトウェアがGPLと互換性のあるライセンスを持っている限り、リンクするか、他のオープンソースソフトウェアを含めることができます。 GPLで要求されていない義務は必要ありません。

通常、使用されるライセンステキストには、ソフトウェアがGPLバージョンN（またはそれ以降のバージョン）の条件で配布されることを示すテキストが含まれています。

現在使用されているGPLライセンスにはv2とv3の2つのバージョンがあります。バージョン3は、1991年のバージョン2のリリース以降に発生したいくつかの問題に対処するために、2007年にリリースされました。

GPL v3には、他のオープンソースライセンスとの互換性規制への対応、特許ライセンスの義務付け、アプライアンスのファームウェアとしてGPLライセンスソフトウェアを使用するための条件の定義、デジタル著作権管理としての概念の考慮など、いくつかの追加条項と条件が含まれています。

MITライセンス

通常MITライセンス、別名X11ライセンスとして知られているオープンソースライセンスは、著作権メッセージを保持している限り、誰もが基本的にライセンスされたコードを好きなように使用できる、非常に寛容な非コピーレフトライセンスです。ソフトウェアにはいかなる種類の保証もありません。

このライセンスは非常に人気があり、X Window System、Ruby on Rails、jQuery、Node.jsなどのいくつかのプロジェクトで使用されています。

GPLと互換性があるため、MITライセンスのコードをGPLソフトウェアに混在させることができます。

Apacheライセンス2.0

Apacheライセンスは、ApacheHTTPサーバーのライセンスとしてApacheSoftware Foundation（ASF）によって作成されました。

MITライセンスと同様に、これは非常に寛容な非コピーレフトライセンスであり、ソフトウェアをあらゆる目的で使用し、配布し、変更し、使用料を気にせずに派生した作品を配布することができます。 MITライセンスとの主な違いは次のとおりです。

ソフトウェアの作成者は、Apacheライセンスを使用して、コードのユーザーまたはディストリビューターに特許ライセンスを付与します。この特許ライセンスは、ソフトウェア作成者のいずれかによってライセンス可能であり、作成したコードによって侵害される可能性のあるすべての特許に適用されます。
Apacheライセンスでは、派生作品の変更されていない部分がライセンスを保持する必要がありました。
すべてのライセンスファイルでは、元の著作権、特許、商標、または帰属に関する通知を保持する必要があります。
ライセンスされたファイルの変更ごとに、ファイルに変更が加えられたことを示す通知が必要です。
ApacheライセンスソフトウェアにNOTICEファイルが含まれている場合、このファイルとその内容は、派生したすべての作品で保存する必要があります。
誰かが意図的にApacheライセンスソフトウェアの寄稿を作成者に送信した場合、この寄稿はApacheライセンスの下で自動的に使用できます。

このライセンスは、自動特許ライセンスと寄付の提出に関する条項があるため、興味深いものです。

GPLと互換性があるため、ApacheライセンスコードをGPLソフトウェアに混在させることができます。

BSDライセンス

3つの異なるBSDライセンスがあります。それらはすべて、コピーレフトのない非常に寛容なライセンスです。

2条項BSDライセンス（または簡易BSDライセンス）は、前に説明したMITライセンスと完全に同等です。

3条項BSDライセンス（または新しいBSDライセンス）は、著作権所有者の名前もその貢献者の名前も、書面による事前の特別な許可なしに、ソフトウェアから派生した製品を推奨または宣伝するために使用できないことを指定する1つの条項を追加します。このバージョンはGPLと互換性があり、3節BSDライセンスのコードをGPLソフトウェアに混在させることができます。

4条項BSDライセンス（またはオリジナルBSDライセンス）は、ソフトウェアの機能または使用に言及するすべての広告資料が、製品に著作権所有者によって開発されたソフトウェアが含まれていることを示す確認を表示する必要があることを指定する別の条項を追加します。この4節のBSDライセンスはGPLと互換性がありません。 4番目の条項はGPLで必要とされていない要件を追加するため、このライセンスを持つコードはGPLの条件に従って再ライセンスすることはできません。

GNU劣等一般公衆利用許諾契約書（LGPL）

LGPLは、コピーレフトが弱いGPLの修正として、FSFによって作成されました。これにより、LGPLライセンスのソフトウェアを他のソフトウェアとリンクできるようになります。 LGPLは、その起源では「Library General Public License」の略でしたが、その後、現在の名前は「Lesser General Public License」になり、すべてのソフトウェアは無料である必要があり、そのためLGPLは無料であってはならないというFSFの意見を表しています。一般的に使用されます。

クローズドソースコードをLGPLライブラリまたはソフトウェアにリンクし、次の条件が満たされている限り、最終結果を配布できます。

LGPLされたパーツのソースコードを、それに加えたすべての変更とともに提供します。
十分な知識を持っているユーザーなら誰でも、プログラムのLGPLされた部分を変更されたバージョンに置き換えることができます。これは、プログラムのLGPLされた部分をダイナミックライブラリ（WindowsではDLL、Linux / Unixでは.so）として配布するか、プログラムのLGPLされていない部分のオブジェクトコードを提供することで実行できます。

LGPL v3はGPLv3と互換性があるため、LGPLv3コードをGPLソフトウェアに入力できます。

芸術的許容

現在のバージョン2.0のArtisticLicenseは、MITライセンスと同様に、コピーレフトのない寛容なオープンソースライセンスです。

MITライセンスとArtisticLicenseの主な違いは、Artistic Licenseでは、コードに加えられた変更を明確に記載する必要があることです。

このライセンスは、Perlコミュニティでほぼ独占的に使用されています。

現在のArtisticLicense2.0はGPLと互換性があり、Artistic-LicensedコードをGPLソフトウェアに混在させることができます。

マイクロソフトパブリックライセンス（MS-PL）

Microsoft Public Licenseは、シェアードソースイニシアチブによって作成されたオープンソースライセンスの1つとして、この会社によって2008年に作成されました。

これは厳格で弱いコピーレフトライセンスです。MS-PLコードを使用してクローズドソースプログラムを作成および配布できますが、ソースコードで配布される場合は、派生作品のライセンスとしてMS-PLを使用する必要があります。

個人的には、このライセンスは少しひねくれたものであり、オープンソースの精神に反していると思います。コードを閉じて、著作権所有者がソフトウェアで何ができるかを気にしないようにすることはできますが、できません。他のコピーレフトソースコードと混合するためのコードを共有します。つまり、別の言い方をすれば、著作権所有者はあなたが何ができるかを本当に気にかけていて、Linuxの改善などの理由であなたにコードを使用してほしくないのです。

MS-PLはGPLと互換性がありません。

Eclipse Public License（EPL）

Eclipse Public Licenseは、統合開発環境のためにEclipseFoundationによって作成されたライセンスです。これは制限的で弱いコピーレフトライセンスであり、多くの点でLGPLに似ています。また、自動特許ライセンス付与の条項も含まれています。

EPLはGPLと互換性がありません。

Mozillaパブリックライセンス（MPL）

Mozilla Public Licenseバージョン2.0は、MozillaFoundationがその製品のために作成したコピーレフトの弱いパーミッシブライセンスです。

このライセンスはLGPLに似ていると考えることができますが、MPLでは、MPLされたコードをクローズドソースソフトウェアに静的にリンクできるという主な違いがあります。

MPLは、現在のバージョン2.0ではGPLと互換性があります。これは、以前のバージョンのMPLには当てはまりません。

Common Development and Distribution License（CDDL）

CDDLは、MPLバージョン1.1に基づいてSun（現在はOracle）によって作成された弱いコピーレフトのパーミッシブライセンスです。基本的に、MPLと同じプロパティがあります。その条件は明確にされましたが、実質的に変更されていません。

CDDLは、Sun（現在はOracle）がOpenSolarisやNetBeansなどの多くの製品に対して選択したオープンソースライセンスです。

このライセンスはMPLv1.1に基づいていたため、このライセンスはGPLと互換性がなく、CDDLライセンスのソースをGPLライセンスのソフトウェアに混在させることはできません。多くの人がこれは意図的なものであると言うので、OpenSolarisソースコードをLinuxカーネルに導入することはできません。

GNU Affero General Public License（AGPL）

AGPLはGPLのバージョンであり、コピーレフトはさらに強力で制限があります。アプリケーションのソースコードは、ソフトウェアのコピーを受け取る人だけでなく、コンピュータネットワークを介してこのソフトウェアを使用する人にも提供する必要があります。

このライセンスは、ネットワークサーバーまたはクラウドで実行されるときにオープンソースソフトウェアの実際的な閉鎖を回避する手段を開発者に提供するためにFSFによって作成されました。これは、GPLがサービスプロバイダーにユーザーにソースコードを提供するように強制できないためです。。この場合、ソフトウェアは配布されません。

AGPLv3はGPL3と互換性があります。最終結果がAGPLv3でライセンスされている限り、AGPLv3コードをGPLv3コードに入れることができます。

ISCライセンス

ISCライセンスは、Internet Software Consortium（ISC）によって作成されたパーミッシブフリーソフトウェアライセンスです。不要と思われる言語を削除した後は、機能的には2条項BSDおよびMITライセンスと同等です。

当初はISC自身のソフトウェアリリースに使用されていましたが、その後、他のプロジェクトの中でも特にOpenBSD（2003年6月以降）の優先ライセンスになりました。

GPLと互換性があります。ISCライセンスのコードをGPLソフトウェアに混在させることができます。

Microsoft相互ライセンス（MS-RL）

Microsoft Reciprocal Licenseは、シェアードソースイニシアチブによって作成されたオープンソースライセンスの1つとして、この会社によって2008年に作成されました。

これは前に説明したMS-PLに似ていますが、コピーレフトが少し強く、LGPL、CDDL、およびEPLの条件に似ています。コードをMS-RLライセンスのソースコードと混合し、最終結果を配布する場合は、少なくとも元のMS-RLライセンスの部分が引き続きこのライセンスでライセンスされている必要があります。

GPLとは互換性がありません。

パブリックドメイン（CC0）

ウィキペディアによると、「パブリックドメインでの作品とは、知的財産権が失効した、没収された、または適用されない作品です」。作品をパブリックドメインに捧げる作者は、著作権法に基づいて作品に対するすべての権利を放棄します。

パブリックドメインにはいくつかのソフトウェアプロジェクトがあります。たとえば、SQLiteは、Mozillaプロジェクト、Androidなど、他のいくつかのプロジェクトに含まれている埋め込み可能でシンプルなSQLデータベースエンジンを実装するライブラリです。

ソフトウェアの一部をパブリックドメイン専用にする方法はたくさんあります。 Creative Commonsは、パブリックドメインに作品を提供するための普遍的な方法であるCC0パブリックドメイン献身を作成しました。 FSFは、ソフトウェアをパブリックドメイン専用にするためにこのテキストを使用することをお勧めします。

パブリックドメインでの作品は、オープンソースまたはクローズドソースのライセンスと互換性があり、他のソフトウェアと混在させることができます。

マルチライセンス

ダブルライセンスまたはトリプルライセンスのオープンソースソフトウェアがいくつかあります。これは、このマルチライセンスソフトウェアを受け取った人が、どのライセンスで配布するかを選択できることを意味します。すべてのライセンスは異なる権限を付与し、異なる義務を課すため、ニーズに最適なライセンスを選択するために選択を行う必要があります。

これは、一部のライブラリでは通常のケースです。たとえば、NSSは、他のセキュリティ関連機能の中でも、SSL/TLSサポートを実装するMozillaによって作成されたライブラリです。これは、MPL、GPL、およびLGPLライセンスの下で3回ライセンスされています。

ライセンスを選択してください

多くの人が、書面によるライセンスなしでGitHubとしてプラットフォームでコードを公開しています。誰もそのコードを使用するべきではありません。それを使用するためにどのような権限を持っているのかわかりません。あなたがそれを使うならば、あなたはそのために訴えられるかもしれません。まるで、これらの人々が私たちをからかっていたようです。かっこいいですね。しかし、あなたはそれを使うことができません、私はあなたに見せたかっただけです！」

それらの1つにならないでください。コードをGitHubまたは同様の公開サイトにアップロードする場合は、他の人がコードを使用して拡張できるようにします。あまり考えたくない場合は、次のことをお勧めします。

それをシンプルで寛容に保ち、あなたに帰属を示し、あなたに責任を負わせない限り、誰もがあなたのコードでやりたいことをできるようにしたい場合は、MITライセンスを使用してください。
それを寛容に保ち、誰もがあなたのコードでやりたいことをできるようにしたいが、著作権法に基づく権利を賢明に列挙し、それらの権利を付与し、寄稿者からユーザーに特許権を明示的に付与したい場合は、Apache2.0ライセンスを使用してください。
変更の共有に関心があり、コードをクローズド開発（クローズドソフトウェア製品でもクローズドハードウェアアプライアンスでも）で使用したくない場合は、GPLv3を使用してください。
- ソフトウェアがクローズドアプライアンスで使用される可能性を気にしない場合は、GPLv2を使用してください。ただし、「またはそれ以降のバージョン」の文を使用してください。そうすれば、コードをGPLv3プロジェクトでも使用できます。
- ソフトウェアがクローズドソフトウェアで使用される可能性を気にしない場合は、ソフトウェアまたはそれを使用する部分が同じ条件でオープンソースであり続ける限り、LGPLv3を使用してください。
- ネットワークを介してソフトウェアを使用するすべての人にソースコードを取得する権利を持たせたい場合は、AGPLv3を使用してください。

このすべての後、あなたはこれらのほとんどナンセンスな準合法的な冗談に疲れ果てているかもしれません。しかし、あなたは何を知っていますか？必要です。ライセンスがないと、コードを使用または配布する権利がありません。