技術

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

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

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

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

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

ビジュアルデザイナーは何をしますか

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

オープンソース：自由のように無料

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

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

オープンソースソフトウェアの一般的なプロパティ

オープンソースはしません

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

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

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

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

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

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

コピーレフト

強いコピーレフトと弱いコピーレフト

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

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

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

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

許容性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オープンソースライセンスの異なる機能

次に、最も人気のあるオープンソースライセンスを分析し、それらの機能の違いに注目し、それらをいつ使用するかどうかについての簡単なガイドを示します。使用量の多いものから少ないものへと並べ替えました。ブラックダックナレッジベース。

GNU General Public License（GPL）

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

その異なる特性：

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

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

現在、v2とv3の2つのバージョンのGPLライセンスが使用されています。バージョン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ライセンス Apache Software Foundation（ASF）によってApacheHTTPサーバーのライセンスとして作成されました。

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は元々「LibraryGeneralPublic License」の略でしたが、その後、現在の名前は「Lesser General Public License」になり、すべてのソフトウェアは無料である必要があり、そのためLGPLは無料であってはならないというFSFの意見を表しています。一般的に使用されます。

クローズドソースコードをLGPLライブラリまたはソフトウェアにリンクし、次の場合に限り最終結果を配布できます。

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

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

芸術的許容

ザ・芸術的許容、現在のバージョン2.0では、MITライセンスと同様に、コピーレフトのないパーミッシブオープンソースライセンスです。

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

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

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

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

ザ・マイクロソフトパブリックライセンスシェアードソースイニシアチブによって作成されたオープンソースライセンスの1つとして、この会社によって2008年に作成されました。

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

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

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

Eclipse Public License（EPL）

ザ・ Eclipseパブリックライセンスは、EclipseFoundationが統合開発環境用に作成したライセンスです。これは、LGPLと多くの点で類似している、制限的でコピーレフトの弱いライセンスです。また、自動特許ライセンス付与の条項も含まれています。

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

Mozilla Public License（MPL）

ザ・ Mozillaパブリックライセンスバージョン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のバージョンです。アプリケーションのソースコードは、ソフトウェアのコピーを受け取る人々だけでなく、コンピュータネットワークを介してこのソフトウェアを使用する人々にも提供する義務があります。

aws認定ソリューションアーキテクトアソシエイト

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

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

ISCライセンス

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

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

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

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

ザ・マイクロソフト相互ライセンスシェアードソースイニシアチブによって作成されたオープンソースライセンスの1つとして、この会社によって2008年に作成されました。

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

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

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

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

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

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

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

マルチライセンス

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

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

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

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

ライセンスは贅沢ではありません、それ

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

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

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