OSSのライセンスについて解説する記事
はじめに
今回の記事では、OSSのライセンスの種類と、OSSにライセンスが必要な理由を解説する。今後OSSに貢献―いわゆる、コントリビュートする上でライセンスに関する知識は必要不可欠だ。
対象とする読者
- OSS活動に興味あるひと
- ライセンスについて曖昧な理解で終わっているひと
- OSSを実務で導入したいひと
- 普段OSSへ貢献しているひと
- タイトルで気になったひと
ライセンスとは？
OSSのライセンスに関する話をする前に、まず「ライセンス」の意味を理解しなければならない。ライセンスとは、Wikipediaによると以下のように記述されている。
ライセンス（米: license、英: licence）は、それが存在しなければ違法となる行為をすることを許可すること、あるいはその許可を証する書面のことをいう。(中略)
元来、英語の"license"には医師免許などのように行政機関が交付する法制度上の免状などが含まれる。
ただ、IT分野における「ライセンス」はソフトウェアのプログラムを開発した著作者が、他者が入手したり利用したりする際の条件をまとめた文書を意味することが多い。他にも、ライセンスにはソースコードが公開され、誰でも自由に入手、使用、改変などができるOSSの利用条件が記載されている文書を意味することがある。GitHubのLICENSE.txtがそれの代表例だ。
▼画像1 Pythonの公式GitHub。GitHubに公開されているOSSのライセンスは原則LICENSE.txtに記載されている。
今回の記事では、OSSのライセンスにフォーカスしてライセンスを表記する理由とライセンスの種類について解説する。
ライセンスがOSSに必要な理由
なぜライセンスがOSSに必要だろうか？主な理由として、以下のようなことが考えられる。
- 利用者への権利と義務を明示するため
- ソフトウェアを法的に保護するため
- 共同開発のルールを決めるため
- 互換性と相互運用性を担保するため
- 知識を共有したり、コミュニティに貢献したりできるため
それぞれ順番に解説する。
利用者への権利と義務を明示するため
ライセンスは、利用者がOSSを使ってできることやしなければならないことを明示する。これにより、利用者はOSSを安全に利用でき、原著作者は期待通りにOSSを運用できる。
ソフトウェアを法的に保護するため
ライセンスにより、OSSの開発者は自身の作品に対する法的な権利を保持できる。
共同開発のルールを決めるため
オープンソースのプロジェクトでは、世界中のエンジニアが協力してコードを開発する。共同で開発するルールをライセンスで明記することで、開発者間のトラブルを未然に防止できる。
互換性と相互運用性を担保するため
異なるオープンソースプロジェクトが互いに組み合わさる場合、ライセンスの互換性が鍵となる。ライセンスを明示することで、他のプロジェクトとの組み合わせが可能かどうかを判断できる。
知識を共有したり、コミュニティに貢献したりできるため
ライセンスを明記することは、ソフトウェアが自由に利用、改変、再配布できることを意味する。これは、エンジニアどうしの知識の共有やコミュニティへの発展に大きく寄与する。
ライセンスがないとどうなるのか？
前章ではライセンスを公開するべき理由を解説した。本章では、ライセンスがないとどうなるのかを考察する。
著作権法第十条一項九号によると、プログラムは漫画や書籍と同様に、著作権法の保護対象になる。それ故に、ライセンスが定められていないプログラムはその著作者から明示的に許可を受けない限り、ソースコードを改変などできないのだ。
ライセンスがないプログラムを無断で再頒布したり改変したりするのは、そのプログラムの著作権を侵害することを意味する。故に、本来の著作者からの申し出によって削除されたり、訴訟されたりするリスクが生じる。
そのような、法律に反した状態やいつ削除されるかわからない状態では、エンジニアは積極的にプログラムの開発に参加できない。ライセンスでプログラムの修正等が許可されていなければ、コミュニティによる活発なソフトウェア開発ができない。
このように、自分の著作物に誰もがアクセスできるようにするためには、ライセンスでプログラムを自由にコピーしたり改変したりすることを許可しなければならない。
主なライセンス
OSSのライセンスは数多く存在し、それぞれが異なる権利と制約を持つ。
MIT License
MIT Licenseは非常にシンプルで制約が少ないオープンソースライセンスだ。このライセンスでは、ソフトウェアのコピー、変更、再配布が許可される。ただし、ソフトウェアのすべてのコピーにはライセンスと著作権表示が必要だ。商用利用やプロプライエタリソフトウェアとの組み合わせも許可されている。
GNU General Public License (GPL)
「コピーレフト」ライセンスの一種で、ソフトウェアの自由な使用、変更、共有を保証します。GPLでライセンスされたソフトウェアを変更し、再配布する際には、変更されたソフトウェアもGPLの下で公開されなければならない。これにより、自由なソフトウェアの普及が促進される。
Apache License 2.0
ソフトウェアの使用、変更、再配布を許可するライセンス。このライセンスは特許に関する条項を含み、著作権表示と変更履歴の維持が求められる。また、商用利用や他のライセンスのソフトウェアとの組み合わせが可能だ。
BSD License
非常に柔軟で制約が少ないライセンスであり、MITライセンスと似ている。主に2-clause、3-clause、4-clauseのバリエーションがある。これらのバリエーションは、ソフトウェアの再配布にあたっての著作権表示の義務や、使用者による開発者の名前の利用に関する制約等に違いがある。商用利用や他のライセンスのソフトウェアとの組み合わせも許可されている。
MIT Licenseとの最大の違いは追加条件にある。MITライセンスは、著作権表示とライセンス表示をソフトウェアのすべてのコピーに含めることを要求する。一方で、BSD Licenseはその条件に加えて、「無保証条項」に関する明示的な表示を要求し、開発者の名前を商品の宣伝に使わないことも要求する。
Creative Commons (CC)
Creative Commonsは、オープンソースソフトウェアライセンスではなく、主に著作物に用いられるライセンスだ。著作権者が自分の作品を公開する際に、一定の権利を保持しつつ、他人にどのように作品を利用させるかを選択できる。異なるバージョンや構成要素（Attribution、ShareAlike、NonCommercial、NoDerivatives）を組み合わせることで、様々なタイプのCCライセンスを生成できる。
Eclipse Public License (EPL)
Eclipse Public License (EPL)は、Eclipse Foundationによって公開されたオープンソースライセンスだ。ユーザーはソフトウェアの使用、変更、再配布ができる。EPLの特徴的な点は、変更部分のソースコードの公開が要求される点にある。これによってコミュニティ全体が発展できます。また、EPLは、特許に関するクリアな条項も含む。
Mozilla Public License 2.0 (MPL)
Mozilla Foundationによって作成されたオープンソースライセンスで、ソフトウェアの改変と再配布を許可する。MPLは、改変したファイルについてのみソースコードの公開を要求する。それ故に、部分的にプロプライエタリ――いわゆる、特定の個人等が所有権を持ち、著作権で保護されるソフトウェアの開発もできる。所有権とオープンソースを両立できるライセンスと言えよう。
GNU Affero General Public License (AGPL)
GNU Affero General Public License (AGPL)は、GPLと非常に似ており、コピーレフトの原則を採用している。ところが、ネットワーク経由での利用時にもソースコードの公開を要求する。これにより、Webアプリケーションのサービス提供者も、利用者にソースコードを提供しなければならない。
GNU Lesser General Public License (LGPL)
GNU Lesser General Public License (LGPL)は、GPLと同じくコピーレフト[1]のライセンスだ。同じ「GPL」でも、GPLよりも柔軟性が高い。このライセンスでは、GPLライセンスのソフトウェアの改変版や派生物もGPLライセンスとして公開しなければならない。言い換えれば、LGPLのソフトウェアはそのソフトウェア全体をオープンソースとして公開する必要はないことになる。
Unlicense
Unlicenseは著作権をパブリックドメインにするためのライセンスだ。著作権者はすべての著作権と関連する権利を放棄し、作品を制約なしに使用、変更、再配布できる。要は、著作権がない状態を意味する。
余談だが、冒頭の"un"は「打ち消し」を意味する英語の接頭辞である。
おわりに
今回の記事ではOSSのライセンスの意義と種類の説明をした。私たちエンジニアが作ったプログラムにライセンスを整備することは、ソフトウェア開発の未来を閉ざさないための行為である。
8年前(2015年)のGitHubの調査によると、GitHubにアップされているプロジェクトのうち、およそ20%にしかライセンスが設定されていないそうだ。
ライセンスを設定することは良質なソフトウェア開発を行う上で必須である。私たちエンジニアは、自分の興味ある技術以外に、ソフトウェアのライセンスについて学ばなければならない。これからOSS活動への参加を検討しているエンジニアは、まずライセンスを深く学ぶことから始めよう。
余談：「オープンソース」とは？
「オープンソース」の定義は、Open Source Initiativeが出しているThe Open Source Definitionで定められている。ここでは、自由な再頒布や祖父手とウェアを変更したものを同じライセンスで配布できることなど、10の項目をすべて満たすものを「オープンソース」と呼ぶ。
利用者が誰でも入手や改変ができるようにすることで、ソフトウェアをより良いものにするという考えがOSSの基本的な理念だ。
参考サイト一覧
-
コピーレフト(Copyleft)は、プログラム(もしくはその他の著作物)を自由(自由の意味において。「無償」ではなく)とし、加えてそのプログラムの改変ないし拡張されたバージョンもすべて自由であることを要求するための、一般的な手法の一つである。参照：https://www.gnu.org/licenses/copyleft.ja.html ↩︎
Discussion