アカウント名:
パスワード:
Oracleとして・SPARC・Java・Solarisあたりはどうするんでしょうね?
MySQLは商用システムの開発において使いづらいDBですね。自社システム開発だけならいいけど開発したシステムを売るとなるとGPLライセンスの利用だと接続ライブラリがLGPLでなくてGPLで開発したシステムが汚染されてしまうためGPLでの利用はきつく商用ライセンス取得しないとだめだしそれならPostgreSQL利用してシステム開発した方がその手の問題は発生しないし規模によってはSQLiteで十分ですかね。俺の中では昔は勉強段階だとMySQLは重宝したけど最近はいらない子な位置づけになりかけている。
MySQLの商用ライセンスコストがどれほどのものか。世を見ても、MySQLをいらないと考えてるのは少数だと思うけどね。当の Oracle だって Berkelay DB開発元買収、InnoDB 開発元買収という軌跡見る限り脅威と考えていたのは明確だし。
自社システムの開発やASPサービスの展開だとGPLライセンス側で十分です。ただ、作ったシステムを売る場合GPLライセンス版だとライブらのもGPLになりソース提示が必須になりますからね。(ここら辺理解してないソフトハウスでGPL汚染が多数ありそうで怖いですね。)
それが嫌なら商用ライセンスって事ですね。 http://www.s-style.co.jp/order/index.html?gclid=CO3psK6r2p0CFcEtpAodMXbnsw [s-style.co.jp] ちなみに日本の代理店と価格。一番安いライセンスでも55,125円。それこそ数万から十数
MySQLが提供しているDBとの接続ライブラリのライセンスがGPLだからダメ。昔はLGPLでの配布だったんですけどね。LGPL→GPLになったときにその関係でいろいろ問題でたよ。その一つにPHP側がMySQLからSQLiteに公式に乗り換えをしようとしたりごたごたが多少あったりしましたね。
公式見解 http://www-jp.mysql.com/about/legal/licensing//commercial-license.html [mysql.com] http://www-jp.mysql.com/about/l [mysql.com]
一部オープンソースプロダクトだけど、一部プロプライエタリプロダクトという混成なので不明瞭なんですが、 mac os x は MySQL をバンドルしてますが、あの形態でのソフトウェア販売はクロってことですよね？
＞MySQLが提供している DB との接続ライブラリのライセンスがGPLだからダメ。
．．．ということは、 ODBC / JDBC 接続の場合、 MySQL 提供が DBMS OK になる？
# 不明瞭なライセンス形態なので利用してませんけどね。
> GPLなライブラリをインタープリタごしに利用してもダメ（perlのDBD::mysqlとかPHPのMySQL拡張とか。PHPの場合はPHPライセンス版のmysqlndドライバあり。）
汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。例えば、PHP で PEAR::MDB2 なんかを通した場合とか。
接続先DBに「mysql://hostname/dbname」と指定すればMySQLドライバが使われるけど、「pgsql://…」なら、PostgreSQLが使われる、って感じで、DBオープン時の引数で、どのデータベースドライバを利用するかが変わるので、プログラムだけを見た場合、インタプリタプログ
> 汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。はっきり言ってグレーだと思います。最終的には法廷で決着をつけるしかないでしょうねえ。判断が付かない場合には問い合わせて貰うのが一番だと思います。
ちなみに、> 例えば、PHP で PEAR::MDB2 なんかを通した場合とか。
この場合に限って言えば、PHPライセンスのmysqlndドライバを利用することで、GPLのことを気にしなくても良くなります。http://dev.mysql.com/downloads/connector/php-mysqlnd/ [mysql.com]
なんか微妙に論点がずれているようですが、それこそ> PHPライセンスのmysqlndドライバを利用することで、GPLのことを気にしなくても良くなります。なんていう状況で、「PHPプログラム」だけを抜き出しても、それが「GPL化する」のかどうか論じることはできないだろう、という主張なのですが。
ていうか、> GPLなライブラリをインタープリタごしに利用してもダメ（perlのDBD::mysqlとか…これがダメだったら、Movable Type (MySQL専用ではないが、DBD::mysql経由でMySQLも使うことができる)のプロプラライセンスが成立しなくなりますね。
>これがダメだったら、Movable Type (MySQL専用ではないが、DBD::mysql経由でMySQLも使うことができる)のプロプラライセンスが成立しなくなりますね。だからMySQLにはGPL利用は嫌だって人たちには商用ライセンスがあるわけですけど理解していますか?MT側はもちろん商用ライセンス取得していると思いますよ。
まぁtaka2さんがどんな職業の人か知りませんがこういう考えの人たちの身勝手なソフトハウスはばれなきゃOKって感じでMySQLのライセンス無視してMySQLをDBとして商用ライセンスを取得してないで開発したシステムを売っている会社ありそうですね。
やっぱりなんだか話がすれ違ってるなぁ。私はプログラム単体を見て、GPL化されるかどうか判断できるのか、ってのを争点にしてるんですが。
PostgreSQLを前提にしたプログラムでも、GPLなライブラリをリンクしたインタプリターを通してMySQLに接続できる可能性があるなら、グレーである、という主張が真なら、商用ライセンスなMySQLへの接続を前提にしたプログラムでも、GPLなライブラリを通してMySQLに接続する可能性があるなら、グレーである、と主張できます。「プロプラライセンスなMovableType」の存在そのものがグレーってことになりま
> 私はプログラム単体を見て、GPL化されるかどうか判断できるのか、ってのを争点にしてるんですが。それはさっきも書いた通りどうしてもグレーゾーンが残ります。GPLなライブラリを前提にしたプログラムなら限りなく黒に近いですが、汎用ドライバのようなものを使っている場合は白に近いと言えるかも知れません。また、作成したプログラムがどのような構造になっているかということについては、様々な解釈が可能です。問題は作成したプログラムがどれだけ「リンクしたGPLライブラリ」に依存しているかどうかです。プログラムの構造がどうかという解釈は、人によって千
> 「プロプラライセンスなMovableType」の存在そのものがグレーってことになります。これは別段グレーではありません。プロプラエタリなMTはコマーシャルライセンスのMySQLを利用すればいいのです。
これがグレーではないなら、私が最初に挙げた
汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。PostgreSQL前提で作ってたプログラムを、「MySQLドライバと結合される場合もあるからGPLにしないとダメだ」なんて言われるとすごく困りものです。
に関しては、別段グレーではないってことでいいんですよね。そのプログラムがプロプラで、PostgreSQLとMySQL両対応だったとしても、「Postgr
> そのプログラムがプロプラで、PostgreSQLとMySQL両対応だったとしても、「PostgreSQLに繋ぐときはGPLの制約は受けない」し、「MySQLを使うときは商用ライセンスMySQLを利用すればいい」のですから。プロプラエタリなソフトウェアとして頒布する場合は、頒布する際にPostgreSQLに繋ぐバージョンをlibmysqlclientにリンクしないようにしておけばGPLには抵触しません。ただし、「これは両対応のプログラムです」といって配布する場合、特にプロプラエタリなソフトウェアの場合には、元からlibmysqlclientとリンクしておかなければならないはずですので、その場合は限りなく黒になるでしょう。両対応の場合は、GPLライブラリへの依存度によって黒からグレーに変化するかも知れません。
> 「mysqlndドライバを入れたPHPで使うときはGPLの制約は受けない」し、「libmysqlなPHP上で使うときは、商用ライセンスのMySQLを使えばいい」ので、別段グレーではないってことになりませんか?これは元の書き方が悪かったかも知れませんね。「perlのDBD::mysqlとかPHPのMySQL拡張とか。ただしPHPの場合はPHPライセンス版のmysqlndドライバあり。」と書くべきでした。というわけで、libmysqlなPHPを利用する場合には注意が必要です。mysqlndならPHPライセンスなので問題は生じません。
> MovableTypeがグレーではないというのなら、MTの場合、OSS版はGPLv2ライセンスなので白、プロプラエタリ版は黒です。プロプラエタリ版においてMySQLを利用するならコマーシャルライセンスが必要です。
> コード上はGPLライブラリにべったり依存していても、そのコードが実行されることがなければOKだってことになるのでしょうか。これは黒だと思います。GPLを避けたければ、GPLライブラリにリンクしないようにビルドする必要があります。
すみません、私は「インタプリタそのものやその後ろのMySQLを含めた全体のシステム」としてどうなるか、ではなく、「PHPやPerlなどのインタプリタ上で動作するプログラム単体」での話をしています。ですから、
プロプラエタリなソフトウェアとして頒布する場合は、頒布する際にPostgreSQLに繋ぐバージョンをlibmysqlclientにリンクしないようにしておけばGPLには抵触しません。
頒布段階で、インタプリタプログラム部分だけしかなく、PHPインタプリタ処理系を含めない場合、実際に使用されるのがlibmysqlclientなPHPなのかmysqlndなPHPなのか不明です。
そういう状況でも、
> そうなると、PerlでDBIを使ったサンプルだとか、PHPでPear::MDB2を使ったサンプル、といったコードを、BSDLのようなGPLでないライセンスでで配ることも出来なくなりますね。はい。そもそもGPLなライブラリをリンクするプログラムはGPLにしなければいけないので、サンプルだけが非GPLでもあまり意味はありませんね。
という主張に基づけば黒になっちゃいますね。
説明不足ですみません。この場合、MovableTypeの利用者ではなく、MovableTypeを提供する側、SixApartの立場での問題です。上述の論理に基づけば、「MovableType は、GPLなライブラリとリンクする可能性があるから、GPLにしなければならない」ので、そもそも「プロプラ版MovableTypeは存在できない」ってことになります。
ていうか、世の中には、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」って結構あると思うのですがそれらの立場はどうなるのでしょうか。#有名どころでぱっと思いつくのは、PHPライセンスのOpenPNE。
>ていうか、世の中には、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」って結構あると思うのですがそれらの立場はどうなるのでしょうか。>#有名どころでぱっと思いつくのは、PHPライセンスのOpenPNE。FOSS 除外規定知らないのか?偉そうにいろいろ言う割には自分では何も調べてないのですね。MySQLとオープンソースやGPLライセンスについて自分で調べていればすぐに検索に引っかかる情報ですけどね。
http://www-jp.mysql.com/about/legal/licensing//foss-exception.html [mysql.com]ここでも読んでおけ。
自分で調べる気がない教えて君はMySQLと同じで知らない子。
私の主張は、「インタプリタ処理系上のGPLなライブラリを利用する可能性がある」なら、「インタプリタプログラムもGPL化する」というのはおかしいだろう、ということです。
「GPLなライブラリを利用する可能性があるなら」って主張の前では、MySQLにFOSS 除外規定があろうと関係ありません。
・PostgreSQL用のインタプリタプログラムでも、MySQLと接続する可能性があるからGPL化しろ・MySQLのFOSS除外規定に該当するインタプリタプログラムでも、純GPLなMySQLと接続する可能性があるからGPL化しろ
どちらも主張の流れとしては同列かと。前者を肯定するなら後者も成立します。
>ていうか、世の中には、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」って結構あると思うのですがそれらの立場はどうなるのでしょうか。>#有名どころでぱっと思いつくのは、PHPライセンスのOpenPNE。の疑問に答えてFOSS 除外規定(簡単に言うとオープンソースに関してはGPL適応外にできる。って感じですかね。)を教えてあげただけなのにこのコメントが付く意味がわからない。なんかもうやりとりができてない。taka2さん技術的な話しの前に人との言葉のやりとりがもうできてませんね。
あのURL先読めばわ
えっと、話の流れがわかりにくくてすみません。私の主張は
「インタプリタ処理系上のGPLなライブラリを利用する可能性がある」なら、「インタプリタプログラムもGPL化する」というのはおかしい
ということですが、
そこに至るまでの、私の主張する論理の流れを言い換えましょう。
・「MySQLのFOSS除外規定」は正しく動作し、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」は存在しえるのであれば、すなわち・「MySQLのFOSS除外規定に該当するインタプリタプログラムでも、純GPLなMySQLと接続する可能性があるからGPL化しろ」という主張は成立しないということであり、同様にして・「PostgreSQLを前提にしたプログラムでも、GPLなライブラリをリンクしたインタプリターを通してMySQLに接続できる可能性があるなら、グレーである」という主張は成立しないし、さらに一般化するなら・「インタプリタ処理系上のGPLなライブラリを利用する可能性がある」なら、「インタプリタプログラムもGPL化する」という主張は成立しないということになる。と。
つまり、FOSS除外規定の話は、私の意見を補強するものであって、私の意見に反するものではありません。(それを、逆の流れで元の命題を否定しようとしてたんですが、わかりにくかったようで…すみません。)
taka2さんもうテンパっているのかな?もう支離滅裂になりかけている。FOSSがなにかすら理解していない。だから無条件にFOSS除外規定が適用されるとおもいこんでいる文書ですね。
もう君いいよ、もう必死になるのは辞めよう。いろいろと君が言っているけどFOSS除外規定についてMySQLとオープンソースあたりを自分で調べていれば自然とFOSS除外規定に行き着く。これすらできずに「OpenPNEはPHPライセンスだ。GPLじゃないのはおかしい」といった段階で君の技量はそこが浅いことは露見している。この部分もそうだけどtaka2は相手の書いた文書に対してなんか論点がずれたコメントを返している。見ていて痛々しい。
別に支離滅裂になってるつもりもテンパってるつもりもなく、最初から主張は変わってないんですけどね。その主張が正しく読みとられていないというか、自身の筆力不足を痛感してますが。
インタプリタ上で動作するプログラムを単独で見た場合に、ghost-q氏の#1660544 [srad.jp]で
GPLなライブラリをインタープリタごしに利用してもダメ（perlのDBD::mysqlとかPHPのMySQL拡張とか。PHPの場合はPHPライセンス版のmysqlndドライバあり。）
と書かれたのに対し、私は#1660552で [srad.jp]
PostgreSQL前提で作ってたプログラムを、「MySQLドライバと結合される場合もあるからGPLにしないとダメだ」なんて言われるとすごく困りもの
だという疑問を持ったのが発端で、それに対しghost-q氏が#1660559 [srad.jp]で
> 汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。はっきり言ってグレーだと思います。
といった意見が出たことに対し、詳細が知りたいと考えているだけです。
最初に出た話はMySQLなので、MySQLに沿って話を進めていますが、GPLの一般論として、インタプリタ処理系が「GPLのライブラリとリンクする」のか「非GPLのライブラリとリンクする」のかが、処理系のコンパイル条件の違いだとか設定だとか配布条件など、実行時の状況によって変わってくる場合に、そのインタプリタ処理系で実行する「プログラム」は「GPLになる」のか「GPLにならない」のか、(言い換えれば、そういう「プログラム」を「非GPLなライセンスで出す」ことは可能かどうか)というのが疑問なわけです。
ghost-q氏は、そういう場合でも「GPLになる」と主張されているように、私は読み取りました。
MySQLについて考えた場合、MySQLがGPLと商用のデュアルライセンスになっている結果としてインタプリタプログラムは「GPLか非GPLかどちらのライブラリとリンクして動作するかわからない」ことになりますが、そういうプログラムを「プロプラで出すことが出来る」のであれば、すなわち、上述の疑問は「GPLにならない」が答えになります。
と、ここまでまとめていて気づいたのですが、ghost-q氏は一環して「MySQLやインタプリタ処理系を含めた全体」として頒布する場合についてのことしか書いてないんですね。#1661198 [srad.jp]
とか。
私は「プロプラなインタプリタプログラムとGPLなMySQLを組み合わせるのは黒だ」というのを否定するつもりはありません。そうではなく、PHPなりPerlなりのスクリプト部分だけを(処理系は含めずに)頒布する場合にどうなるのかって疑問を投げかけているのに、それに対する返答になってない、と。
あと、
>MySQLのFOSS除外規定に該当するインタプリタプログラムでも、純GPLなMySQLと接続する可能性があるからGPL化しろなんて言う意味不明なコメントが出る。
すみません、これは確かに間違えてました。FOSS除外規定に該当する場合は、GPLなMySQLライブラリとリンクする可能性はないですから、私の疑問に対して、MySQLを利用するオープンソースライセンスなプロダクトの存在は、肯定材料にも否定材料にもならないですね。挙げた例が適切ではありませんでした。すみません。
#でも「FOSS除外規定にないオープンソースライセンス」で配られているMySQL利用インタプリタプログラムってのもあるよね。
>インタプリタプログラムは「GPLか非GPLかどちらのライブラリとリンクして動作するかわからない」ことになりますがすでにここからおかしいことに気がついてないの?
すみません、なぜ「ここからおかしい」と言えるのか私にはさっぱり分かりません。
PHP処理系は、MySQLクライアントライブラリとして「GPLなlibmysqlclientをリンクしている場合もあれば、商用ライセンスのlibmysqlclientやPHPライセンスのmysqlndといった非GPLのライブラリをリンクしている場合もある」というのはおかしくありませんよね。
そうであれば、「PHPのスクリプト部分だけを(処理系は含めずに)頒布する場合」には、頒布したプログラムは、頒布段階では「GPLか非GPLかどちらのライブラリとリンクして動作するかわからない」というのは当然のことだと思うのですが、
この考えはどうおかしいのか、教えて頂けませんか。
>すみません、なぜ「ここからおかしい」と言えるのか私にはさっぱり分かりません。なぜ?インタプリタ限定?可能性としてはコンパイラされた言語でも誰かが非GPLな接続ライブラリ開発したとして可能性は発生するよね。
>GPLなlibmysqlclientをリンクしている場合もあれば、商用ライセンスのlibmysqlclientこれデベロッパー側がライセンス取得して販売すればどっちのライセンスかはっきりするよね。
そもそもいろいろ知りたければMySQLのライセンスを販売している代理店やSUNに直接問い合わせすればいいのになにここで必死になっているの?
なぜ?インタプリタ限定?可能性としてはコンパイラされた言語でも誰かが非GPLな接続ライブラリ開発したとして可能性は発生するよね。
その通りです。話の発端がインタプリタについての話ですから、それに沿って論じてきましたが、コンパイル言語で書かれたプログラムでも、・バイナリ頒布を行わずにソース頒布のみを行う・使用しているライブラリに、GPLと非GPLの両方の実装がある・頒布者は、利用者がどちらのライブラリでバイナリを作成するか想定できない場合には、同様の問題は起きると思います。ちょっとそういう「ライブラリ」の具体例は心当たりがありませんが。
そもそもいろいろ知りたければMySQLのライセンスを販売している代理店やSUNに直接問い合わせすればいいのに
私の話の発端はPostgreSQL前提で作ってたプログラムを、「MySQLドライバと結合される場合もあるからGPLにしないとダメだ」なんて言われるとすごく困りもの [srad.jp]だという所にあります。どうして使いもしないMySQLのライセンスについて調べなきゃいけないんですか?
GPL一般論として「処理系がGPLなライブラリをリンクする可能性があるならGPL化しろ」というのであれば、開発側の見知らぬライブラリが関わってくる可能性があります。今回はMySQLという分かりやすい物が出てきてますから権利者に問い合わせるという解決手段が取れますが、いつもそんなことができるとはかぎりません。
インタプリタプログラムのみの頒布の場合、例えば、ドキュメントに「mysqlndをリンクしたPHPで実行してください」とでも書いておけばOKとか言うことですか?
それで言いんだったら最初からこんなに話が延びなかったとういか、上述のようなPostgreSQL接続用プログラムだって「PostgreSQLに接続して使ってください」とでも書いておけばOKってことになりますね。それで話はだいたい終わるんですが…
(それでも、開発者がGPLでないと想定していてかつドキュメントで言及していないライブラリに、実際には開発者の知らないところでGPLな別実装が存在するって可能性はありますね。かといって、使用しているライブラリ全てを列挙しろというのは難しいかと。)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
MySQLの行方 (スコア:0)
一部ではMySQLを売れなどと言われることもありますが、Oracleとしては、どうしたいのか見えてきませんね。
大々的にMySQLを今後も継続することを確約するリリースでも出せば安心できるだろうに。(それでもムリか)
他社に売って競合になるより、自社で飼い殺しにするために沈黙しているのだろうか。
それにしてもサンの赤字も大変だね。買収の件での停滞を除いても。
これからリストラなどを行うということだが、遅すぎじゃねぇか。赤字部門も閉鎖するなどしないと。黒字部門がなかったり？
Re: (スコア:0)
Oracleとして
・SPARC
・Java
・Solaris
あたりはどうするんでしょうね?
MySQLは商用システムの開発において使いづらいDBですね。自社システム開発だけならいいけど開発したシステムを売るとなると
GPLライセンスの利用だと接続ライブラリがLGPLでなくてGPLで開発したシステムが汚染されてしまうためGPLでの利用はきつく商用ライセンス取得しないとだめだし
それならPostgreSQL利用してシステム開発した方がその手の問題は発生しないし規模によってはSQLiteで十分ですかね。
俺の中では昔は勉強段階だとMySQLは重宝したけど最近はいらない子な位置づけになりかけている。
Re: (スコア:0)
MySQLの商用ライセンスコストがどれほどのものか。
世を見ても、MySQLをいらないと考えてるのは少数だと思うけどね。
当の Oracle だって Berkelay DB開発元買収、InnoDB 開発元買収という軌跡見る限り脅威と考えていたのは明確だし。
Re: (スコア:0)
自社システムの開発やASPサービスの展開だとGPLライセンス側で十分です。
ただ、作ったシステムを売る場合GPLライセンス版だとライブらのもGPLになりソース提示が必須になりますからね。
(ここら辺理解してないソフトハウスでGPL汚染が多数ありそうで怖いですね。)
それが嫌なら商用ライセンスって事ですね。
http://www.s-style.co.jp/order/index.html?gclid=CO3psK6r2p0CFcEtpAodMXbnsw [s-style.co.jp]
ちなみに日本の代理店と価格。
一番安いライセンスでも55,125円。
それこそ数万から十数
Re: (スコア:0)
Re: (スコア:2, 参考になる)
MySQLが提供しているDBとの接続ライブラリのライセンスがGPLだからダメ。
昔はLGPLでの配布だったんですけどね。
LGPL→GPLになったときにその関係でいろいろ問題でたよ。
その一つにPHP側がMySQLからSQLiteに公式に乗り換えをしようとしたりごたごたが多少あったりしましたね。
公式見解
http://www-jp.mysql.com/about/legal/licensing//commercial-license.html [mysql.com]
http://www-jp.mysql.com/about/l [mysql.com]
Apple (スコア:0)
一部オープンソースプロダクトだけど、一部プロプライエタリプロダクトという混成なので不明瞭なんですが、 mac os x は MySQL をバンドルしてますが、あの形態でのソフトウェア販売はクロってことですよね？
＞MySQLが提供している DB との接続ライブラリのライセンスがGPLだからダメ。
．．．ということは、 ODBC / JDBC 接続の場合、 MySQL 提供が DBMS OK になる？
# 不明瞭なライセンス形態なので利用してませんけどね。
Re: (スコア:3, 参考になる)
Re: (スコア:1)
> GPLなライブラリをインタープリタごしに利用してもダメ（perlのDBD::mysqlとかPHPのMySQL拡張とか。PHPの場合はPHPライセンス版のmysqlndドライバあり。）
汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。
例えば、PHP で PEAR::MDB2 なんかを通した場合とか。
接続先DBに「mysql://hostname/dbname」と指定すればMySQLドライバが使われるけど、
「pgsql://…」なら、PostgreSQLが使われる、って感じで、
DBオープン時の引数で、どのデータベースドライバを利用するかが変わるので、
プログラムだけを見た場合、インタプリタプログ
Re: (スコア:2, 参考になる)
> 汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。
はっきり言ってグレーだと思います。最終的には法廷で決着をつけるしかないでしょうねえ。判断が付かない場合には問い合わせて貰うのが一番だと思います。
ちなみに、
> 例えば、PHP で PEAR::MDB2 なんかを通した場合とか。
この場合に限って言えば、PHPライセンスのmysqlndドライバを利用することで、GPLのことを気にしなくても良くなります。
http://dev.mysql.com/downloads/connector/php-mysqlnd/ [mysql.com]
Re: (スコア:1)
なんか微妙に論点がずれているようですが、それこそ
> PHPライセンスのmysqlndドライバを利用することで、GPLのことを気にしなくても良くなります。
なんていう状況で、「PHPプログラム」だけを抜き出しても、それが「GPL化する」のかどうか論じることはできないだろう、という主張なのですが。
ていうか、
> GPLなライブラリをインタープリタごしに利用してもダメ（perlのDBD::mysqlとか…
これがダメだったら、Movable Type (MySQL専用ではないが、DBD::mysql経由でMySQLも使うことができる)のプロプラライセンスが成立しなくなりますね。
Re: (スコア:0)
>これがダメだったら、Movable Type (MySQL専用ではないが、DBD::mysql経由でMySQLも使うことができる)のプロプラライセンスが成立しなくなりますね。
だからMySQLにはGPL利用は嫌だって人たちには商用ライセンスがあるわけですけど理解していますか?
MT側はもちろん商用ライセンス取得していると思いますよ。
まぁtaka2さんがどんな職業の人か知りませんがこういう考えの人たちの身勝手なソフトハウスはばれなきゃOKって感じで
MySQLのライセンス無視してMySQLをDBとして商用ライセンスを取得してないで開発したシステムを売っている会社ありそうですね。
Re: (スコア:1)
やっぱりなんだか話がすれ違ってるなぁ。
私はプログラム単体を見て、GPL化されるかどうか判断できるのか、ってのを争点にしてるんですが。
PostgreSQLを前提にしたプログラムでも、GPLなライブラリをリンクしたインタプリターを通してMySQLに接続できる可能性があるなら、グレーである、という主張が真なら、
商用ライセンスなMySQLへの接続を前提にしたプログラムでも、GPLなライブラリを通してMySQLに接続する可能性があるなら、グレーである、と主張できます。「プロプラライセンスなMovableType」の存在そのものがグレーってことになりま
Re: (スコア:1)
> 私はプログラム単体を見て、GPL化されるかどうか判断できるのか、ってのを争点にしてるんですが。
それはさっきも書いた通りどうしてもグレーゾーンが残ります。GPLなライブラリを前提にしたプログラムなら限りなく黒に近いですが、汎用ドライバのようなものを使っている場合は白に近いと言えるかも知れません。また、作成したプログラムがどのような構造になっているかということについては、様々な解釈が可能です。問題は作成したプログラムがどれだけ「リンクしたGPLライブラリ」に依存しているかどうかです。プログラムの構造がどうかという解釈は、人によって千
Re: (スコア:1)
これがグレーではないなら、私が最初に挙げた
に関しては、別段グレーではないってことでいいんですよね。そのプログラムがプロプラで、PostgreSQLとMySQL両対応だったとしても、「Postgr
Re:Apple (スコア:1)
> そのプログラムがプロプラで、PostgreSQLとMySQL両対応だったとしても、「PostgreSQLに繋ぐときはGPLの制約は受けない」し、「MySQLを使うときは商用ライセンスMySQLを利用すればいい」のですから。
プロプラエタリなソフトウェアとして頒布する場合は、頒布する際にPostgreSQLに繋ぐバージョンをlibmysqlclientにリンクしないようにしておけばGPLには抵触しません。ただし、「これは両対応のプログラムです」といって配布する場合、特にプロプラエタリなソフトウェアの場合には、元からlibmysqlclientとリンクしておかなければならないはずですので、その場合は限りなく黒になるでしょう。両対応の場合は、GPLライブラリへの依存度によって黒からグレーに変化するかも知れません。
> 「mysqlndドライバを入れたPHPで使うときはGPLの制約は受けない」し、「libmysqlなPHP上で使うときは、商用ライセンスのMySQLを使えばいい」ので、別段グレーではないってことになりませんか?
これは元の書き方が悪かったかも知れませんね。「perlのDBD::mysqlとかPHPのMySQL拡張とか。ただしPHPの場合はPHPライセンス版のmysqlndドライバあり。」と書くべきでした。というわけで、libmysqlなPHPを利用する場合には注意が必要です。mysqlndならPHPライセンスなので問題は生じません。
> MovableTypeがグレーではないというのなら、
MTの場合、OSS版はGPLv2ライセンスなので白、プロプラエタリ版は黒です。プロプラエタリ版においてMySQLを利用するならコマーシャルライセンスが必要です。
> コード上はGPLライブラリにべったり依存していても、そのコードが実行されることがなければOKだってことになるのでしょうか。
これは黒だと思います。GPLを避けたければ、GPLライブラリにリンクしないようにビルドする必要があります。
Re:Apple (スコア:1)
すみません、私は「インタプリタそのものやその後ろのMySQLを含めた全体のシステム」としてどうなるか、ではなく、
「PHPやPerlなどのインタプリタ上で動作するプログラム単体」での話をしています。
ですから、
頒布段階で、インタプリタプログラム部分だけしかなく、PHPインタプリタ処理系を含めない場合、実際に使用されるのがlibmysqlclientなPHPなのかmysqlndなPHPなのか不明です。
そういう状況でも、
という主張に基づけば黒になっちゃいますね。
説明不足ですみません。この場合、MovableTypeの利用者ではなく、MovableTypeを提供する側、SixApartの立場での問題です。上述の論理に基づけば、「MovableType は、GPLなライブラリとリンクする可能性があるから、GPLにしなければならない」ので、そもそも「プロプラ版MovableTypeは存在できない」ってことになります。
ていうか、世の中には、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」って結構あると思うのですがそれらの立場はどうなるのでしょうか。
#有名どころでぱっと思いつくのは、PHPライセンスのOpenPNE。
Re: (スコア:0)
>ていうか、世の中には、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」って結構あると思うのですがそれらの立場はどうなるのでしょうか。
>#有名どころでぱっと思いつくのは、PHPライセンスのOpenPNE。
FOSS 除外規定知らないのか?
偉そうにいろいろ言う割には自分では何も調べてないのですね。
MySQLとオープンソースやGPLライセンスについて自分で調べていればすぐに検索に引っかかる情報ですけどね。
http://www-jp.mysql.com/about/legal/licensing//foss-exception.html [mysql.com]
ここでも読んでおけ。
自分で調べる気がない教えて君はMySQLと同じで知らない子。
Re:Apple (スコア:1)
私の主張は、
「インタプリタ処理系上のGPLなライブラリを利用する可能性がある」なら、「インタプリタプログラムもGPL化する」
というのはおかしいだろう、ということです。
「GPLなライブラリを利用する可能性があるなら」って主張の前では、MySQLにFOSS 除外規定があろうと関係ありません。
・PostgreSQL用のインタプリタプログラムでも、MySQLと接続する可能性があるからGPL化しろ
・MySQLのFOSS除外規定に該当するインタプリタプログラムでも、純GPLなMySQLと接続する可能性があるからGPL化しろ
どちらも主張の流れとしては同列かと。前者を肯定するなら後者も成立します。
Re: (スコア:0)
>ていうか、世の中には、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」って結構あると思うのですがそれらの立場はどうなるのでしょうか。
>#有名どころでぱっと思いつくのは、PHPライセンスのOpenPNE。
の疑問に答えてFOSS 除外規定(簡単に言うとオープンソースに関してはGPL適応外にできる。って感じですかね。)を教えてあげただけなのにこのコメントが付く意味がわからない。
なんかもうやりとりができてない。taka2さん技術的な話しの前に人との言葉のやりとりがもうできてませんね。
あのURL先読めばわ
Re:Apple (スコア:1)
えっと、話の流れがわかりにくくてすみません。
私の主張は
ということですが、
そこに至るまでの、私の主張する論理の流れを言い換えましょう。
・「MySQLのFOSS除外規定」は正しく動作し、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」は存在しえる
のであれば、すなわち
・「MySQLのFOSS除外規定に該当するインタプリタプログラムでも、純GPLなMySQLと接続する可能性があるからGPL化しろ」という主張は成立しない
ということであり、同様にして
・「PostgreSQLを前提にしたプログラムでも、GPLなライブラリをリンクしたインタプリターを通してMySQLに接続できる可能性があるなら、グレーである」という主張は成立しない
し、さらに一般化するなら
・「インタプリタ処理系上のGPLなライブラリを利用する可能性がある」なら、「インタプリタプログラムもGPL化する」という主張は成立しない
ということになる。と。
つまり、FOSS除外規定の話は、私の意見を補強するものであって、私の意見に反するものではありません。
(それを、逆の流れで元の命題を否定しようとしてたんですが、わかりにくかったようで…すみません。)
Re: (スコア:0)
taka2さんもうテンパっているのかな?もう支離滅裂になりかけている。
FOSSがなにかすら理解していない。
だから無条件にFOSS除外規定が適用されるとおもいこんでいる文書ですね。
もう君いいよ、もう必死になるのは辞めよう。
いろいろと君が言っているけど
FOSS除外規定についてMySQLとオープンソースあたりを自分で調べていれば自然とFOSS除外規定に行き着く。
これすらできずに
「OpenPNEはPHPライセンスだ。GPLじゃないのはおかしい」といった段階で君の技量はそこが浅いことは露見している。
この部分もそうだけどtaka2は相手の書いた文書に対してなんか論点がずれたコメントを返している。見ていて痛々しい。
Re:Apple (スコア:1)
別に支離滅裂になってるつもりもテンパってるつもりもなく、最初から主張は変わってないんですけどね。
その主張が正しく読みとられていないというか、自身の筆力不足を痛感してますが。
インタプリタ上で動作するプログラムを単独で見た場合に、
ghost-q氏の#1660544 [srad.jp]で
と書かれたのに対し、私は#1660552で [srad.jp]
だという疑問を持ったのが発端で、それに対しghost-q氏が#1660559 [srad.jp]で
といった意見が出たことに対し、詳細が知りたいと考えているだけです。
最初に出た話はMySQLなので、MySQLに沿って話を進めていますが、GPLの一般論として、
インタプリタ処理系が「GPLのライブラリとリンクする」のか「非GPLのライブラリとリンクする」のかが、
処理系のコンパイル条件の違いだとか設定だとか配布条件など、実行時の状況によって変わってくる場合に、
そのインタプリタ処理系で実行する「プログラム」は「GPLになる」のか「GPLにならない」のか、
(言い換えれば、そういう「プログラム」を「非GPLなライセンスで出す」ことは可能かどうか)
というのが疑問なわけです。
ghost-q氏は、そういう場合でも「GPLになる」と主張されているように、私は読み取りました。
MySQLについて考えた場合、MySQLがGPLと商用のデュアルライセンスになっている結果として
インタプリタプログラムは「GPLか非GPLかどちらのライブラリとリンクして動作するかわからない」ことになりますが、
そういうプログラムを「プロプラで出すことが出来る」のであれば、すなわち、上述の疑問は「GPLにならない」が答えになります。
と、ここまでまとめていて気づいたのですが、ghost-q氏は一環して「MySQLやインタプリタ処理系を含めた全体」として頒布する場合についてのことしか書いてないんですね。#1661198 [srad.jp]
とか。
私は「プロプラなインタプリタプログラムとGPLなMySQLを組み合わせるのは黒だ」というのを否定するつもりはありません。
そうではなく、PHPなりPerlなりのスクリプト部分だけを(処理系は含めずに)頒布する場合にどうなるのかって疑問を投げかけているのに、それに対する返答になってない、と。
あと、
すみません、これは確かに間違えてました。
FOSS除外規定に該当する場合は、GPLなMySQLライブラリとリンクする可能性はないですから、
私の疑問に対して、MySQLを利用するオープンソースライセンスなプロダクトの存在は、肯定材料にも否定材料にもならないですね。
挙げた例が適切ではありませんでした。すみません。
#でも「FOSS除外規定にないオープンソースライセンス」で配られているMySQL利用インタプリタプログラムってのもあるよね。
Re: (スコア:0)
>インタプリタプログラムは「GPLか非GPLかどちらのライブラリとリンクして動作するかわからない」ことになりますが
すでにここからおかしいことに気がついてないの?
Re:Apple (スコア:1)
すみません、なぜ「ここからおかしい」と言えるのか私にはさっぱり分かりません。
PHP処理系は、MySQLクライアントライブラリとして「GPLなlibmysqlclientをリンクしている場合もあれば、商用ライセンスのlibmysqlclientやPHPライセンスのmysqlndといった非GPLのライブラリをリンクしている場合もある」というのはおかしくありませんよね。
そうであれば、「PHPのスクリプト部分だけを(処理系は含めずに)頒布する場合」には、
頒布したプログラムは、頒布段階では「GPLか非GPLかどちらのライブラリとリンクして動作するかわからない」というのは当然のことだと思うのですが、
この考えはどうおかしいのか、教えて頂けませんか。
Re: (スコア:0)
>すみません、なぜ「ここからおかしい」と言えるのか私にはさっぱり分かりません。
なぜ?インタプリタ限定?
可能性としてはコンパイラされた言語でも誰かが非GPLな接続ライブラリ開発したとして可能性は発生するよね。
>GPLなlibmysqlclientをリンクしている場合もあれば、商用ライセンスのlibmysqlclient
これデベロッパー側がライセンス取得して販売すればどっちのライセンスかはっきりするよね。
そもそもいろいろ知りたければMySQLのライセンスを販売している代理店やSUNに直接問い合わせすればいいのに
なにここで必死になっているの?
Re:Apple (スコア:1)
その通りです。話の発端がインタプリタについての話ですから、それに沿って論じてきましたが、コンパイル言語で書かれたプログラムでも、
・バイナリ頒布を行わずにソース頒布のみを行う
・使用しているライブラリに、GPLと非GPLの両方の実装がある
・頒布者は、利用者がどちらのライブラリでバイナリを作成するか想定できない
場合には、同様の問題は起きると思います。
ちょっとそういう「ライブラリ」の具体例は心当たりがありませんが。
私の話の発端はPostgreSQL前提で作ってたプログラムを、「MySQLドライバと結合される場合もあるからGPLにしないとダメだ」なんて言われるとすごく困りもの [srad.jp]だという所にあります。どうして使いもしないMySQLのライセンスについて調べなきゃいけないんですか?
GPL一般論として「処理系がGPLなライブラリをリンクする可能性があるならGPL化しろ」というのであれば、開発側の見知らぬライブラリが関わってくる可能性があります。
今回はMySQLという分かりやすい物が出てきてますから権利者に問い合わせるという解決手段が取れますが、いつもそんなことができるとはかぎりません。
インタプリタプログラムのみの頒布の場合、例えば、ドキュメントに「mysqlndをリンクしたPHPで実行してください」とでも書いておけばOKとか言うことですか?
それで言いんだったら最初からこんなに話が延びなかったとういか、
上述のようなPostgreSQL接続用プログラムだって「PostgreSQLに接続して使ってください」とでも書いておけばOKってことになりますね。それで話はだいたい終わるんですが…
(それでも、開発者がGPLでないと想定していてかつドキュメントで言及していないライブラリに、実際には開発者の知らないところでGPLな別実装が存在するって可能性はありますね。かといって、使用しているライブラリ全てを列挙しろというのは難しいかと。)