ビジネスとオープンソースライセンス（後編）

オープンソースビジネスでは、どの製品をオープンソースにし、どの製品を販売するのかの判断が重要だ。オープンソースのクライアントと、特許に守られたサーバソフトウェアの組み合わせなどは、最良のビジネスモデルの1つだろう。

宮本和明
株式会社ホライズン・デジタル・エンタープライズ
2000/10/3

今回のおもな内容 成功するライセンスの選び方 GNU GPLは後戻りできない パッケージングの際には　「derivative（派生物）」の定義に注意 オープンソース・ライセンスと特許の組み合わせはうまくいくか 倒産したらソ「オープンソース化する」というライセンスはいかが

成功するライセンスの選び方

　前回は、オープンソース周辺ビジネスを展開するという方向で話を進めた。今度は、自社のソフトウェアをオープンソースにするかどうか、という観点から、オープンソースのライセンスなどについて考えてみたい。

　企業にとって開発とは投資である。開発者の人件費は基本的に高い。企業という組織体では、投資に対しては必ず回収が求められる。開発したソフトウェアのオープンソース化は、単純に投資の回収効率を下げる可能性が高いので、採用しにくい手段である。

　したがって、投資の回収可能なビジネスモデルを示すには、回収できる仕組みを組み合わせてオープンソース化を採用することになる。つまり、開発したソフトウェア以外のところをメインビジネスにして、それを支援するために、ソフトウェアをオープンソース化することは考えられる。

　前回、オープンソースビジネスは、オープンソース周辺ビジネスだと述べたが、今回の場合も同様なスタンスをとることが多い。前回示した、以下の図を参照していただきたい。

どこで儲けるか？	オープンソースをどう利用するか？
本を売ることがメインのビジネス	テーマがオープンソース
サービス業務がメインのビジネス	サービスを支援する対象がオープンソース
セミナー開催がメインのビジネス	セミナーの教材となるのがオープンソース
別の商用サーバ・ソフトウェアがメイン商品	クライアント・ソフトウェアは自社製オープンソース

　この4つ目の例も、ほかの3つの例と同じく、メインビジネスである「商用サーバソフトウェア販売」というビジネスモデルがしっかりできているかどうかが、成功の鍵を握っているのである。

　ここで一点注意したいのは、IT業界は非常にトレンドの移り変わりが速いので、現時点では利用するに値しないと思ったものでも、3カ月後には売れ筋商品になっていることがよくある、という点である。

　そこで、そうしたトレンドの変化を踏まえて、4つ目の例である、商用サーバソフトウェアが有償で、クライアントソフトウェアはオープンソース、というビジネスの展開を考えてみよう。

GNU GPLは後戻りできない

　実は、この「商用サーバソフトウェアが有償で、クライアントソフトウェアはオープンソース」はNetscape NavigatorとNetscape Enterprise Serverとの関係に近く、最近よく見かけるようになった組み合わせである。 要するに、マーケティング戦略としては、「クライアントソフトウェアをオープンソースライセンス準拠にすることにより、普及を促進させよう」ということである。

　ところが、3カ月後に、実はサーバソフトウェアよりクライアントソフトウェアの改良版を自社ソフトとして、ライセンスを守って販売した方がよいのではないかということになった場合はどうだろう。

　まず、元のクライアントソフトウェアのオープンソースライセンスをGNU GPL（GNU General Public License）にしていた場合には、前回述べた通り、後戻りはできない。なぜなら、GNU GPLにはこういった後戻りをさせないという目的があり、ほかのライセンスへの転用が規制されているからだ（記事末のコラム参照）。

	オープンソース ワールド 若林宏著 秀和システム 1999年 ISBN4-87966-850-8 2400円

　「ぼくは営利に反対したことはない。ソフトウェアの販売にも賛成だよ。」とリチャード・ストールマン（Richard Stallman）氏は語っているが（「オープンソースワールド」P.55参照）、GNU GPLが現在のビジネスにおいて使いにくくなっていることは事実なのだ。したがって、現実的な路線としては、BSD型のコピーライトが選択されることが多いのである（それぞれのライセンス内容については、前回を参照）。

　しかし、ビジネスにおいて、GNU GPLを選択した方がよい場合もある。そこで、GNU GPLを選択する場合のメリットも考えておこう。

　ちょっと小耳に挟んだ話だが、LinuxがFreeBSDよりも進歩のスピードが速かった要因には、GNU GPLを選択したことが挙げられる、という。 つまり、Linuxカーネルがパブリック・ドメインという１つのスタンダードに収斂したおかげで、カーネルのスタンダードが枝分かれをせずに済んだ。だから、いくつもに枝分かれをしたFreeBSDよりも周辺ソフトウェアが作りやすく、進歩のスピードが速かったのではないか、ということである。

　確かに、GNU GPLがBSD型コピーライトに比べて枝分かれしにくいというのはもっともな気がする。なぜなら、BSD型コピーライトの場合、他社が派生ソフトウェアを自社ライセンスとして販売し、強力な販売力（またはマーケティング力）で特定の業界でのスタンダードを作り上げてしまう……ということもあり得ない話ではないからだ。そう考えると、オープンソースを利用するビジネスにおいて、GNU GPLを選択することにも、十分にメリットがあるといえる。

パッケージングの際には 　「derivative（派生物）」の定義に注意

　技術的な面にも注目してみよう。ソフトウェアで連携することになるとパッケージングの仕方を工夫しなければならない。

　当社では、HDE Linux Controllerというソフトウェアを販売しているが、これはlcserverというデーモンの上で動作することになっている。lcserverはApacheをカスタマイズしたものであり、Apacheライセンスの下に配布されることになっているので、当社としては、HDE Linux Controller にlcserverを“含む”ことはできない。そこで、HDE Linux Controllerとlcserverを別のパッケージにして、HDE Linux Controllerを販売し、それにlcserverを添付するという形をとっている。

　この販売・配布方法で問題がないという結論に至るまでには、実にさまざまな議論がなされた。まず議論されたのは、HDE Linux Controllerがlcserverというデーモンに「依存」しているとすれば、HDE Linux Controller自体がApacheの「derivative（派生物）」だとみなされるのではないか、という点についてだった。もし「派生物である」ということになったら、HDE Linux Controller自体をApacheライセンスの下で配布しなければならなくなるからだ。

　ところが、ここで問題になるのは、「派生物」の定義である。GNU GPLをみてみると、

a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. （「プログラム生成物」とは、プログラム自身、または、著作権法下における全ての派生物：すなわち、そのプログラムの全部または一部を、そのまま、または、変更して、且つ／または、他の言語に変換して、内部に組み込んだ生成物を意味します）

とある。この文面からだと、“a work containing the Program or a portion of it…” ということなので、我々としては「自分の作ったプログラムはここまでです」と意思表示し、そこに元となるプログラム（の一部）が含まれていなければ、派生物ではないということになる。 “under copyright law…”とあるので、さらに正確な意味を知りたければ、各国著作権法内の“derivative”という単語を追いかけていけばよい。

　だが、プログラムに関して言えば、「含まれて」いるかどうかの判断が難しい場合がある。それは、“link”である。「リンク」とは、いわば、「そこに存在しないのに、まるで存在しているかのような振る舞いをする」という状況である。そのため、元のプログラムにlinkするようになっているプログラムは、元のプログラムを含んでいることになるかならないかを誰かが定義しなければならない。現実問題として、この定義はライセンスによって異なっている。GNU GPLよりも制限がゆるやかとされるGNU LGPL(GNU Lesser General Public License) では、

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. （ライブラリまたはその一部の派生物を含んでいないが、共にコンパイルされたり、リンクされたりすることによってそのライブラリとともに動くように設計されたプログラムは、「ライブラリを利用する生成物」と呼ばれる。そのような生成物では、そのことだけでは、ライブラリの派生物ではなく、それゆえ、ライセンスの範囲外になる）

となっているから、リンクしているからといって必ずしも派生物ではないことになっている。

　他方、GNU GPLでは、

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. （GPLは、あなたのプログラムを、財産権の対象となっている他のプログラムに組み込むことは認めていません。もしあなたのプログラムがサブルーチンライブラリなら、そのライブラリを財産権の対象となっている他のアプリケーションとリンクさせることによってさらに有用なものにできるかもしれません。もしそれを望むのであれば、GPLではなくてLGPLを利用してください）

となっている。linkという単語を追いかけていくかぎり、GNU GPLではリンクだからといって派生物ではない、と切り分けることはできないようだ。

　先ほど、HDE Linux ControllerとApacheの関係に触れたが、もしApacheがApacheのライセンスではなくて、GNU GPLに従っていて、かつ、HDE Linux Controllerの一部がApacheの一部にリンクを張っていたとしたら、HDE Linux ControllerはGNU GPLでなければならないことになる。幸いなことに、ApacheはGNU GPLではなく、HDE Linux ControllerもApacheの一部にリンクを張っているわけでもなかったので、別パッケージとして考えることが可能であった。

　要するに、このような点については、それぞれのソフトウェアのライセンス条項を１つ１つ追いかけねばならず、さらに言えば、そのソースを書いた人のコメントを確認していくのが確実な方法である。

　例えば、リーヌス・トーバルズ（Linus Torvalds）氏は、Linuxカーネルのライセンスがどこまで及ぶかについて直接触れている（「オープンソースソフトウェア」参照。もしくはWeb版第8章）。

オープンソース ソフトウェア クリス・ディボナ、 サム・オックマン、 マーク・ストーン編著 倉骨　彰訳 発行：オライリー・ジャパン 発売：オーム社　1999年 ISBN4-900900-95-8 1900円

「オープンソース周辺のソフトウェアを開発する者としては、リンクあるいは同時にコンパイルしようとしている同梱ソフトウェアがどんなライセンスに従っているかを正確に認識し、自分の開発しているソフトウェアのライセンスの選択肢がいくつあるのかを把握する必要があるだろう」と。

　また、上記のような技術的な努力をフォローする意味で、ソフトウェアに付随させるドキュメントの内容を確認することも重要である。実際には派生物でなくとも、ドキュメントに「これは＊＊＊をカスタマイズして作ったものである」などと記述しているだけで、ライセンスの問題を問われることになりかねない。そういう点では、技術者とドキュメント作成者、法務担当者との密接な連携が要求される。

オープンソース・ライセンスと 　特許の組み合わせはうまくいくか

　ここでオープンソースの対極にあるともいえる、特許についても考えておきたい。

　オープンソースと特許が混じって、やや混乱状態になっているソフトウェアに、「openssl」がある。名前の通り、ソースコードはオープンになっていて、無償で手に入る。しかしここで使われている技術は米国ではRSA社の特許になっている。特許は基本的に属地主義をとっているので、米国を離れると特許に関する問題はこの限りではないなど、さらに混乱に輪をかける結果となっている。

　当社も暗号化の技術を採用しようとしたときにopensslを検討したが、上記の問題については明確な解答がなく、非常に悩まされた。opensslの元になったSSLeayのWebページ（原文、日本語訳参照）を見ると、作者自身も

Is this legal? That is one of the hard questions on which there is as yet no clear answer. You need to read quite a bit of information to draw your own conclusions - and then go and talk to a lawyer. （これは合法的ですか? − それは最も難しい質問の一つで、まだ明解な答えがありません。あなたが結論を出すにはかなりの文書を読み(SSLeayのソース配布の中にある四方八方に分散したファイルを見て下さい) - そして弁護士に相談に行く必要があります）

と語っている。

　企業がソフトウェアを販売できる権利を守る手段としては、特許は非常に有効だ。前述の例の「商用サーバソフトウェアとオープンソースのクライアントソフトウェア」というビジネスモデルの場合でも、1つ間違うと大変なことになる。自社の身銭をきってオープンソースソフトウェアを開発し、オープンソースのメリットを利用して普及させた仕組みを、他社の戦略によって、全部もっていかれる可能性があるからだ。そしてそうならないようにするには、重ねて言うが、特許は非常に有効な手段だ。

　オープンソースと特許がひとつのソフトウェアに混在していると、opensslのように問題はこんがらがってしまう。グレーゾーンの残るプロダクトは、エンドユーザーがこっそり使うことはあっても、大々的に市場において採用されるのは難しい。グレーゾーンを回避する最も簡単な方法は、オープンソースであるソフトウェアと商用ソフトウェアとを明確に分けることだ。

　プロダクトを明確に分けた上で、それらをうまく組み合わせると、ビジネスが成立する可能性が出てくる。いやむしろ、普及しやすいオープンソース・ソフトウェアと特許で守られた商用ソフトウェアとは実は非常に相性の良い組み合わせになるのである。

　今のところ、「特許技術によって作られたサーバソフトウェアと、オープンソースのクライアントソフトウェアの組み合わせ」というのは最良のオープンソースビジネスモデルの1つとなり得るのではないか、と私は考えている。

倒産したら「オープンソース化する」 　というライセンスはいかが

　最後に1つ提案をしておこう。

　ソフトウェアをオープンソース化するメリットとして“必ず”挙げられる項目が、実はもう一点ある。それは、企業が自社開発のソフトウェアの面倒（バグフィックス／アップグレード）を見なくなる、あるいは、見られなくなった場合でも、オープンソース化されていれば、ソフトウェアのメンテナンスが継続する可能性があるということだ。

　特に、ソフトウェアを購入したのにその会社が倒産してしまった、ということになると、クローズドなソフトウェアの場合、実に大変な事態となる。それならいっそのこと、「企業が倒産したら、その企業が開発したソフトウェアはすべてオープンソース化する」という条項を持つライセンスがあれば、非常に世のためになるだろう（とはいえ、優秀なソフトウェアであればライセンス譲渡・営業譲渡が考えられるので、実はその方がメンテナンスが進む場合もあり、一概にそうとは言えないが）。

　「当社が倒産したら、このソフトウェアはオープンソース化し、http://…/ に公開します。ただし、ライセンス譲渡された場合はその限りではありません」なんていうライセンスは、ある意味お洒落な気がする。御社のライセンス条項として、採用してはみてはいかがだろうか。

コラム　GPLについての補足 　本文中の記述「元のクライアントソフトウェアのオープンソースライセンスをGNU GPL（GNU General Public License）にしていた場合には、前回述べた通り、後戻りはできない。なぜなら、GNU GPLにはこういった後戻りをさせないという目的があり、ほかのライセンスへの転用が規制されているからだ」について、読者から、「そのソフトウェアの著者の権利としては、そのソフトウェアをGPL以外のものに変更する権利があるはずだが……」というご指摘をいただきました。 　ある人（甲さん）が、「A」というソフトウェアをGPLで公開し、その後、甲さん自身によって、「Aの派生ソフトウェア（＝A’）」を公開する場合には、AがGPLであるかぎり、A’もＧPLにしなければなりません。もしも、A’をGPLでないライセンスで公開しくとも、A’だけをＧPLでないものに「後戻り」させることはできないので、ＡをGPLでないものに変更して、その上でA’を任意のライセンスで公開しなければならないことになります。 　しかし、ご指摘の通り、すでにオープンソースとしてGPLに従って公開されているソフトウェアであっても、著作者の権利として、そのソフトウェアをGPLでないものに変更することは可能です。 　ただし、ここで考えなければならないことは、甲さん以外の人（乙さん）がAを手に入れ、その派生物（A’’）を作ったり、さらにその派生物（A’’’）がでてきて公開されていたりする場合のことを考えると（当然A’’やA’’’はGPLで公開されることになります）。気軽にAをGPLでなくすることは困難です。 　場合によっては、乙さんを始めとする派生物の作者や配布者に（法的に、あるいは道義的に）なんらかの承認や断りが必要になることもありえますので、ご注意いただくのがよいかと思います。

■記事履歴 2000/10/18
コラムを追加

Profile

宮本 和明　（みやもと かずあき） 株式会社ホライズン・デジタル・エンタープライズ代表取締役副社長。 東京大学文学部卒。在学中に黎明期のホライズン・デジタル・エンタープライズに参加。 97年11月、代表取締役就任。現行プロダクツの前身となるものを企画・開発。 現在は危機管理を中心として、全社的な管理業務を担当する。オープンソースソフトウェア の取扱いは重要な管理課題の1つであるという。

Linux Square全記事インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）