序章

ソフトウェアライセンスは、特定のソフトウェアの使用方法を定義する法的契約です。 特定の権利、許可、および作業の使用方法、変更方法、および他のユーザーによる共有方法を制御したいソフトウェア開発者にとって、ソフトウェアライセンスを選択することは重要な決定です。 一部の開発者は、ソフトウェアの使用方法に強い制限を課したいと思うかもしれません。 ただし、制限がほとんどないかまったくないソフトウェアのライセンスを選択する場合もあります。 これは、ソフトウェアをできるだけ広く使用することを望んでいるためか、哲学的な理由で制限的なソフトウェアライセンスに反対しているためである可能性があります。

理由に関係なく、開発者はオープンソースソフトウェアライセンスを実装することでこれを実現できます。 大まかに言えば、オープンソースソフトウェアライセンスは、合意された条件に基づいて、ソースコードを使用、変更、および配布できるようにします。 さまざまなオープンソースソフトウェアライセンスがあり、それらは、作成者が将来のユーザーに遵守してもらいたい制限に基づいて異なります。

プロジェクトの長期計画に関しては、利用可能なオープンソースソフトウェアライセンスを理解しておくと、プロジェクトのニーズに最適なライセンスを十分な情報に基づいて決定できるので便利です。 この記事では、作品の作成時に所有する権利（著作権など）と、ソフトウェアを使用する際にユーザーに遵守してほしい法的合意をライセンスが確立するのにどのように役立つかについての情報を共有します。 また、プロプライエタリ、フリー、オープンソースソフトウェア、許容ライセンスとコピーレフトライセンスの違い、およびGitHubプロジェクトの作成時に提案されたオープンソースソフトウェアライセンスオプションに関する情報についても説明します。

注：この記事は法律上のアドバイスを提供することを目的としたものではなく、オープンソースソフトウェアライセンスのトピックに関する情報のリソースにすぎません。

特許、商標、および知的財産について詳しく知りたい場合は、次のWebサイトにアクセスしてください。 私たち 特許商標庁 。

米国で そして多くの国では、あなたが制作する創造的な作品に対して自動的に付与される特定の法的保護があり、その1つが著作権です。 アメリカ 著作権局は、著作権を「原作者の著作物を保護する一種の知的財産」と定義しています。特に、「著作者が具体的な表現形式で著作物を修正する場合」です。 これは、著作権であなたがアイデアの所有者ではなく、アイデアの物質的な表現であることを意味します。 著作権所有者が自分の作品に対してより厳格な法的保護を希望する場合、これは特許、商標、および知的財産法を通じて達成できます。 あなたの作品を著作権で保護することは、これらの権利が与えられることを確実にするための正式なプロセスを必要としません。

著作権は、著作物の複製や配布など、所有者にさまざまな権利を付与します。 所有者が自分の作業を他の人がどのように使用できるかを制御したい場合は、それらのユーザーが従う必要のあるルールの概要を示すライセンスを実装する必要があります。 著作権所有者が作品を「無断複写・転載を禁じます」と述べている場合、これは、自分以外の誰もが自分の作品を使用または変更できないことを意味します。

認めるべきもう1つの複雑さは、雇用主のために作成する創造的な仕事です。 職務著作と呼ばれるものに従事している場合、これは、あなたが働いている会社または組織のために作成したすべての仕事は、その仕事に対してあなたにお金を払っているので、そのエンティティに属することを意味します。 結果として、あなたには著作権またはライセンスの所有権がないため、許可なくこの作品を共有することは法的な結果をもたらします。

プロプライエタリソフトウェア、フリーソフトウェア、およびオープンソースソフトウェア

プロプライエタリソフトウェアは、使用、変更、または共有の方法を制限するライセンスを持つソフトウェアです。 ビデオゲームは、プロプライエタリソフトウェアの一般的な例です。 ビデオゲームを購入した場合（カートリッジ、ディスク、デジタルダウンロードのいずれであっても）、そのゲームのコピーを作成して友人と共有したり、営利目的で販売したりすることはできません。 また、ゲームのコードを変更して、最初に購入したプラットフォームとは異なるプラットフォームで実行することは許可されていない可能性があります。

ソフトウェアユーザーは通常、エンドユーザーライセンス契約（EULA）によって特定の制限が課せられます。 ソフトウェアを購入したことがある場合は、そのソフトウェアを所有していると思っているかもしれません。 ただし、プロプライエタリソフトウェアを購入した場合は、そのソフトウェアを所有していないことを指定するEULAが付属している可能性があります。 代わりに、あなたはそのソフトウェアの使用を許可するソフトウェアライセンスの所有者です。 EULAは、ライセンス自体の使用方法も定義する場合があり、通常、ソフトウェアの所有者（ソフトウェアの開発者または発行者）の許可なしに他のユーザーとライセンスを共有することを制限します。

EULAに類似したもう1つの法的文書は、利用規約（ToS）です。 利用規約または利用規約とも呼ばれるToSは、プログラムまたはサービスの使用を許可するためにユーザーが従う必要のあるルールの概要を示しています。 1回限りの購入が必要なソフトウェアにEULAが含まれているのが一般的ですが、サブスクリプションサービスやWebサイトではToS契約がより一般的です。 多くの場合、特定のプロプライエタリソフトウェアを初めて起動すると、EULAまたはToSについて説明し、使用する前にクリックする必要がある I同意ボタン（または同様のもの）を含むダイアログボックスが表示されます。プログラム。

このような制限のあるソフトウェアは、常に標準であるとは限りません。 1970年代以前は、ソフトウェアは通常、ソースコードとともに配布されていました。つまり、ユーザーはソフトウェアを自由に変更して共有することができました。 しかし、時間の経過とともに、ソフトウェア発行者はこれらの活動に制限を課し始めました。これは通常、ソフトウェアを使用したが料金を支払わなかった人の数を減らすことで利益を増やすことを目的としています。

この開発には、2つの密接に関連した動き、つまり自由ソフトウェアとオープンソースソフトウェアの動きという形で影響がありました。 この2つは異なりますが、フリーソフトウェアとオープンソースソフトウェアの動きはどちらも、ソフトウェアユーザーがプログラムのソースコードにアクセスし、適切と思われるように変更し、何度でも好きな人と共有できるようにする必要があると主張しています。

注：一般にフリーソフトウェアはオープンソースと見なされますが、オープンソースソフトウェアは必ずしも無料とは見なされないため、このガイドではデフォルトで「オープンソースソフトウェア」と「オープン」というより包括的な用語を使用します。 -ソースソフトウェアライセンス」を前進させます。 ただし、2つの用語は常に交換可能であるとは限らないことに注意してください。

フリーソフトウェアとオープンソースソフトウェアの歴史と違いについてさらに詳しく説明したい場合は、フリーソフトウェアとオープンソースソフトウェアの違いに関する記事を読むことをお勧めします。

オープンソースソフトウェアの支持者は、開発者にライセンスを使用してソフトウェアを配布することを引き続き推奨しています。 ただし、ユーザーが実行できないことを概説するプロプライエタリソフトウェアライセンスの代わりに、特定のソフトウェアのユーザーが利用できる自由を概説するオープンソースソフトウェアライセンスを使用することをお勧めします。 これらのライセンスは、多くの場合、プログラム内で単一のファイルとして配布されます。 LICENSE.txt または同様の命名規則。

何年にもわたって、オープンソースソフトウェアライセンスによってどのような特定の自由が保証されるべきかについて、いくらかの意見の相違がありました。 これにより、多くの異なるオープンソースライセンスが出現しましたが、これらのほとんどは、許可ライセンスとコピーレフトライセンスの2つのカテゴリのいずれかに分類できます。

許容およびコピーレフトのオープンソースソフトウェアライセンス

パーミッシブライセンスは、非コピーレフトライセンスと呼ばれることもあり、ソースコードの使用、変更、共有をユーザーに許可しますが、ユーザーは一部を変更することもできます。 派生物を含む再配布の利用規約。 ソフトウェアのコンテキストでは、二次的著作物は、既存のプログラムに基づくソフトウェアの一部です。 オリジナルがパーミッシブライセンスの下でリリースされた場合、作成者は、オリジナルの作品のライセンスが必要としていたものとは異なる条件で派生物を共有することを選択できます。

コピーレフトライセンスは、ソースコードの使用、変更、および共有の許可もユーザーに付与しますが、特定の制限および条件を通じて再ライセンスに対する保護を提供します。 つまり、二次的著作物を作成するソフトウェアユーザーは、元の著作物と同じコピーレフトライセンス条件の下でリリースする必要があります。 この相互性は、コピーレフトライセンスの定義的な側面であり、元のソフトウェアから派生した作品を使用するときにユーザーが同じ権利と権限を持つことを保証することにより、作成者の意図を保護することを目的としています。

さらに、パブリックドメインに相当するライセンスがあり、帰属や必要なライセンス互換性なしに著作権で保護された作品を使用する許可をユーザーに付与します。 クリエイターにとって、これは彼らの作品に対するいかなる権利も完全に没収されることを意味します。 パブリックドメインとフリーおよびオープンソースのソフトウェアライセンスの背後にある哲学にはいくつかの重複がありますが、パブリックドメインと同等のライセンスが本当にオープンソースとして適格であるかどうかについては長年にわたって意見の相違がありました。 2012年に、 CC0 ライセンスが提出されましたが、オープンソースソフトウェアの標準を定義し、承認されたオープンソースライセンスのリストを維持している非営利組織であるOpen Source Initiative（OSI）による承認を最終的に拒否しました。 ただし、OSIは、2020年にUnlicenseと呼ばれるパブリックドメインに相当するライセンスを承認しました。

なぜオープンソースソフトウェアライセンスを含めるのですか？

プロジェクトを最初から開始する開発者として、他の人に自分の作業をどのように使用してほしいかを評価するために利用できるオープンソースソフトウェアライセンスにある程度精通していることが重要です。 これらのライセンスを認識することは、ユーザーが作成者の作品を使用するときに締結した契約によって設定された許可または制限を理解できるようにするためにも重要です。

繰り返しになりますが、オリジナルの作品は完成時に著作権がありますが、ライセンスがないと、それを使用したい人に何が許可され、何が許可されないかが不明確になります。 オープンソースソフトウェアライセンスを含める理由は次のとおりです。

  • 改善：オープンソースコミュニティは、コラボレーションとイノベーションを促進する文化を育むことに誇りを持っています。 オープンソースソフトウェアライセンスを使用すると、ユーザーはコミュニティ開発に参加できます。 これにより、ソースコードを一貫して改善したり、プログラムをさらに拡張してすべての人の利益になるという共通の責任感が生まれます。

  • 所有権：仕事に対してより強力な力を行使したい場合は、それらの制限を課すことができるライセンスを選択すると、そうするのに役立ちます。 たとえば、派生物に最初に選択したものと同じ権限を付与する場合は、コピーレフトライセンスを選択することをお勧めします。 幸いなことに、オープンソースソフトウェアライセンスは、将来のユーザーに、作業の量が多いか少ないかにかかわらず、作業をどの程度制御できるかについての透明性を提供します。

  • 競争：そこにはたくさんのソフトウェアがあり、その市場に参入したいのであれば、オープンソースライセンスを使用することで地図に載ることができます。 確立された独自の代替手段と競合するために開発されたオープンソースソフトウェアの人気のある例には、Linuxオペレーティングシステム、Android by Google、Firefoxブラウザなどがあります。

オープンソースソフトウェアプロジェクトを収益化することは可能ですが、ソフトウェアを収益化するための一般的なビジネス慣行は、ソフトウェアの共有や盗難からソフトウェアを保護するためにプロプライエタリライセンスを使用することです。

オープンソースソフトウェアライセンスを使用するこれらの理由は、すべてが当てはまるとは限りません。次のプロジェクトのライセンスを選択する前に、このテーマについて独自の調査を行うことをお勧めします。 さらに、現在および将来のあなたの仕事にとってライセンスが何を意味するのかを完全に理解していることを確認するために、法律専門家の支援を求めることもできます。

前述のように、この記事では、GitHubでプロジェクトの新しいリポジトリを作成するときにリストされるオープンソースソフトウェアライセンスに焦点を当てています。 ページの最後に、ライセンスを選択するためのオプションがあります。 ボックスをクリックすると、次のように、ライセンスのドロップダウンリストが表示され、そこから選択できます。

次のセクションでは、GitHubが推奨するパーミッシブライセンスから始めて、次のプロジェクトで選択できるオープンソースソフトウェアライセンスの種類について簡単に説明します。

パーミッシブオープンソースソフトウェアライセンス

パーミッシブライセンスは、ソフトウェアユーザーに、ソースコードを使用、変更、および共有するためのアクセス許可を付与します。 さらに、パーミッシブライセンスソフトウェアから派生したソフトウェアの作成者は、再配布のライセンス条件を変更できます。

以下のリストは、利用可能なすべてのパーミッシブオープンソースソフトウェアライセンスを代表するものではないことに注意してください。 むしろ、このリストは、新しいプロジェクトを開始するときにGitHubによって提供されるライセンスオプションから取得されます。 また、これらの簡単な説明は包括的ではありません。 詳細については、使用したいライセンスのドキュメントを注意深く読んだり、法律専門家に相談したりすることをお勧めします。

Apacheライセンス

Apacheライセンスは、 Apache Software Foundation（ASF）によって作成されています。 このライセンスでは、ユーザーは同じライセンスで変更されたバージョンのソースコードを共有する必要がなく、別のライセンスを使用することを選択できます。これはサブライセンスと呼ばれます。

MITライセンス

MITライセンスはマサチューセッツ工科大学（MIT）からのものであり、ほとんど制限なしで読むのに最も短いものの1つです。 Apacheライセンスと同様に、ソフトウェアをサブライセンスするオプションもユーザーに提供します。

BSDライセンス

GitHubでは、2つのBSDライセンス、 BSD 2-Clause「Simplified」ライセンス（「FreeBSD」ライセンスと呼ばれることもあります）から選択できます。 およびBSD3-条項「新規」または「改訂」ライセンス。 これら2つのライセンスの主な違いは、3節です。 この条項は、ソフトウェアユーザーが製品またはサービスを推奨するために、作成者、作成者、または寄稿者の名前を使用することを制限します。

ブーストソフトウェアライセンス

Boostソフトウェアライセンスは、C ++のBoostライブラリからのものであり、2008年にOSIによって承認されました。 このライセンスは、バイナリ形式で再配布するときにアトリビューションを必要としないことを除いて、MITおよびBSDライセンスに似ています。

コピーレフトオープンソースソフトウェアライセンス

コピーレフトライセンスは、ソフトウェアユーザーにソースコードの使用、変更、共有の許可を与えるだけでなく、特定の制限や条件を通じて再ライセンスから保護します。 これは、このライセンスの相互特性を表しており、ユーザーの作業は、ライセンスに概説されている元の権利を順守する必要があります。

繰り返しになりますが、以下のリストは、利用可能なすべてのコピーレフトオープンソースソフトウェアライセンスを代表するものではありません。 むしろ、このリストは、新しいプロジェクトを開始するときにGitHubによって提供されるライセンスオプションから取得されます。 また、これらの簡単な説明は包括的ではありません。 詳細については、使用したいライセンスのドキュメントを注意深く読んだり、法律専門家に相談したりすることをお勧めします。

GNUライセンス

Free SoftwareFoundationによってリリースされたGNUGeneral Public License （GPL）にはいくつかのバージョンがあり、そのうちの4つはGitHubで選択できます。 GPL v3.0 では、ユーザーは元のコードに変更を加え、そのライセンスされたソフトウェアの下で作業に使用されるバイナリを配布するときに元のコードを利用できるようにする必要があります。 このライセンスにより、以前のバージョン（v2.0）には互換性がなかったApacheなどの他のライセンスの操作も簡単になりました。

現在のGPLv3.0バージョンの前に、2番目のバージョンである GNU Public Licensev2.0が作成されました。 このライセンスはv3.0と同様の契約条件を共有していますが、強力なコピーレフトライセンスと見なされます。 強力なコピーレフトライセンスでは、ソースコードへの変更を同じライセンスを使用してリリースする必要があります。 v2.0との主な違いは、ソフトウェアユーザーは、以前の法的義務に関係なく、ライセンスの要件に準拠している場合に作業を配布できることです。 この条項の目的は、個人または当事者が、このライセンスに基づくユーザーの自由を制限する特許侵害の申し立てを提出することを防ぐことです。

LGPLと呼ばれるGNU劣等一般公衆利用許諾契約書や、GPLv2.0のv2.1もあります。 このライセンスは、強力なコピーレフトライセンスと弱いコピーレフトライセンスの中間として機能することを目的としています。 このライセンスとの主な違いは、ソフトウェアユーザーがLGPLのソフトウェアコンポーネントを独自のコンポーネントと組み合わせることができ、独自のコンポーネントのソースコードを共有する必要がないことです。 ユーザーは、LGPLライブラリの関数と非LGPLの関数を組み合わせたハイブリッドライブラリを配布することもできますが、その非LGPLライブラリのコピーとその場所に関する情報が必要です。

もう1つのGNUライセンスは、 GNU Affero General Public License v3.0 であり、AGPLと呼ばれます。 このライセンスとの主な違いは、サーバーで使用されるソフトウェアプログラムに固有であるということです。 このライセンスでは、サーバー上で変更されたプログラムを実行するユーザーがこの情報を共有し、サーバー上で現在実行されている関連する変更されたバージョンに変更されたソースコードをダウンロードできるようにする必要があります。

Eclipseパブリックライセンス

Eclipse Public License は、Eclipse Foundationからのものであり、 weakcopyleftライセンスと見なされます。 弱いコピーレフトライセンスでは、ソフトウェアユーザーがコードに加えた変更を共有する必要があります。 このライセンスは、ユーザーがGNUの一般公開ライセンスで遭遇するより厳しい要件を軽減する方法として、より弱いコピーレフトを実装することを選択しました。

Mozillaパブリックライセンス

Mozilla Public License 、またはMPLは、 Mozilla Foundation からのものであり、弱いコピーレフトライセンスとも見なされます。 このライセンスとの違い（Eclipse Public Licenseとの比較）は、ファイルベースのコピーレフトであるということです。つまり、コードをオープンソースまたはプロプライエタリコードと組み合わせることができます。

パブリックドメインと同等のライセンス

パブリックドメインに相当するライセンスは、帰属または必要なライセンス互換性なしに著作権で保護された作品を使用する許可をユーザーに付与します。 ご存知かもしれませんが、これらのライセンスは必ずしもOSI承認されているわけではありません。

クリエイティブコモンズゼロユニバーサルライセンス

クリエイティブコモンズゼロユニバーサルライセンスは、クリエイティブコモンズによって作成され、パブリック著作権ライセンスと見なされます。 これは、著作権で保護された作品を自由に配布できることを意味します。 このライセンスはOSI承認されていないことに注意してください。 このライセンスの主なポイントは、ユーザーがソースコードを使用、配布、および変更できることですが、パブリックドメインでこの作品にアクセスできるようにするには、著作権を放棄することに同意する必要があります。 さらに、ユーザーは作品への帰属を提供する必要はなく、商業的に使用することができます。

Unlicense

Unlicense は2012年にリリースされ、OSI承認済みのパブリックドメインと同等のライセンスと見なされます。 このライセンスにより、ソフトウェアユーザーは、商用目的と非商用目的の両方で、ソースコード、およびコンパイル済みバイナリを使用、変更、配布できます。 このライセンスはまた、コードベースをパブリックと共有することへのコミットメントについての声明を含めることにより、コードまたはソフトウェアへの貢献がパブリックドメインで利用可能であることを保証したいユーザーにアドバイスします。

結論

オープンソースソフトウェアライセンスを選択する際に考慮すべき多くの要因があります。 それでも、開発者コミュニティの間には確かに人気のある選択肢があります。 一般的なパーミッシブライセンスには、MITライセンス、Apacheライセンス、およびBSDライセンスが含まれます。 一般的なコピーレフトライセンスには、GNU GeneralPublicLicenseとMozillaPublicLicenseが含まれます。

この記事では、いくつかの一般的なオープンソースソフトウェアライセンス、特にGitHubによって提案されたライセンスに関する情報のみを提供したことを忘れないでください。 利用可能なすべてのライセンスオプションを検討するか、法律専門家の助けを借りて、プロジェクトのニーズに最適なものについて情報に基づいた決定を行うことをお勧めします。