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

[Ko Kazaana]

　こんにちは。風穴です。


= On Sat, Jun 21, 2003 at 05:12:06PM +0900,
= Rui Hirokawa-san wrote:
> 現状のライブラリのライセンス(LGPL)を変更せずに、
> 著作権者の意図である上記の条項をライセンス条件として
> (Aさんが)PHPの開発に対して許諾を求めるというのは、
> 1つの有力な解決策かと思います。
> この場合、PHPの開発者にとっては、デュアルライセンスということ
> になると思います。
(snip)

　いえ、ちょっと違います。
　私の図をさらに詳しく書くと、

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┏━━┓ ライセンス(3)┏━━━┓ ライセンス(2) ┏━━━━━━━━━━━━━┓
┃PHP ┃<-------------┃Aさん ┃<--------------┃アクセンス・テクノロジー社┃
┗━━┛              ┗━━━┛               ┗━━━━━━┳━━━━━━┛
                                                             ┃             
                                                             ┃ライセンス(1)             
                                                             ┃
                                                       　一般公衆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

となります。ここで、ライセンス(1)とライセンス(2)は、まったく別個のもので
構いません。また、ライセンス(2)によって、Aさんに「任意のライセンスでサブ
ライセンスする権利」を許諾したとすれば、ライセンス(3)は、ライセンス(1)や
ライセンス(2)とはまったく別個のライセンスで構いません。

　なので、PHP開発者は、Aさんとの間で「ライセンス(3)」という契約を結ぶこ
とになりますので、「PHPの開発者にとっては、デュアルライセンス」というこ
とではありません。

　契約というのは、あくまでも「peer to peer」なものだということを押さえて
おけば、理解できるのではないかと思います。


(snip)
> ただ、まだ少し理解できないことがあります。
> 
> 1.風穴さんのご提案にあるAさんとは誰になるべきでしょうか?
>   これは本質的な質問ではないかと思いますが、現実には特定の個人
> よりもPHPコミュニティの意志が反映される組織の方が望ましいような
> 気がします。

　組織でも個人でも何でもよいですし、それについては私はno idea（sgkさんが
信頼できる人、という一般的な条件しか思いつきません）なのですが、いずれに
せよ法律上の人格（法人格）が必要です。これは自然人（いわゆる個人）か、法
律によって存在が認められた法人である必要があります。つまり「任意団体」で
はダメだということです。もちろん「PHPコミュニティの意志が反映される組織」
で、かつ著作権者も信頼できる組織で、さらに法人格を有するところがあれば、
それでも構わないと思います。



> 2.sgkさんの3項「一般用語的意味でのライブラリ＝再利用可能性」
>  に関しては、PHP固有のAPIに依存する実装になり、
> 単体として動作しないようになって欲しくないというご意志と
> 解釈します。
>  これに関して、少し、細かい疑問ですが、マクロの定義で依存性が
> 解消される場合、例えば、
> #ifdef PHP
> ...
> PHP固有のコード
> ...
> #endif
> という状態の場合は、上記の意図に反しているとお考えでしょうか?
> 具体例としては、ZTS(Zend Thread Safe)に関する引数や
> 関連した #include文等があたります。
> 
> また、現状、PHPのエラー表示用APIがmbfilter.cのコードに
> 入っていますが、これもマクロでラッピングすることで
> 上記のマクロ定義による依存性解消と同じ状態にできると
> 思います。


　この部分、背景等をちゃんと理解していないので的はずれかもしれませんが、
アクセンス・テクノロジー社が著作権を有するライブラリが、ライブラリとして
（PHPから）独立かどうかは、私が述べたような方法をとる場合は、どうでも良
いと思います。
　ライブラリソフトウェアの流れとして上図を書き直すと、

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┏━━┓ ライブラリY  ┏━━━┓  ライブラリX  ┏━━━━━━━━━━━━━┓
┃PHP ┃<-------------┃Aさん ┃<--------------┃アクセンス・テクノロジー社┃
┗━━┛              ┗━━━┛               ┗━━━━━━┳━━━━━━┛
                                                             ┃             
                                                             ┃ライブラリX
                                                             ┃
                                                       　一般公衆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

となります。
　PHP開発者は、Aさんから「ライセンス(3)」によってライセンスされた「Y」と
いうライブラリを利用する、というだけです。それがライブラリXと同一のもの
かどうかは考慮する必要はまったくありません。
　というか、「Y」は、ライブラリのような形である必要もないかもしれません。
そのほうがやりやすいなら、AさんがコントリビュートしたPHPのコード（ただし
著作権者表示としては、アクセンス・テクノロジー社の名前も入るけど）、とい
う形になっても、構図としては何ら問題ないと思います。

　私が説明した方法は、あくまでもPHP開発者側は、Aさんからライセンスを受け
ている、というだけなのですから。（著作権者表記は入るとしても） PHP開発者
の側からアクセンス・テクノロジー社は意識する必要がない、ということです。
それがこの方法のミソでもあるのですが。

　私はそういう意味で「PHP開発者側にとって分かりやすい構図」だと書いたの
でした。


　あと、ちなみに私が説明した方法は、あくまでも「1つの方法」にすぎない、
ということは、申し添えておきます。「こうしろ」とか、「こうしてほしい」と
いうことでは、もちろんありません。もっと頭をひねれば、もっと良い解法があ
るかもしれませんが、一例として「こういう考え方もできる」ということです。(^_^;

-- 
Ko Kazaana / editor-in-chief of "TechStyle" ( http://techstyle.jp/ )
GnuPG Fingerprint = 1A50 B204 46BD EE22 2E8C  903F F2EB CEA7 4BCF 808F