[PHP-dev 677] Re: mbfl ライセンスに関して

[php-dev@php.gr.jp]

On Sun, Jan 05, 2003 at 05:37:37AM +0900, sgk wrote:
> お返事するのにすごーく時間がかかってしまって申し訳ありません。
> 私事でかなりばたばたしていまして、気持ちにも余裕が無いです。
> でも、どうお返事していいもんだか、困っていたことは確かです。

議論を始めるにしては不明瞭な文章になってしまいまして、大変申し訳ないです。
 
> あと、細かいところで恐縮ですが、「…LGPL違反である」
> ではなくて「…ライセンス違反である」ではないかと。
> LGPLそれ自体は使用許諾契約ではないということを
> ご理解いただいていますでしょうか？LGPLやGPLそれ自体は、
> あがめたてまつるようなものじゃなくて、ただの例文集ですから。

私が LGPL 違反だというは、mbfl を利用している php の配布形態
のことです。つまり、私は、現在 php のソースにバンドルされた形でしか
mbfilter は配布されていないと勘違いしていましたので、
この配布の仕方はまずい、という意味で書いたつもりでした。
ただ、LGPLという名で呼ばれているライセンスに違反している
という趣旨のことを「LGPL違反」と書いちゃまずいですかね?

ただ、もしかしたら、LGPL が効力を発揮するのに必要な要件を
mbfilter が満たしていないという趣旨のことを「LGPL違反」などと
他のところで書いているかもしれません。だとしたらすみません。


> よくわかんないままでは議論が進みませんので、
> こちらの状況を説明しておきます。
> 少しは疑問の答えになるかもしれません。
> 
> 1)ハッピーサイズという会社が作ったソフトウェアがベースである。
> 
> 私が在籍していたハッピーサイズっていう会社がありました。
> この会社で漢字コード変換フィルタライブラリを作って、
> 自社で使っていました。ソースファイルのコメントに書いてありますが、
> 最初はC++で書いてあったのですが、PHP3への利用という話を
> 期として、Cに書き直しました。このあたりの作業は私がやった
> ものですが、会社業務として行いましたので、会社の著作物です。
>
> 2)ハッピーサイズはこれを無償で一般に提供した。
> 
> 一般にって言っても、PHPで使われた他はめだつところでは
> 使われていないようです。持って行った人は多数。

これらは私の認識内のことですので、誤解はないはずです。

> 3)このソフトウェアは今でも提供されている。
> 
> ftp://happysize.com/opensource/happysize-kanji-0.3.tar.gz
> 当時からこのURLだったかどうかは定かじゃありません。
> ソースを見ていただくとおわかりのとおり、あまり、
> かっこよくはないです。

この場所を知りたかったんです。ここで原型が存続することが明らかになりました
から、この場所をソースコードに記載したほうがいいと思います。
 
> また、ソースに記載のメールアドレスに問い合わせても、
> ソースをもらうことができます。URL教えられるだけですけど。

これは、まず私がやるべきことでしたね。もしやっていれば、今回の議論
は無用だったかもしれません。


> 4)無償提供したのは、一定の希望を持ってである。
> 
> ・自社のソフトウェアの実用性を確かめたい。
> ・世の中に少しは貢献したい。お返しがしたい。
> ・このソフトウェアが発展していくといいな。

これに関しては非常に共感するところですが、今回の議論とは
直接関係ないですね。

> 5)ライセンス条項としてLGPLを選択した
> 
> 最初はGPLでしたが、後にLGPLになりました。
> GPLにしたのは、PHP3がGPLだったからです。変更の理由は、
> 上記の「希望」によれば、LGPLがより望ましいだろうとの考えです。
> 
> 変更に際しては、すでにPHP3のために大きく機能拡張を行っていた
> 塚田さんの了承を得ています。
> 
> LGPLを選択したのは、自社で細かい条文を書けなかったことと、
> 当時他にテキトウな例文集がみつけられなかったからです。

このいきさつは、過去ログなどから調べていましたので、多少存じていました。

> 6)当然ながら、ハッピーサイズの著作権は拡張部分には及ばない。
> 
> ハッピーサイズの使用許諾契約は、各々の変更者が変更部分に
> ついてLGPLを適用することを条件に変更と再配布を許しています。
> 当然ですが、ハッピーサイズの諸権利やコントロールは、
> 拡張部分には及びません。
> 
> もしもライセンス内容を変更するとしたら、拡張部分については
> それぞれの著作者（主に塚田さん）の了承を得る必要があります。

金本さんは、おそらく私がここのところを理解していないとお考え
なのかもしれませんが、これに関して、私の認識としては、

 - ソースコードに関する著作権
 - ライブラリという物(パッケージ、生成されたオブジェクトコード)
   に関する著作権

この2つは切り離して考えなくてはならないと思います。

例えが悪いのかも知れませんが、たとえば日本における百科辞典の著作権
がどうなっているのかを見てみますと、 辞典自体は編集著作物であるとして、
素材を収集して、 ある形に整えたことに独創性が認められるという
仮定の下で著作権は出版者に帰属しますが、記事自体の著作権は、
出版者に複製許諾を与えたその著作者に帰属するとのことです。
(参考: http://www.cric.or.jp/houkoku/s63_10/s63_10_main.html)

とにかく、ソースコードのみの配布が行われるのだとしたら著作権の所在は
非常にクリアになりますが、バイナリ化してしまったものに関しては、
どのオペコードがどの著作者由来の物なのか、という話になってしまうと
ナンセンスなので、

 a. 共同著作権という形で、著作者全員が一つの著作物に関する諸々の権利
    保持するようにする。日本の場合、著作権法第65条によれば、著作権の行使は、
    全ての著作権者の同意が必要ですが、これを拒否する場合は正当な理由が必要
    ですので、おそらく問題は起こらないでしょう。

 b. 何か任意の法人格を立て、著作者が、その法人に、著作物からの生成物に関する
    権利を保持することを認めるようにすることで、権利の所在をはっきりさせる。
    (Apache Software Foundationスタイル)

のいずれかの道を選択する必要があると考えます。
今回は(a)のケースだと思うのですが、
ハッピーサイズ社がライブラリの一次複写物を領布しており、なおかつ
パッケージングもハッピーサイズ社が行っているのだと見なされる場合は、
編集著作権がハッピーサイズ社に(アクセンス・テクノロジー社に)帰属するかも
しれません。(これ以上は何分裁判沙汰になった事柄ではないので、
明確な解はないと思います :)

(snip)
> 
> ライブラリとしての独立性云々の話について。PHP3の最終版まで
> について言えば、ライブラリとしての独立性は保たれていたと
> 考えます。.aファイルを作るようにはなっていませんが、
> .aがライブラリの必要要件というわけではないですよね。

.a ファイルはライブラリがライブラリたる必要用件ではないと思います。

> 入手先も、間接的ではあるけれど記載され続けていました。
> だから、使用許諾契約に違反した状態ではなかったと考えます。

これはおっしゃる通りかも知れませんが、入手先とはさきほど触れられた
メールアドレスの事でしょうか? だとすれば、メールを送ると
いつでも最新版が取得できるということを明記してあれば
なお親切だったかと存じます。
 
> ＞あくまで LGPL の適用されたライブラリであると主張する必要が
> ＞あるならば mbfilter の原型をどこかで入手できなくてはならないし、
> 
> うーん。小泉さんの議論のこの辺に違和感を感じるんですよ。
> LGPLはその適格性を問うものではなくて、
> 単に被許諾者が守るべき条項ですよね。
> もしもLGPLの条項への違反が疑わしい状況があっても、
> 単に著作権者がおめこぼしをしているだけであって、
> LGPLを主張できないとか、著作権を主張できないとかって
> ことはあり得ません。
> 私、なにか読み違えてます？

著作権を主張できない場合というのは、著作権を主張するけれども、法的に
認められない場合ということです。これは、著作権のスコープが不明で、
共同著作者を同定できない場合です。

これまでの私のメールで、その可能性は十分指摘できたと思いますから、
ここでは触れません。

> しかし、私の所有物じゃなくて会社の物なので、
> 会社が判断することです。しかし、会社と交渉するにしても、
> 
> ・使用許諾契約違反しているが、
> ・違反を回避するための作業が大変なので、
> ・現状追認して、
> ・契約内容を変更してくれ。
> 
> っていう議論じゃお話にならないです。
> これまでのメールを見せたら、その後の交渉はあり得ないです。
> 私一人でやっている会社じゃないですから。

もし、この言葉が私だけに向けられたものでないのでしたら大変失礼ですが、
私一人が作業に関与しているわけではありませんので。
仮に交渉が必要とあっても、私がすべて一人でやることではないわけです。
会社がどうのこうの、というのはピンと来ません。

今回の議論はあくまで私個人の見解、つまり可能性を示唆したものであって、
他の開発者の方との総意ではありません。 もし、他の方が問題がないと
判断されたのなら、どんどん本家の方にマージされればいいと思います。

私は現在著作者ではありませんので、事情が分からないこともあって、
あまり突っ込んだことはわかりませんが、アクセンス・テクノロジー社
が例えライセンス条項の変更に異義を唱えても、他の著作者の方が十分
納得する必要があるでしょう。

あと、違反を回避する作業が必要で、それが大変だとしても致し方
ないと思っています。面倒だからどうの、という話をしているつもりも
ありません。

ただ、少なくとも現実として、PHPの開発者の方は、
LGPLでライセンスされたコードを使うのを嫌がるでしょう。libmysqlでさえ
public domain となっています。まあ、はっきり彼らに聞いたことではない
ので聞き流しておいていただきたいのですが。

> 私が過去に作ったソフトウェアをPHPで使っていただけているのは、
> とても嬉しく思っています。だからPHPの発展にとってそれが
> 不便ならそれを解消したいと思います。でも、今の状況だと
> 交渉にもならないので、できることなら以下のようなプロセスを
> ふみたいと思っています。
> 
> 1)まずはLGPLに適合していると思える状態にする。
> 少々大変かとは思いますが、なんとか当初の使用許諾契約に
> 違反していないと見える状態にする。つまり、ライブラリとして
> 他の人が比較的簡単に再利用できる状態にする。
> 
> その上で、
> 
> 2)ライセンス内容を変更した方が今後の発展にはより良い、
> 　という交渉をする。
> 
> こういう形でなら、交渉の可能性があると思います。
> 
> 
> 会社の立場で考えると、無償提供であったとしても、
> 無償だからなおさらかもしれませんが、著作者としての存在が
> 埋没していくことを一番嫌います。一番望まれることは、
> 著作者名の表示が常に維持されることです。
> 
> この点で言えば、小さなソフトウェアかもしれませんが、
> PHPチームないしZendにcontributeしたり、「PHP License」
> そのものを適用したりってことは、ほぼあり得ないことです。

こういった状態になってしまったのは、本家の方でmbstring に貢献して
くださった開発者の方が、失礼ながら LGPL の条項に関して無頓着
であった部分もあると思います。その方々に、LGPL への変更をお願いする
方法もあるでしょう。または、変換フィルターをハードコーディングしなくても
組み込めるような技巧を凝らすなどしてもいいでしょう。

> 少し余談です。LGPLでは、バイナリ配布のときは著作権表示を
> 行わなくてはならない決まりです（BSDなどでも同じですよね）
> が、僕らのソフトウェアについては守ってもらったためしが
> ないです。よく、LinuxとApacheとPHPを組み込んだルータとか
> ありますが、ハッピーサイズや当時の「日本語化チーム」の
> 名前を見ることはありません。どういうことなんでしょうね。
> LGPLなりなんなりの厳密性は、そこまで問わないだろうって
> ことなのかなあ。うちの会社は今のところ、あまりめくじら
> 立てるつもりはありませんが。

おめこぼしについつい甘んじているのか、それとも単に
知らないだけなのか、グレーゾーンですねえ。

> 長々とすみません。
>

いえ、こちらこそ長々とつき合って頂いて感謝です。