GitHubで便利そうなライブラリを見つけて、いざ使おうと思ったときに目に入る「MIT License」や「GPL-3.0」の文字。なんとなく「自由に使っていいやつでしょ」と流していませんか。実はライセンスごとに条件はけっこう違っていて、知らずに使うと後でトラブルになることもあります。
私自身、仕事で外部ライブラリの選定をする機会が増えてから、ライセンスの違いを意識するようになりました。今回は、よく見かける主要なオープンソースライセンスについて、それぞれの特徴と注意点を整理してみます。
そもそもオープンソースライセンスとは
オープンソースソフトウェアは「無料で使えるソフト」と思われがちですが、正確には少し違います。ソースコードが公開されていて、ライセンスで定められた条件のもとで利用・改変・再配布が認められているソフトウェア、というのが本来の意味です。
つまり「条件付きで自由に使える」のがポイントで、その条件を定めているのがライセンスです。条件を守らずに使えば、著作権侵害になる可能性もあります。
ライセンスは大きく分けると2つの系統があります。
- コピーレフト型:改変したものを配布する際に、同じライセンスでのソースコード公開を求めるタイプ(GPLなど)
- 非コピーレフト型(寛容型):著作権表示などの最低限の条件さえ守れば、商用利用も非公開利用も自由なタイプ(MIT、Apacheなど)
この違いを頭に入れておくと、各ライセンスの位置づけがぐっとわかりやすくなります。
MIT License:とにかくシンプルで自由
おそらく一番よく見かけるのがMITライセンスです。jQueryやRails、Reactなど、有名どころのプロジェクトでも広く採用されています。
条件は驚くほどシンプルで、著作権表示とライセンス文を残しておけば、商用利用も改変も再配布もほぼ自由。改変したコードを公開する義務もありません。自社製品に組み込んでソースを非公開にしたままでも問題なしです。
その代わり「無保証」であることが明記されています。使って何か問題が起きても作者は責任を負いません、というスタンスですね。とはいえこれはほとんどのオープンソースライセンスに共通する話なので、MITだけのデメリットではありません。
迷ったらMIT、と言われるくらい使いやすいライセンスです。自分でライブラリを公開するときの第一候補にもなるでしょう。
Apache License 2.0:特許条項が心強い
Apacheライセンスも寛容型の代表格です。AndroidやKubernetesなど、大規模なプロジェクトでの採用が目立ちます。
基本的な自由度はMITと近いのですが、大きな違いは特許に関する条項がしっかり書かれていること。コードの貢献者は、そのコードに関する特許の利用を利用者に許諾する、という内容が含まれています。さらに、利用者が特許訴訟を起こした場合にはライセンスが終了するという防衛的な仕組みもあります。
企業が関わる規模の大きいプロジェクトでApacheライセンスが好まれるのは、この特許まわりの安心感が理由のひとつです。一方で、改変したファイルには変更した旨を記載する必要があるなど、MITよりは守るべき事項が少し多めです。
GPL:コピーレフトの代表格
GNU General Public License、通称GPLは、コピーレフト型の代表的なライセンスです。LinuxカーネルがGPLv2を採用していることでも有名ですね。
GPLの最大の特徴は、GPLのコードを組み込んだソフトウェアを配布する場合、そのソフトウェア全体をGPLで公開しなければならない点です。いわゆる「伝播性」と呼ばれる性質で、これがあるおかげでソフトウェアの自由が保たれる、というのがGPLの思想です。
裏を返すと、ソースコードを非公開にしたい商用ソフトにGPLのライブラリを組み込むのは基本的にNGということになります。企業の法務部門がGPLに敏感なのはこのためです。
なお、よく誤解されるのですが、GPLでも商用利用自体は禁止されていません。ソースを公開する義務があるだけで、販売することは可能です。実際、GPLのソフトウェアを使ったビジネスはたくさん存在します。
現在はGPLv2とGPLv3が使われていて、v3では特許やDRMに関する条項が追加されています。両者には互換性の問題もあるので、組み合わせて使う場合は注意が必要です。
LGPL:ライブラリ向けのゆるめなGPL
LGPL(GNU Lesser General Public License)は、GPLのコピーレフトを少し緩和したライセンスです。
最大のポイントは、動的リンクで利用するだけなら、自分のソフトウェアのソースコードを公開しなくてもよいこと。LGPLのライブラリ自体に手を加えた場合はその部分の公開が必要ですが、単に「使う」だけなら影響が及びません。
商用ソフトでも使いやすいため、ライブラリ系のプロジェクトでよく採用されています。GPLでは利用のハードルが高すぎる、でもコピーレフトの精神は残したい、という場面にちょうどいい落としどころと言えます。
AGPL:Webサービス時代のGPL
AGPL(GNU Affero General Public License)は、GPLの考え方をWebサービスにまで広げたライセンスです。
通常のGPLは「配布」した場合にソース公開義務が発生します。しかしWebサービスの場合、ソフトウェアを配布せずサーバー上で動かしてユーザーに機能だけを提供できるため、GPLの義務を回避できてしまいます。この抜け道(ASPループホールと呼ばれます)を塞ぐのがAGPLです。
AGPLのコードを使ったサービスをネットワーク経由で提供する場合、利用者に対してソースコードを公開する義務が生じます。MongoDBやGrafanaなど、データベースやインフラ系のソフトウェアで採用例が増えてきました(MongoDBはその後、独自のSSPLに移行しています)。
クラウドサービスを開発している場合は、依存ライブラリにAGPLのものが紛れ込んでいないか、特に注意したいところです。
BSD License:MITの親戚のような存在
BSDライセンスもMITと並ぶ寛容型ライセンスの古株です。現在主に使われているのは、条項が2つの「2条項BSD」と3つの「3条項BSD」です。
内容はMITとほぼ同じで、著作権表示を残せば自由に使えます。3条項BSDには「作者の名前を宣伝に使ってはいけない」という条項が追加されている点が特徴です。
実務上、MITとBSDの違いを意識する場面はほとんどありませんが、歴史あるプロジェクト(FreeBSDなど)では今もBSDライセンスが現役です。
MPL 2.0:ファイル単位のコピーレフト
Mozilla Public License 2.0は、FirefoxでおなじみMozillaが策定したライセンスで、コピーレフト型と寛容型の中間に位置します。
コピーレフトが適用されるのは「ファイル単位」。MPLのコードを含むファイルを改変したら、そのファイルのソースは公開する必要がありますが、別ファイルとして書いた自分のコードは非公開のままで構いません。
GPLほど厳格ではなく、MITほどゆるくもない。バランス型のライセンスとして、企業のオープンソースプロジェクトで選ばれることがあります。
主要ライセンスを一覧表で比較
ここまで紹介した7つのライセンスの違いを、一覧表にまとめました。
| ライセンス | 商用利用 | 改変 | 再配布 | 改変部分の ソース公開義務 | 組み込み先の ソース公開義務 | 特許条項 | 著作権・ ライセンス表示 |
|---|---|---|---|---|---|---|---|
| MIT | ○ | ○ | ○ | 不要 | 不要 | なし | 必要 |
| Apache 2.0 | ○ | ○ | ○ | 不要 ※1 | 不要 | あり | 必要 |
| BSD(2/3条項) | ○ | ○ | ○ | 不要 | 不要 | なし | 必要 ※2 |
| MPL 2.0 | ○ | ○ | ○ | 必要 (ファイル単位) | 不要 | あり | 必要 |
| LGPL | ○ | ○ | ○ | 必要 | 不要 (動的リンク時) | あり(v3) | 必要 |
| GPL(v2/v3) | ○ | ○ | ○ | 必要 | 必要 (配布時) | あり(v3) | 必要 |
| AGPL | ○ | ○ | ○ | 必要 | 必要 (ネット提供でも) | あり | 必要 |
※1 ソース公開は不要ですが、改変したファイルに変更した旨の記載が必要です。
※2 3条項BSDでは、作者名を製品の宣伝に使うことが禁止されています。
表の見方を少し補足します。すべてのライセンスで商用利用・改変・再配布は可能で、その点ではどれも「オープンソース」の条件を満たしています。違いが出るのは「ソースコードをどこまで公開しなければならないか」の部分です。
表の上にあるものほど義務が軽く、下に行くほどコピーレフトの効力が強くなります。MIT・Apache・BSDは公開義務が一切なし、MPLは改変したファイルのみ、LGPLはライブラリ部分のみ、GPLは組み込んだソフトウェア全体、AGPLはWebサービスとして提供する場合まで、と段階的に範囲が広がっていくイメージです。
どう選べばいい?どう確認すればいい?
ライブラリを「使う側」の視点
まずプロジェクトのリポジトリにあるLICENSEファイルを確認する習慣をつけましょう。寛容型(MIT、Apache、BSD)なら基本的に安心して使えます。GPL系が含まれている場合は、自分のソフトウェアの公開方針と矛盾しないかを確認する必要があります。依存関係が多いプロジェクトでは、ライセンスを自動チェックしてくれるツールを導入するのもおすすめです。
自分のコードを「公開する側」の視点
大まかな目安は次のとおりです。
- 誰にでも気軽に使ってほしい → MIT
- 特許リスクにも備えたい → Apache 2.0
- 改変版も必ずオープンであってほしい → GPL系
最後にひとつ補足を。この記事は一般的な情報の整理であって、法的なアドバイスではありません。ビジネスでの利用判断など、重要な場面では弁護士や専門家に相談することを強くおすすめします。
まとめ
オープンソースライセンスは種類が多くて取っつきにくい印象がありますが、「コピーレフト型か寛容型か」という軸で見ると整理しやすくなります。
普段なにげなく使っているライブラリも、作者が定めたルールの上に成り立っています。ライセンスを正しく理解して使うことは、開発者としてのマナーであると同時に、オープンソース文化への敬意でもあると思います。次にLICENSEファイルを見かけたら、ぜひ中身にも目を通してみてください。
コメント