サン、オラクルによる買収の停滞により毎月約1億ドルの赤字 62
ストーリー by hylom
引き延ばされてやせ細る 部門より
引き延ばされてやせ細る 部門より
あるAnonymous Coward 曰く、
サン・マイクロシステムズは20日、今後1年で世界で3000人の人員削減を行うことを発表したとのこと。これは全従業員の10%にあたる人数にあたるそうだ（ロイター、本家/.記事）。
人員削減の背景には、オラクルによるサン・マイクロシステムズの買収に関する欧州当局の審査・承認の遅れがある。買収計画の行く末が不透明なサン・マイクロシステムズの顧客は購入を先延ばしにしたり競合他社から購入したりしており、結果として同社に大きな経済的打撃を与えているとのこと。EU Competition CommissionerのNeelie Kroes氏は承認の遅れに関し、委員会の度重なる要請にも関わらずオラクルが競合上の問題が無いことを証明しなかったり、また委員会が提示した懸念事項に対する改善処置を提案しなかったことに対し遺憾の意を表明し、事態解決にはオラクルによる迅速な対応が不可避であることを示唆したとのこと。
なお、買収計画の停滞により、サン・マイクロシステムズは毎月約1億ドルの赤字が発生しているそうだ。
ZFS (スコア:3, 参考になる)
AppleがZFSの採用を止めちゃうそうです。まあOracleがやる気がないからでしょう。
http://zfs.macosforge.org/ [macosforge.org]
MySQLも重要ですが、ZFSにも期待していただけに、かなり残念。
Re:ZFS (スコア:1)
もう Snow Leopard では zfs コマンドもなくなってたんですね。なのにこんなこと [srad.jp]書いちゃって、あたしったらバカ />_<\
※ 書いたときはまだ Snow Leopard 手に入れてなかったんだけど、出てすぐ気づいてた人は沢さんいたようで
Windows2000の代わりに (スコア:1)
ATOKをフリーで使えるのは魅力的だよね。
Re: (スコア:0)
初回出荷から最低10年サポート(ただし最後の3年は有料サポートのみで新規セキュリティ
パッチの提供もなし)を保証しているので、あと3年くらいは大丈夫じゃないでしょうか。
問題は来年中ごろといわれている Solaris 11 がどうなるかでしょう。
Solaris 9 は今月末が最終出荷なので、パッチ提供終了まであと2年ですな。
おやぢギャグ(-1) (スコア:0)
Re: (スコア:0)
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: (スコア:0)
group by に無いものを select できること前提っていうのは、やっぱり変だと思う
Re: (スコア:0)
> それこそ数万から十数万の規模のシステムにおいて
一から構築するシステムでその金額は流石に想定外だわ…
Re: (スコア:0)
フレームワーク
Re: (スコア:0)
Re:MySQLの行方 (スコア: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/legal/licensing/faq.html [mysql.com]
など
こういうコメントが付くようだからソフトハウスもここら辺のライセンス違反してMySQLでシステム開発している企業もそこそこありそうですけどね。
Re:MySQLの行方 (スコア:2, 参考になる)
Re: (スコア:0)
エンドユーザがMySQLのライセンスを購入する形にしているんだった。
Apple (スコア:0)
一部オープンソースプロダクトだけど、一部プロプライエタリプロダクトという混成なので不明瞭なんですが、 mac os x は MySQL をバンドルしてますが、あの形態でのソフトウェア販売はクロってことですよね？
＞MySQLが提供している DB との接続ライブラリのライセンスがGPLだからダメ。
．．．ということは、 ODBC / JDBC 接続の場合、 MySQL 提供が DBMS OK になる？
# 不明瞭なライセンス形態なので利用してませんけどね。
Re:Apple (スコア:3, 参考になる)
Re:Apple (スコア:1)
> GPLなライブラリをインタープリタごしに利用してもダメ（perlのDBD::mysqlとかPHPのMySQL拡張とか。PHPの場合はPHPライセンス版のmysqlndドライバあり。）
汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。
例えば、PHP で PEAR::MDB2 なんかを通した場合とか。
接続先DBに「mysql://hostname/dbname」と指定すればMySQLドライバが使われるけど、
「pgsql://…」なら、PostgreSQLが使われる、って感じで、
DBオープン時の引数で、どのデータベースドライバを利用するかが変わるので、
プログラムだけを見た場合、インタプリタプログラムが、どのライブラリを使うかは不定です。
そういう場合、
> プロトコルが明確になっている場合はネットワーク越しならOK
よりも、プログラムとGPLライブラリとの結合は疎になってると思います。
これで、PostgreSQL前提で作ってたプログラムを、「MySQLドライバと結合される場合もあるからGPLにしないとダメだ」なんて言われるとすごく困りものです。
Re:Apple (スコア:2, 参考になる)
> 汎用データベースドライバライブラリ経由の場合はどうなるんでしょうねぇ。
はっきり言ってグレーだと思います。最終的には法廷で決着をつけるしかないでしょうねえ。判断が付かない場合には問い合わせて貰うのが一番だと思います。
ちなみに、
> 例えば、PHP で PEAR::MDB2 なんかを通した場合とか。
この場合に限って言えば、PHPライセンスのmysqlndドライバを利用することで、GPLのことを気にしなくても良くなります。
http://dev.mysql.com/downloads/connector/php-mysqlnd/ [mysql.com]
Re: (スコア:0)
># 不明瞭なライセンス形態なので利用してませんけどね。
実際そうなんですよね。
ASPとしてサービス展開や自社システム開発ならGPL汚染されていてもソース提示する義務は無いので問題ないですけど
システムを売る側としたらGPL汚染を避けるために商用ライセンス取得しないといけない。
でそれならPostgreSQL利用した方が問題なく利用できる。
商用ライセンス買うなら安くなっているオラクルの方を買ったって良いんじゃない?って結論になる。
こんな微妙なライセンスだと勉強用には良いけど実務系だといらない子になってきても仕方がない。
CMS系でもMySQL前提のが多いけどPostgreSQL使えるのもそこそこありますからね。
そのくせ格安系の共用タイプの(さくらあたりなど)レンタルサーバだとMySQLは使えてもPostgreSQLは使えない所とか結構ありますね。
Re:Apple (スコア: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:Apple (スコア:1)
やっぱりなんだか話がすれ違ってるなぁ。
私はプログラム単体を見て、GPL化されるかどうか判断できるのか、ってのを争点にしてるんですが。
PostgreSQLを前提にしたプログラムでも、GPLなライブラリをリンクしたインタプリターを通してMySQLに接続できる可能性があるなら、グレーである、という主張が真なら、
商用ライセンスなMySQLへの接続を前提にしたプログラムでも、GPLなライブラリを通してMySQLに接続する可能性があるなら、グレーである、と主張できます。「プロプラライセンスなMovableType」の存在そのものがグレーってことになります。
この論点では、MySQLに商用ライセンス版があるかどうかは問題になりません。
「汎用的なデーターベースドライバ」の繋がる先のどこかで「GPLなライブラリ」を通りえるだけで「GPL化される」ってことに異を唱えてるわけです。
そうなると、PerlでDBIを使ったサンプルだとか、PHPでPear::MDB2を使ったサンプル、といったコードを、
BSDLのようなGPLでないライセンスでで配ることも出来なくなりますね。
Re:Apple (スコア:1)
> 私はプログラム単体を見て、GPL化されるかどうか判断できるのか、ってのを争点にしてるんですが。
それはさっきも書いた通りどうしてもグレーゾーンが残ります。GPLなライブラリを前提にしたプログラムなら限りなく黒に近いですが、汎用ドライバのようなものを使っている場合は白に近いと言えるかも知れません。また、作成したプログラムがどのような構造になっているかということについては、様々な解釈が可能です。問題は作成したプログラムがどれだけ「リンクしたGPLライブラリ」に依存しているかどうかです。プログラムの構造がどうかという解釈は、人によって千差万別ですからはっきりと白黒つけるのはそもそも技術的に難しいのです。
> 商用ライセンスなMySQLへの接続を前提にしたプログラムでも、GPLなライブラリを通してMySQLに接続する可能性があるなら、グレーである、と主張できます。
中間に位置するライブラリがGPLなら、GPLに準拠しなければいけません。そのライブラリに完全に依存しているなら、グレーではなく黒です。
中間に位置するライブラリとして、perl-DBIを指しているならそのような心配は要りません。DBIはGPLとArtistic Licenseのデュアルライセンスですから、Artistic Licenseを選択すれば良いでしょう。
従って、
> 「プロプラライセンスなMovableType」の存在そのものがグレーってことになります。
これは別段グレーではありません。プロプラエタリなMTはコマーシャルライセンスのMySQLを利用すればいいのです。
ちなみに、OSSなMTはGPLv2です。
参考：http://neta.ywcafe.net/000749.html
> そうなると、PerlでDBIを使ったサンプルだとか、PHPでPear::MDB2を使ったサンプル、といったコードを、BSDLのようなGPLでないライセンスでで配ることも出来なくなりますね。
はい。そもそもGPLなライブラリをリンクするプログラムはGPLにしなければいけないので、サンプルだけが非GPLでもあまり意味はありませんね。
ただ、MySQLに限った話をすると、FOSS License Exceptionという規約があり、オープンソースライセンスであればGPL以外のライセンスでもソフトウェアをリリースすることを認めています。（ただし一緒にバンドルされるMySQLはGPLのままとなります）
http://www.mysql.com/about/legal/licensing/foss-exception/ [mysql.com]
従って、MySQLの場合はBSDLのサンプルコードを開示するのはOKです。（他のGPLソフトウェアではNGです。）
Re:Apple (スコア:1)
これがグレーではないなら、私が最初に挙げた
に関しては、別段グレーではないってことでいいんですよね。そのプログラムがプロプラで、PostgreSQLとMySQL両対応だったとしても、「PostgreSQLに繋ぐときはGPLの制約は受けない」し、「MySQLを使うときは商用ライセンスMySQLを利用すればいい」のですから。
さらに、
についても、PHPに関しては、「mysqlndドライバを入れたPHPで使うときはGPLの制約は受けない」し、「libmysqlなPHP上で使うときは、商用ライセンスのMySQLを使えばいい」ので、別段グレーではないってことになりませんか?
しかも、「DBIを通さずにDBD::MySQL経由でも動く」ようになっているMovableTypeがグレーではないというのなら、
これについても、コード上はGPLライブラリにべったり依存していても、そのコードが実行されることがなければOKだってことになるのでしょうか。
分かったような気がしたのですが、考え直してみるとやっぱり分からなくなってきました。
Re:Apple (スコア:1)
いや、私の疑問の発端は
って所であり、PostgreSQLを使うのを想定した、MySQLを使うことを考えてないプログラムでも、グレーだMySQLの商用ライセンス購入するかGPL化しろなどと言われれるのが納得できないって所なんですけど。
それを
> MySQLを利用したシステムを開発/販売でもしていて
> 商用ライセンスを取得して無くて自己保身のために必死になっている
と取られるとすごく心外です。
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:Apple (スコア:1)
私の主張は、
「インタプリタ処理系上のGPLなライブラリを利用する可能性がある」なら、「インタプリタプログラムもGPL化する」
というのはおかしいだろう、ということです。
「GPLなライブラリを利用する可能性があるなら」って主張の前では、MySQLにFOSS 除外規定があろうと関係ありません。
・PostgreSQL用のインタプリタプログラムでも、MySQLと接続する可能性があるからGPL化しろ
・MySQLのFOSS除外規定に該当するインタプリタプログラムでも、純GPLなMySQLと接続する可能性があるからGPL化しろ
どちらも主張の流れとしては同列かと。前者を肯定するなら後者も成立します。
Re:Apple (スコア:1)
えっと、話の流れがわかりにくくてすみません。
私の主張は
ということですが、
そこに至るまでの、私の主張する論理の流れを言い換えましょう。
・「MySQLのFOSS除外規定」は正しく動作し、「MySQLにべったり依存した、GPLではないオープンソースライセンスに基づくプログラム」は存在しえる
のであれば、すなわち
・「MySQLのFOSS除外規定に該当するインタプリタプログラムでも、純GPLなMySQLと接続する可能性があるからGPL化しろ」という主張は成立しない
ということであり、同様にして
・「PostgreSQLを前提にしたプログラムでも、GPLなライブラリをリンクしたインタプリターを通してMySQLに接続できる可能性があるなら、グレーである」という主張は成立しない
し、さらに一般化するなら
・「インタプリタ処理系上のGPLなライブラリを利用する可能性がある」なら、「インタプリタプログラムもGPL化する」という主張は成立しない
ということになる。と。
つまり、FOSS除外規定の話は、私の意見を補強するものであって、私の意見に反するものではありません。
(それを、逆の流れで元の命題を否定しようとしてたんですが、わかりにくかったようで…すみません。)
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:Apple (スコア:1)
すみません、なぜ「ここからおかしい」と言えるのか私にはさっぱり分かりません。
PHP処理系は、MySQLクライアントライブラリとして「GPLなlibmysqlclientをリンクしている場合もあれば、商用ライセンスのlibmysqlclientやPHPライセンスのmysqlndといった非GPLのライブラリをリンクしている場合もある」というのはおかしくありませんよね。
そうであれば、「PHPのスクリプト部分だけを(処理系は含めずに)頒布する場合」には、
頒布したプログラムは、頒布段階では「GPLか非GPLかどちらのライブラリとリンクして動作するかわからない」というのは当然のことだと思うのですが、
この考えはどうおかしいのか、教えて頂けませんか。
Re:Apple (スコア:1)
その通りです。話の発端がインタプリタについての話ですから、それに沿って論じてきましたが、コンパイル言語で書かれたプログラムでも、
・バイナリ頒布を行わずにソース頒布のみを行う
・使用しているライブラリに、GPLと非GPLの両方の実装がある
・頒布者は、利用者がどちらのライブラリでバイナリを作成するか想定できない
場合には、同様の問題は起きると思います。
ちょっとそういう「ライブラリ」の具体例は心当たりがありませんが。
私の話の発端はPostgreSQL前提で作ってたプログラムを、「MySQLドライバと結合される場合もあるからGPLにしないとダメだ」なんて言われるとすごく困りもの [srad.jp]だという所にあります。どうして使いもしないMySQLのライセンスについて調べなきゃいけないんですか?
GPL一般論として「処理系がGPLなライブラリをリンクする可能性があるならGPL化しろ」というのであれば、開発側の見知らぬライブラリが関わってくる可能性があります。
今回はMySQLという分かりやすい物が出てきてますから権利者に問い合わせるという解決手段が取れますが、いつもそんなことができるとはかぎりません。
インタプリタプログラムのみの頒布の場合、例えば、ドキュメントに「mysqlndをリンクしたPHPで実行してください」とでも書いておけばOKとか言うことですか?
それで言いんだったら最初からこんなに話が延びなかったとういか、
上述のようなPostgreSQL接続用プログラムだって「PostgreSQLに接続して使ってください」とでも書いておけばOKってことになりますね。それで話はだいたい終わるんですが…
(それでも、開発者がGPLでないと想定していてかつドキュメントで言及していないライブラリに、実際には開発者の知らないところでGPLな別実装が存在するって可能性はありますね。かといって、使用しているライブラリ全てを列挙しろというのは難しいかと。)
ORACLEの意図は？ (スコア:0)
長引くにつれ、これから手に入れるモノの価値が減じていくのなら
普通は事を急ぎますよね。
ORACLEは、ただSunを弱体化させたかったのでしょうか。
Re:ORACLEの意図は？ (スコア:1, 興味深い)
http://enterprise.watch.impress.co.jp/docs/series/infostand/20091026_3... [impress.co.jp]
なんかスッキリしない理由ですよね。
Re:ORACLEの意図は？ (スコア:1)
http://www.oracle.com/lang/jp/corporate/pricing/doc/Processor_Core_Factor_Table_jp.pdf
IBM機(pSeries)にOracleを搭載するとライセンスが高額になる→サーバもSunに替えようという誘導の一環なのかもしれません。
Re: (スコア:0)
欧州何様 (スコア:0)
アメリカの会社がアメリカの会社を買うのにEUの許しが要るとは、不勉強にして知りませんでした。
Re: (スコア:0)
EUでも商売やってるからな。
合併そのものは（欧州の子会社等を取っ払うんなら）自由だが、その後独占を理由にEU市場から閉め出される可能性もあるわけで、欧州委員会の認可が出ないのに合併なんぞは無理。
まあ別に欧州に限ったことではなく、大きな市場を持っている国の公取委（のようなもの）の承認は普通取り付ける。
Re: (スコア:0)
Re: (スコア:0)
それだと、中国さまからクレームついたりしていたような気もします
まぁわが国が、クレームつけることは滅多にないわけですが。
Re:欧州何様 (スコア:1, 興味深い)
クレームを付けたら、日本市場なんてチッポケな市場から撤退するだけかもよ。
＃市場が小さいくて閉鎖的だし、英語読めないからマニュアルも全部翻訳しなきゃいけないし、
＃細かいことを気にするし。なにより日本で売れる商品は世界で売れない。(例外アリ)
＃そりゃあノキアとか撤退するわなあ。
Re: (スコア:0)
Re: (スコア:0)
>そりゃあノキアとか撤退するわなあ。
Appleは出来てるのにねぇ。
まあNokiaは業績が落ち込んでいるらしく、Appleを訴えたりしているけど
UKの記事 [timesonline.co.uk]では「この訴訟は危険な賭け」とも言われている。
>Lawyers believe that Nokia is playing a dangerous game. Robin Fry, a partner in Beachcroft, said: “This is a poker game in which there is a risk that Nokia’s patents could be ruled invalid. It’s a
グローバル企業ゆえ (スコア:0)
別にEUが何言おうと合併そのものはできますよ。
ただし商売している主要各国の公取でOKもらわないと、最悪そこの市場から追い出されますので大打撃なワケですよ。
(主要各国といっても大国とか先進国ではなく、その企業にとってそこそこ売り上げがでかい地域を指す)
それは合併の効果が相殺されてあまりあるでしょう？
# 個人的にはひとつにならなくとも、プラットフォーム担当子会社化して終了でいい気がするよ。
おしえてデルポイのエロい巫女 (スコア:0)
>買収計画の行く末が不透明
「汝自身を知れ」
「過剰の中の無」
「誓約と破滅は紙一重」
―――デルポイの戒め [wikipedia.org]
Re:おしえてデルポイのエロい巫女 (スコア:2, おもしろおかしい)
「収入に見合った額のご利用を」
「ご利用は計画的に」
「無理の無いご返済プランで」
…サラ金のCMに見えてくるのは私が疲れてるからでしょうか。