PHPマルチバイト文字列モジュールにライセンス問題 59
ストーリー by Oliver
最初から気を使いましょう 部門より
最初から気を使いましょう 部門より
don_z80曰く、"PHP4系列では、日本語(マルチバイト文字列)を扱うためのモジュールが本家からの配布にマージされ、日本語を使うアプリケーションの開発が簡単になったのはご存じの事だと思う。しかし、実はこれらのマルチバイト文字列モジュールはLGPLライセンスで配布されており、PHP4系列のBSDライクなライセンス(PHPライセンス)と矛盾する状態となっていた。
以前から日本国内のPHPコミュニティでは問題が提起されていたが、最近本家コミュニティでも問題が認識され、現在その対応が検討されている。PHP-dev ML(日本語ML)では、
- mbfilter について開発元にお願いしてライセンス形態を変更してもらう
- mbrgex について、BSDライセンスで提供されている鬼車ベースのものに入れ換える
という案が提案されており、これについての議論がするんでいる。"
日本チームの体制って (スコア:2, すばらしい洞察)
PHP を、特にマルチバイト関連や日本語化、本家に対する要望活動を支えている人数って PHP の重要度に比べかなり数が少ないような気がして今回も薄氷を踏むような感じに思えました。メンバーへの負担も高そうです。
ちょっと心配なのですがどうなのでしょう。
やっぱり人が足らないのか、足りてるのか、PHP だけが特にこうなのか、どこも似たような状況なのか。
PHP は実用的過ぎて開発に関われるような層の興味を引かないという意見を耳にした事があるので少し気になりました。
# コミットしたいけど知識&経験が足りず。半年以内の参加を目指して頑張ります。
Re:日本チームの体制って (スコア:5, 参考になる)
> # 余談ですが、 php5 のベータ版がもうすぐ出ます。
> # 急がないと php5 から zend-multibyte のサポートが外れてしまう
> # 危険性が。救援求む…
という状況のようです。
自分自身が開発に携われればよいのですが、日々の仕事に追われて出来そうもありません。
とりあえず、ML-devの購読を検討することにします。
べつに「チーム」とかってきばらなくても (スコア:1, 興味深い)
ただ、どこの世界でも、ユーザは増えるけど開発に (ほんのちょっとでも) 関わる人は増えない、というのが現状のように感じています。私もいくつかの「開発」系メーリングリストに参加していますが、「はじめまして」メールがやってきたり、名前を聞いたことがない人が参加してきたりということを、もう長い間見ていないように思います。
そんなの寂しいです。私がとくに危惧しているのが、「継続的に開発に参加するわけではないけど、パッチを送ってきたり開発上の議論に(ひとつの話題にだけ)参加したりする人」がほとんど皆無であることです。そういう人のなかから、継続的に開発に参加したいと思う人が現れたりするものだと思ってますので。
なんてことを書くと、「単発的にパッチを送っただけで、継続的な開発者になることを期待されてしまうのではないか」と恐れを持つ人もいるかもしれませんが、そんなことはありません。まあ、期待する気持ちがないといえばうそになりますが、そんなの勝手に思ってるだけですし。
Re:べつに「チーム」とかってきばらなくても (スコア:0)
Re:日本チームの体制って (スコア:0)
Re:日本チームの体制って (スコア:1)
CLI、ちょっとしたことをるすのにけっこう便利っすよ。
[By waa]
Re:日本チームの体制って (スコア:0)
に保存するにもコードを書く必要はない。
最近話題のSledgeとかって、なにげに高度に抽象化されていますよ。
補足 (スコア:2, 参考になる)
> # mbrgex について、BSDライセンスで提供されている鬼車ベースのものに入れ換える
上記の他、「PHP開発に関して、特定の誰かに、別のライセンスで提供する」 [php.gr.jp]という案も出て、有力な候補になってるみたいです。
既になんらかのライセンスで公開されていたり、特許を持ってたりする技術に関して企業と交渉するのに参考になりそうです。
契約というのは、あくまでも「peer to peer」なものだ [php.gr.jp]そうで。
Re:補足 (スコア:1, すばらしい洞察)
その1:
Aさんに他のライセンスを供与するのであれば、最初からLGPLとPHPL(またはBSD)のデュアルライセンスにしてしまえば良いのでは?
Aさんをわざわざ介する意味は無いと思う。
2種類のライセンスで提供する事に変わりは無い。
その2:
「AさんがそのライブラリをPHP開発に利用する場合に限って、ある程度自由に出来る」
という限定があるのであれば、AさんはPHPLで再ライセンスする事はできない。
PHPLでは、PHPLの元で提供されるソースをPHP以外のプロダクトへ流用する事を妨げていない。
その3:
Aさんという第三者を介入させる事により、原著作者へのパスが長くなるので、「フィードバックを受けたい」という原著作者の意向に反するのでは?
デュアルライセンス (スコア:2, 参考になる)
・開発元の会社が、法人格「A」にライセンスし、「A」がphpチームにライセンス供給する。
・それぞれのライセンスは異なったものでよい。
ただし、開発元の会社が許諾するか、法人格「A」はどうするのか、といった点はこれから話し合いになりそうです。
しかし、ライセンスに関して、目から鱗のコメントもあり、ちょっとびっくりしました。もっと理解するように努力せねば。。
GPLやLGPLというのは、まさにsgkさんが指摘されていたように、フリーソフト
ウェアライセンスの「便利な雛型」であって「法律」ではありません。なので、
「GPL違反」とか「LGPL違反」という言い方は正しくありませんし、議論の混乱
の元にもなりかねません。
「GPLに矛盾」、「LGPLに矛盾」というのも、ありえません。著作権者は、著
作物に対して、著作権法で定められた権利を(著作権法に定められた範囲で)絶
対的に持っていますので、著作権者の意向が「すべて」なのです。
Re:デュアルライセンス (スコア:3, 参考になる)
「著作権者の行動はGPLを選択してもまったく制限されない」だと誤解が少ないかなあ。
まつもと ゆきひろ /;|)
Re:デュアルライセンス (スコア:0)
実際、著作権者が一人ならば、GPL を選んでも本人があとでそれを
くつがえすことは容易ですね。
# 一人なら、ですけど。
Re:デュアルライセンス (スコア:1, すばらしい洞察)
それに対していちいち「このパッチの著作権を放棄することに同意してね」
という(ソフトウェア会社の従業員などの場合は書面で)契約をしない限りは、
パッチを送ってきた人はパッチがGPLの下で取り込まれることを前提としている
と言えると思います。
つまり、最初のパッチを取り込んだ時点で、もう元の作者自身が
GPLに縛られてしまうと思いますが、違うかな。「送られてきたパッチを
取り込んだ場合、著作権は私に属することとします」と宣言していたと
しても、契約書(この場合GPL)に書かれていない限り有効とは思えないし、
そういう条項を足したらもうGPLではないし。(GPL自体にも矛盾しそう)
Re:デュアルライセンス (スコア:0)
唯一の著作権者であれば、
GNU FAQ (スコア:1, 参考になる)
ここで重要なのは『著作権者が』つうことですな。当たり前だけど、ちゃんと見極めとかないと混乱するよね。
野分
Re:GNU FAQ (スコア:0)
「著作権者(開発者)が自らの著作物をGPLに基づいて
ユーザに提供する際に、ソースの提供方法に関して
GPL第4項bの方式(最低3年間のソース提供の保証)を選択し、
その条件の元でライセンス契約を締結した
Re:GNU FAQ (スコア:0)
Re:GNU FAQ (スコア:0)
その FAQ がこのような事態までを想定して書かれているかどうか、微妙ですね。
Re:デュアルライセンス (スコア:1)
たとえば、著作権者の意向として、「ライセンスにはこう書いてるけど、この項目は無視していいよ」とMLなりnewsなりで言ったとする。で、そのつもりで使っていると、後で著作権者が考え直して「やっぱライセンスに従え」と言われたらどうする。
逆に、ライセンスに書かれてないことを、あとから「俺の本当の意向はこうだ。この条件にも従え」と言われたらどうする。
どちらもありうることだ。事例を思い浮かべる方もおられるだろう。
利用者からすれば(そしておそらく裁判になったとしても)、ライセンスが「すべて」だ。それ以外の「意向」なんざ、著作権者の頭の中にあるだけかもしれないし、言ったとしても知る機会もないかもしれない。
著作権者は始めから自分の意向を反映したライセンスを選択あるいは作成すべきだ。てきとーに選択するのは危険だ。
>著作権者は、著
>作物に対して、著作権法で定められた権利を(著作権法に定められた範囲で)絶
>対的に持っていますので、著作権者の意向が「すべて」なのです。
というのは公開前なら正しい。でもってその権利を、例えば複製権や翻案権を「印税10%」とか「映画化権ウン万円」とか「ソース公開しろ」とか「売るな」とかの条件付きで他人に売ったりあげたり貸したりするとかの取り決めが契約やライセンスだ。
著作権者がある(法)人Aとある条件(例えば10%)で契約したとしても(その契約が買取や独占契約でない限り(GPL等のライセンスにはそんなこと書いてない))、別の(法)人Bと別の条件(8%や12%)で契約したりAと契約しなおすのはアリ、というような話をしたいんだろうが、このコメントだと、著作権者の一存で「やっぱ12%よこせ」とか契約にないことを持ち出したり契約を無効にするのがアリに聞こえるで、余計混乱すると思う。
Re:デュアルライセンス (スコア:0)
むー。
Re:デュアルライセンス (スコア:1, すばらしい洞察)
Re:デュアルライセンス (スコア:0)
#wxWindowsはLGPLも可能なデュアルライセンスでもあるけど……
野分
英語のライセンス文にこだわる必要性は? (スコア:2, 興味深い)
金本さんの発言 [php.gr.jp]を見ていて思ったのですが、
という文を読んで、ふと疑問を持ちました。 ライセンス条項を策定するにあたって、英語にこだわる必要があるのでしょうか? たとえばGPLの日本語訳 [gnu.org]でも、
とあります。 同じように自らライセンスを制定するにあたって、「効力を持つのは日本語文書だけであり、英語文書は参考用にすぎない」としてもよさそうに思うのです。 法的に有効な完璧な文書である事にこだわらなければ、英語文書を作成するのに必要な手間もいくらか少なくなるのではないかと思います。この方法に何か問題がありうるでしょうか?
Re:英語のライセンス文にこだわる必要性は? (スコア:1, 参考になる)
#日本語を読める人口なんて高が知れていますから。
世界的な使用を前提とするなら、もっとも普及した言語で契約書を記述する方が合理的で、それがたまたま英語なのです。
#いつの日か中国語が取って代わるかもしれませんけどね。;-)
ちなみに複数言語で正式な契約書を作成することは、法解釈の一意性が失われる恐れがあるため、出来ません。
#どれが正式な契約書であるかを定める必要があります。
最初から気を使いましょう 部門より. (スコア:1, 参考になる)
って言うか、PHPのライセンスが変わったのが問題の大元のようですねぇ
Re:最初から気を使いましょう 部門より. (スコア:2, 興味深い)
こんな形で矛盾してしまうとは皮肉なものですね。
/* なにをもって自由とするかの違い?
なんか宗教戦争(戦争は言い過ぎですけど)みたい。 */
----------------------------
万能文化電波人間近衛隊のfengshenでした
Re:最初から気を使いましょう 部門より. (スコア:3, 興味深い)
> こんな形で矛盾してしまうとは皮肉なものですね。
BSD styleライセンスとGNU (L)GPLとでは目指すところが違いますので、矛盾することがあるのは仕方ありません。というより当然です。
> /* なにをもって自由とするかの違い?
> なんか宗教戦争(戦争は言い過ぎですけど)みたい。 */
BSD styleライセンスの求めているのは、受けとった側がほとんどなにをしてもよいという自由です。
対してGNU (L)GPLの求めているのは、どこまでいってもソースコードにアクセスできるという意味での自由です。それ(著作者の意図)を妨げることが許されず、途中の誰かが好き勝手をすることはできないという観点からは不自由であるともいえます。
※よい、悪いの話ではなくて目的が違うということ。
元の問題に話を戻すと、ライセンスの解釈はその文面がすべてです。著作権者の意図が別にあることが分かっていても、第三者がその意図を前提にすることはできないのに注意しましょう。
以前NetBSDプロジェクトがCVSリポジトリーにcommitされたソースコードの差分をメールで配布する(CTM)サービスを始めたときの話です。
BSD styleのライセンスではその第1条でソースコードの配布時にcopyrightの表示を外してはいけないということが謳われています。CTMでは差分だけの配布のため、この第1条を満足していません。このためこのサービスは中止されました。
この議論の際にある人が書いたメッセージです。
「不幸なことに、これはBSD style licenseの精神とは矛盾しないが、その文面と矛盾する。」
とくに著作者の為人を知っているとこういった話がうざったいのは確かですが、余計なトラブルを避け、互いの身を守るという意味からも、ライセンスについてはきっちりさせておくべきでしょう。
Re:最初から気を使いましょう 部門より. (スコア:0)
差分を配布する以上は、(元のCopyrightが記された)ファイルを持っていることが前提なので
問題にはならないと思うけどなあ。Copyright部分を(著作権者の
Re:最初から気を使いましょう 部門より. (スコア:1)
また、各条約も加盟国と非加盟国がある。
ルール外のことだと、契約だと思うが、その契約が有効なのか無効なのかといった問題もあるよね。
例えば、無茶な理不尽な要求は消費者契約法上どうなのかとかね。
他者から突っ込まれない様に安全をきしたければ、微妙な解釈の奴は採用するべきではない。
この程度なら判断が微妙なところだから訴えてこないと判断し採用するのも良い。
そういった選択の問題と安全かどうかの問題は別だと思う。
Re:最初から気を使いましょう 部門より. (スコア:1)
> 差分を配布する以上は、(元のCopyrightが記された)ファイルを持っていることが前提なので
メールだからではなくて、手元に対応するソースがなくても差分の配布を受けとれる点が問題にされたのだと思います。
> で、今のNetBSDプロジェクトはどう判断しているんでしょう。各種サービスは動いているようですが。
プロジェクトとしての判断をする立場にありませんが、大筋では上に書いた通りだと思います。
Re:最初から気を使いましょう 部門より. (スコア:0)
cvsに手を入れて cvs rdiff などは禁止してるとか?でも、 cvs diff も
リビジョンは自己申告だからやっぱりだめだね。同様に CVSweb の
差分抽出機能もアウト?
ちなみに、 CVSup や rsync だとブロックごとのハッシュ値を送る必要が
あるので事実上手元にソースがないと差分はもらえない。が、
Re:最初から気を使いましょう 部門より. (スコア:1)
確かそのころは、NetBSDはanonymous CVSのサービスをまだやっていませんでした。
> cvsに手を入れて cvs rdiff などは禁止してるとか?でも、 cvs diff も
> リビジョンは自己申告だからやっぱりだめだね。同様に CVSweb の
> 差分抽出機能もアウト?
そういうことはしていないはずです。
どちらかというと、CTMは問題だと考える人(著作権者)が多かった、CVSなどは問題視する人がほとんどいない、というくらいですね。なぜCTMだけ嫌われたのかは謎です。
> そもそも差分の著作権自体が曖昧なものだよね。著作者がつっこみそうも
> ないことまで自己規制をはじめたら、オープンソースの開発モデル自体が
> 立ち行かなくなる恐れも。
これはいやですね。そもそもBSD styleライセンスにするのって「このソースはあなたの好きにしていいよ。その代わり面倒なことはやめてね」という感覚に近いので、厳格に黒白つけなきゃならないのは勘弁してほしいです。だめかなあ。
Re:最初から気を使いましょう 部門より. (スコア:0)
ちなみに個人的にはGPLの本当の怖さは、よくアンチGPL厨が繰り返す「ソース公開」ではなく、GPL自体が課している以上の制限を禁止しているところにあると思っています。
Re:最初から気を使いましょう 部門より. (スコア:1, 参考になる)
Re:最初から気を使いましょう 部門より. (スコア:1)
ライセンスAがライセンスの変更を認めるライセンスだったら、全然別のライセンスになるぞ。BSDLからプロプラ製品作るとかな。
ライセンスAがライセンスBの部分集合だったら、混ぜたものはライセンスBになる。GPL compatibleとGPLを混ぜたらGPLになるとか、宣伝条項ナシのBSDLとアリのBSDL混ぜたらアリのBSDLになるとかな。
AとBが矛盾してたら混ぜるのは不可能。Aがソース全体の公開必須で、BがNDAでソース公開禁止とかな。
Re:最初から気を使いましょう 部門より. (スコア:0)
やっぱり混ぜるな危険だね (スコア:1, 参考になる)
…だからさぁ、AがBSDライセンス、BがGPLだった場合そもそもAとBを混ぜちゃいけないんだってば。もう少し詳しく言うと、GPLなソースにBSDライセンスなソースを混ぜるのは良いけど、BSDライセンスなソースにGPLなソースを混ぜるのは不可。(混ぜた場合、ソース全体をGPLにしなきゃいけなくなる。GPLなソースの著者の許可があれば別だけど。)
#343265はそのことは理解しているか?
Re:やっぱり混ぜるな危険だね (スコア:0)
Re:最初から気を使いましょう 部門より. (スコア:0)
GPL 2.b 項によって、GPL でライセンスされているソースを含む派生物は全体をGPLによって配布する必要があります。
修正BSDLのソースをGPLの配布物に含めることは、修正BSDLの条項に触れないので、BSDL, GPLの両方のライセンス条件を満たしています(=矛盾しない)。
GPLのソースを修正BSDLの配布物に含めようとすることは、上記2.
Re:最初から気を使いましょう 部門より. (スコア:2, 参考になる)
タレコミ文では繁雑になるのを避けるために省略しましたが、
PHP3系列はGPLでリリースされており、日本のPHPコミュニティ
の手による日本語対応版(国際化版)もGPLでリリースされていま
した。
PHP4系列は、タレコミに書いた通りBSDライクなライセンスでの
配布に変更されました。
これは、GPLより自由な(ソースの開示義務などに縛られない)利用
を可能とするための変更だったようです。
Re:最初から気を使いましょう 部門より. (スコア:1, 参考になる)
「GPLでも」でしょ。デュアルライセンスなんだから。
Re:最初から気を使いましょう 部門より. (スコア:0)
日本語対応版などということをせずに、オリジナル版で日本語対応できるようにしておけば、こんなことはなかったはずなのに。
少なくとも、オリジナル版のライセンス変更のときには、オリジナル版を構成するソースコ
Re:最初から気を使いましょう 部門より. (スコア:0)
typo (スコア:1)
> これについての議論がするんでいる。
"すすんでいる"のtypoでしょうか。
Re:typo (スコア:1)
Re:typo (スコア:0)
いや、「するする」だと思う。
mbstring ステ? (スコア:0)
「誰かが機能を拡張したら、その部分も公開されて欲しい。」
とのことなので、PHPとバンドルして配布するのは無理なのでは?
namazuのPHPモジュールもあやしい (スコア:0)
Re:namazuのPHPモジュールもあやしい (スコア:2, 参考になる)
PHPのコアにはnamazuモジュールは含まれないので
問題ない(関係ない)です.
ただしPEAR(PECL)としての問題は別にあるのかもしれませんが.
PECLの取り出しってcvs以外でも出来るの?
って思ったら一部のモジュールはウェブから取り出せるようになってた
えりゅふ
よくきたblog [blog.poyo.jp]
それよりバグはどうなった? (スコア:0)