コピーレフト型と非コピーレフト型OSSライセンスの違いとは？

前回はOSSの概要、特徴、主要なライセンスをご紹介しました。今回はそれぞれのライセンスについてより詳細な特徴を説明していきます。

具体的には、読者の皆さんが作成したソフトウェアにOSSを組み込んで再頒布した際に、どのような対応が必要になるのか、という視点で説明します。ソフトウェアを再頒布する際には、OSSライセンスの条件に従った対応を要求されるためです。なお、ライセンステキストの添付はここで取り上げるすべてのライセンスにおいて共通の条件です。

コピーレフト型のライセンス

まずコピーレフト型のライセンスを取り上げます。この類型のライセンスの特徴としては以下が挙げられます。

• ライセンステキストの添付が必要
• 改変した（コピー＆ペーストも含む）ソースコードの開示
• 組み合わせて利用した場合、対応する部分のソースコードの開示

コピーレフト型のライセンスで最も有名なライセンスはFree Software Foundation（以下FSFとします）によって作成されたGNU General Public License（以下GPLとします）です。OSSライセンスの中でも飛び抜けて人気のあるライセンスです。オープンソースのプロジェクトが数多く登録されていることで有名なSourceForgeで本稿執筆時点（2014年1月）の状況を調べてみたところ、プロジェクトの内57.1%（GPL v2-32.4%、GPL v3-24.7%）のOSSにGPLが適用されていることがわかりました。
2012年にも調査したことがありますが、その時は59.9%でしたので、相変わらず高い人気があることが伺えます。歴史も古く、GPL v2は1991年にリリースされています。またLinux KernelのようなOSSに採用されていることから、影響力もあります。

図1：SourceForge.net におけるOSSライセンスの比率（2014/1/25調査）（クリックで拡大）

きちんと知れば怖くない GPLライセンス

GPLはライセンス違反があった場合にFSFやSFLC（Software Freedom Law Center）が著作権侵害で企業を提訴したことでも知られています。そのためGPLを利用するとなると特に神経をとがらせる企業が多いようです。

実を言うと、このような組織からメールが届くこと自体はそれほど珍しいことではありません。筆者が知る限りでも、SFLCやFSFから公開サイトの情報不足や、リンク切れ等を問い合わせる目的でメールが届いた日本の企業は複数あります。

ただ、実際のところ日本ではこれまでGPL違反が理由で訴訟になったケースはありません。FSFやSFLCの目的はあくまでGPLの普及と順守ですから、問い合わせを受けた企業や組織がライセンスの順守状況を確認し、万一対応に不備があったとしても速やかに是正すれば、トラブルに発展することはまずありません。FSFないしSFLCにとっても、提訴は悪質なケースでの最後の手段でしかないと考えられます。

GPLは非常に人気のあるライセンスであるがゆえに、それについてのノウハウやドキュメントが充実しています。日本語で読める最高のGPLの解説書が『GNU GPLv3 逐条解説書』です。この解説書はGPLv2との差異にも言及しているため、GPLv2の理解も深まります。またGPLv3の起草者であるEben Moglen氏やSFLCの協力を得て解説されており、ライセンスの条件のみならず、どのように対応すれば問題ないかまで踏み込んで言及されている点も特徴です。

ASPに対応するためAGPLのOSSが増加

Affero General Public License Version 3（以下AGPLとします）はFSFから2007年にリリースされたライセンスです。このライセンスが作成された経緯を説明する前に、まずライセンス作成元のFSFの思想を復習しておきます。

FSFの思想とはつまり、ソフトウェアは単にソースコードが開示されているだけではなく、その改変版やそれに基づいて作成され再頒布されたものに至るまで、自由にソースコードを入手しさらに改変できるべきである、というものです（ソフトウェアの自由については「自由ソフトウェアとは?」という文章が、その思想を理解するための助けになります）。

しかし、最近ではテクノロジーの進歩によりソフトウェアが手元になくても利用できるASP（アプリケーションサービスプロバイダ）という仕組みが現れました。この場合はソフトウェアが再頒布されないため、GPLがOSSに適用されていてもソフトウェアの利用者にはソースコードは開示されませんでした。AGPLはこのようにネットワーク経由でソフトウェアを利用しているユーザーに対してもソースコードを開示されるような条件が追加されている点が特徴です。つまりGPLではカバーできなかった範囲を補うために作成されたライセンスといえます。

AGPLは現在利用されている主要なOSSライセンスの中では最もコピーレフト性が強いライセンスです。Berkeley DBが2013年6月にライセンスをAGPLに変更したように、AGPLのOSSが増えているのも注目しておくべき点です。

また、FSFによって作成されたものではありませんが、Sleepycat Licenseもコピーレフトとして知っておくべきライセンスです。一見BSD Licenseのように見え、1条項、2条項はBSD Licenseと同じなのですが、3条項にはGPLの条件とほぼ同等の内容が記述されています。

Sleepycat License 3条項部分の抜粋

Redistributions in any form must be accompanied by information on how to obtain complete source code for the DB software and any accompanying software that uses the DB software. The source code must either be included in the distribution or be available for no more than the cost of distribution plus a nominal fee, and must be freely redistributable under reasonable conditions. For an executable file, complete source code means the source code for all modules it contains. It does not include source code for modules or files that typically accompany the major components of the operating system on which the executable file runs.

＞　日本語参考訳

Sleepycat LicenseはBerkeley DBの12c以前のバージョンに適用されています。また、SVNKitというOSSに適用されているThe TMate Open Source LicenseもSleepycat Licenseと同等の条件を持つライセンスで、検査の過程で筆者も何度か遭遇したことがあります。

この類型のライセンスを利用する際には自社のソースコードの開示が必要になる場合がありますので、皆さんが利用を検討する際には、利用可否、留意すべきリスクや対策等について、プロジェクト管理者や、組織内でOSSライセンスの内容、OSS利用に関するポリシーを判断する立場にある部門（法務部門や品質保証部門等）に確認されることを特に推奨します。

いずれにせよ、GPLを恐れる必要はありません。その思想に賛同し、ライセンスする側、受ける側それぞれが負う義務を理解し、実行すればよいという点で、他のライセンスや契約となんら変わりありません。ただ、「ソフトウェアはフリー（自由）であるべき」という思想を実現するために、他のOSSライセンスよりも複雑な仕組みになっているという点で、企業や組織の中でも特に注意を払う必要があるということです。

準コピーレフト型のライセンス

準コピーレフト型のライセンスに共通する特徴としては以下が挙げられます。

• ライセンステキストの添付が必要
• 改変した（コピー＆ペーストも含む）ソースコードの開示

LGPLがリバースエンジニアリングを認める理由

GNU Lesser General Public License（以下LGPLとします）はGPL同様、FSFによって作成されたライセンスです。LGPLは、その名の通りGPLから条件を少し弱めたライセンスです。

元々"GNU Library General Public License"として公開されましたが、後にGNU Lesser General Publicと名前を改められました。最初のLGPL 2.0では"Library"という単語をライセンス名に入れてしまったために、FSFの意図から外れてライブラリとして利用される多くのOSSに適用されてしまったためです。その辺りの経緯を記述したリチャード・ストールマンによるドキュメントが「あなたの次回のライブラリには劣等GPLを使うべきでない理由」です。

LGPLの基本的な考え方はGPLと同じですが、組み合わせて利用した場合でも対応するソースコードの開示を要求しないという点が異なります。ただし、以下を順守する必要があります。

• リバースエンジニアリングを禁止してはならない
• LGPLのライブラリを利用する著作物のオブジェクトコードの開示

なぜこのような条件が適用されるかは、このライセンスの思想を考えると理解しやすくなります。前述した「自由ソフトウェアとは？」を思い出していただきたいのですが、LGPLのライブラリとリンクしたソフトウェアを受け取った人に自由を与えるためには、リバースエンジニアリングの許可とそれを実行するためのオブジェクトコードが必要になるという訳です。

ユーザー自作部分を区別するMPL

Mozilla Public License（以下MPLとします）は、1999年にVersion 1.1がリリースされました。2012年に2.0がリリースされたばかりですが、影響力のあったのはVersion 1.1の方です。なぜならこのライセンスを元に作成された有力なライセンスが複数あるからです。
MPLを元に作成されたライセンスの例としてCDDL（Common Development and Distribution License）、CPAL（Common Public Attribution License）が挙げられます。MPL自体はMozilla Projectの有名なFirefoxやThunderbirdに適用されている以外にはあまり見かけませんが、上記で挙げたようにMPLの派生ライセンスのOSSはたくさんあるため、MPLについて理解しておくことが重要になります。

MPLのライセンスの背景には「オープンソース（MPL）由来のソフトウェア部分についてはすべてソースコードを開示してください」という思想があります。逆に言うと、それ以外の部分（ユーザー自作部分）のソースコードの開示は要求しない、ともいえます。コピーレフト型のライセンスのように組み合わせた部分までソースコードを開示する必要はありませんが、ユーザーが改変したソースコードは開示が必要になる点が特徴です。

非コピーレフト型のライセンス

非コピーレフト型のライセンスの特徴は以下の2点です。

• ライセンステキストの添付が必要
• ソースコードを変更したとしても、ソースコードを開示する必要はない

著作者の数だけ存在する！？BSDライセンス

BSD License は1990年に4条項のライセンスとして作成されました。そのため、この最初のBSD Licenseは、original BSD LicenseまたはBSD 4-clause License と呼ばれます。そしていわゆる宣伝条項（ソフトウェアの機能や仕様に言及している広告媒体に謝辞を記載せよとの条項）が撤廃され、3条に減ったのが1999年です。さらに最近は3条項（ソフトウェアから派生した製品の宣伝または販売促進に、著作権者またはコントリビューターの名前を使用してはならない、という意味の条項）も削除した2条のみのBSD 2-clause Licenseを多く見かけるようになりました。現在はこの3条のBSD 3-clause Licenseと2条のBSD 2-clause Licenseが主流です。

BSD Licenseは、固定のライセンス文がなくテンプレートがあるのみという点で、これまでご紹介したライセンスとは異なります。OSSの著作者はBSD Licenseのテンプレートに年号と著作者を入力することで、新しくライセンスを作成します。そのため厳密にはBSD Licenseといっても全く同じものはなく、著作者の数だけライセンスがあります。

BSD Licenseのもう一つの特徴として、派生ライセンスの多さが挙げられます。上で述べたように、BSD Licenseには著作者が必ず手を入れる必要があります。一つ手を入れるともう一つ手を入れたくなるものなのでしょうか、元々のBSD License の条項が少し変更されたり、条項を新たに追加されたりしているライセンスをよく見かけます。後に述べるApache License 1.1も広義ではBSDスタイルのライセンスの一つです。

BSD Licenseは元々FreeBSDなどOSに使われていたライセンスですが、Web系のコンポーネントなどでも用いられることも多く、どの分野でも広く使われています。派生ライセンスも含めると目にする機会が非常に多いですので、それぞれのBSD N-clause License（Nは2、3、4いずれか）を覚えておくと、非常に役に立ちます。

JavaScript系のOSSで多く利用されているMITライセンス

MIT Licenseはマサチューセッツ工科大学により1980年台後半に作成されたライセンスです。非常に条文が短いライセンスとしても知られています。BSD Licenseと同様にこのライセンスもテンプレートが用意されているだけですので、OSSの著作者は著作者と年号を記述する必要があります。歴史が古くシンプルでわかりやすいライセンスのため、いろんな分野のOSSに適用されています。特にJavaScriptの言語で実装されたOSSでよく利用されています。

Androidなど、Java言語のOSSに適用されているApacheライセンス

Apache Licenseは、Apache Software FoundationでリリースされているコンポーネントやAndroidに適用されているライセンスです。Apache Software FoundationからはJava言語で実装されたOSSが多数リリースされているということもあり、Java言語のOSSに適用されていることが多いです。またAndroid周辺の小規模なOSSにこのライセンスが適用されていることもあります。

現在Apache Software Foundationから公開されているOSSにはすべてApache License 2が適用されています。ただし、筆者がソフトウェアの検査をしていますと、2004年以前の古いバージョンのライブラリがそのまま利用されている、というケースもたまにあります。この場合のライセンスはApache License 1.1になるため、開発者の方（特にJava使いの方）は2だけ知っていればよいということにはならず、やはり1.1と2の違いは押さえておくべきでしょう。1.1にはエンドユーザードキュメントに"This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."の文言を要求する条項があります。2.0ではこの条件はなく、新たに特許についての条件が追加されています。

今回紹介したタイプ別の主なOSSライセンス

最後に、今回紹介した主なOSSライセンスとそのタイプを一覧で紹介します。

今回はよく利用されているOSSライセンスそれぞれの特徴を説明しました。最終回となる次回はOSSライセンスの最新の動向をご紹介します。また、ライセンステキスト添付の具体的な方法や、特殊なツールを使わなくともできるライセンスのチェック方法など、読者の皆さんがすぐに始められるOSSライセンス順守実践テクニックをご紹介します。