More info...

2009-09-08

GPLの境界線

GPLを利用するにあたって度々議論されるのが「プログラムの境界」という問題である。GPLソフトウェアを改良または組み込んで別のソフトウェアを作成すると、頒布する際に新しく作成したソフトウェアのライセンスもGPLにしなければならない。ここで注意しなければいけないのは、どこまでがそのソフトウェアの「境界」なのかということである。言い換えると、どこまでが「GPLソフトウェアを組み込んだ」状態なのかということである。自分のソフトウェアをGPLで頒布しようと考えている人にとっては、境界線はあまり意識しなくてもいいテーマである。優れたGPLソフトウェア資産は利用し放題のワンダーランドである。しかしGPL以外のライセンスを利用したいと考えている人にとっては、どこまでならGPLのソフトウェアを利用しても構わないのか?ということを明確に把握していないと、後で著作権法違反で訴えられることになってしまうので注意が必要である。そのような問題があるとなるとGPLソフトウェアを毛嫌いするようになって、極端な人は「コンピュータ内でひとつでもGPLソフトウェアが動いていればそのコンピュータ全体をGPLにしなければいけないのか?」と考えてしまう人も出てくるだろう。GPLについての知識が乏しく、「得体の知れない恐ろしいライセンス」だと考えている人はそのような誤解をしてしまうかも知れないが、しかし実際はそのようなことはない。そのように恐怖してしまうのはGPLについてよく知らないからであり、GPLについて正しい知識を身につければ無闇に恐れることもなくなるだろう。より多くの人にGPLソフトウェアを利用して貰い、時には他のライセンスを用いて上手にGPLとつきあい、時にはGPLでソフトウェアをリリースして社会に貢献することができるよう、今日はGPLの境界線について説明しようと思う。

ズバリ、境界線はプロセス

多くのOSにはGPLソフトウェア、例えばGNU tarやGCC、gdb、bash、GNOME、MySQLなどがバンドルされている。商用ライセンスのもの、例えばMac OS X Serverなどである。GPLソフトウェアをバンドルするとOS全体をGPLにしてソースコードを公開しなければいけないんじゃないか?と思うかも知れないが、そのようなことはない。GPLにおいて、「ソフトウェアを一部に取り入れた」と見なされるのはプロセスまでである。従って、GPLと同一のプロセスで動作するようにしなければ、ライセンスをGPLにしなくても良いのである。いくらMySQL Serverをバンドルしていようが、Mac OS X ServerをGPLにしなくても良いのはこのためである。

同一のプロセスとして動作するということは、

  • 元のGPLソフトウェアを改造
  • GPLのライブラリをリンク

のいずれかをするということである。それ以外の場合は、安全にGPLと他のソフトウェアを組み合わせて利用することが出来るのである。

ここはMPLやCDDLなどのライセンスと大きく異なる点である。MPLやCDDLにおけるソフトウェアの境界線は「ソースコード」である。ライブラリをリンクしようが何しようが、元のソースコードに手を加えなければライセンスをMPLまたはCDDLにしなくても良い。このため、これらのライセンスはGPLとは非互換であり、コピーレフトの強制力はずっと緩い。(コピーレフトの観点からしても、互換性の点からしてもダメライセンスなのである。)

ネットワーク経由で利用する場合

GPLのサーバープログラムへネットワークを介して接続するクライアントプログラムを作成する場合、そのクライアントはGPLにしなければいけないのか?答えはNo!!である。上記の通りGPLソフトウェアの境界線はプロセスであり、ネットワークを介して接続する場合にはGPLの強制力は働かない。どのようなライセンスを採用するかは自由である。MPLでも、Apacheライセンスでも、プロプラエタリでも問題ない。

だったらMySQL Serverに接続するクライアントプログラムもGPL以外のライセンスを自由に採用してもいいのか?!と思うかも知れないが、ここには注意すべき点がある。クライアントプログラムがlibmysqlclientやConnector/J(JDBCドライバ)を利用する場合、これらのライブラリがGPLであるためリンクするとGPLの強制力が働いてしまう。MySQL Serverへ接続するプログラムをGPL以外のライセンスでリリースしたければ、これらのライブラリを利用せず自分で接続用のドライバを開発するか、libmysqlclientやConnector/Jの商用ライセンスを購入する必要がある。

インタープリターは?

もしインタープリターのライセンスがGPLだった場合はどうだろうか?実はGPLにはインタープリター上で動くプログラムに対する強制力はない。インタープリターがGPLであっても、インタープリター上で動くプログラムはGPLにしなくても良い。

ただし、インタープリターに拡張モジュールを追加した場合には注意が必要である。もしインター上で動くプログラムが拡張モジュールを利用するようであれば、そのプログラムはGPLにしなければいけない。この点はとても理解に苦しむ点かも知れない。何故ならばインタープリターがGPLでもGPLの強制力はないのに、そのインタープリターにGPLの拡張モジュールを追加した場合は強制力が働いてしまうからだ。

このようなややこしいルールが設定されている理由は明確で、それは抜け穴を塞ぐためである。もし、拡張モジュールとしてGPLのライブラリを利用しても良いのであれば、GPLのライブラリはインタープリターを介せばGPLの強制力が失われてしまうことになり、プロプラエタリな製品で利用し放題になってしまう。これではGPLの意義は失われてしまうだろう。優れたGPLライブラリがあり、そのライブラリを拡張モジュールとしてインタープリター上で動くプログラムで利用したければ、そのプログラムはGPLにしなければならないのである。

PHPやPerl、RubyなどでMySQL Serverへ接続するためのプログラムをGPLにしなければいけないのはこの制約があるからであり、これらのプログラムがMySQL Serverへ接続するための拡張モジュール(mysql拡張、mysqli拡張、DBD::mysql、MySQL/Rubyなど)はlibmysqlclientのバインディングになっているのである。GPLのlibmysqlclientを利用するため、例えインタープリター上で動くプログラムであってもGPLにしなければならないのである。

2 件のコメント:

  1. 「境界線はプロセス」とは言い切れません。
    FSFは(解釈できる余地を残しておくためか)明言を避けています。

    「単なる集積」と「二つのモジュールを一つのプログラムに結合すること」の違いは何ですか?

    つまり

    1 - 静的リンク - 言うまでもなく結合
    2 - 動的リンク - ほぼ間違いなく結合
    3 - プロセス - プロセス間通信が緊密なら結合かも

    ※ただしこれはFSFの見解なので、続きは法廷で


    ついでにGPLにはOSコンポーネント例外(3節)があるので、境界がどうであろうと、Mac OS X ServerをGPLにしなくても良いと思います

    返信削除
  2. beroさん、

    ご指摘ありがとうございます。複数のプロセスがIPCで協調動作するような場合が3のケースに当てはまりますね。まだまだGPLについて知らなければならないことが多いです。

    返信削除