オープンソースライセンスの背景と歴史

2016.11.29

2,351

最近は、多くの企業で社内開発されたプロジェクトを、オープンソースとして公開するケースが多いようです。
（UbuntuのOSからDBのMySQL、CUBRID、MariaDB、その他AngularJS、Zeplin…etc）

オープンソースは、単にソースコードのみ公開すればよいというものではなく、他の人がそのコードを使用できるように作ってこそ、オープンソースであると言えるでしょう。世界の多くのオープンソース財団では、オープンソースに対する規定を定めていますが、各財団で考えるオープンソースの哲学と方向性は若干異なっており、その結果、各財団が考えるオープンソースのライセンスを発行し始めています。

1. BSD（Berkeley Software Distribution）Lisense

1.1 BSD Lisense登場の背景

AT＆Tのベル研究所（Bell Labs. 現在はノキア所属）とマサチューセッツ工科大学で1964年から開発を開始し、1969年にタイムシェアリングオペレーティングシステムであるMulticsを発表しました。その後、ベル研究所のケン・トンプソン、デニス・リッチー、ダグラス・マキルロイが1969年からMulticsを簡略化して小型コンピュータでも動作できるオペレーティングシステムを開発し、UNIXという名称で1973年10月に一般公開しました。

AT＆Tは米国の電話産業における独占企業であったため、米国政府から反トラスト規制を受け、電話産業とそれに関連する事業以外の製品は販売できなくなりました。これにより、この時期に電話産業とは何の関連もなかったUNIXも、ソースコードまで無料で配布されることになりました。

1977年にカリフォルニア大学バークレー校の大学院生であったビル・ジョイ（Bill Joy）は、UNIXのソースコードをベースにBSDの最初のバージョンを作成して配布しました。後にCSRG（Computer Systems Research Group）と呼ばれるグループを作成し、BSDの開発を引き受けることになりました。

CSRGで開発されたBSDのソースコードは、AT＆TのUSL（UNIX System Laboratories, Inc.）のソースコードを使用していたので、USLから訴訟されたが最終的には合意に至りました。この訴訟が長期化したため、オープンソースのオペレーティングシステムの代表格がBSDからLinuxに移ったのです。訴訟が提起された直後、AT＆TはUSLをNovellに販売しました。

USLとCSRGの合意案は、完全なソースコードを含め、4.4BSD-EncumberedはUSLからライセンスを得なければ使用できず、USLのソースコードを削除した4.4BSD-Lite（1994年6月発売）については、今後USLは訴訟を提起できない、という内容でした。そのため、以前のBSDのバージョンを基盤にフォークしたFreeBSD、NetBSDは4.4BSD-Liteを基盤に、自分たちが今までに作成したソースコードを追加して、オペレーティングシステムのソースコードを再作成する必要がありました。現在の最新バージョンは4.4BSD-Lite Release 2（1995年6月発売）です。

この訴訟でCSRGは、BSDライセンスと呼ばれるソースコードの作成者名の表記義務の他はほとんど制限がないライセンスでBSDを配布しました。

1.2 BSD License History

背景と歴史

BSDライセンスで配布されている代表的なプロジェクトは、先に説明したBSD OSです。
1977年から1995年まで活動した大学バークレー校のCSRG（Computer Systems Research Group）で最初に配布したBSD OSは、現在FreeBSD、OpenBSD、NetBSD、DragonFly BSDなどの形態に変形し、継続してオープンソースで配布されています。つまり、Windows NT3.1のTCP/IPネットワークコードや、Apple OS XとiOSの基礎の大部分を占め、現代のオペレーティングシステムに部分的にも全体的にも含まれています。

元のBSDライセンスは4つの条項があり、そのうち第3項の広告規定は、米バークレー校のコードを使用して製品を宣伝するときは、必ずそのコードを使用していることを明記するように要求しました。しかし、この条項は1999年7月22日、カリフォルニア州立大学の技術ライセンス部門の責任者が正式に廃止しました。（つまり、4つの条項からなるライセンスは、OSIの承認を受けません）

BSD 3-Cause（第3項BSD「BSD New」または「BSD Simplified」）のライセンスは、広告に対する条項を削除したものを意味します。他の名称で「BSD NEW」という言葉を使っていますが、BSDライセンスの最新版ではありません。このバージョン以降に「BSD Simplified」という名称のBSD 2-Causeバージョンがリリースされました。

OSI理事会は、前述した元のBSDライセンスで、広告条項を削除したBSD 3-Cause、BSD 2-Causeを承認しました。
※OSIで承認されたライセンスリスト- https://opensource.org/licenses/alphabetical
※BSD Licenseの全バージョン- https://en.wikipedia.org/wiki/BSD_licenses

参考資料: UNIX、UNIX系オペレーティングシステムの系譜

ソース
（1）BSDのロゴ- https://en.wikipedia.org/wiki/Template:BSD
（2）UNIX系オペレーティングシステムの系譜- https://commons.wikimedia.org/wiki/File：Unix_history-simple.svg

2. Apache License

2.1（ASF Apache Sfotware Foundation、ASFの）登場の背景

Apacheソフトウェア財団（Apache Software Foundation, ASF）は、様々なオープンソースプロジェクトを支援、管理する非営利組織です。フリーソフトウェア財団（Free Software Foundation, FSF）と共にオープンソース文化を花咲かせた代表団体として知られています。ASFで管理するオープンソースソフトウェアは、誰もが参加できると同時に「Apacheの方式（Apache Way）」というユニークな文化の下で管理されています。

ASFは1999年に設立された米国の公式非営利団体です。ASF設立に参加した彼らはすでに1995年から1999年まで「Apacheグループ」という名称で活動しており、当時の「ApacheのHTTPD Webサーバー」の開発に注力していました。Apache Webサーバーは、誰でも無料で使用でき、ソースコードを変更して再配布できるサーバーです。同時に、継続的なメンテナンスも必要でした。当時、ブライアン・ベエレンドルフ（Brian Behlendorf）という開発者は、より体系的にApache Webサーバーの技術を改善しようとメーリングリストを作り、後に多くの貢献者がコラボレーションしながら、Apache Webサーバー技術を発展させました。

ASFは、なぜ「Apache」という名前を使用したのでしょう。Apacheは、米国のインディアン部族名から命名したそうです。Apache部族は勇猛な戦士を率いて様々な戦略を構想する種族として有名で、19世紀にはアメリカ軍と戦闘を繰り広げたりもしました。また「パッチWebサーバー（patchy web server）」という発音と似ている点も、Apacheという名前を選択するのに影響したようです。パッチは任意のプログラムを一部修正する作業を意味します。

Apacheサーバーは、世界中のWebサイトのうち65％が使用するほど人気のある技術になりました。Apacheグループは他にも、Java、Perl、PHPに関連する様々なオープンソースプロジェクトを進行しました。開発に携わった開発者たちは、法律的なアドバイスや経済的な支援をしてくれる体系的な団体が必要だと感じ、これによってASFが設立されました。

2.2 Apache License History

Apacheの財団や財団のプロジェクトによって作られたすべてのソフトウェアは、現在、Apacheライセンスバージョン2.0で配布されています。Apacheライセンスバージョン2.0は、2004年、Apache財団によって承認されました。バージョン2.0に更新した理由は、多くのプロジェクトがライセンスを変更することなく再利用できるようにして、貢献コード（Contribution）の提出のライセンスを明確にし、貢献者たちの特許に対する特許ライセンスを要求するなどの内容を反映するためでした。ライセンス改正に伴い、Apacheグループの当初の目標に忠実でありながら、他のオープンソースライセンスとの相互運用性も高くなりました。Apache財団で作られたすべてのパッケージは、特別な言及がなくても、Apacheライセンスバージョン2.0で配布されます。

Apacheライセンスの最大プロジェクトは、Androidプラットフォームです。カーネルやアプリケーションを除くAndroidプラットフォームの多くは、Apacheライセンスで配布されています。しかし一部の要素は、CPL、EPL、GPL、LGPLなどで配布されており、これらはApacheライセンスではなく、それぞれのライセンス規則に従う必要があります。
※Apacheライセンスの全バージョンhttp://www.apache.org/licenses/

2.3（その他）Apache Way

ASFで作るソフトウェアは、LinuxやPythonのような特定人物を中心に開発されていません。同じ興味を持つグループが集まって情報を共有し、集団で開発します。ASFが提供するオープンソースプロジェクトは他のオープンソースライセンスより自由度が高い「Apacheライセンス」に配布されています。

ASFのコミュニティ運営方式は少し独特です。まず、各オープンソース技術は「PMC」（Project Management Committees）所属の貢献者が主導します。ASFプロジェクトには誰でも貢献できますが、エラー報告などの比較的単純な参加のみとなります。PMCメンバーのようにソースコードへのアクセス権を持つよりコアな貢献者になるには、既存PMCメンバーからの招待を受けなければなりません。すべての意思疎通は仲間の意見に基づいて決定され、意見が定まらない場合は投票を経て意思決定します。

PMCのほか、ASF運営組織、ASF理事会、ASFメンバーも別に存在します。ASF理事会は9名で、ASFのメンバーが投票して選出します。ASFのオープンソースプロジェクトの技術貢献は数千名ですが、ASFメンバーは500名余りで規模が小さいです。ASFメンバーは、既存メンバーの推薦や投票によって決定されます。ASFではこのように貢献度や関心が高い人に特定の権限を与える方法を「能力主義（Meritocracy）」と呼びます。

ASFは、内部文化にもApache方式を適用しました。ASFに属するすべての人々は、▲ソフトウェア共同開発▲商業的に活用できる標準ライセンス▲高品質を維持しているソフトウェア▲お互いに尊敬し正直に技術交流をすること▲標準に忠実である▲セキュリティ機能を充実させること、この6つの原則に従わなければなりません。

ASFメンバーやPMCメンバーのほとんどは、無給で働き、才能寄付の一環としてコミュニティ活動を行っています。財団を運営するにはある程度の費用が必要で、ASFはこれを後援で解決しています。主要スポンサーには、Pivotal、Facebook、Cloudera、Google、Yahoo、Microsoftなど、他にも40社以上の企業が、様々な規模でASFを後援しています。

ソース
（1）Apache Way – http://www.slideshare.net/shanecurcuru/the-apache-way- 16769653

3. GPL（General Public License）

3.1 FSF（Free Software Foundation）登場の背景

Free Software意味

フリーソフトウェアの「フリー」は「無料」を意味するものではありません。「表現の自由」の自由が無料ではなく、特定の条件に拘束されない観点を言うように、フリーソフトウェアの自由も似たような意味を持ちます。フリーソフトウェアの反対概念は「独占」ソフトウェアであり、ソフトウェアのソースコードを特定の企業が独占する事例を指します。「マイクロソフト（MS）オフィス」のような製品を考えるとよく分かりますね。MS Office製品のソースコードが公開されていないため誰でも修正することができません。ユーザーもライセンス料を支払わなければインストールができません。

フリーソフトウェアは、自由の意味を大きく4つで捉えています。

プログラムをどのような目的にも実行できる自由
プログラムの動作原理を研究し、これを自分のニーズに合わせて変更できる自由。これらの自由には、ソースコードへのアクセスが先行する
隣人を助けるために、プログラムを複製して配布できる自由
プログラムを向上させ、これをコミュニティ全体の利益のために還元できる自由。これらの自由には、ソースコードへのアクセスが先行する

Free Software FoundationやGNU

ソフトウェアも企業の資産と考えるなら、企業がソフトウェアのソースコードを公開せずに有料で販売することになるでしょう。フリーソフトウェア財団を作ったリチャード・ストールマンはこのような考えに反旗を翻しました。リチャード・ストールマンは、ソフトウェアが最初に登場した時から共有精神が広がっていたことを強調しています。実際に1970年にストールマンがMIT人工知能研究所に入ったとき、ITS（Incompatible Time-sharing System）というオペレーティングシステムを利用しました。リチャード・ストールマンを含む内部研究者らは、ITSオペレーティングシステムの改善に寄与しており、他の大学や企業から、MIT研究所が作成した技術を利用したいと要求があれば、気兼ねなくプログラムを貸与しました。リチャード・ストールマンは、このような文化を「レシピの共有が料理の歴史の中で古くからあるもの」であるように、「ソフトウェアの共有は、コンピュータの歴史と同じくらい古いものである」と表現しました。

リチャード・ストールマンが経験したソフトウェア共有文化は、1980年代から変わり始めます。PCやソフトウェア産業が発展し、関連企業が誕生し、ソフトウェア特許や独占に関する法律を適用するケースが増えました。ユーザーはソフトウェアに簡単にアクセスできず、開発者もお互いに協力する道が閉ざされました。リチャード・ストールマンは、自分が経験したソフトウェア共有の文化を蘇らせるため、まずプログラムを作ることにしました。こうして始まったのが「GNU」プロジェクトです。

GNUはUNIXと互換性のあるオペレーティングシステムです。リチャード・ストールマンは、ソフトウェア共有運動を始めるにあたって最初に必要なものがオペレーティングシステムだと考えました。オペレーティングシステムは、コンピュータを使用するのに必要なコアソフトウェアで、オペレーティングシステムがあれば、コンピュータを使って様々な種類の作業ができるからです。したがって、自由に使用できるオペレーティングシステムがあれば、相互協力する開発者がもう一度コミュニティを作ることができると判断しました。

リチャード・ストールマンがUNIX系列のオペレーティングシステムを作ることにした理由は、既存のUNIXユーザーが新しいシステムに簡単に適応できると思ったからです。GNUという名称は「GNUはUNIXではない」（Gnu is Not UNIX）の最初の文字を取って作った略語です。GNUはUNIXと互換されるように作られたオペレーティングシステムですが、UNIXとは異なるオペレーティングシステムであるという意味を内包するため作成された名称です。GNUプロジェクトでは、システムリソースを管理するカーネル群を作ったりもしましたが、1991年にLinuxが注目を集めてGNUツールのLinuxカーネルに統合されました。

リチャード・ストールマンは、1985年にGNUプロジェクトを支援するフリーソフトウェア財団を設立しました。オペレーティングシステムの他にライセンスも作成し、共有運動を繰り広げました。つまり自由を実質的に保障するために、リチャード・ストールマンは、自分のソフトウェアに対する著作権を確保した後、こうした権利を前提に、その著作物を一定条件で使用することを許可した「GNU GPL（GENERAL PUBLIC LICENSE, 一般公衆利用許諾契約書）」を作成しました。これを略して「GPL」と表現することもあります。

GPLは遵守条項の多いライセンスでしたが、フリーソフトウェア財団は、これを少しずつ緩和し、GPLバージョン1、バージョン3で、新たにライセンスを修正して公開しました。また、GPL違反を見つけたときは誰でもフリーソフトウェア財団に通報できるようにしました。フリーソフトウェア財団は、このようにソフトウェア共有文化に役立つように、ライセンスを発展させる方法でGPL文化を啓蒙運動を進めています。現在、GPLは全体のオープンソースのうち、2番目に多く使用されています。

3.2 GPL 2.0 License History

商用ソフトウェアライセンスの大半は、ソフトウェアの共有、修正の自由を禁止するために考案されました。一方GPLは、フリーソフトウェアを共有して変更できる自由を確保することを意図しました。つまり、ユーザーがソフトウェアを自由に利用できるようにするものです。GPLはフリーソフトウェア財団（FSF）のソフトウェアをはじめ、著作者がこのライセンスの使用を指定した他のプログラムに適用されます。誰もが自分のプログラムにこのライセンスを適用できます。

フリーソフトウェアで使用される「Free」という言葉は、無料という金銭的な意味ではなく、自由（Freedom）を意味します。FSFのライセンスは、ユーザーが自由にソフトウェアの複製を配布できる（そして必要な場合、販売もできる）自由を確保するために考案されました。ソースコードを受け取ったり、ソフトウェアを修正したり、その一部を新しいフリープログラム内で使用できたり、このようなことを保証するために考案されました。

ユーザーの権利を保護するために、他者がユーザーの権利を否定したり、放棄するように要求する行為を禁止する規定があります。これらの規定は、ユーザーがソフトウェアの複製を配布したり、修正した場合にも特定の義務を課します。つまり、プログラムを無償や有償で配布する場合、すべての権利を受取人に伝達する必要があります。

3.3 GPL 3.0 License History

1991年に配布されたGPl 2.0は、2007年までの16年間、変更することなく使用されました。ソフトウェア関連技術とそれを取り巻く市場、制度の変化速度に照らしてみると、長期間にわたり改正されずに使用されたものと評価できます。しかし、1990年代初めオープンソースソフトウェアが広く使用される前に作られたGPL 2.0は、最近の変化状況から少しずつその限界を呈しています。たとえばフリー/オープンソースソフトウェア運動が米国で始まり、GPL 2.0が米国の法制度に基づいて作成されましたが、現在のフリー/オープンソースソフトウェアとGPLは世界的に使用されており、それによって各国法制度の違いを反映する必要性が提起されました。この他にソフトウェア特許の拡大とそれに伴うリスクの増加、フリー/オープンソースソフトウェアのライセンスの増加と両立性の問題、DRM技術の拡大適用と法による保護、ネットワークサーバーベースのソフトウェアの増加は、P2Pなどの新しい技術の登場など一連の環境変化によりGPLの改正の必要性はさらに増大しました。

しかし、フリー/オープンソースソフトウェアとGPlのユーザー層が拡散するほど改正作業はさらに複雑になりました。1991年GPL 2.0が発表された当時、リチャード・ストールマンが何名かの法律家と開発者らの意見を取り入れたりしていましたが、GPLの改訂において公式的な意見収集の手続きや議論が必要ではありませんでした。GPL 2.0が発表され、FSFは直ちにGNUプロジェクトの成果をGPL 2.0に交替し、リーナス・トーバルズ（Linus Torvalds）も、LinuxカーネルにGPL 2.0を採用しました。しかし、今回の状況はそうではありませんでした。GPLは、世界中の数万個のプロジェクトで使用されており、PC、サーバー、オペレーティングシステムをはじめ携帯電話、PD、セットトップボックス、ホームネットワーク機器などの組込みソフトウェア分野において広く使用されていました。もはやFSFのGNUプロジェクトでのみ使用されているライセンスではなく、フリー/オープンソースソフトウェアに関わる多くの企業と人々が守るべき行動規範の地位を持つようになったのです。

FSFは数年間、フリー/オープンソースソフトウェアコミュニティ、産業界、学界などと公式または非公式にGPLの改正について議論してきており、これに基づいて用意した初案（First Discussion Draft）を2006年1月に発表しました。草案の発表とともに様々な意見を収集するため議論委員会などの公式プロセスを作成しました。インターネットを通じた意見収集、数回の国際カンファレンスを経て、2006年7月に第2案、2007年3月と5月に第3、第4案を発表し、2007年6月29日、ついに正式にGPL3.0を発表しました。GPLの改訂過程で最も議論になったのは、DRM（またはTivoization）関連争点、特許権の取扱い、オープンソースライセンス間の両立性、ネットワークサーバーの形でGPLソフトウェアを利用する場合の処理などでした。このほか、ソースコードの範囲を明確にし、新しい用語を定義するなどの修正がありました。

3.4 Affero GPL 3.0 History

Affero GPL（AGPL）は、ネットワークサーバーソフトウェアの事例においてコミュニティとの協力を確保するために作られたライセンスです。Affero GPLはGPLライセンスに基づいて作られたライセンスで、Affero GPL 1.0はGPL 2.0に基づいてAffero GPL 3.0は、2007年GPL 3.0に基づいて制定されました。

すべてのユーザーの自由を保護することの副次的利益は、プログラムの代替バージョンで作成された改善点が広く通用する場合、他の開発者がそれを統合して使用できるというものです。フリーソフトウェア開発者の多くは、これらの結果によってコラボレーションが促進され、勇気を得ます。しかし、ネットワークサーバーで使用されるソフトウェアの場合には、このような結果が出ないこともあります。GPLは修正バージョンを作成し、ソースコードをリリースしない状態で公衆が修正バージョンをサーバー上でアクセスすることを許容します。Affero GPLは、そのような場合に修正されたソースコードがコミュニティに提供されるように確保するため特別に考案されました。これは、ネットワークサーバーの運営者がそこで実行されている修正バージョンのソースコードを、サーバーのユーザーに提供するように要求します。したがって、一般にアクセス可能なサーバー上で修正バージョンを公開的に使用するということは、修正版のソースコードに対する公開アクセスを許容するということです。

3.5 LGPL License History

Lesser GPL（LGPL）のライセンスは、ライブラリーは共有するものの、開発された製品に対してはソースを公開せず、商用ソフトウェア販売ができるように認めたもので、GPLより緩和されたライセンスです。LGPL 2.1はGNU Lesser General Public Licenseの名称で公表された最初のバージョンですが、GNU Library General Public Licenseバージョン2の後継版と見做し、バージョン番号に2.1を付けたものです。LGPL 3.0はGPL 3.0基盤で作成されました。

LGPLライセンスはフリーソフトウェア財団やその他の著作者のソフトウェアの中で、主にライブラリのように特別に設計された一部ソフトウェアパッケージに適用されます。たとえば、ライブラリのレプリカを無償や有償で配布する場合に、与えられたすべての権利を受取人にもそのまま付与する必要があります。また、受取人がソースコードを受け取られるように、あるいは必要に応じて自ら入手できるように保障する必要があります。もしライブラリに他のコードをリンクさせた場合、受取人がライブラリを変更してコンパイルする場合でも、再リンクをかけることができるように、そのコードに対応する完全なオブジェクトファイルを一緒に提供する必要があります。また受取人がこのような権利を明確に認知できるように、関連規定を表示する必要があります。

3.6 Free Software vs OpenSource

フリーソフトウェアの登場から時間が経過し、いくつかの欠点が指摘され始めました。フリーソフトウェアは制約が多く、GPLの条項のため商用技術開発では活用できないという指摘が代表的なものです。エリック・レイモンド、ブルース・ペレンスなどは「オープンソース」（Open Source）と呼ばれる新しい用語を提案し、企業がソースコードの公開により多く参加できるよう支援しました。同時に、エリック・レイモンドとブルース・ペレンスは1998年に「オープンソースイニシアチブ」（Open Source Initiative, OSI）を設立し、オープンソースに対応するライセンスの最低基準を定義（Open Source Definition, OSD）しました。OSIは、この定義に基づいて、認証、管理、促進を進めています。現在業界では、フリーソフトウェアとオープンソースを混在して使う場合が多いですが、一般的に、オープンソースのソフトウェアは、フリーソフトウェアを含む広い意味として使用されます。

フリーソフトウェア財団は、オープンソースソフトウェアという用語に「自由に使用する権利」が含まれていないと考え、フリーソフトウェアという用語の使用を推奨しています。とはいえ2つの文化が互いに敵対する関係ではありません。GNUプロジェクトの公式ホームページでは、「フリーソフトウェア運動とオープンソース運動は、共同体における2つの政党のようなものだ」とし「フリーソフトウェア運動とオープンソース運動は、基本原則について意見を異にするが、すべての現実的な方策については、同じ考え方をしており、細部的なプロジェクトで共に協力している」と説明しています。特に「フリーソフトウェア運動において、私たちはオープンソースの動きを敵だと思っていない」とし「私たちの少ない独自ソフトウェア」と強調しています。

3.7 設立から30年経ったフリーソフトウェア財団

かつて一部の人々はリチャード・ストールマンを「社会主義者」と表現するほど、過度な理想主義者であると思っていました。フリーソフトウェア財団が設立されてから30年が経過した現在、IT業界の姿を見ると、リチャード・ストールマンの夢が少しずつ実現されているようです。過去のフリーソフトウェア文化に反対していた多くの人々は、「金銭的利益がなければ、誰もプログラミングをしないだろう」、「ソフトウェア開発も競争を通じて、より良い結果を得られる」、「GNUが無料なら、誰もそれを使わない」といった主張をしています。しかし、今では多くの開発者が、フリーソフトウェアとオープンソース運動に同意し、ハブのようなオープンソースリポジトリに先を争ってソースコードをアップしています。

特に開発者文化が発達したIT企業ほど、オープンソースへの投資が活発です。GoogleとFacebookは、オープンソース技術に最も積極的に参加している企業として知られています。Googleはこれまで900以上のオープンソースプロジェクトを公開しており、Facebookも330以上のオープンソースプロジェクトを「みんなの資産」として公開しました。さらに、オープンソースの「ガン」と見られていたMicrosoftでさえ「MSはLinuxを愛する」と、オープンソース陣営の開発者とユーザーにラブコールを送っています。またオープンソース技術のみを維持、補修する専門企業も増えています。

今日、多くのIT企業は、世界中の開発者と協力すれば良いソースコードを作成できる、という考えに概ね同意しています。時には実力のある開発者を採用したり、マーケティング効果を狙う手段として、オープンソースのプロジェクトを進行することもありますが、これには貢献者数とユーザー数を増やして、特定技術の生態系を確保しようとする戦略も隠れています。特にGoogleが「Android」というモバイルオペレーティングシステムをオープンソースとして公開し、新たな市場の競争力を得たのは、オープンソースの生態系の良いロールモデルです。

3.8 ライブラリにLGPLを使用してはならない理由

GNUプロジェクトはライブラリに2つの主な利用許諾（ライセンス）を使用しています。1つは、LGPLと呼ばれるGNU Lesser GPLで、もう1つは一般的なGNU GPLです。利用許諾の選択は大きな違いを生じます。LGPLが適用されたライブラリは、独自ソフトウェアを使用できますが、一般的なGPLが適用されたライブラリは、フリープログラムのみ使用できます。

特定ライブラリへの利用許諾の適用可否は戦略的な問題のため、具体的には状況に応じて異なります。現在、ほとんどのGNUライブラリはLGPLに従っていますが、これは私たちが2つの戦略のうち、1つは無視したままもう1つの戦略だけを追求していることを意味します。このような理由から、私たちは多くのライブラリをLGPLではなく、一般的なGPLで配布しようと努力しています。

独占的ソフトウェアの開発者はコスト面で比較的優位性があり、そのためフリーソフトウェア開発者は、これらの部分を相殺できるメリットを互いに提供する必要があります。ライブラリに一般的なGPLを適用すると、フリーソフトウェアの開発者は、これを使用することができますが、独占的ソフトウェアの開発者は使用ができず、フリーソフトウェア開発者にメリットを提供できます。

一般的なGPLの適用がすべてのライブラリにメリットを提供することはなく、ある場合では、LGPLの使用を勧めています。このような場合の一般的な形態は、GPLを適用したライブラリの機能が、代替ライブラリにより独占的ソフトウェアでも簡単に実装できるときです。GPLが適用されたライブラリがフリーソフトウェアに対する特別なメリットをもたらすことができないため、単純にLGPLを適用するのが、使用範囲を広げるためにも良いと考えられています。

このような理由から、私たちはGNU CライブラリにLGPLを使用しました。GNU Cライブラリ以外にも、他のCライブラリがたくさん存在するので、GNU CライブラリにGPLを適用すると、独占的ソフトウェアの開発者は、彼らが使用できる他のCライブラリを使用することになるでしょう。これらの結果は、私たちに問題を増やすだけで独占的ソフトウェアの開発者にとっては何の問題にもなりません。

しかし、あるライブラリがGNU Readlineのように独自機能を提供する場合は、全く別問題になります。Readlineライブラリは、エディタやシェルのような対話型プログラムを使用するとき、コマンドライン編集や履歴機能を提供しますが、これらの機能は他のライブラリにはない特徴的なものです。したがってReadlineにGPLを適用すると、Readlineの使用をフリーソフトウェアに限定できるので、フリーソフトウェアコミュニティにおいて実質的な力になります。Readlineの機能が含まれるソフトウェアをフリーソフトウェアに作ることができます。

もし私たちが独自ソフトウェアにはない機能を持つGPL基盤の強力なライブラリを蓄積できれば、それは新しいフリーソフトウェアを開発できる非常に便利なモジュールとして活用できるでしょう。これはフリーソフトウェアの開発に一層大きな利点を与えるもので、一部のプロジェクトはGPLが適用されたライブラリを使用するために、今後開発されるソフトウェアをフリーソフトウェアとして作成することにも繋がるだろう。大学のプロジェクトはこれらの影響を受けることが多く、最近では企業もフリーソフトウェアを作り始めており、一部の商業的なプロジェクトもこれらの影響を受けることになりました。

自由競争が持つ重要なメリットを否定しようとする独占的ソフトウェアの開発者は、プログラム著作者にライブラリをGPLソフトウェアに組み込まないように説得しようと努力しています。たとえば、ライブラリを独占的ソフトウェア製品を作るのに使用すると、より多くのユーザーがそのライブラリを使うようになると主張するかもしれません。これらの点をプログラム著作者の自尊心と功名心に求めて説得する場合には、人気を集める単一ライブラリを作り出すことが、フリーソフトウェアのコミュニティが直面する最も必要な要求だという誤った判断を誘導することになります。

しかし私たちはこのような誘惑に負けてはなりません。なぜならGPLのライブラリを通じた団結により、さらに多くのことを達成できるからです。フリーソフトウェアの開発者は互いにサポートをする必要があります。ライブラリをフリーソフトウェアに限定して配布する方法を用いて、仲間の開発者が作ったフリーソフトウェアパッケージがこれに対応する独占的ソフトウェアを凌駕するように助けてくれます。この方法により、フリーソフトウェアが全体的な競争優位性を持つようになると、フリーソフトウェア運動全体がより人気を集めることになるでしょう。

ソース
（1）FSF哲学- https://www.gnu.org/philosophy/free-sw.html
（2）オープンソースとの区分- https://www.gnu.org/philosophy/categories.html
（3）GPL 2.0, 3.0, AGPL, LGPL Histroy
（4）LGPLを使用してはならない理由- https://www.gnu.org/licenses/why-not-lgpl.html

4. MPL（Mozilla Public License）

4.1 Mozilla Foundation登場の背景

Mozillaプロジェクトは、1998年ナビゲーターとエクスプローラとのブラウザ戦争で不利を感じたNetscapeに、ブラウザスイートのソースコードを公開して、数千名に及ぶプログラマが起こすイノベーションの力でブラウザ市場を再びリードしていく目的で開始されました。一年も経っていないので、新しいコミュニティのメンバーは、実際に新しい機能と既存機能のアップグレードと共にプロジェクト自体の企画と管理にも深く関与し始めました。

特定企業が主管していましたが、オープンコミュニティとしてMozillaプロジェクトは、すでに企業の組織範囲を超えて成長し始め、コミュニティのメンバーは、プロジェクトが当初目指したミッションの範囲を超えて、様々なブラウザや開発ツールの開発などのプロジェクトにも参加しています。人々は様々な方法でMozillaプロジェクトに貢献しましたが、これらの努力は2002年、Mozilla 1.0がリリースされて光が射すようになります。このバージョンは、既存のナビゲータブラウザの機能を大幅にアップグレードしただけでなく、電子メールクライアントをはじめ様々なアプリケーションを含むスイートの形態を取りました。しかし、すでにブラウザ市場の支配権は、Internet Explorerに移った状態でした。2002年90％を超えるインターネットユーザーがInternet Explorerを使っており、Mozillaの発表がこれを覆す力はありませんでした。Mozillaにおける新しいブラウザPhoenixも2002年に発表されましたが、このブラウザが後にFirefoxになると、GoogleのChromeが発表されるまでブラウザの地位を少しずつ広げ、Microsoft Internet Explorerに対抗できるブラウザとして奮闘しました。

2003年、Mozillaプロジェクトは、AOLの手を離れて独立した非営利組織であるMozilla Foundationに移管されます。新しいMozilla Foundationは、開放性を維持しながら、技術革新とインターネットの機会を拡大するために様々な役割をしながら、FirefoxとThunderbirdなどが発表できるようにして、ウェブのアクセシビリティ拡大のような公益的な事業を支援するのための研究資金を提供していました。2004年に発表されたFirefox 1.0は、大きな成功を収めながら、1億件以上のダウンロードを記録し、その後市場シェアを拡大しつつ、2008年には全世界のブラウザ市場の20％を突破しました。

しかし、Mozillaプロジェクトと、Mozilla Foundationのこのような成功は決して簡単なことではありませんでした。オープンソースプロジェクトは、そのまま放置しても自ら進行されるものではありません。NetscapeはMozillaプロジェクトのために運営スタッフを6〜8名投入し、100〜150名規模のNetscape製品エンジニアが作成したコードを寄付しています。しかし、Netscapeを買収したAOLの態度が少しずつ変わり始めました。AOLは、Netscapeクライアントを通じてAOLウェブサイトへのトラフィックが増えることを望みましたが、Mozillaプロジェクトチームは、オープンソースプロジェクトの運営原則に則ってプロジェクトを進める必要があり、AOLの様々な圧力に抵抗しなければなりませんでした。この過程で、Mozillaの運営スタッフは、MozillaプロジェクトがAOLに所属したNetscapeエンジニアが主導するのではなく、外部の純粋な開発者が主導するべきであることに気づき、可能な限り核心技術が新しいオープンソースの開発者によって開発できるように誘導しました。このような中で、Netscape製品群の市場シェアは下落します。

ついにAOL内部で2つが対立しました。1つは、オープンソースが驚くべき変化をもたらしたことで、これを積極的に支持して大きなコミュニティを作成するという意見と、もう1つは、主に経営陣の視点で、すべての決定は利益に基づくべきであるという意見です。Mozillaの運営スタッフは、AOLの経営陣との意見の相違がありました。AOLに利益をもたらす方向で運営すると、自発的なボランティアや他の商業パートナーからの熱心な参加を誘導できず、その結果、プロジェクトの質が下がるなら、最終的にMozillaプロジェクトは失敗するということを認知していました。このような葛藤の中で発表されたNetscape 6は市場ですさまじい失敗となり、状況はさらに悪化しました。特にUI要素をめぐる双方の対立が激しく、たとえば、特定のボタンからAOLのサイトに流入させたり、広告に関連した要素を入れて、お金を支払ったパートナーが売上を伸ばす要素を入れるなどが代表的なものでした。

このような葛藤が続き、Mozillaプロジェクトの運営スタッフは、AOLの従業員としての地位との矛盾を感じるしかありませんでした。しかし、彼らはプロジェクトの本質を損なうことができなかったため、事あるごとに経営陣との衝突が続きました。Netscape 6の発表以来、Netscapeブラウザを利用した売上が年々減少すると、最終的にAOLは2001年、Mozillaプロジェクトを率いミッチェル・ベイカー（Mitchell Baker）を解雇し、Mozillaプロジェクトを直接管理しようとしました。しかし、Mozillaプロジェクトの運営スタッフたちの反旗もあり、しばらくの間、外部に権力闘争を晒していました。特に解雇されたミッチェル・ベイカーは、従業員としてではなく、ボランティアへと役職を変え、出勤を続けてプロジェクトを守りました。そしてついに2002年にMozilla 1.0がリリースされました。多くの人々がプロジェクトの完成度に驚きながらも、あまり良いユーザー経験は得られなかったという評価を下しました。当時ミッチェル・ベイカーは、Mozillaプロジェクトの他に、Lotus 1-2-3を作ったミッチ・ケイパー（Mitch Kapor）と他のオープンソースプロジェクトも進行していました。ミッチ・ケイパーはミッチェル・ベイカーとブレンダン・アイク（Brendan Eich）に自分が投資をするから独立したMozilla Foundationを作ってみないかと提案しました。

結局、2003年にAOLは、Webブラウザクライアントへの投資を完全に中断すると宣言しました。すると、ミッチェル・ベイカーは、AOLに対し、Mozillaに最小限の初期資金を与えてくれれば、これを自分たちが運営すると説得をして200万ドルの資金を受け取り、AOLはMozillaから手を引くことになりました。この過程で安定した職場を捨てて不確実なオープンソース財団の仕事をするため、ブレンダン・アイクとブライアン・ベエレンドルフ、クリス・ブリザードもNetscapeを出て取締役に合流し、Mozilla財団が誕生しました。Mozillaが独立した場合、これらを積極的に支援するつもりがあったミッチ・ケイパーは30万ドルを出資して、Mozilla Foundationの初代理事長席になりました。この中にMozillaと志を同じくする一部のエンジニアが参加をして、Mozilla Foundationは10人程度の小規模人材で巨大なオープンソースのプラットフォームを運営しなければならない運命となりました。

Mozilla Foundationの立ち上げも紆余曲折がありましたが、運営も問題が山積みでした。このように大きなコミュニティを管理しながら仕事を進めるには働く人々の数があまりに少なかったのです。何より計画通りに進んでいると仮定しても、最も重要な製品であるFirefoxは15ヶ月後に発売される予定で、少なくともこの時までにまともに働ける資金が確保できるか直ちに問題となりました。驚くべきことに、Mozillaに友好的なパートナーがオフィスを無料で貸してくれました。小さくて何もない劣悪な環境でしたが、Mozilla Foundationを率いる人々には大きな希望と幸福感を与えるものでした。

コア研究者の数が少なかったものの、一生懸命Mozillaプロジェクトのために働き、完全なオープンソースのオペレーティング組織としてブラウザ製品群を作り始めると、その成果は明確になり始めました。消費者向けの視覚的なデザイン要素は重要でしたが、カナダのセンターアイランド（Center Island）において、複数のビジュアルデザイナーが素敵なロゴと過去になかった新鮮なビジュアル要素を作り提供しました。最後に検索が問題になりましたが、この部分はGoogleとYahooなどの競争構図を利用して検索ボックスを使ったMozilla初期のビジネスモデルを構築し、今日のMozilla Foundationの持続可能な発展を根拠付けました。このように、オープンソースの精神哲学と巨大企業の圧力に屈しなかった人々の積極的な闘争が、今日のMozillaを可能にしました。

4.2 MPL License History

Mozillaプロジェクトは、1998年にNetscape社が自社のWebブラウザソフトウェアのソースコードをオープンソースで配布して始まりました。その頃にオープンソースライセンスとしてはBSD系のライセンスと、GPLやLGPLなどが広く使用されていました。しかしMozillaプロジェクトでは、既存のライセンスがMozillaプロジェクトのライセンスには適さないと判断し、MPLという別のライセンスを作成しました。

ところが、MPLライセンスはGPLライセンス等の相互運用性（Compatibility）で問題が発生しました。これらの問題を解決するため、Mozilla Foundationはプロジェクトのコードを「Mozilla tri-license」つまりMPL/GPL/LGPLライセンスに応じて配布しました。よってMozillaのコードは、3つのライセンスによって使用できます。このように3つのライセンスで配布する理由は、Mozillaのコードが他のオープンソースライセンスと相互運用できるようにするためです。Mozilla Foundationは、2004年にライセンスポリシーを変更するまでの2年間、450名以上のすべての貢献者からライセンス移行に関する同意を受けました。

最近改訂されたMPL 2.0はCreative Commons Zero, Other Public Domain Dedications, MIT, New BSD and Similar Permissive Licenses, Apache 2.0, GPL and MPL Dual Licenseと相互運用できます。しかし、CC-BY, CC-BY- *, GPLはそうではありません。

一方、Mozillaの様々な部分で、新しいコード基盤でNon-MPLライセンスを使用していますが、MPLモジュールチームはこれに対する討論を行いました。Non-MPLライセンスの使用を正式に許可しようという提案内容で、新しいコードベースのライセンスでApache 2.0を選択できるようにするということで結論に至りました。

5. EPL（Eclipse Public License）History

Eclipseプロジェクトは2001年にIBMによって開始され、2004年に独立非営利組織であるEclipse Foundationが設立されてEclipseのコミュニティStewardとしての役割を果たしています。現在、Eclipse Foundationのプロジェクトは178件に達します。CPLとEPLはIBMがEclipseなどのオープンソースプロジェクトを進行する過程で作られたライセンスで、現在IBMはEPLのみを使用しています。

NHN Cloud Meetup 編集部

NHN Cloudの技術ナレッジやお得なイベント情報を発信していきます

前の記事次の記事