パスワードを忘れた? アカウント作成
5951 story

PHPマルチバイト文字列モジュールにライセンス問題 59

ストーリー by Oliver
最初から気を使いましょう 部門より

don_z80曰く、"PHP4系列では、日本語(マルチバイト文字列)を扱うためのモジュールが本家からの配布にマージされ、日本語を使うアプリケーションの開発が簡単になったのはご存じの事だと思う。しかし、実はこれらのマルチバイト文字列モジュールはLGPLライセンスで配布されており、PHP4系列のBSDライクなライセンス(PHPライセンス)と矛盾する状態となっていた。
以前から日本国内のPHPコミュニティでは問題が提起されていたが、最近本家コミュニティでも問題が認識され、現在その対応が検討されている。PHP-dev ML(日本語ML)では、

  • mbfilter について開発元にお願いしてライセンス形態を変更してもらう
  • mbrgex について、BSDライセンスで提供されている鬼車ベースのものに入れ換える

という案が提案されており、これについての議論がするんでいる。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 日本チームの体制って (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2003年06月22日 22時33分 (#343160)
    もう参考実装が出来ているようです。お疲れ様です。
    PHP を、特にマルチバイト関連や日本語化、本家に対する要望活動を支えている人数って PHP の重要度に比べかなり数が少ないような気がして今回も薄氷を踏むような感じに思えました。メンバーへの負担も高そうです。
    ちょっと心配なのですがどうなのでしょう。
    やっぱり人が足らないのか、足りてるのか、PHP だけが特にこうなのか、どこも似たような状況なのか。
    PHP は実用的過ぎて開発に関われるような層の興味を引かないという意見を耳にした事があるので少し気になりました。

    # コミットしたいけど知識&経験が足りず。半年以内の参加を目指して頑張ります。
    • by duria (16308) on 2003年06月23日 1時18分 (#343272) 日記
      ここ [php.gr.jp]を見ると、

      > # 余談ですが、 php5 のベータ版がもうすぐ出ます。
      > # 急がないと php5 から zend-multibyte のサポートが外れてしまう
      > # 危険性が。救援求む…

      という状況のようです。
      自分自身が開発に携われればよいのですが、日々の仕事に追われて出来そうもありません。
      とりあえず、ML-devの購読を検討することにします。
      親コメント
    • by Anonymous Coward on 2003年06月23日 9時55分 (#343442)
      PHP って、ユーザコミュニティがそこそこの大きさがあると思うんですが、その場合は、手を挙げる人もそれなりに出てきてもよいような気がします。

      ただ、どこの世界でも、ユーザは増えるけど開発に (ほんのちょっとでも) 関わる人は増えない、というのが現状のように感じています。私もいくつかの「開発」系メーリングリストに参加していますが、「はじめまして」メールがやってきたり、名前を聞いたことがない人が参加してきたりということを、もう長い間見ていないように思います。

      そんなの寂しいです。私がとくに危惧しているのが、「継続的に開発に参加するわけではないけど、パッチを送ってきたり開発上の議論に(ひとつの話題にだけ)参加したりする人」がほとんど皆無であることです。そういう人のなかから、継続的に開発に参加したいと思う人が現れたりするものだと思ってますので。

      なんてことを書くと、「単発的にパッチを送っただけで、継続的な開発者になることを期待されてしまうのではないか」と恐れを持つ人もいるかもしれませんが、そんなことはありません。まあ、期待する気持ちがないといえばうそになりますが、そんなの勝手に思ってるだけですし。

      親コメント
      • PHPの場合継続的に開発する人も危機的に見えます。PHP5でのZend-Multibyteの件も結局ふじもとさんが手を挙げてくださいましたがご本人がもうPHPはあまり使っていないとおっしゃっているわけで… そういう人が手を挙げざるを得ない状況ってのはどうなのかな、と。
    • CGI専用のスクリプト言語って現状だとあまり意味ないなぁ。 gcc+cgiccがテンプレート自在でタイプ量も少なく、 ワイドキャラクタが使えて、 重い処理はデーモンプロセス化により高速化できていいことずくめ。 C++と他のスクリプト言語のCGIって実はそんなに手間は変わらない。
      • by waa (50) on 2003年06月23日 5時00分 (#343364)
        さいきんはCGI専用ということではなくなってきています。
        CLI、ちょっとしたことをるすのにけっこう便利っすよ。
        --
        [By waa]
        親コメント
      • たとえばPerlだと、Template-ToolkitとかDBIとか各種決済モジュールが整備されていて、それらを密接に統合するフレームワークもいくつかある。PHPやRubyも周辺ライブラリが豊富。セッションをDB
        に保存するにもコードを書く必要はない。

        最近話題のSledgeとかって、なにげに高度に抽象化されていますよ。
  • 補足 (スコア:2, 参考になる)

    by j3259 (7093) on 2003年06月22日 23時15分 (#343194) ホームページ 日記
    > # mbfilter について開発元にお願いしてライセンス形態を変更してもらう
    > # mbrgex について、BSDライセンスで提供されている鬼車ベースのものに入れ換える

    上記の他、「PHP開発に関して、特定の誰かに、別のライセンスで提供する」 [php.gr.jp]という案も出て、有力な候補になってるみたいです。

    既になんらかのライセンスで公開されていたり、特許を持ってたりする技術に関して企業と交渉するのに参考になりそうです。

    契約というのは、あくまでも「peer to peer」なものだ [php.gr.jp]そうで。

    • Re:補足 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2003年06月23日 2時34分 (#343318)
      何かあまり解決になっていないような・・・
      その1:
      Aさんに他のライセンスを供与するのであれば、最初からLGPLとPHPL(またはBSD)のデュアルライセンスにしてしまえば良いのでは?
      Aさんをわざわざ介する意味は無いと思う。
      2種類のライセンスで提供する事に変わりは無い。

      その2:
      「AさんがそのライブラリをPHP開発に利用する場合に限って、ある程度自由に出来る」
      という限定があるのであれば、AさんはPHPLで再ライセンスする事はできない。
      PHPLでは、PHPLの元で提供されるソースをPHP以外のプロダクトへ流用する事を妨げていない。

      その3:
      Aさんという第三者を介入させる事により、原著作者へのパスが長くなるので、「フィードバックを受けたい」という原著作者の意向に反するのでは?

      親コメント
  • by duria (16308) on 2003年06月22日 23時21分 (#343198) 日記
    メーリングリスト上では、デュアルライセンスという技で回避可能との [php.gr.jp]があります。
    ・開発元の会社が、法人格「A」にライセンスし、「A」がphpチームにライセンス供給する。
    ・それぞれのライセンスは異なったものでよい。
    ただし、開発元の会社が許諾するか、法人格「A」はどうするのか、といった点はこれから話し合いになりそうです。

    しかし、ライセンスに関して、目から鱗のコメントもあり、ちょっとびっくりしました。もっと理解するように努力せねば。。

     GPLやLGPLというのは、まさにsgkさんが指摘されていたように、フリーソフト
    ウェアライセンスの「便利な雛型」であって「法律」ではありません。なので、
    「GPL違反」とか「LGPL違反」という言い方は正しくありませんし、議論の混乱
    の元にもなりかねません。
     「GPLに矛盾」、「LGPLに矛盾」というのも、ありえません。著作権者は、著
    作物に対して、著作権法で定められた権利を(著作権法に定められた範囲で)絶
    対的に持っていますので、著作権者の意向が「すべて」なのです。
    • by matz (2690) on 2003年06月22日 23時56分 (#343225) ホームページ
      「GPLに矛盾はありえない」というのは(風穴さんの意図は分かるけど)、誤解されると思います。

      「著作権者の行動はGPLを選択してもまったく制限されない」だと誤解が少ないかなあ。
      --
      まつもと ゆきひろ /;|)
      親コメント
      • > 「著作権者の行動はGPLを選択してもまったく制限されない」だと誤解が少ないかなあ。

        実際、著作権者が一人ならば、GPL を選んでも本人があとでそれを
        くつがえすことは容易ですね。

        # 一人なら、ですけど。
        • Re:デュアルライセンス (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2003年06月23日 13時31分 (#343617)
          いったんGPLで公開してから、ほかの人からパッチが送られてくるとします。
          それに対していちいち「このパッチの著作権を放棄することに同意してね」
          という(ソフトウェア会社の従業員などの場合は書面で)契約をしない限りは、
          パッチを送ってきた人はパッチがGPLの下で取り込まれることを前提としている
          と言えると思います。

          つまり、最初のパッチを取り込んだ時点で、もう元の作者自身が
          GPLに縛られてしまうと思いますが、違うかな。「送られてきたパッチを
          取り込んだ場合、著作権は私に属することとします」と宣言していたと
          しても、契約書(この場合GPL)に書かれていない限り有効とは思えないし、
          そういう条項を足したらもうGPLではないし。(GPL自体にも矛盾しそう)
          親コメント
        • 「くつがえす」というとちょっと語弊があるかも。
          唯一の著作権者であれば、
          • GPLで公開したままに、他のライセンスでも公開する(デュアルライセンス等)事が可能
          • GPLでの公開を取り止めて、他のライセンスだけで公開する事も可能
          • 全く公開を取り止めてしま
    • GNU FAQ (スコア:1, 参考になる)

      by Anonymous Coward on 2003年06月23日 0時52分 (#343263)
      GNU FAQにも似たようなのがありますな。このあたりからの一連のFAQ [gnu.org]
      ここで重要なのは『著作権者が』つうことですな。当たり前だけど、ちゃんと見極めとかないと混乱するよね。

      野分
      親コメント
      • by Anonymous Coward
        そのFAQには「 開発者自身はGPLに束縛されない [gnu.org]」とありますが、

        「著作権者(開発者)が自らの著作物をGPLに基づいて
         ユーザに提供する際に、ソースの提供方法に関して
         GPL第4項bの方式(最低3年間のソース提供の保証)を選択し、
         その条件の元でライセンス契約を締結した
        • by Anonymous Coward
          契約は無効となって使用権が無くなるのでは?
        • by Anonymous Coward
          すでに GPL でリリースしてしまったものについては、縛られると思います。「束縛されない」とは、まったく同じもの (やバージョンアップなどの派生物) を別ライセンスでリリースしてもかまわない、ということです。(Qt とかがその例?)

          その FAQ がこのような事態までを想定して書かれているかどうか、微妙ですね。

    • by bero (5057) on 2003年06月24日 4時01分 (#343988) 日記
      そのコメント、その部分だけ鵜呑みにするのは危険だと思う。

      たとえば、著作権者の意向として、「ライセンスにはこう書いてるけど、この項目は無視していいよ」とMLなりnewsなりで言ったとする。で、そのつもりで使っていると、後で著作権者が考え直して「やっぱライセンスに従え」と言われたらどうする。
      逆に、ライセンスに書かれてないことを、あとから「俺の本当の意向はこうだ。この条件にも従え」と言われたらどうする。
      どちらもありうることだ。事例を思い浮かべる方もおられるだろう。

      利用者からすれば(そしておそらく裁判になったとしても)、ライセンスが「すべて」だ。それ以外の「意向」なんざ、著作権者の頭の中にあるだけかもしれないし、言ったとしても知る機会もないかもしれない。
      著作権者は始めから自分の意向を反映したライセンスを選択あるいは作成すべきだ。てきとーに選択するのは危険だ。

      >著作権者は、著
      >作物に対して、著作権法で定められた権利を(著作権法に定められた範囲で)絶
      >対的に持っていますので、著作権者の意向が「すべて」なのです。
      というのは公開前なら正しい。でもってその権利を、例えば複製権や翻案権を「印税10%」とか「映画化権ウン万円」とか「ソース公開しろ」とか「売るな」とかの条件付きで他人に売ったりあげたり貸したりするとかの取り決めが契約やライセンスだ。

      著作権者がある(法)人Aとある条件(例えば10%)で契約したとしても(その契約が買取や独占契約でない限り(GPL等のライセンスにはそんなこと書いてない))、別の(法)人Bと別の条件(8%や12%)で契約したりAと契約しなおすのはアリ、というような話をしたいんだろうが、このコメントだと、著作権者の一存で「やっぱ12%よこせ」とか契約にないことを持ち出したり契約を無効にするのがアリに聞こえるで、余計混乱すると思う。
      親コメント
    • ライセンスって、技で回避するものなのか・・・。

      むー。
    • wxWindows Library Licence, Version 3 [wxwindows.org]みたいな修整LGPLライセンスつかっているところもありますな。
      #wxWindowsはLGPLも可能なデュアルライセンスでもあるけど……

      野分
  • 金本さんの発言 [php.gr.jp]を見ていて思ったのですが、

    ・当社は過日、公開するにあたって、
     自社でライセンス条項を策定しようとした。
    ・しかし面倒なので(特に英語が!)、出来あいの文面を採用することにした。

    という文を読んで、ふと疑問を持ちました。 ライセンス条項を策定するにあたって、英語にこだわる必要があるのでしょうか? たとえばGPLの日本語訳 [gnu.org]でも、

     英文文書 (GNU General Public License) を正式文書とする。この和文文書
    は弁護士の意見を採り入れて、できるだけ正確に英文文書を翻訳したものであ
    るが、法律的に有効な契約書ではない。

    とあります。 同じように自らライセンスを制定するにあたって、「効力を持つのは日本語文書だけであり、英語文書は参考用にすぎない」としてもよさそうに思うのです。 法的に有効な完璧な文書である事にこだわらなければ、英語文書を作成するのに必要な手間もいくらか少なくなるのではないかと思います。この方法に何か問題がありうるでしょうか?

    • by Anonymous Coward on 2003年06月23日 16時31分 (#343688)
      契約書を何語で書くかは当事者の自由ですが、ユーザが読める言語には当然制限があります。日本国内のみを相手にする場合には日本語でもいいでしょうが、世界的に使ってもらいたい場合には、日本語で契約書を記述すると不都合が生じますよね。
      #日本語を読める人口なんて高が知れていますから。

      世界的な使用を前提とするなら、もっとも普及した言語で契約書を記述する方が合理的で、それがたまたま英語なのです。
      #いつの日か中国語が取って代わるかもしれませんけどね。;-)

      ちなみに複数言語で正式な契約書を作成することは、法解釈の一意性が失われる恐れがあるため、出来ません。
      #どれが正式な契約書であるかを定める必要があります。
      親コメント
  • by Anonymous Coward on 2003年06月22日 22時14分 (#343143)
    >最初から気を使いましょう 部門より.

    って言うか、PHPのライセンスが変わったのが問題の大元のようですねぇ

    • BSDライセンス(PHPL?)もLGPLも自由をもとめたものなのに
      こんな形で矛盾してしまうとは皮肉なものですね。

      /* なにをもって自由とするかの違い?
            なんか宗教戦争(戦争は言い過ぎですけど)みたい。 */
      ----------------------------
      万能文化電波人間近衛隊のfengshenでした
      親コメント
      • > BSDライセンス(PHPL?)もLGPLも自由をもとめたものなのに
        > こんな形で矛盾してしまうとは皮肉なものですね。

        BSD styleライセンスとGNU (L)GPLとでは目指すところが違いますので、矛盾することがあるのは仕方ありません。というより当然です。

        > /* なにをもって自由とするかの違い?
        > なんか宗教戦争(戦争は言い過ぎですけど)みたい。 */

        BSD styleライセンスの求めているのは、受けとった側がほとんどなにをしてもよいという自由です。

        対してGNU (L)GPLの求めているのは、どこまでいってもソースコードにアクセスできるという意味での自由です。それ(著作者の意図)を妨げることが許されず、途中の誰かが好き勝手をすることはできないという観点からは不自由であるともいえます。

        ※よい、悪いの話ではなくて目的が違うということ。

        元の問題に話を戻すと、ライセンスの解釈はその文面がすべてです。著作権者の意図が別にあることが分かっていても、第三者がその意図を前提にすることはできないのに注意しましょう。

        以前NetBSDプロジェクトがCVSリポジトリーにcommitされたソースコードの差分をメールで配布する(CTM)サービスを始めたときの話です。

        BSD styleのライセンスではその第1条でソースコードの配布時にcopyrightの表示を外してはいけないということが謳われています。CTMでは差分だけの配布のため、この第1条を満足していません。このためこのサービスは中止されました。

        この議論の際にある人が書いたメッセージです。

        「不幸なことに、これはBSD style licenseの精神とは矛盾しないが、その文面と矛盾する。」

        とくに著作者の為人を知っているとこういった話がうざったいのは確かですが、余計なトラブルを避け、互いの身を守るという意味からも、ライセンスについてはきっちりさせておくべきでしょう。
        親コメント
        • CTMの問題は、CVSでもCVSupでも同じだよね。トランスポートがメールだから特別扱いってのは変だし。

          差分を配布する以上は、(元のCopyrightが記された)ファイルを持っていることが前提なので
          問題にはならないと思うけどなあ。Copyright部分を(著作権者の
          • 著作権って、各国の著作権法によってルールが決められていますので、国によって微妙にルールが違います。
            また、各条約も加盟国と非加盟国がある。

            ルール外のことだと、契約だと思うが、その契約が有効なのか無効なのかといった問題もあるよね。
            例えば、無茶な理不尽な要求は消費者契約法上どうなのかとかね。

            他者から突っ込まれない様に安全をきしたければ、微妙な解釈の奴は採用するべきではない。
            この程度なら判断が微妙なところだから訴えてこないと判断し採用するのも良い。
            そういった選択の問題と安全かどうかの問題は別だと思う。
            親コメント
          • > CTMの問題は、CVSでもCVSupでも同じだよね。トランスポートがメールだから特別扱いってのは変だし。

            > 差分を配布する以上は、(元のCopyrightが記された)ファイルを持っていることが前提なので

            メールだからではなくて、手元に対応するソースがなくても差分の配布を受けとれる点が問題にされたのだと思います。

            > で、今のNetBSDプロジェクトはどう判断しているんでしょう。各種サービスは動いているようですが。

            プロジェクトとしての判断をする立場にありませんが、大筋では上に書いた通りだと思います。
            親コメント
            • それ本気かねえ。CVSも元のソースがなくたって差分を受けとれますよ。
              cvsに手を入れて cvs rdiff などは禁止してるとか?でも、 cvs diff も
              リビジョンは自己申告だからやっぱりだめだね。同様に CVSweb の
              差分抽出機能もアウト?

              ちなみに、 CVSup や rsync だとブロックごとのハッシュ値を送る必要が
              あるので事実上手元にソースがないと差分はもらえない。が、
              • > それ本気かねえ。CVSも元のソースがなくたって差分を受けとれますよ。

                確かそのころは、NetBSDはanonymous CVSのサービスをまだやっていませんでした。

                > cvsに手を入れて cvs rdiff などは禁止してるとか?でも、 cvs diff も
                > リビジョンは自己申告だからやっぱりだめだね。同様に CVSweb の
                > 差分抽出機能もアウト?

                そういうことはしていないはずです。

                どちらかというと、CTMは問題だと考える人(著作権者)が多かった、CVSなどは問題視する人がほとんどいない、というくらいですね。なぜCTMだけ嫌われたのかは謎です。

                > そもそも差分の著作権自体が曖昧なものだよね。著作者がつっこみそうも
                > ないことまで自己規制をはじめたら、オープンソースの開発モデル自体が
                > 立ち行かなくなる恐れも。

                これはいやですね。そもそもBSD styleライセンスにするのって「このソースはあなたの好きにしていいよ。その代わり面倒なことはやめてね」という感覚に近いので、厳格に黒白つけなきゃならないのは勘弁してほしいです。だめかなあ。
                親コメント
      • 宣伝条項があるのとないのとは区別しようよ。宣伝条項なしBSDライセンスはGPLと矛盾しないのだし。

        ちなみに個人的にはGPLの本当の怖さは、よくアンチGPL厨が繰り返す「ソース公開」ではなく、GPL自体が課している以上の制限を禁止しているところにあると思っています。
        • by Anonymous Coward on 2003年06月23日 0時05分 (#343235)
          「矛盾しない」のは、宣伝条項なしBSDライセンスのソースをGPLのソースに含めて配布する場合で、 GPLのソースをBSDライセンスで配布したら明確にライセンス違反だと思いますが。
          親コメント
          • ちがうぞ(とは言いすぎか)。
            ライセンスAがライセンスの変更を認めるライセンスだったら、全然別のライセンスになるぞ。BSDLからプロプラ製品作るとかな。
            ライセンスAがライセンスBの部分集合だったら、混ぜたものはライセンスBになる。GPL compatibleとGPLを混ぜたらGPLになるとか、宣伝条項ナシのBSDLとアリのBSDL混ぜたらアリのBSDLになるとかな。
            AとBが矛盾してたら混ぜるのは不可能。Aがソース全体の公開必須で、BがNDAでソース公開禁止とかな。
            親コメント
          • つか、そもそも一つのプログラムを構成するのにライセンスAなソースとライセンスBなソースをまぜた場合、そのプログラムにはAとBの両方のライセンスが適用されるが、#343235はそのことは理解しているか?
            • by Anonymous Coward on 2003年06月23日 1時30分 (#343280)
              >ライセンスAなソースとライセンスBなソースをまぜた場合

              …だからさぁ、AがBSDライセンス、BがGPLだった場合そもそもAとBを混ぜちゃいけないんだってば。もう少し詳しく言うと、GPLなソースにBSDライセンスなソースを混ぜるのは良いけど、BSDライセンスなソースにGPLなソースを混ぜるのは不可。(混ぜた場合、ソース全体をGPLにしなきゃいけなくなる。GPLなソースの著者の許可があれば別だけど。)

              #343265はそのことは理解しているか?
              親コメント
            • GPL 2.b 項によって、GPL でライセンスされているソースを含む派生物は全体をGPLによって配布する必要があります。

              修正BSDLのソースをGPLの配布物に含めることは、修正BSDLの条項に触れないので、BSDL, GPLの両方のライセンス条件を満たしています(=矛盾しない)。

              GPLのソースを修正BSDLの配布物に含めようとすることは、上記2.

    • by don_z80 (8200) on 2003年06月22日 22時53分 (#343174)
      はい。
      タレコミ文では繁雑になるのを避けるために省略しましたが、
      PHP3系列はGPLでリリースされており、日本のPHPコミュニティ
      の手による日本語対応版(国際化版)もGPLでリリースされていま
      した。

      PHP4系列は、タレコミに書いた通りBSDライクなライセンスでの
      配布に変更されました。
      これは、GPLより自由な(ソースの開示義務などに縛られない)利用
      を可能とするための変更だったようです。
      親コメント
  • by TomTNG (9459) on 2003年06月23日 0時36分 (#343254)
    最終行
    > これについての議論がするんでいる。

    "すすんでいる"のtypoでしょうか。
  • by Anonymous Coward on 2003年06月22日 21時44分 (#343123)
    sgk氏の言葉 [php.gr.jp]によれば、
    「誰かが機能を拡張したら、その部分も公開されて欲しい。」
    とのことなので、PHPとバンドルして配布するのは無理なのでは?
  • by Anonymous Coward on 2003年06月22日 23時11分 (#343186)
    libnmzは(LGPLではなく)GPLなのでPHPライセンスとは矛盾するのでリンクすることはできないと思うのですが、その辺はどう言い訳しているのでしょうか?
  • by Anonymous Coward on 2003年06月23日 15時40分 (#343672)
    mbstring ってバグ持ちだから Red Hat から外されたまんまになってるね。
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...