オープンソースについて調べていくと、ライセンスに関する説明が目に付きます。ここでは、それをOSSのライセンスがどのようなものか、どのような種類があるか、どのように適用するか、といった基本的なノウハウを解説します。
「これは、誰でも自由に利用できるソースコードである」と宣言するのが、オープンソースソフトウェア(以下、OSS)のライセンスの働きです。オープンソースの定義は、OSSのライセンス(以下、OSSライセンス)がどのような条件を満たしているかを述べています。このようなライセンスは、著作権の働きにより効果を与えます。
OSSに限らずソフトウェアのライセンスは、著作権の仕組みの上で働いています。著作権というフレームワークの上に実装されていると考えると、分かりやすいでしょう。
著作権とは、非常に大ざっぱに言えば、作品をどのように公開するか、どのように利用するかを作者が決定する権利です。この権利は、日本の法律では、どこかに申請したり登録したりしなくても、自動的に発生するとされています。
著作物の利用とは、印刷したり録音したり、それを配布するといった使い方を指します。例えば、本誌のような冊子であれば、印刷・出版することが利用になります。
ところが、本を読むことは利用にはあたりません。著作権の考え方では、このような使い方を使用として区別します。使用については、著作権者の許可は必要なく自由に行えます。また、利用についても、教育や引用などの特定の用途であれば自由に行えます。
著作権の話題となると、「勝手に使ってはいけない」という禁止の話になりがちですが、自由に使える部分もあるということを覚えておいてください。
著作物を利用するには、作者から著作権の一部を譲り受けるか、著作権者の利用許可が必要になります。
この著作物の利用許可が"ライセンス"です。ドライバーライセンスと言えば、自動車免許です。殺しのライセンスを持つのは、ジェームズ・ボンドです。
著作物に対するライセンスとは、"一定の条件に従えば、その著作物を指定の範囲で利用してもいい"という利用許可です。たとえば、"お金を支払えば"とか"1万部まで印刷可"といった条件があり得ます。
ソフトウェアは、著作権法上の著作物に当たります。それを利用する場合に、著作権者の許可が必要になります。
ソフトウェアでは、複製・配布・改変について利用許可が必要になります。
ソフトウェアの複製は、CD-Rに焼いたり、インターネットからダウンロード(サーバーからクライアントへのコピー)に当たります。ソフトウェアの配布は、そのCD-Rを販売したり、インターネットで公開することに当たります。ソフトウェアの改変は、機能を変更したり追加することに当たります。
一般的なソフトウェアライセンスでは、このような許可を与えるために、代金を請求したり、使用の一部を制限したりしています。Microsoftは、Windowsなどの自社製品を販売するとき、代金と引き替えに一定の複製を許可します。そのおかげで、パソコ ンにインストールできますが、改変は許可されていません。また、本来自由にできるリバースエンジニアリングなどを制限しま す。
このような利用許可は、ソフトウェアのインストール時に表示されます。利用者が「同意する」ボタンをクリックすると、インストールが完了します。
では、OSSのライセンスは、どのような条件を備えているのでしょうか。これをまとめたのが、Open Source Initiative(OSI)が定めた「オープンソースの定義」(Open Source Definition)です。
ここには、3つの権利と6つの条件が書かれています。ここで重要なのは、次の3つの権利です。
OSSのライセンスには、このような権利が備わっています。利用者は、一定の条件に従えば、ソースコードを自由に利用(複製・配布・改変)できるのです。
その条件は、ライセンスごとに異なっていますが、オープンソースの定義では、最低でも次の条件を備えるとしています。
「個人もしくは団体を差別しない」ので、特定の国で利用禁止とはできません。「使用分野に対する差別をしない」ので、戦争には利用禁止とできません。「再配布時には追加ライセンスを必要としない」ので、別のライセンスを購入しないと利用不可とはできません。
OSSライセンスは、ソースコードの再利用と共同開発を促進するために、できる限りソースコードの複製・配布・改変を制限しないようになっているのです。
OSSライセンスの詳細は、ライセンスの種類ごとに異なっています。ここでは、代表的な3つのライセンスについて、その特徴と理解のポイントを説明します。
オープンソースについて知ろうとすると、GPLについて真っ先に説明されることが多いようですが、これは一番長文かつ複雑で理解が難しいと思います。ここでは、最も単純な修正BSDライセンスから説明していきます。
各ライセンスの代表的なソフトウェアを表1に示します。
ライセンス名採用 | している代表的なソフトウェア |
---|---|
修正BSDライセンス | FreeBSD、NetBSD、OpenBSD |
MPL | Firefox、Thunderbird(ともにMPL/LGPL/GPLのトリプルライセンス) |
GPL | Linuxカーネル、GIMP |
LGPL | GTK+、OpenOffice.org |
このライセンスは、著作権表示と免責条項を含めれば、自由に複製・配布・改変できるとするライセンスです。改変したソフトウェアを商用ライセンスなどの異なるライセンスを適用して公開しても構いません。単に、BSDライセンスと呼ばれる場合もあります。
同様の内容を持つライセンスに、MIT/X11ライセンスがあります。
以下のようなシンプルな条項を持っています。
これは、OSG-jpのOSI承認ライセンス日本語参考訳をもとに、読者の理解を助けるために一部書き換えを行ったものです。短い文なので、じっくりと読んでみてください。
プログラム名
Copyright 制作年著作権者 All rights reserved.
元々、修正BSDライセンスは、カリフォルニア大学バークレー校で、UNIX互換OSの配布用に作られたライセンスです。制約が少ないことから、大学などの研究成果によく利用されます。
しかし、改変版のソースコードを異なるライセンスで配布できるため、他のプログラム中に独占的に取り込まれてしまう可能性があります。
では、OSSライセンスを理解するポイントをいくつか解説します。
OSSライセンスには、「代金を請求してはいけない」と書いてありません。OSSの利点として、無償で配布できることが強調されがちですが、有償でも良いのです。
ただし、有償で販売したものを購入者が再配布できるので、何か付加価値を付けないとビジネスにならないでしょう。
オープンソースでは、元のソースコードを改変した場合に、その改変版を公開しなければならないとする「コピーレフト」の考えを持っているものがあります。
ソフトウェアの改変として、一般的に次のような作業を上げることができます。
どの作業を改変と見なすかは、ライセンスごとに次のようになります。
ライセンス名 | 修正 | 追加 | 静的リンク | 動的リンク |
---|---|---|---|---|
GPL | ○ | ○ | ○ | ○ |
LGPL | ○ | ○ | ○ | × |
MPL | ○ | ○ | × | × |
○=改変,×=改変ではない |
GPL/LGPL/MPLが適用されたソースコードでは、改変となるソースコードを公開する必要があります。ただし、改変版を配布しないのであれば、公開する必要はありません。
オープンソースについてのよくある勘違いとして、「ソースコードを改変したら必ずオープンソースにしなければならない」と考があります。
経済産業省は、GPLの適用と運用について、「オープンソース・ソフトウェアの導入検討ガイドライン」を公表しています。こ れは、経産省の企画の下で、情報処理推進機構(IPA:Information-technology Promotion Agency)による「電子商取引 関連基盤技術開発・実証事業」の一環として、ソフトウェア情報センター(SOFTIC)の研究会がまとめたもので、PDFファイル で公開されています。
産経省:オープンソースソフトウエアの利用状況調査/導入検討ガイドラインの公表について
http://www.meti.go.jp/kohosys/press/0004397/
しかし、このような条件を持っているのは、オープンソースライセンスの一部です(例:GPL)。このような条件は、一般的に「コピーレフト」と呼ばれ、ソースコードを改変したり、独自に開発したプログラムに組み込んだ場合に、改変版プログラムを同じライセンスで公開するとしています。
コピーレフトを条件として持っていない場合(例:修正BSDライセンス)は、改変版のプログラムのライセンスを変更して、非オープンソースソフトウェアとして販売できます。
いくつかのOSSでは、デュアルライセンス(Dual License)を採用しています。これは、複数のライセンスを提示して、ユーザにそれを選択させるという方式です。多くの場合、GPLとそれよりも制限の緩いライセンスの選択方式になっています。たとえば、MySQLでは、GPLと商用ライセンスのデュアルライセンスになっています。
ほとんどのOSSライセンスでは、英語のライセンス文は正文となっています。日本語は、参考訳という位置づけです。インターネットのおかげで、公開したソースコードは、世界中で利用される可能性があります。そのため、できるだけ多く人が理解可能な言語が選ばれています(欧米中心ということかも知れませんが)。
ここでは、OSSのソースコードを利用するとき、ライセンスをどのように適用するか、オープンソースプロジェクトと関わるには、といった実践的な内容を解説します。
まずは、OSSのソースコードを改変したり、自作のソフトウェアをオープンソースにする場合、どのようにライセンスを適用するのか説明します。
OSSのソースコードを利用するのであれば、まずはそのライセンスを確認しましょう。もしも、身近にOSSのソースコードがあれば、そのソースファイルを開いてみてください。ほとんどの場合、モジュールファイルの冒頭にライセンス文かライセンスの宣言文を記述してあります。
修正BSDライセンスまたはMPLのソースコードでは、ライセンス文自体がソースコードの冒頭に記述してあります。GPL/LGPL では、ライセンスの宣言文がソースコードの冒頭に記載してあります。また、ライセンスの全文がソースコードのアーカイブに同梱してあります。
ソースコードを改変したら、修正版を公開するかどうかを判断します。前述の「改変の範囲」を参考にしてください。オリジナルと同じライセンスにしておくのが、手堅い選択だと思います。
なお、改変ソフトウェアを配布せず、自社内で使うだけの場合は公開する必要はありません。たとえば、改変したLinuxをWebサーバーのOSとして用いる場合には、公開しなくても構いません。
自分が開発したソースコードを公開する場合には、ライセンスを選択しなくてはなりません。
では、どのようにライセンスを選択すべきでしょうか。Rubyの開発者であるまつもとゆきひろさんは、自身のブログで「フリーソフトウェアライセンス診断」を公開しており、いくつかの質問によりライセンスを選択できるとしています。これを要約すると次のようになります。
まつもとさんの診断方法は、タイトルからも分かるように"フリーソフトウェア"を対象としています。これは、オープンソースとは微妙に異なるものです。(まつもとさんは、ソフトバンクのオープンソースマガジン2007年1月号に掲載されたオープンソース特集で、この「フリーソフトウェアライセンス診断」をアップデートしています)
企業が自社ソフトウェアをオープンソースにする場合には、デュアルライセンスやCPLについて検討すると良いでしょう。
自作コードをOSSにするには、次のような作業を行います。
修正BSDライセンスとMPLの場合、ライセンス宣言文には、ライセンス全文を使います。GPL/LGPLの場合には、ライセンス全文の末尾に宣言文の雛形が用意してあるので、これを使います。
以上に当てはまらない場合は、修正BSDライセンスを選択する。
あなたが新しいプログラムを開発したとして、公衆によってそれが利用される可能性を最大にしたいなら、そのプログラムをこの契約書の条項に従って誰でも再頒布あるいは変更できるようフリーソフトウェアにするのが最善です。
そのためには、プログラムに以下のような表示を添付してください。その場合、保証が排除されているということを最も効的に伝えるために、それぞれのソースファイルの冒頭に表示を添付すれば最も安全です。少なくとも、「著作権表示」という行と全文がある場所へのポインタだけは各ファイルに含めて置いてください。
one line to give the program's name and an idea of what it does.
Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
訳=====
ここに、プログラムの名前と、それが何をするかについての簡単な説明を記述する。
Copyright (C) 西暦年 作者の名前
このプログラムはフリーソフトウェアです。あなたはこれを、フリーソフトウェア財団によって発行された GNU 一般公衆利用許諾契約書(バージョン2か、希望によってはそれ以降のバージョンのうちどれか)の定める条件の下で再頒布または改変することができます。
このプログラムは有用であることを願って頒布されますが、*全くの無保証* です。商業可能性の保証や特定の目的への適合性は、言外に示されたものも含め全く存在しません。詳しくはGNU 一般公衆利用許諾契約書をご覧ください。
あなたはこのプログラムと共に、GNU 一般公衆利用許諾契約書の複製物を一部受け取ったはずです。もし受け取っていなければ、フリーソフトウェア財団まで請求してください(宛先は the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA)。
=====
GNU 一般公衆利用許諾契約書より Free Software Foundation, Inc., 八田真行訳
ソースコードを改変したり、新しくライセンスを選択するときには、次の点に注意します。
既存のOSSライセンスを選択するとき、その一部を勝手に書き換えて、元と同じ名称で用いるべきではありません。利用者にとって混乱の元になりますし、ライセンスによってはそれを禁止している場合があります。
ライセンスの種類によっては、次のように適用ライセンスを変更できます。
ソースコードを利用するときには、異なるライセンスのソースコードを混在させていないか注意しましょう。ライセンスの組み合わせによっては、混在が禁止されている場合があります。
たとえば、単独でGPLまたはMPLを適用しているソースコードは、単独で他方を適用しているソースコードに追加したりリンクしたりできません。MPLとGPLが、矛盾する追加項目を備えているためです。ただ、MPLとGPLのデュアルライセンスを適用しているソースコードであれば、GPLを適用しているソースコードを追加・リンク可能です。
最後に、OSSライセンスの現状と課題について、いくつかの話題を紹介しましょう。
ライセンスの適用や運用を考えるとき、ライセンス以外の要素も考慮しておくといいでしょう。
ソースコードの改変をプロジェクトにフィードバックしたい人は、各プロジェクトがどのような手順でフィードバックを受け付けているか確認しておきましょう。
OSSのソースコードを利用して、バグを発見した場合を考えてみましょう。自分で使うプログラムにパッチを当てるだけでな く、それを他の人にも役立ててもらおうと公開すると、喜ばれるかも知れません。さらに、他の利用者がいちいちパッチをあてる のは面倒なので、開発元のOSSプロジェクトでソースコードにパッチを統合してもらうと良いでしょう。
しかし、開発元のOSSプロジェクトでは、誰でも自由にソースコードを追加できる訳ではありません。誰でも追加できるとした ら、ウィルスやバックドアを仕掛けられて、それが公式版として配布されてしまうといった可能性があるからです。
OSSは、自由に複製・配布・改変できますが、その改変をフィードバックしたとき、開発元が受け入れてくれるかどうかは別の問題です。
フリーのオフィススイートであるOpenOffice.orgでは、フィードバックする開発者に対して、イニシャル・デベロッパーであるSun Micorsystemsと共同著作権管理契約(JCA:Joint Copyright Assignment)を結ぶよう求めています。モジュールごとに著作権者が違っていると、全体のライセンスの管理が煩雑になりますが、この契約を一種の委任状とすることで、SunはOpenOffice.orgのライセンスを独自に変更できるようになっています。
ソフトウェアは、著作権法上の著作物となっています。しかし、ソフトウェアに含まれる権利は、著作権だけとは限らず、商 標や特許が含まれる場合があります。著作物としてのソースコードは自由に複製・配布・改変できますが、商標や特許だけを取り 出して、自由に使えないとするのが一般的です。これを利用して、オープンソースのビジネスを展開している企業もあります。
Red Hat Enterprise Linux(RHEL)は、Redhatの商標を含めたままでは、複製・配布できないとしています。そこで、コミュニティベースで商標部分を削除した、CentOSなどのRHELクローンが登場しました。
Mozilla財団が開発しているWebブラウザFirefoxでは、その名称やトレードマーク・アイコンの改変を許可していません。そのため、フリーなソフトウェアをボランティアで配布しているDebianプロジェクトでは、FirefoxをベースとするWebブラウザからロゴを削除し、異なる名称で収録しています。
オープンソースが人気を集めてくると、オープンソース以外のコンテンツも誰でも自由に複製・配布・改変できないかと考える人も出てきました。
この場合、OSSライセンスはそのまま採用できないので、次のようなドキュメントや素材用ライセンスが登場しています。
GFDLは、GPL/LGPLと同じくFSFが定めたドキュメント用ライセンスです。Wikipediaが採用しています。一方、Debianプロジェクトでは、GFDLは条件が厳しすぎるとして、フリーなドキュメントとして配布していません。
Creative Commonsは、ドキュメントに限らず、音楽・画像・映像などの創造的な作品に,柔軟な著作権をライセンスで、次のような特徴を持っています。
特に、商用利用の可否・コピーレフトの可否など柔軟な条件を選択できるところも便利です。新規のドキュメントを公開する場合には、こちらが使いやすいと思います。
オープンソースは、いろいろな状況に揉まれながら、着実に存在感を増してきました。同時に、コンピュータを取り巻く環境も刻々と変化しており、それに連れてソフトウェア特許やDRM・ライセンスの国際化対応といった新しい課題が注目を集めています。
FSFは、そのような課題に対応するため、GPLv3への改訂を検討しています。ドラフト1が2006年9月に公開され、現在コメン
トに対応したドラフト2が公開されています。Linuxカーネルの開発者の一人であるリーナス・トーバルズが、このGPLv3に異議を
唱えるなど、議論はまだまだ白熱していく模様です。
(編注:その後、2007年6月29日に正式リリースされました)
とはいえ、ライセンスを選択するのは、著作権者であるソフトウェア開発者です。何となくライセンスを選ぶのではなく、きちんと理解して、作者と利用者の利便性のバランスを取っていくことが欠かせないでしょう。