Nishiki-Hub

国内外のPC/PCパーツ/スマホ/Appleなどの最新情報を取り上げています

OSSの主流ライセンスをまとめてみる

個人的にすごくわかりにくい話として「オープンソースソフトウェア」(OSS)のライセンス問題。今回は、主流なライセンスの違いなどをある程度まとめておこうかと思いまして。

不定期「Step-ZERO」

このシリーズでは、読者の皆様がなにかを調べる「最初の段階」となる内容をまとめています。この記事で完結するもよし、ここから更に調べるもよし

免責事項

ライセンスについて、著者は法律家でもなんでもありません。なので、この記事も正しいとは限りません。あくまでも大枠さえ掴んでいただければと思います。

つまり、実際に使うときはもっとよく調べてくれってことです。ここに書いてあるやつはできる限りの正確性を追求しましたが、絶対正しいとは言いません。

責任は負いません。

MITライセンス

MITライセンスは、マサチューセッツ工科大学発のライセンスで非常にわかりやすいものになっています。

めっちゃわかりやすく説明すると「無制限で使っていいし、改変改造しても問題ない。ただし、重要なファイル、又は複製したソースコードのすべてに著作権表示をしMITライセンスであることを示さなければならない(実際には著作権表示をそのまま掲載する必要がある)。そして何があっても責任は負わない」というもの。もっとかみくだくと、「著作権表示さえすれば何やってもいいよ!責任追わないけどね!」っていうライセンスです。

個人的に公開して配布する系のソースコードには基本的にMITライセンスを適用するようにしています。理由としてはやはり、私自身が理解できるから。

MITライセンスでは、ソースコードの公開が必須ではないことから、プロプライエタリソフトウェアでも利用されます。

BSDライセンス

BSDカルフォルニア大学発のライセンス形態でいくつかのバリアントがあるライセンス形態です。

この4つが大体すべてです。実際には、これとあともう一つ、最初期に利用されていたBSDライセンスがあるのですが、現在使われてない上、資料がほとんどなく正確性に自身がないので割愛します。同様に一条項BSDライセンスも割愛します。

四条項BSDライセンス

四条項BSDライセンス(4-clause BSD license)は別名「オリジナルBSDライセンス」や「旧BSDライセンス」と呼ばれるものです。つまりこれらは同じ意味を指します(初期ライセンスという名称が用いられている場合もあるのですが、どうやら先述の最初期に利用されていたBSDライセンスも初期ライセンスが用いられることがあるようです)。

四条項とあるとおり4つの条項からなるライセンスです。

  1. ソースコードの再配布は、著作権表示*1、列挙された条件、免責条項を保持すること
  2. バイナリの再配布の場合は、著作権表示*2、列挙された条件、免責条項をドキュメントや資料で配布すること
  3. このソフトウェアの機能に言及するまたは使用するすべての広告資料には、次の表示をする必要がある:This product includes software developed by the <copyright holder>(この製品は<著作権保有者>によって開発されたソフトウェアを含んでいます。)
  4. 著作権保有者> の名前もその寄稿者の名前も、書面による事前の特別な許可がない限り、このソフトウェアから派生した製品を推奨または宣伝するために使用することはできない

簡単にまとめると

  • 配布してもいいけど、このライセンス文を書け
  • 謝辞を書け
  • 謝辞以外の宣伝で俺等の名前を許可なく使うな

となります。

特徴としては第3条があること。この第3条は宣伝条項と呼ばれるものです。宣伝条項とは「使っていいけど謝辞を書いてね。」という条項ですが、これは大きなプロジェクトで謝辞が極端に多くなること、後述するGPLと矛盾するため互換性がなくなることとして問題となりました。それを解消したのが三条項BSDライセンスであり、この四条項BSDライセンスは廃止されています。

三条項BSDライセンス

三条項BSDライセンス(3-clause BSD license)別名「修正BSDライセンス*3は四条項BSDライセンスから第3条(宣伝条項)を消したものです。なので、四条項BSDライセンスを説明した現時点でこれ以上なにかを説明することがありません。

ライセンスで書かれているのは以下の通り。

  • 配布してもいいけど、このライセンス文を書け
  • 宣伝で俺等の名前を許可なく使うな

宣伝条項をなくしたため、GPLとの互換性が保たれるようになり、併用することが可能になりました。

このライセンスの派生として「BSD-3-Clause-No-Nuclear-Warranty」というものがあります。これは原子力発電所で使うことを目的に三条項BSDライセンスを改良したライセンスです。

二条項BSDライセンス

二条項BSDライセンス(2-clause BSD license)は別名「FreeBSD License」とも呼ばれるライセンスで、三条項BSDライセンスから第3条(著作権保有者や寄附者の名前を勝手に使うな)を削除したライセンスです。別名にあるとおり使用場面は限定的ですが、特許版の派生があります。

0条項BSDライセンス

0条項BSDライセンス(0-clause BSD license)は、BSD派生ではなくISC派生で、別名「Free Public License 1.0.0」です。パブリックドメインのライセンスとなっており、基本的にかなり自由であるというのが特徴です。

超簡単に説明すると「責任負わないけど何やってもいいよ。」となります。著作権表示に関する明示的な規定もありません。

GPL

GPLは「GNU General Public License」、日本語名では「GNU 一般公衆利用許諾契約書」と呼ばれるライセンスです。GNUとあるようにフリーソフトウェア財団(Free Software Foundation/FSF)が作成しています。

GPLの解説の前に、理解を促すことを目的としてGNUの考え方について触れます。GNUは元々はOSであり、Unixと同じ設計であるがUnix由来のコードを一切含まないものとして作られました。現在では、GNUプロジェクト下で様々なフリーソフトウェアが作られています。FSFは、すべてのソフトウェアは自由ソフトウェアであることを目標に活動しています。つまり、GNUWindowsmacOS、MP3やAACのようなプロプライエタリなソフトウェアや規格をオープンなものにするということが目標であり、GPLにもそれが反映されています。

ただ、GPLはこのGNUイデオロギーが大きく反映されているため、条文が分かりづらくなっています。

GPLは、FSFGNUの創設者、リチャード・ストールマン氏が作成したライセンスです。MITやBSDと比較するとライセンス文は長く、またこれらのライセンスには見られないコピーレフトと呼ばれる概念が存在しています。

コピーレフトとは、無償で利用・改造・再配布することができるかわりに、再配布する場合は改変後のソースコードGPLを適用した上で公開する必要があります(これを「GPLに感染する」と呼ばれることもあります)。これが意味しているものと言うのは、プロプライエタリソフトにGPLライセンスソースコードを混入させてはならないということを意味しています。

改変後のソースコードを公開しなければならないのは、広く公開した場合のみに限られ、組織内だけあるいは個人的に利用する場合はソースコードの公開は不要であると定められています。

GPLが適用されている例として「Linux」がありますが、LinuxをベースとしたOSはすべて公開されています。Linuxベースの「Android」はGoogleが主導するオープンソースプロジェクトですし、商用Linuxとして有名なRed Hat Linuxは、ソースコード自体は公開されており*4、そのサポートで料金を徴収するというビジネス形態となっています。なお、このRed Hatのようにソースコードを公開して、その保証をするかわりに手数料を取るということについてはGPLでは認めていることが明記されています。

また、GPLGPLよりも制限の強いライセンスを併用することが出来ないとも定められています。これは、「宣伝条項」が定められている「四条項BSDライセンス」が、GPLよりも制限の強いライセンスとみなされ互換性がありません。同様の理由から、GPLでライセンスした著作物は、NDAなどで秘密保持することも出来ないとされています。

更に厄介なのはライブラリの扱い方で、GPLライセンスが適用されたライブラリを静的リンクする場合は確実にGPLに感染しますが、動的リンクの場合は議論が分かれるとかいうなかなかな曖昧っぷりです。後述するLGPLはこの問題を若干解決していますが、GNU自体はLGPLではなくGPLを使ってほしそうです。

GPLにも版がありますが、原則として指定されたGPLのバージョンかつ、それ以降のいかなるバージョンを適用してもいいとされた場合には、指定されたGPLのバージョンかそれ以降のバージョンを自由に選択してもいいということが定められています。

GPL-2.0

GNU Genaral Public License verison 2(GPL-2.0)は、GPLの版の一つです。

かなり長いので、Open Source Group Japanによる和訳を見ていただきたいとおもいますが、基本的には先述の通り、GPLが適用したソースコードを改変して再配布する場合には、同じくGPLを適用しソースコードを公開する必要があります。

GPL-2.0では、特許や法的規制でソースコードを公開できないとき(=バイナリしか頒布できないとき)は再配布することが出来ないと定められました。これは「法律」と「GPL」が矛盾した場合の措置が定められているものです。もっというと、裁判所でGPLに矛盾した判決が出たとしても、GPLに従う必要があるが、これは物理的に不可能なので再頒布出来ないというものです。

GPL-3.0

GPL-3.0もGPL-2.0と同様に先述のGPLの説明通りのライセンスとなっていますが、2007年に発表され、時代の流れに合わせた条項が追加されているのが特徴です。

特にハードウェアに搭載されたソフトウェアの改変を防止する機能(TiVo)や著作権保護機能(DRM)を禁止することが明記されました。つまりこれは、ハードウェア(機械やゲームハードなど)がGPL-3.0が適用されたソースコードを利用している場合、ユーザーによるソフトウェアの改変の禁止や防止措置は認められないということを意味しています。

さらにGPL-2.0で定められていた特許との兼ね合いについても改めて明記されています。これはやはり、GPLと法律の矛盾を防止するためのもので、特許が絡む場合は再頒布することは認められないとされています。

SaaSモデルにおけるGPL-2.0の問題

また、GPL-3.0では、Software as a Service(SaaS)においての抜け道を塞ごうとしています。SaaSとは、インターネットを通じてサービスを提供するビジネス形態のことで、ユーザー自身がバイナリやソースコードを得るわけではないという点からGPL-2.0のライセンス下では、ユーザーに対するソースコードの公開は必要ありません。

例を挙げます。SaaSとは、TwitterYouTubeなどがいい例になります。これらのサービスは決してバイナリをダウンロードして使うサービスではありません。なのでもし、サービス側がGPLが適用されたソースコードを用いていたとしても、ユーザー側にそのソースコードを提供する事はできません。一方で、サービス側がこのソースコードを用いて改変したソースコードを公開したとします。この場合はGPLに基づきソースコードを公開する必要があるのです(詳しくは上記図参照)。

GPL-3.0でもユーザーに対するこのソースコードの公開が義務付けられたわけではありませんが、後述するAGPLでは義務付けられており、GPL-3.0では互換性を保つための変更が加えられています。

AGPL

GPL-3.0の流れからAGPL-3.0(GNU Affero General Public License version 3)を解説します。

GPL-3.0では、SaaSにおいてユーザーに対してのソースコードの公開は義務付けられませんでした。ですが、このAGPLについてはそれが義務付けられています。

AGPLの簡単なイメージ

基本的にAGPL-3.0はGPL-3.0をベースにしており、ユーザーへの提供以外はほとんどGPL-3.0と一致しています。

違いはこの部分のみで、SaaSとして提供する場合にはユーザーに対してもソースコードの公開が必要です。

例を上げます。AGPLを採用しているソフトウェアとして「マストドン」があります。マストドンは、サーバー向けソフトウェアですが、ユーザー向けにもソースコードが公開されています。これはマストドンあるいはマストドンを採用するプロバイダの善意ではなく、AGPLに定められているためです。

LGPL

LGPLGNU Lesser General Public License)は日本語名「GNU劣等一般公衆利用許諾書」とよばれ、GPL・AGPLが強いコピーレフトであるのに対して、LGPLは弱いコピーレフトであるという違いがあります。主に採用される例はライブラリで、元々LGPLの1つ目のLはLessorではなくLibraryであったという事実もあります。

GPLとの違いは、利用物に対してソースコードの公開が必要ないということです。

LGPLのイメージ

ただし、LGPLは一見わかりやすいように見えて結構複雑です。その理由としては、静的リンクと動的リンクで扱いが異なる点が挙げられます。

まず静的リンクの場合、オブジェクトコードまたはソースコードを提供する必要があります。

動的リンクの場合は、LGPLのライブラリを一緒に配布しないのであれば制約がありません。ただし、LGPLのライブラリと共に運搬(配布)する場合は、LGPLの定める方法でソースコードを運搬する必要があります。

まあこの動的リンク・静的リンクが分かりにくくて・・・・。

Apache License

Apache Licenseは、Apache Software Foundatitonが作成したライセンスです。BSDライセンスをベースにしており、MITやBSD同様比較的易しいライセンスです。

リビジョン1.0では、四条項BSDライセンスのように宣伝条項が存在していましたが、1.1で削除されています。

Apache Licenseは、著作権表示と免責表示をすることを条件に、自由に使用・再配布・改変することが可能となっています。特徴的なのは特許条項の存在で、この特許条項によってAppleなどでもApache Licenseが用いられることがあります。

特許条項では、各コントリビューターが自動的に成果物を作成・使用・販売・インポートなどを行うことを無期限・世界的に非独占的で無料の「特許ライセンス」を付与することが定められています。これは、Apache Licenseを適用したソフトウェアにコントリビューターからの特許が入っている場合、自動的にその特許のライセンスが、そのソフトウェアを複製・改変・使用などをしようとした人に対して付与されます。ただし、この特許ライセンスを使って他人を訴えた場合、その瞬間に特許ライセンスが失効します。

特許ライセンスのイメージ

特許ライセンスが失効する唯一の例

今回は、個人的によく見る「MIT License」「BSDライセンス」「GPL」「Apache License」の4系統10種類のライセンスをご紹介しました。個人的にGPLが一番理解するのに時間がかかりましたが、これからOSSを使う機会が増えていく前に勉強するのは必要かと思いまして記事にしました。

再度お伝えしますが、これは私の解釈であり、正しいとは限りません。もしもわからないことがあれば、著作権保有者に確認することをおすすめします。

(以下、脚注)

*1:通常はこの条項とともに著作権表示が書かれますので、それのことを指しています

*2:通常はこの条項とともに著作権表示が書かれますので、それのことを指しています

*3:Revised BSD License / New BSD License / Modified BSD License

*4:最近、契約者だけになったっぽいけど