アカウント名:
パスワード:
KDEがライセンス的に譲歩してくれない限り身を引くとは思えませんが(w
# それなりに譲歩してるような気はするけどRSM的には # まだまだなんでしょうねぇ
QTはLGPLじゃないので、商用ソフトはライセンスを払ってクローズソースにする必要がある。
クローズドのKDE向けソフトはQTを使わないか(KDE向けに書かない)、
ちなみに、KDEのkdelibsは基本的にLGPLです。 #完全に調べたわけではないので、"基本的に"としています。 なので、Safariではkdelibsに含まれるKHTMLを使うことが 可能だったわけです。まあ、kdelibs(の一部)のQtからの 切り離しなんて普通の企業はやらないし、できないと思いますが。 また、開発する際に、QtのGPLとkdelibsのLGPLとはどのように 影響するのかというのは、GPLとLGPLについてあまり詳しくないので 分かりません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
GNOMEもうだめぽ (スコア:1, 興味深い)
いいのに。。。
Re:GNOMEもうだめぽ (スコア:1, 興味深い)
KDEがライセンス的に譲歩してくれない限り身を引くとは思えませんが(w
# それなりに譲歩してるような気はするけどRSM的には
# まだまだなんでしょうねぇ
Re:GNOMEもうだめぽ (スコア:0)
初耳なんですけれども。
#RSMってなに? RMSの間違い?
Re:GNOMEもうだめぽ (スコア:2, 参考になる)
QTが基本ライブラリなのに、LGPLじゃなくて、GPLって部分でしょうね。
クローズドのKDE向けソフトはQTを使わないか(KDE向けに書かない)、または QTライセンスを選んでライセンス料を支払うって選択になるわけです。
QTのLINUX以外の版のライセンスはどうなんでしょう?
WINDOWS版QTは全然フリーじゃないって思ってましたけど。
LINUX専用のフリーソフトウエアを作る人達には問題はないでしょうが、
QTはLGPLじゃないので、商用ソフトはライセンスを払ってクローズソースにする必要がある。
作ったソフトをWIN
Re:GNOMEもうだめぽ (スコア:0)
ちょっと表現が間違っているかな。「クローズソースにする場合には、
ライセンスの取得が必要である」ってことですね。
別にGPLなソフトは商用ソフトになれないわけではないので。
うーん、意味がいまいちわかんないですね。
KDE向けなのにKDE向けに書かないっていうのは・・・。
ちなみに、KDEのkdelibsは基本的にLGPLです。
#完全に調べたわけではないので、"基本的に"としています。
なので、Safariではkdelibsに含まれるKHTMLを使うことが
可能だったわけです。まあ、kdelibs(の一部)のQtからの
切り離しなんて普通の企業はやらないし、できないと思いますが。
また、開発する際に、QtのGPLとkdelibsのLGPLとはどのように
影響するのかというのは、GPLとLGPLについてあまり詳しくないので
分かりません。
Re:GNOMEもうだめぽ (スコア:1)
> うーん、意味がいまいちわかんないですね。
はい、ライセンス料を払わずに『ソース不公開のKDE向けのソフト』を配付することは出来ないってことですが、冗談で上の表現を使いました。笑えなかったらゴメン。
>また、開発する際に、QtのGPLとkdelibsのLGPLとはどのように影響するのか
kdelibs は Qtにリンクして使う限り、GPL/Qtライセンスに留まると思います。LGPLとしての扱いはできないと思います。
『ソースを閉じる』/『ライセンス料を払わない』で済ますためには、アップルのしたように、Qtとのリンクを切ることしかないと思います。(または、GPLの Qt/X11を MacOSXに移植する?)
実は、『QtのライセンスをGPLでよしとする』のか、『LGPLになるまでフリーソフトウエアのベースに使うべきではない』とするのか、議論が起きないのを不思議に思っていました。
企業の戦略としては、『LGPLをベースライブラリに適用しているGnome/GTKを可能なかぎり採用する』のは、ごく当然の選択だと思います。