2007年12月29日土曜日

ギークとスーツの間に横たわる深い溝

埋まらない...絶対に。

日本のSIerの構造ではギークは評価されず、スーツが評価される
ばかり。SIerの経営者の頭の中では仕様書が完成した時点で
システムは完成したも同然という誤った認識が蔓延っている。
ギークを仕様書の転記屋くらいにしか認識していないのである。

SIerのスーツは頭の中の穴だらけの仕様を仕様書におとし、
そのツケを全てギークにまわすことが多いにも関わらずである。
スーツの多くは穴だらけの仕様による不具合を全てギークのせい
にして自分に非がないかのように振舞う。

SIerのスーツは「ユーザ」を持ち出して自分に都合の
よい方便でギークを納得させようとする。
そこで、スーツの言い分に騙されるようでは"お先、真暗"。

SIerのスーツにとって、建前上お客さんは大事、実際は
ユーザ第一と言いながら、ユーザからの対価(=自分への対価)
が第一。

スーツはスーツの論理で動いていて、ギークを理解しよう
とはしない、理解しているふりをするのみである。
ギークに自分の論理を押し付けて、上手く使おうという
スーツが大半。

スーツはギークがいなければ何もできない、仕様があっても
優秀な実装者がいなくてはシステムは完成しないが、
ギークを自分と対等だと思っているスーツは日本のSIerには
いない。

真のギークを目指すなら、SIerでスーツと仕事をするあるいは
し続けるのは百害あって一利なし、時間の無駄。

2007年12月23日日曜日

InstantRails

http://d.hatena.ne.jp/asip/20071223#1270772948

最近のJBoss

JBoss5 beta3がでた。
JBoss MicroContainer(MC)2.0を積んだ最初のリリース?
JBossも初期のJBoss SeamにDIコンテナとしてJBoss MCを組み込んでいたこと
もあり、JBoss MCを最初の頃、Spring etcと同じような汎用DIコンテナの
一種かと思っていた。
Google Guiceの登場後、JBoss MCの位置づけが変わった。
WebBeans仕様をJBossがJCPに提案し、SeamをWebBeans仕様のRI
(参照実装)と位置づけ、WebBeans=DIコンテナの共通API、
Seam=WebBeans対応のDIコンテナという図式にした。
JBossはこの位置づけ変更に伴い、JBoss MCを汎用DIコンテナでは
なく、JBoss AS用のサービス統合基盤と(GeronimoのGBeanと同じ位置
づけに)位置づけし直した。

JBossはJBossAS5に着手した辺りから、プロダクト間での共通機能の
切り出し、ライブラリ化を加速している。DIコンテナ等のプロダクト
レベルでの傾倒ではなく、もっと低レベルの層に重きを置いている
印象。低レベル層にコミットすることでプロダクトの底上げを図って
いるように感じる。

2007年11月11日日曜日

最近の狛犬もどきのカリスマ

また、JPAやHibernateの粗を根拠に自家製プロダクト、マンセーやってます。
S*Daoの時と同じ手法でS*JDBCのセールストークをやってます、進歩なし。

そもそもS*JDBCはJDBC&SQLの単純なラッパ以外の何物でもない。
S*JDBCの比較対象がJPAやHibernateというのがそもそもおかしすぎる。
狛犬もどきのカリスマがあげているJPAやHibernateの粗、JPAやHibernate
を業務システムで採用した経験のあるまともなエンジニアならほぼ誰でも
知ってます。今更、他人から講釈を受けるような類の話でもない。
狛犬もどきのカリスマは誰に対して講釈をたれているんだろうか?謎だ。

JDBC&SQLの単純なラッパとして実装されたライブラリならどれでも
狛犬もどきのカリスマが実施しているようなベンチマークでは性能的に
JPAやHibernateに難なく勝てる。
相手の弱点をあげてそれに対する自家製プロダクトの優位性を主張する
セールストークをやってる時点で底が浅いのが丸わかり。
相手の短所は口撃しつつ、相手の長所は自家製プロダクトに組み込んでるのが
笑える。

Ruby界隈でも話題になってるけど、最近は自動翻訳機能を実装したWEB上の
サービスがある。日本語で書いてるから外人には読まれていないと思って
書いていると自動翻訳を利用して読まれてたりすることがあるらしい。
現にSunのエンジニアがブログに「日本語で書いた記事を同僚の外人
エンジニアが読んで、ショックを受けた的な連絡があった」と書いて
いたりする。

上記のようなセールストークをブログ上で展開しているのを外人が読んでいて
冷めた目で見てたりする可能性なんて考えてもいないんだろうが。

そういえば、Springに対する同様のセールストークを狛犬もどきのカリスマは
「Rod Jhonsonとの対談(?)」で詫びたらしいが、相手がどう思っているのかは
謎。アウトオブ眼中かもしれないが,,,。
(同じようなことを以前書いたような...。)

2007年11月10日土曜日

最近より少し前の狛犬もどきのカリスマ

「舶来信仰を打破するためにまず日本で頑張ります!」ってのが笑える。
確か去年のJavaOneに気炎を吐いて乗り込んだはいいものの聴衆はほとんど
米在住の日本人というオチでおわったはず。知名度が全くない
状態で乗り込んだら絶対そうなる罠。知名度がないから、BOF(Bird Of Feather)
という扱い。それに気づかずに乗り込んだこと自体がアレだな。

以前にも書いた(後、狛犬もどきの中の人がウザかったので消した)けど、
欧米で成功するためには草の根からの浸透が必須。
狛犬もどきの"いきなりメジャー、一発逆転満塁ホームラン"的なアプローチは
時間の無駄。件のカリスマは「欧米の著名エンジニアとの対談」とか「JavaOne
等イベントへの参加」を通して一足飛びに世界進出という路線が好きなだけ。
狛犬もどきの世界進出に関するこれまでの動向を整理してみると"地道な活動"
をする気がないことがよくわかる。
ありもしないレールで路線を組んでいる時点で終わってる。

以前、JBossのエンジニアと対談して対談の最後に「一緒に何かやりましょう」
的な別れの挨拶になったらしいけど、JBossからは音沙汰なし。
狛犬もどきのプロダクトにJBossが注目するようなアイデアはなかったんだろう。
そのあと、JBossのGavin King氏はGoogleのGuice開発者と組んでWebBeans
仕様策定中。狛犬もどきのカリスマはアウトオブ眼中。
狛犬もどきのプロダクトはほとんど舶来のアイデアの再実装だし、世界標準に
取り込まれそうなアイデアは何もない。

Rubyは草の根レベルでの浸透に寄与する地道な活動が実を結んで、世界進出
に成功した。いきなりソフトを引っさげて世界進出したわけではなく、英語圏
用のメーリングリスト開設や様々なドキュメントの英訳等の地道な活動を何年
も続けてきた結果、世界でメジャーになってきている。Rubyが凄いソフトウェア
だから世界進出に成功したわけではない。

「なぜRubyが世界進出に成功したかを正しく分析できていない」時点で
狛犬もどきの世界進出成功はありえない。

世界進出どころか日本で高普及率も難しい。日本は大手SIを主軸とした下請
構造が幅を利かせてるから、大手SIからコミットされない限り、日本のSI業界
での大ブレークは難しい。
大手SIは世界標準が好きだから自社製品以外の独自仕様タップリの国産
プロダクトは世界で認められでもしない限り、採用しないと考えられる。
OSSかどうかなんてのは採用プロダクトの選定にあまり関係しない。
どちらかといえば世界市場での採用実績のほうを優先する、採用実績が
豊富ということはそれだけ利用されているということであり、その結果
ある程度のレベルまで枯れてきていると判断できるから。イベント等を
通じて名だけが知れ渡っているような知名度は意味がない。
大手SIにとって商用サポートがあり、高度な専門知識を持つエンジニアが終日
対応してくれる環境が望ましいのは当たり前。
以前にも書いたが「OSSなんだからソースを読んで自分で直せ」なんてのは
論外。大手SIの業務システム開発部門に"フレームワークのソースコードを
解析して難題を適切に解決できる"クラスのエンジニアはほとんどいない。
そのクラスのエンジニアが大手SIの業務システム開発部門にゴロゴロいると
いう想定は無意味。
OSSは、Redhat、JBoss、MySQL etcのように専門の会社の戦略としてOSSを
推進してでもいない限り、開発者が分散していることもあり、上記の
ようなレベルのサポートが提供されるケースはない。だから、世界市場
での採用実績がより重視される。

「"世界市場での採用実績"の重視傾向」を"舶来信仰"と勘違いしている
時点で狛犬もどきのカリスマは情報分析能力に欠けていると言わざるを
えない。
"舶来信仰"なんていう日本のSI業界にありもしない偶像に挑戦している
時点で終わってる。
ありもしない偶像に挑むカリスマ(?)を応援する狛犬もどき崇拝者は、水車を
怪物と勘違いして挑みかかるドンキホーテを応援するセバスチャン(?)に
重なる。

そんなに知名度のない時点で非営利法人なんて立ち上げてる時点でかなりアレ
だが...日本国内に留まっていてもジリ貧。

2007年10月27日土曜日

最近の狛犬もどきのカリスマ

今度はJPA仮想敵で俺達サイコーやってます。
「*2JDBC」のセールストークでマーチン・ファウラーの
「流れるようなインターフェイス」引用してますが、JPAの
インターフェイスをパクっている時点で既に論理的に破綻してます。
JPAベースで流れるようなインターフェイスを実現するラッパーは作成
可能であり、流暢なインターフェイスを実装していることが「*2JDBC」
のセールスポイントにならないことは明らか。
CoC(規約重視)マンセーで使った偽太陽etcがユーザ層の拡大に失敗している
からCoCやめてみました、それだけ。

特定のDIコンテナに統合されている時点で「*2JDBC」は個人的には利用対象
外、モノは悪くないとは思うが狛犬もどき2に依存する気にはなれない。
"*2JDBC"は"*2DAO"の発展型以外の何ものでもないというのが感想。


"CoCの本質は最低限の規約で最大限の効果を得る"ことにあり、規約でがんじ
がらめにしている時点でCoCを語る資格はない。
偽太陽をみるとわかると思うが「狛犬もどき」はCoCの本質を理解していない。
例えば、偽太陽の属性の扱いまわり、実装で楽をするためにあんな変な規約
を導入しているとしか思えない。
Click等の軽量WEBフレームワークマンセーな人でも偽太陽マンセーな人は
少なく、狛犬もどきの信者だけが偽太陽マンセー。

「*2DAO」についても同様、テーブルのリレーションを変数名で表現する規約が
気持悪かった、「*2JDBC」になってその規約がなくなったのは当然の帰結?...。

狛犬もどきの失敗は「狛犬もどき2」の中で閉じた世界を構築していること。
「狛犬もどき2」中心で閉じた独自の世界を構築してるから、他所からは
異質にみえ段階的な移行も不可能だから既存の資産を持つエンジニアは
ほとんど移行してこない。
Springとは設計・挙動が異なると言いながら移行パスを用意していないんだから
ほとんど誰もSpringから移行してこない罠。
Spring2.xはSpring1.xからの移行パスを用意してSpring1.xのユーザのほとんど
を円滑にSpringに囲い込んだ...。
狛犬もどき2はSpring1.xの発展系の一つとでもいうべきものであり、
"進化(革新)系"とはよべないシロモノ。

外側からみると、狛犬もどきの信者はハイレベルとはいえないと感じる。
「"*2JDBC"が流れるようなインターフェイスを実装しているからそのような
インターフェイスでないJPAより優れている」等のセールストークに騙される
時点でおわってる。
「狛犬もどき」自体の開発者のうちカリスマ他数名はハイレベル(?)なんだろうが...。
新しいプロダクトをリリースする度に行われる「セールストーク」の質の低さには
ウンザリ。

「JPAがその仕様(実装?)の特性上、扱いづらい側面があるので、そのような
特性のない*2JDBCのほうが優れている」というセールストークも質が低い...。
"JPAが万能でない"ことは明らかなんだから、その特性が気持悪い人間は
そもそも初めから使わない。現時点で実業務でJPAを利用している人間は
JPAの長所短所を理解したうえでJPAを選択していると思われ、実業務で
使っている人間がその長所短所を理解したうえで利用していることを
想定していないセールストークは"質が低い"と言わざるをえない。

狛犬もどきからは「お前たちは俺たちよりレベル低いんだから俺たちの作った
プロダクトを有難く黙って使ってろ」的な匂いを感じる。
狛犬もどきの開発者は外のエンジニアのうち、自分たちと同列ではなく自分たち
よりレベルが低いエンジニアをターゲットにしている、あるいは外のエンジニア
は須らく自分たちよりレベルが低いと思っているとしかその文面(そのカリスマが
綴る文章)からは思えない。少なくとも外部のエンジニアを自分たちと対等の存在
であるとは思っていないと感じる。

2007年10月22日月曜日

最近のJBoss

Watchしていない間にJBoss5の開発が着々と進行。
JBoss5はBeta3に向け開発中。
JBoss MC(Micro Container)2.0.0はCR1、JBoss AOP2.0.0はbeta2を開発中。

除夜の鐘がなる前にリリースになる可能性も。

2007年10月14日日曜日

W3C XML Schemaの終焉?

W3C Technical Reports and Publicationsから
XML Schema 1.1 Part 1: Structuresのワーキングドラフトが消え、
W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structuresの最終ワーキングドラフトが出現。
XML Schema 1.1 Part 2: Datatypesの最終ワーキングドラフトはそのまま。
W3C XML Schema1.1はW3C XML Schema Definition Language (XSDL) 1.1
と改名され、存続の模様。
W3C XML Schema Definition Language (XSDL) 1.1 Part 1: Structures、
印刷すると170ページ近く無駄にデカイ。

2007年10月13日土曜日

ブラウザのCPU利用率 on Windows

Safari3>>IE6>>Firefox2
(低い順)
...書きかけ。

Firefox2、CPU利用率高すぎ、Mobile Firefox開発での改善に期待。
SafariはiPhone,iPod Touchへの組み込みが功を奏した模様?

ORの代わりに正規表現 その2

http://d.hatena.ne.jp/asip/20071013#1270830802

2007年7月29日日曜日

冷蔵庫、ゆく

新しい冷蔵庫を購入。冷蔵庫、高い...値段が。懐、寒っ。
製氷、水をタンクに入れるだけで自動的にやってくれるよ、
10万円超えるだけのことはあるかも...。

2007年7月21日土曜日

最近の某OSSプロジェクトのカリスマ(?)

RubyやRoRを(仮想?)敵として設定している模様。Matz氏の書いた文章に
くいついているが、Matz氏およびRuby陣営からは全く相手にされていない。
FW作者が言語作者に...DHH氏(RoRの作者)にならまだわかるが。

2007年6月23日土曜日

DLRやSilverlightに胡散臭さを感じる...

M$信奉者は絶賛しているが、M$信奉者以外がどのくらい高評価を下す
だろうか?M$はいつもクロスプラットフォームとは一線を画してきた
というか、クロスプラットフォームという甘い餌をユーザにちらつかせ
つつ、巧妙にWindowsプラットフォームに誘導してきた。
そして、そのての事例には暇がない。
OpenGLとDirectXの融和を謳いつつSGIからシーングラフAPIの技術を
引きだし頓挫に持っていった(?)ファーレンハイト 。FreeBSDへの移植を
謳いつつ、いつの間にかフェードアウトさせた.Net Framework。
M$のクロスプラットフォーム化の囁きの裏にはいつも自社プラット
フォームへの誘導の意図が汲み取れる。
DLRやSilverlightのクロスプラットフォーム性に夢を描くのは止めることを
お勧めする。
その囁きを信じたら馬鹿をみる、のは過去の事例からほぼ確実。

2007年6月10日日曜日

PHP信者とM$信者の類似性

似た匂いを感じる。
「***ならこう設定すればできるのに、他の言語ではできない。」
というときにその環境特有の設定の仕方はわかるが、どのような
原理でそうなるのかはわかっていない人間が多い。
その環境のみで有効な知識で止まっていて、その先はみようとも
しないのである。
PHPにしてもASP(.net)にしてもお手軽な言語ではあるが、言語(環境)
に特化しないマルチなWEBエンジニアを育てるには不向き。

優しさ、易しさ...

優しさや易しさは本人や作った当人が判断するモノではない、普通。
それを判断するのは他人。(作った)本人やそのトリマキが
「優しさや易しさ」を主張しても、他所からみると、優しく"ない"
易しく"ない"ことが往々にしてある。
「優しさや易しさ」を(作った)本人やそのトリマキの尺度でしか
規定していないからこのようになる。万人(初心者?)にとって
どうなのかという視点が抜け落ちているのが何ともいえない。

2007年5月27日日曜日

DIコンテナは最先端の技術なのか?

もはや、DIコンテナは最先端の技術ではないと思う。

個人的にはDIコンテナという範疇の中での瑣末な違いに作者以外が
拘ることが何の得になるのか、さっぱりわからない。

今後10年生き残る技術かと問われれば、10年生き残るかは不明と
答えるし、10年近く生き残る事が決まっているかのごとく書かれた
文章を読めば、疑問符が10個以上、頭の中を飛び回る。

DIコンテナの登場による祭りは世界では過去の出来事にも関わらず、
日本の技術者の一部では未だにお祭り騒ぎが続いているようにみえる。

DI(IoC)という概念自体はDIコンテナが登場する以前から存在し、別段
最新の概念ではない。DIコンテナの登場により脚光を浴びるように
なっただけであり、DIコンテナと共に登場したわけではない。
そのことは1997年刊行1998年改訂のJavaプログラムデザインの中で
既に紹介されていることからも伺える。

ソフトウェア工学の分野では既に存在した概念が数年遅れで世間で
流行し、最新の技術のようにもてはやされるのはありがちなことだとは
思うが、言語仕様の概念でもない精々ミドルウェアの実装概念の一つ
に過ぎない技術の流行が今後何年も続いていくものであるかのように
錯覚しているとすれば、ある種、滑稽ですらある。

DIコンテナはゴールデン・ハンマーでも万能ナイフでもない。

推敲中...つづく?

WEBアプリのUIコンポーネントの潮流

http://d.hatena.ne.jp/asip/20070527#1270773768

2007年5月26日土曜日

GPLでライセンスされたライブラリは商用利用できるのか?

Linuxは何故GPLでありながら商用利用されるのか?は間違いだらけでしたが
書きたかったことはLinuxについてのことではなく、GPLと商用ソフトウェア
の関係についてです。

Linuxはそのライセンスに記述されている例外条項によりその上で動く商用
アプリの開発を可能にしています。
KDE3に関してはQtベースの機能を利用したソフトウェアを開発する場合、例外
条項が存在せず、素のGPLであるため、商用ソフトウェアの開発はまずありえません。

つまり言いたかったことはこうです。
例外条項を設けられていない素のGPLで公開されたライブラリを利用する全て
のソフトウェア(ライブラリを含む)は、GPLで公開される義務があり、例外は
認められないということです。無論、素のGPLで公開されたライブラリを利用する
ソフトウェアがそのソフトウェア独自の例外条項をライセンスに追加することは許可
されていません。

素のGPLでライブラリを公開すれば、ほぼ例外なく商用利用されることを回避
できます。

蛇足となりますが、GlassFishやOpenJDK等Sunの公開するOSSプロダクトでは
ライセンスをGPL+ classpath exception等の例外条項として、それらのライブラリ
を利用するソフトウェアの商用利用を可能にしています。

但し、標準化団体で標準化されたインターフェイスを実装したGPLで公開された
ライブラリを作成したソフトウェア(標準化されたインターフェイスのみを利用)に
同梱した場合、作成したソフトをGPLで公開する必要があるかは議論の余地が
あると思います。

[omake]
KDE4ではFreeDesktop.orgでホストされているD-Bus(on off)という
メッセージバスシステムを用いることでKDEのライブラリ外からのKDEのコア機能
の利用を可能にしています。

[2007/5/27追記]
KDE3に関してはライセンスの見直しが行われ、kdelibs、kdecoreの
一部等Qtが利用されていないソースに関してはGPLを適用しない
方向に進んでいた...いつの間にか。
KDE4は追っていなかったのでわかっていませんでしたが
KDE4において現状におけるKDEのコア機能を利用するGPL
以外のライセンスのアプリが開発しづらい問題等を解決する取り組み
の一環としてkdelibs全体からQtに依存するコードを取り除く方向
に進み、kdelibsにGPLは適用されていないようです。
KDE のコピーライトおよびライセンス問題に関するDebian のスタンス
に書かれている問題全ての解決方法にはならない気がします。

#重箱の隅をつついて喜ぶ人がいるようなので色々と追記・修正。
#商用利用は「プロプライエタリなソフトでの商売」という意味です、
#文脈を辿ればわかることです。1から10まで説明する義務は
#ありません。

#GPLなライブラリを利用したソフトはソースの公開が必須、
#プログラムを書いてそのコードへの対価を得て商売している
#場合にGPLでソースを公開する選択肢はほぼありえないw。
#コードではなくサービスで十分な対価を得られるのは、ほん
#の一握り。コードを公開してサービスで対価を得られるのは
#更にその一握り。業務用システムに限定すれば、ソース公開は
#100%ありえないw。
#サービスで十分な対価を得られる人間は、ミドルウェア・サポート
#等一部のケースを除いて、コード作成時に利用するライブラリに
#関して大騒ぎしないし、拘らない。より便利なモノがないか
#リサーチを欠かさず、スイッチしていく...99%。
#何故なら、コードを書くのが目的ではなく、サービスを作るのが目的
#だから。短期間でサービスを立ち上げられる手段を模索こそすれ、
#コード内で利用する何かに異常に拘ることはない、自分がその作者
#である場合を除いて。
#コード内で利用する何かに異常に拘るグループはサービスを提供
#することで十分な対価を得られる人間からすれば、負け組以外の
#何者でもないだろうと思う。

#重箱の隅をつついて喜んでいる人に一言。
#ここは個人のブログ、思い込みや間違いがあっても別に問題は
#ありませんが何か?思い込みや間違いが気になるなら、
#読まなければいいだけ。読む側が思い込みや間違いを
#チェックするのがWEBでは常識。
#一つの記事を読んで鵜呑みにするのではなく、関連する記事も
#読んで判断すればいいだけ。間違いや思い込みで書かれた文章を
#鵜呑みにするのは読む側の問題。
#指摘されたら(狛犬もどき関連を除いて)修正はしますよ。
#自分が気に入らないからといって、個人のブログの重箱の隅つつき
#を熱心にやって、こちらの評価も下がるかもしれんが、そちらの
#第3者からの評価も下がっていくとは思わんのかいな。
#WEBのブログで一々、一から十まで調査して書くことを他人に強要する
#のはどうかと思うよ、気楽に書いてるブログに何で事前に調査して
#書くなんて面倒臭い手順を加えなくてはならないのか、よくわからん。
#そちらが事前調査を念入りにして書くのはそちらの勝手。
#自分の考えを相手に押し付けようとするところがアレだな。

2007年5月12日土曜日

Linuxは何故GPLでありながら商用利用されるのか?(当たり前のこと)

>勘違い開始---->>
>Linux自体はPOSIX準拠で、Linuxでも利用されているGLIBCはISOやANSIで
>標準化されているCの標準ライブラリを実装しています。
>Linux自体はGPLですが、POSIXやISO Cで標準化されている
>インターフェイスでアプリを記述する限り、そのアプリをGPLで公開する
>必要がないのです。だから、Linuxは広く商用利用されるようになりました。
>もし、Linuxが標準化されていない独自のインターフェイスのみで実装されて
>いたならこんなに広く商用利用されることはなかったでしょう。
>POSIX準拠(UNIXほぼ準拠)であるため、UNIX用に書かれたソフトの大半が
>ほぼそのままLinux上で利用できたこともLinuxの商用利用の拡大に繋がり
>ました。
>>--勘違い終了

間違い①
GLIBCはLGPL。GPLだとばかり思い込んでました。
GPLの場合には、ダイナミックリンクする場合もGPLに従う必要があります。
間違い②
Linuxの場合、基本的にはGPLですが、例外条項が存在し、 通常のシステム
コールを利用するユーザプログラムについてはソースをGPLで開示する必要
はない。デバイスドライバは別。

詳しくはこちら

LinuxやGlibcに関する上記の記述は以上の勘違いから上の文書は全くの
間違いです。POSIXやISO Cで標準化されているインターフェイスでソフト
を記述する限り、そのソフトをGPLで公開する必要がないという一文について
は間違いではないと思います。GPLのライセンス上はライセンス違反だったと
しても。

正しくはLinuxは基本的にはGPLだが、例外条項により、通常のシステム
コールを利用するユーザプログラムについてはソースをGPLで開示する必要
がないことがLinuxが広く商用利用される要因の一つであるとなります。

KDE3のGUIライブラリを利用した商用ソフトが存在しません。KDE3の基盤で
あるQtはGPLと商用ライセンスの2重ライセンスです。Qtの開発元である
Trolltechはソース公開必須のGPLでQtを公開しつつ、商用ライセンスで
収益を上げています。
蛇足になりますが、Qtは独自インターフェイスです。
大手LinuxベンダがGnomeを採用する傾向にあるのは
KDE3のGUIライブラリでGUIベースのソフトを開発する場合、必然的に
QtベースとなりGPL適用の義務が発生するため、KDE3のGUIライブラリ
を利用した商用GUIソフトをユーザが開発することがほぼ不可能だからです。

#ここに書いてあることはLinuxがGPLでありながら商用利用される理由の一つで
#あり、全てではありません。

#狛犬もどき厨向けに書いてみた。
#2007/5/26追記
#まぁ、個人的には思い込みを修正できたので「odz氏、ありがとう」な心境。
#http://d.hatena.ne.jp/odz/20070512/1178994457

#もともと「GPLであるLinuxが商用利用できるから、GPLも商用利用できる」
#みたいに思っている狛犬もどき厨がいるようなので書いてみたネタ。

#「LinuxはGPLだが、標準化されたインターフェイスを実装しているので
#商用利用できる」が本当は「Linuxは基本的にはGPLだが、例外条項を
#設けているので商用利用できる」だったのは本来(裏)の主旨からすれば
#枝葉末節の間違い。
#枝葉末節に間違いはあったものの、この文章を書いた本来の目的は
#果たしているので問題なし。

#「素のGPLでライセンスされたライブラリを利用するプログラムはGPLで
#配布する必要がある義務を免れないので、そのライブラリの商用利用は
#まずありえない」というこの文章の本来(裏)の趣旨は損なっていない。

#(狛犬もどき関連を除いては)思い込みを交えて文章を書かないように気を
#つけます。

#2007/5/27追記
#一部の文章を削除。