[PHP-dev 805]Re: mbfilter/mbregexのライセンス問題について

[Moriyoshi Koizumi]

小泉です。

風穴さんのご意見、大変参考になりました。

Ko Kazaana <kaza ＠ kk.iij4u.or.jp> wrote:

> 　ライブラリの利用に際して、そのライセンスが問題となった場合の解決方法と
> して、「ライブラリのライセンスを変更してもらう」というのが、唯一絶対の解
> というわけではありません。
> 
> 　つまり、「問題のライブラリを使い続けるなら、アクセンス・テクノロジー社
> にライセンスを変更してもらうしか方法がない」というわけではない、というこ
> とです。
> 
> 　この点を理解すれば、もう少し柔軟な議論ができるのではないかと思います。

つまり、ライセンスそのものの変更というよりは、ライセンス形態の変更も可能だ
ということですね。

> 
> 　例えば、「PHP開発に関して、特定の誰かに、別のライセンスで提供する」と
> いう方法があります。
<snip> 
> 　具体的には、アクセンス・テクノロジー社は、特定の誰か（個人でも、法人格
> がある団体でも構いませんが、今回の場合は、これに関わっている日本人の、誰
> か信用できる個人にしたほうが、いろいろ楽チンだと思います）との間で、 PHP
> 開発への利用に関して、（単体のライブラリとして配布している際に利用してい
> るライセンスとは別の）特別なライセンス契約を結びます。この「特別な契約」
> では、AさんがそのライブラリをPHP開発に利用する場合に限って（別に限らなく
> ても良いのですが）、ある程度自由に出来る、というようなことになっていれば
> 良いわけです（詳しくは後述しますが、sgkさんが書かれている著作権者の意向
> として、それは問題ないだろうと読み取りました）。
> 
> 　この方法の利点は、Aさんが、アクセンス・テクノロジー社との契約を遵守し
> ている限り、PHP開発におけるライセンスの議論等に、アクセンス・テクノロジー
> 社が直接巻き込まれることがなくなる、という点です。今回のように、著作権法
> やライセンスに関してよく分かっていない人たちから「不便だから、大もとのラ
> イブラリのライセンスを変更せよ」なんて、理不尽なことを言われることもなく
> なります。

始めに私がライセンスの変更を行なうことを提案したのは、まず、本家の開発者に
説明する際に、できるだけ状況を単純化して、きちんと納得していただける状況に
もっていきたかったという点と、現状を鑑みて、その変更によって著作権者の意向
が大きく損なわれることはないだろう、という憶測からでした。

その提案において注意した点は、現在 PHP と共にバンドルされて配布されている 
mbfilter が、元の形態とかなり異なっており、さまざまな PHP 開発者による修正
や機能拡張が行なわれているというところです。

つまり、現状では、どこまでが PHP のパッケージで、どこまでが mbfilter のパ
ッケージなのか、スコープがあいまいなままになっているということです。

私はこの問題を個人的にコミットされた方に問い合わせてみましたが、自分たちは 
PHP に貢献したつもりで、そのライブラリ単体について貢献したつもりはなかった、
とおっしゃっていました。

その方々の考えの是非は別としても、私はそのスコープがはっきりさえすれば、ラ
イセンスの問題が、あるとすれば、それは解消できるものと思っていました。これ
が当初からの考えです。だから、そもそもライセンス変更にこだわっているわけで
はありませんでしたが、正式にお願いするとすれば、ライセンス変更という形でま
ずは検討いただきたいというのが、私のスタンスです。

いずれにしても、私の提案に対し、金本さん、あるいは、アクセンス・テクノロジ
ー社が強い遺憾をもつこと自体は当然かもしれません。この提案を行なった動機に
は、一個人の意見として、双方の利益につながるとの考えがあったことを一応付し
ておきます。

> 　もちろん、ここで「GPL」や「LGPL」にこだわる必要はありません。公衆に対
> する一般的なライセンスとする場合には、GPLやLGPLのような広く知られている
> （といっても、理解されているとは限りませんが ;-)）ものを雛型として利用す
> れば、利用する方も分かりやすい、という利点がありますが、Aさんとアクセン
> ス・テクノロジー社との間では、そういう点は考慮する必要はありませんので。

別にオープンソースのプロダクトには OSI 認定のライセンスを用いる必要がある
という決まりもありませんし、ライセンス形態は自由であって構わないと思いま
す。そこで、異なるプロジェクト同士で個別の契約を結ぶというものも、風穴さん
のおっしゃる通り、選択肢に含まれるかと存じます。各国の国内法においての効力
は不明ですが、デュアルライセンスという形態もありますし。しかし、私の知る限
りでは、今回のケースはやや特殊なものと感じられますが、過去にそういった事例
があるとしたら、非常に興味深いです。もしありましたら、ポインタを示していた
だけると幸いです。

> 　ライセンス（今回の議論では「利用許諾契約」）というのは、当事者間の合意
> であればよく、特に、その当事者間でそれを巡って争いとなる可能性が極めて低
> ければ、文面も、特に難しく考える必要はありません。法律上は（少なくとも日
> 本国内法上は）、口約束でも契約は成立します。

ライセンスと一口に言っても、パッケージを配布する立場にいる当事者同士の契約
という側面もありますが、利用する側と、パッケージ配布者の間の「約款」という
側面もあります。その点をクリアにしなければ、安易にライセンス形態を変更する
ことは、望ましくない結果を生む懸念があることを指摘したつもりでしたが、その
点は考慮する必要がないのでしょうか？

> 　あと、アクセンス・テクノロジー社の意向として、著作権者表示をきちんと入
> れてほしい、というのがありますが、これは当然守られるべきです。私が上で述
> べたような、方法を取る場合でも、アクセンス・テクノロジー社の著作権者表示
> は、きちんと入れられなければなりません。このことは、アクセンス・テクノロ
> ジー社とAさんとの契約に「入れること」を明記しても、しなくても、変わりま
> せん。

この問題は、まったく今回のライセンスの問題とは違うものですね。今後、さらに、
著作権者表示を徹底するよう、一介の開発者としてはすぐに対処したいと思ってい
ます。

> 　GPLやLGPLというのは、まさにsgkさんが指摘されていたように、フリーソフト
> ウェアライセンスの「便利な雛型」であって「法律」ではありません。なので、
> 「GPL違反」とか「LGPL違反」という言い方は正しくありませんし、議論の混乱
> の元にもなりかねません。

ここは、ずっと誤解されていると感じる点の一つなのですが、GPL や LGPL に違反
しているとの指摘の意味は、PHP のパッケージを配布する側が契約に違反している
可能性があるということです。アクセンス・テクノロジーはじめ、mbfilter のパ
ッケージ配布者の方は、この議論の前に、LGPL 以外の契約形態を提示されていま
せんでしたから、もし、PHP での利用形態を見て、他のプロジェクトにおいて、
mbfilter を完全にパッケージに統合し、他の契約文書によってそれを配布するこ
とには問題がないと判断された場合において、後で、著作権者が権利を主張するこ
とができるのかというと、著作権者の意向とはいえ、できない場合もあるのではな
いでしょうか？私にはその判断はしかねますが、著作権者の文書化されていない意
向を、すべてのパッケージの配布者と利用者に伝達することが事実上無理な以上、
その約款が利用条件のすべてである、とパッケージの配布者と利用者が判断するこ
とは無理がないと思います。

これをこの議論にもってくるのは不適かとは思いますが、
日本国の著作権法第二十条では、著作権者の同一性保持権について、
「特定の電子計算機においては利用し得ないプログラムの著作物を当該電子計算機
において利用し得るようにするため、又はプログラムの著作物を電子計算機におい
てより効果的に利用し得るようにするために必要な改変」が加えられることについ
ては、適用を受けないと述べられています。

それに、 LGPL で記載されている条文は、必ずしも著作権を保護するための条文で
なく、もっと一般的な契約条項を含んでいますので、その点で、私は現状と、その
条文に書かれている内容が「矛盾」すると言ったまでです。権利が有効にならない
おそれはあるとは言いましたが、著作権が無効になるとまでは述べたつもりはあり
ません。