GPL/LGPL等ライセンスとゲーム製作

**名無しさん＠お腹いっぱい。** · 01/11/15 18:56

GPLやLGPLなどのライセンスとゲーム製作のかかわりについて。

GPL http://www.gnu.org/copyleft/copyleft.ja.html#translations
LGPL http://www.debian.or.jp/~mhatta/lesser.ja.txt

**名無しさん＠お腹いっぱい。** · 01/11/19 10:07

>>43
いいと思う。
加えれば、オンラインの場合、「ソースを配る」ってのは
「同じ場所に置いておく」ってのも含まれる。

2.b)について。ライブラリのソースを配る必要はある。
(これは、「自分のソースがウンヌン」以前に、GPL/LGPLな
ソフト等を配る際に必須)

あと、GPL/LGPLの重要なメリットは、
「使用者は、自由に使うことができる」2次配布さえしなければ、商用利用がどーの、とか、同時使用は
何台まで、だとか、リバースエンジニアリングするな、とかの
制限は一切なし。

もっとも、使う側のメリットだけどね。

**名無しさん＠お腹いっぱい。** · 01/11/19 16:16

えー、しばらくあれこれ調べまくってました。頭遺体（ＴＴ）
も少しｷﾞﾓｰﾝに付き合って欲しいなりです。LGPLの第 6 節の

>ただしその場合、あなたの条件は顧客自身の利用のための著作物の
>変更を許可し、またそのような変更をデバッグするための
>リバースエンジニアリングを許可していなければならない。

これは静的リンク、動的リンクいずれにも適用されるんですよね？
さらに第 6 節のaとc、

>ユーザが『ライブラリ』を変更した後に再リンクして、変更された
>『ライブラリ』を含む変更された実行形式を作成できるようにする

この辺、ユーザがライブラリを差し替えられるようにするための条項なので
そういうことが不可能な家庭用ゲーム機では
（LGPLのライブラリは）使えないという解釈が
あるみたいなんですが、実際のところどうなんでしょう。

あと>>40の疑問も依然としてあるです。
たぶんアーカイブに含めないといけないんだろうなとは思いますが。

**名無しさん＠お腹いっぱい。** · 01/11/19 18:47

私、マルチプラットフォームで動くソフトを作りたいのですが
フリーで公開するにしても自前のソースをGPLに感染させたくなかったので、
>>20も述べられてるAllegroを使っております。
（ただ、厨房なんでVisualCで使うために３日かかった・・・
　解説サイトも見つからない・・・フォント上手く使えん・・・鬱）

でもやっぱり、妙な制約の無いライセンス使ってたほうが、幸せになれるかな。

38 · 01/11/19 21:01

>>39
この「再配布可能ファイル」ってのは、「お客様」(=開発者)による
再配布ってことですよね?
つまり、プログラムの開発者自身による配布についての権利であって、
これは納得してます。

で、疑問なのは、自分の作ったプログラムの「エンドユーザー」の権利です。
このプログラムはもちろんBorlandのライブラリをリンクしているわけで、
そうすると、エンドユーザーが再配布したり、DLLを開発に利用したりすると
ライセンス違反になるの? OBJやLIBならOKなの? とか思ったわけです。

**名無しさん＠お腹いっぱい。** · 01/11/19 22:13

>>47
GPLとは話が逸れるのでsageるね。

「再配布可能ファイル」というのは動的にランタイムをリンクするアプリケーションを配布する時に
添付する dll、bpl、 jpn ファイルなど（及び必要ならばそれらに関するドキュメント）のこと。
あとInstallShieldとか。
で、これらをエンドユーザに再配布させちゃいけませんよ。という事。

ライブラリが静的にリンクされた単独アプリケーションであれば、そのプログラムをエンドユーザが
再配布できるかは開発者が決定できる…であってるかな？
自分で開発したDLLもOBJもLIBも同様のはず。

38 · 01/11/20 03:16

39さん48さんありがと
別に悩むようなことでもないのか...

**名無しさん＠お腹いっぱい。** · 01/11/21 22:36

>>45
遅レスすまん

リバースエンジニアリングは、静的動的かかわらず許さないといけない
みたいね。
(プロテクトクラッキングはどーなるんだ？リバースエンジニアリングとは
ちゃうか。)

> 実際のところどうなんでしょう。
これは正直、だれも答えられないと思う。
っていうのも、GPL自体が対象となった訴訟の類が(知る限りは)ないから。
(もしあるのなら、教えて～)
意図する「ゲーム機でのLGPLの適用」ってのが、どういう場合かちょっと
読みとれないよ。
ただ、家庭用ゲーム機であっても、エミュレータの類が不可能ではない
わけだし、PS2やドリキャスでBSDやらLinuxやらが動く時代に、
「ゲーム機だから」って特別扱いするのは、あまり意味がないような
気はするね。

>>40の場合、(LGPLな)ライブラリのオブジェクトを自分がソースから
コンパイルして配るなら、とうぜんソースも必要。

でも、ふつーはライブラリのオブジェクトが置いてあるサイトの
案内をREADMEで書いておく、って話じゃないの？
そういう形で自分のソフト配ったことないから、事情はよくわからないん
だけど、問題を感じるなら、それを避けて通ればいいだけの話。
道は一本だけじゃないしね。
(ってわけで、>>26だけ知っていればいい。という話になる)

いままでいろんなフリーソフトのライセンスみているけど、
2次配布に対して制限が多いものって、少なくないよ。
注意してね。

**名無しさん＠お腹いっぱい。** · 01/11/22 00:30

LGPLも結局はオプソに全面的に陶酔しちゃってる人以外にはまだ使いにくいって感じ?
少なくともシャアな人は使わない方が無難…と

**名無しさん＠お腹いっぱい。** · 01/11/22 02:45

陶酔とか言われてもオプソでしかプログラム書いたことないからなあ。
趣味人ゆえ。GPLじゃなくてBSDLにしてるけどね。

**名無しさん＠お腹いっぱい。** · 01/11/22 08:56

問題は、オープンにしちゃいけない（というかライセンス上できない
ものと一緒に使用した場合なんだよね・・・。

**名無しさん＠お腹いっぱい。** · 01/11/22 17:26

一緒に使えるようにLGPLがあるんだけど胡散臭くて使いたくないって感じ？

**名無しさん＠お腹いっぱい。** · 01/11/22 17:47

GPL なソフトのサポートで商売しようとしていた会社も、殆どが上手く
逝ってないみたいだし、GPLって理想的過ぎて、ゴタゴタな現実には
対応できない場合が多いよね。

>20　にあるAllegro のライセンス条件カッコ良すぎ。

**名無しさん＠お腹いっぱい。** · 01/11/22 21:56

Allegroのライセンス意訳してﾐﾀｰﾘ
ドキュメントとか見る限り、実際はもっとくだけた感じだと思います。

> Allegroはギフトウェアです。
> それは多くの人々の協力で作られ、あなたに贈り物として無料で与えられます。
> あなたはそれをお好みのあらゆる方法で使用し、改変し、再配布し、
> 広くハックすることができ、私たちに何かお返しをする義務はありません。
>
> けれども、もしあなたがこの製品を気に入れば、あなたはAllegroのコミュニティに
> 感謝のお返しをすることが奨励されます。それは例えばアドオン・パッケージを
> 書いたり、有用なバグレポートを提供したり、ライブラリを改良したり、
> もしくは単にあなたのプログラムのソースコードを公開し
> 他の人々がそれらから学べるようにすることが挙げられるでしょう。
>
> もしあなたがこのコードの一部を再配布したり、それを使ってゲームを作ったとき、
> クレジットのどこかでAllegroについて言及してもらえればするらしいですが、
> あなたはそうすることを要求されているわけではありません。
> 私たちは、あなたが私たちの気前のよさを踏みにじらないことを信じます。

56 · 01/11/22 21:57

ギャース！どうしてこんなしょぼいミスをするのか。
s/するらしい/すばらしい/

**名前は開発中のものです。** · 01/11/22 23:34

>>55
っつっても、実際問題、オープンじゃないライセンスなら
ゴタゴタしないかってのも疑問だけどなー

>>56
これ見て思ったんだけど、ストールマンがGNUをつくったのは、
(そして、あんなに窮屈なGPLを作ったのは)
まさに「気前のよさを踏みにじられた」からだってことは、
絶対にわすれちゃいけないよね。

**名前は開発中のものです。** · 01/11/23 00:55

ま、モジラのソースとIEコンポーネント、
ブラウザを作るときにどちらが使いやすく役に立つか、
を考えて見れば答えは見えてくるさ（ｗ

**名前は開発中のものです。** · 01/11/23 01:29

MozillaすごいよねマルチプラットフォームでMozillaベースのアプリとか作れるし

**名前は開発中のものです。** · 01/11/23 02:44

>>59
IEコンポーネントって、ブラウザのインターフェースだけを
作る時には有効なんだけどねー。
やっぱブラウザ自作するには、ソースみれないと使えねーよな。

**名前は開発中のものです。** · 01/11/23 09:58

てゆーか、Allegroもオープンソースなんだけどな。

**名前は開発中のものです。** · 01/11/24 04:21

>>61はブラウザ作ったことない、に一票。

**名前は開発中のものです。** · 01/11/24 12:05

いろいろなIEコンポーネントを使ったブラウザがまともに
動いている現状をみれば、オープンソースでないIEが
そのような用途においてさほど使いづらい訳ではないのかな。

問題はその一歩先に踏み込むばあいだね。完全にエンジンを
本当の意味で「組み込む」場合とか。

**名前は開発中のものです。** · 01/11/24 16:45

本当の意味で「組み込む」ってどういう意味？例きぼん。

**名前は開発中のものです。** · 01/11/24 17:12

64じゃないけど
Mozillaベースのブラウザは結構ある。
特に移植するにはオープンソースじゃないとできないね
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports
http://www.mozilla.org/ports/

Komodo http://www.activestate.com/Products/Komodo/
はMozillaベースのアプリケーション。組み込みっていうよりか
どうつながってるのかはよく知らん。

**名前は開発中のものです。** · 01/11/24 17:54

>>64
だってコンポーネント使うだけならひどく簡単だし。
ブラウザ作ってる気は全くしない。

**名前は開発中のものです。** · 01/11/24 18:23

そもそも、Mozillaをソースからビルドするのに成功した奴、
このスレに居るの？
#漏れ？ダウンロードに挫折したよ。

**名前は開発中のものです。** · 01/11/24 18:24

説明の通りにやれば割と簡単だよ

**名前は開発中のものです。** · 01/11/24 18:29

>>68
したよ。MathML 使いたくて。
時間かかるから滅多にやらないけど。

**名前は開発中のものです。** · 01/11/24 21:02

MathMLってなに？
MozillaってC++じゃなくてMLで作られてんの？

**名前は開発中のものです。** · 01/11/24 21:29

検索しなはれ。
http://www.e-words.ne.jp/view.asp?word=MathML

**名前は開発中のものです。** · 01/11/24 22:34

結局、本当に組み込むってのは、
ソースからビルドするって事で、
効能は自己満足とオリジナルとは違う環境に移植できるって事なのか？
そういう事なら動作環境Win限定の漏れみたいな奴は本当に組み込めなくてもいいや。

**名前は開発中のものです。** · 01/11/26 22:10

>>63
なぜわかったんだぁぁ！！？

>>73
IEの話だけならそれもいいかもね。

ゲームに話をもどすと、「遊んでもらえる」為には、どーせなら
ターゲットユーザーが多い方がいい。
そのときに、ソースがオープンなライブラリの上に構築していれば、
移植性は確実に上がるよね。たとえば、PS2の上ですでに
SDLは動いている。SDLで書かれたものならば、動くわけ。
もし、ベンダー依存のライブラリで書いてたら、ベンダーが
その気になるか、もしくは自前でライブラリ相当のものを書かないと
移植ができない。

IEのコンポーネントをつかったブラウザがPalmの上で動くことは
絶対にないけど、Mozillaのソース流用したブラウザがPalmの上で
動くって可能性はあるわけだ。

Windowsしか見えてない人には、関係ないっちゃ関係ないね。
がんばってDirectXでプログラミングしておくれ。でも、メーカーに縛られない世界ってのがあることも
知っておいて損はないと思うよ。
自分が書いたゲームが、10年後もちゃんとコンパイルできて
ちゃんと動いたら、ちょっと嬉しくないかな？

**天邪鬼雄** · 01/11/26 23:24

むしろ恥ずいと思われ（藁
つか、SDLって10年後も新ハードに対応し続けているかな？
10年前と今のハードの違いよりも変化大きそうだけど

**名前は開発中のものです。** · 01/11/26 23:58

>>74
それは……XMLとXSLTがあるから
普通のページと携帯電話用ページで
同じXMLソースを使えばいい並みの理想論だと思われ。

**名前は開発中のものです。** · 01/11/27 00:07

今作ったゲームが、10年後の環境で動いたら楽しいかもしれないけど
レトロ物以上の商品価値はないような気が。

**名前は開発中のものです。** · 01/11/27 01:58

この板でも「ここだけ時代が５年ずれてるスレ」やりたいね

**マジレスきぼん** · 01/11/27 03:17

GPLなライブラリを使ってhogehogeツクール作った場合、
そのツクールで作られた作品もGPLになるのかな？
ツクールじゃなくてスクリプト言語だった場合はどうかな？

**名前は開発中のものです。** · 01/11/27 03:38

>>79
そのツクールなりスクリプト言語を作るあなた次第。
あなたがGPLじゃなくていいよ、と言えば(特例を設ければ)GPLで
なくても良い。

あなたが作者じゃない場合はドキュメントを良く読むか
作者に問い合わせましょう。

**名前は開発中のものです。** · 01/11/27 05:07

>>79
ランタイムにGPLなライブラリが含まれていなければいいんじゃない。
ツクール自体はGPLで配布するとして。

79 · 01/11/27 11:31

作者だとしてです。
ランタイムにGPLが含まれると、それで作った作品もGPLになるんですか。
ツクール作品のシナリオデータとか画像、スクリプトソースもGPLに従い公開する必要があるんですね。

**名前は開発中のものです。** · 01/11/27 12:40

というか、まずランタイムのソースコード全部からやね。

**名前は開発中のものです。** · 01/11/27 12:47

作者といっても>>82が「ライブラリの作者」ではないということか

**名前は開発中のものです。** · 01/11/27 13:21

>>82
ならないんじゃないかな。
まぁ、スクリプトとランタイムをまぜこぜにして配布すると駄目かも知れないけど、
ちゃんと分離して(ランタイムのインストーラとゲームのインストーラを別にして)、
ランタイムのソースコートの場所を明示しておけばOKじゃない？

スクリプトがランタイムによって実行されることが、「リンクされている」と
解釈されるならまた話は別だけど、どうなんだろ。
よくわからん。
GPLなスクリプト言語で、その言語でかかれたスクリプトが非GPLで配布されてる
例ってあるかな？
PerlもRubyもArtisticかGPLのデュアルライセンスだし。

あと、GPLで問題なのは、ソースコードを配布しないといけないことじゃなくて、
無料で無限にコピーしてばら撒いても文句が言えないってことだと思う。個人的に。

85 · 01/11/27 13:24

舌足らず。
分離した上で、いっしょに配布すれば問題ないって趣旨ね>>85

**名前は開発中のものです。** · 01/11/27 13:37

>あと、GPLで問題なのは、ソースコードを配布しないといけないことじゃなくて、
>無料で無限にコピーしてばら撒いても文句が言えないってことだと思う。個人的に。

さらにそれをネタに商売されても文句を言えない

**名前は開発中のものです。** · 01/11/27 13:43

あった。
http://www.gnu.org/copyleft/gpl-faq.html#TOCIfInterpreterIsGPL
Q.もしプログラミング言語がGPLなら、その言語で実行される言語は
　GPLにしなければなりませんか？
A.インタプリタが、ただ言語をインタプリットするだけなら、答えはNOです。
　実行されるプログラムは、インタプリタから見てただのデータだからです。
　…

ということで、ランタイムで実行される作品が完全にスクリプトであるなら、
GPLにする必要はなし。
(RPGツクール2000みたいなRPG_RT.exeがランタイムで、
ゲームデータを付ける形式ならOK。)

逆に、HSPみたいにEXEにしちゃうやつや、MFC42.dllみたいなランタイム
ライブラリのことをいってるなら、GPLにする必要あり。

**名前は開発中のものです。** · 01/11/27 13:47

>>87
そうそう。
で、商売するやつが、商売するために機能向上させたり、
機能追加したり、バグ直したりしたところは、
ソースコードを公開させることで、必ず本家に反映させる
ことができるってのが、GPLの利点。

ツクールには(ツクール自体で商売しないなら)、非常に
よくマッチしたライセンスだと思うよ。

**名前は開発中のものです。** · 01/11/27 14:02

GPLなライブラリ使ってHSP用のDLL作った場合はどうなるのかな？
DLLはGPLになってソース公開コピー自由だろうけど、そのDLLを使うHSPスクリプト書いたら？スクリプトはGPLになるのかな？
HSP自体はGPLじゃないけど、HSPで作ったexeとDLLを一緒にアーカイブして配布する時はGPLで、別個に配布なら違う？
この場合、スクリプトでありながら、DLLは事実上ランタイムとなるけど。

**名前は開発中のものです。** · 01/11/27 14:12

>>88
同じランタイムでも、RPG_RT.EXEを利用するのはGPLじゃなくて、MFC42.DLLはGPLってのは
ランタイムを利用するのが機械語かデータかって事が重要なんかな。
そう考えると>>90はGPLで、スクリプト公開は必須かな。

90 · 01/11/27 14:29

HSPはスクリプトをexeと一体化する事もできるけど、ツクールみたいにexeと
別にしたまま実行することもできるんだけど、一体化しなければGPLにならない？

**名前は開発中のものです。** · 01/11/27 14:39

>>90
GPLプログラムをダイナミックリンクする場合、
リンクする側もGPLである必要があります。逆の場合も同様です。

HSPで作ったexeがGPLなDLLを(間接的にでも)リンクするなら、
そのexeはGPLでなければなりません。
同様に、そのexeがリンクするHSPのランタイム(があるんだっけ?)も
GPLでなければなりません。
もちろん、HSPのランタイム(や他の非GPLなDLL)はGPLじゃないので、
GPLであるexeとDLLは、事実上、配布することはできません。

ということで、そもそもHSP用のGPLなDLLを配布できない、というのが結論。
スクリプトは、スクリプトのまま配布するならGPLでなくてもいいけど、
実行できないんじゃ、意味ないね。

ただ、
http://www.gnu.org/copyleft/gpl-faq.html#TOCWindowsRuntimeAndGPL
にあるように、Windowsの(VCやVBの)ランタイムとダイナミックリンク
させる場合は、OKみたいですね。

HSPをこの例と同様に考えることができるかはわかりませんが、
プラグインを使うプログラムの場合、プログラムとプラグインのどちらかが
GPLなら、両方GPLじゃないといけないみたいなことも書いてあるので、
結局、難しいんじゃないかと思います。

あと、DLLがLGPLである場合は、この限りではありません。

**名前は開発中のものです。** · 01/11/27 14:47

>>91
この場合は、
・プログラムかどうか
・そのプログラムが(ダイナミック)リンクされるかどうか
が問題。
スクリプト(ゲーム)が、純粋にGPLなインタプリタ(ランタイム)で実行されるだけなら、
そのスクリプトは「プログラム」ではなく「データ」なので、GPLの対象には
なりません。
だから、そのスクリプトは、GPLでなくてもよい。

>>92
>93の
>HSPで作ったexeがGPLなDLLを(間接的にでも)リンクするなら、
>そのexeはGPLでなければなりません。
HSPがGPLなDLLを(間接的にでも)リンクするなら、
HSPはGPLでなければなりません。

と読み替えてくれ。

**名前は開発中のものです。** · 01/11/27 15:36

>>93
リンク先が英語で読んでもよく判らないんだけど、ｽﾏｿ
GPLではないVC,VBのランタイムDLLとのリンクは良くて、
GPLではないHSPのランタイムEXEとのリンクは駄目というのは、
前者がDLLで後者がEXEだから？
なんか漏れ、勘違いしてるような気がするんだけど。

**名前は開発中のものです。** · 01/11/27 16:42

>>95
http://www.gnu.org/copyleft/gpl-faq.html#TOCWritingFSWithNFLibs
ここに答えがあるよ。
GPLには、例外事項が載っていて(GPLの4節)、
「OSや処理系などの主要なコンポーネントは配布物に含めなくてよい」
つまり、コンポーネント(MFC42.DLLのようなランタイム)は、
(GPLなものといっしょに配布しないので)GPLである必要はない、
ということかな。

で、それ以外のコンポーネントの場合(OSや処理系の主要コンポーネント
でない)場合、"そのコンポーネント"と"それとリンクされるプログラム"
(やライブラリ)のどちらかがGPLである場合、両方GPLにしなければなら
ないと。

HSP本体(かランタイム)は、処理系の主要コンポーネントなんだから、
そいつとリンクするDLLをGPLで作るのはOKって解釈はアリかな？
だとすると、>>93は間違いだね。
といっても、いっしょに配布するのは、やっぱり無理っぽい。

**名前は開発中のものです。** · 01/11/27 17:21

DLLなのかEXEかが問題なんじゃなくて、処理系の主要コンポーネントなのかユーザプログラムかが重要ってことでいいんだよね。
ｻｿｸｽ!

**名前は開発中のものです。** · 01/11/28 01:36

ストールマンがRedHatの人間じゃなけりゃGPLもすんなり受け入れられるんだが。

例えるなら、信者達のお布施により暮らしているどこぞの教団の教祖が、
信者たちに喜捨を強制してるようなモンだ。

**名前は開発中のものです。** · 01/11/28 02:52

ともあれグレーゾーンなものなら、
素直にＧＰＬを破棄しましょうよ、みなさん。

ＶＣだとかＶＢだとかＢＣに添付されているコンポーネントは
全てＧＰＬからクリーンなのだから、それらのみを使って
構築する選択肢も十分にありえるわけでしょ？

それにしても
ＨＳＰのＤＬＬを使うのにＧＰＬものを避けて通るのって
そんなに困難なの？具体的な事情は知らないんだけどさ。

必要なコンポーネントって大抵、ＭＳだとかボーランドが
無許可組み込みＯＫとして公開しているよね？
それじゃ足りないケースってあるのかなぁ？

カスタマイズの必要があってソース公開が肝なんだとしたら
ＧＰＬに従う価値はあるんじゃないかな？

**漏れ的見方** · 01/11/28 03:25

開発環境にくっついてくるコンポーネントじゃ足りないから色んなライブラリが作られる訳じゃん。
でもって海外の使えそうなライブラリがGPLだったりすることもあるよ。ただ、ゲームのメインプログラム作る場合は公開されてるライブラリなんか必要としないことが多いと思う。

**名前は開発中のものです。** · 01/11/28 08:45

そうなんだよな。いざ組み込もうとしてライセンスみるとGPL。んでガクっとくると。
アマチェア用途ならそのまま使うんだけど。

**名前は開発中のものです。** · 01/11/28 11:00

DLLがGPLで、その縛りを逃れる方法はいくつかあって、
GNUのFAQの中で言及されてるのが、
・DLLをWrapするプログラムを作って、別プロセスで起動し、
　メインプログラムと(限られた手段で)通信する。
・DLLのままでも、メインプログラムから↑の形式に準じた形の
　限られたインタフェースでリンクされるだけならOK。
あたり。
限られた手段てのは「main()と標準入出力(パイプ)」を意味するみたい。

使いたいDLLのインタフェースを制限するようなWrapプログラム(DLL)を作って、
それをリンクすれば、メインプログラムは、GPLに感染しない。
まぁ、こんなまどろっこしいことするより、自分で作るか、代替品探した
ほうが早いかもしれんが。

でも商用ゲームでGPLが有効な局面って、ちょっと思いつかないな。

**名前は開発中のものです。** · 01/11/28 16:20

ラッパもDLLじゃ連鎖感染するんじゃない？別プロセスで起動にならないし。

**名前は開発中のものです。** · 01/11/28 16:42

別プロセスにして通信とかしていたら、遅くてゲームには使えないのでは？

**名前は開発中のものです。** · 01/11/28 16:47

102も言ってるけど、ゲームの速度が必要な部分で使いたいGPLなライブラリなんてあまり無いんじゃないかな。

**名前は開発中のものです。** · 01/11/28 18:11

>>103
だから、公式FAQに感染しないって書いてあるんだって。
英語は読めませんか？

>>104
無理して使えっていってるんじゃなくて、
どうしても使いたいときの話だよ。
わかってると思うけど。

>>105
ゲームメーカーが、自らの製品をGPLにして有効なこともなさそう。
ミドルウェアをGPLで公開して、それを使った他社が改造したり、
修正したりした部分をフィードバックしてもらうってモデルなら
有効そうだけど、それだと、ゲーム全部がGPLになっちゃう。

まぁ、LGPL使えばいいんだけどね。
SDLなんか、もろそれだし。

**名前は開発中のものです。** · 01/11/29 00:47

>DLLがGPLで、その縛りを逃れる方法はいくつかあって、
>GNUのFAQの中で言及されてるのが、
>・DLLをWrapするプログラムを作って、別プロセスで起動し、
>　メインプログラムと(限られた手段で)通信する。
>・DLLのままでも、メインプログラムから↑の形式に準じた形の
>　限られたインタフェースでリンクされるだけならOK。

そんな風にのらりくらりと法的にクリアしてたとしても倫理的にどうよ？
って感じだね。半ばへ理屈に近い上に、なによりもそのソフトウェアの作家に
対して失礼だな。いくら思想の合わないＧＰＬものだからといって、
俺はそこまで落ちたくねーし、逝きたくもない。

**名前は開発中のものです。** · 01/11/29 01:25

各種結論が出揃ったのでこのスレは終了です。

**名前は開発中のものです。** · 01/11/29 09:57

>>107
無理して使えっていってるんじゃなくて、
どうしても使いたいときの話だよ。
わかってると思うけど。

**名前は開発中のものです。** · 01/11/29 14:32

LGPLからGPLをダイナミックリンクはOKなの？
それがOKならLGPLでラッパを作れば、
実質的にGPLからLGPLへのライセンスコンバートができる？

**名前は開発中のものです。** · 01/11/29 14:53

だからそういう乞食みたいな考えはやめなって言ってるんですが。
答えとしては、前にも書いてあるがそんな事しなくても
main.exe : 非GPL 自作
↓
wrap.dll : GPL 自作↓
hoge.dll : GPL
という風にすれば感染しない。頼むからGNUのFAQ読んでよ。

**名前は開発中のものです。** · 01/11/29 15:16

>>110
ＧＰＬとリンクした時点で、それはＧＰＬになるから、無理。

**名前は開発中のものです。** · 01/11/29 16:04

>>112
112も英語読めないの？>>106参照。

**名前は開発中のものです。** · 01/11/29 21:26

結局、ちゃんと自分でとことん調べる気がないか、
あるいは単にGNUの精神に共感できないなら
無理にGPLモンに手を出すなということで終了。

**名前は開発中のものです。** · 01/11/29 21:44

おれが、GPL(LGPL)でつくっちゃるぜ！っていう剛の者はいないのか。

**名前は開発中のものです。** · 01/11/30 09:29

WindowsならDLL使えるからいいけど、
ゲーム機だと埋め込みで使わないといけないから
GPLは感染するよね。LGPLはどうなんかな。

**名前は開発中のものです。** · 01/11/30 12:19

GPLでラッパ作るたって「限られた手段で」通信せにゃいかんのだろ
mainと標準入出力じゃランチャーくらいにしかならんと思うが

**名前は開発中のものです。** · 01/11/30 12:37

>>117
なぜ「mainと標準入出力」だけになるんだ。。。

**名前は開発中のものです。** · 01/11/30 15:00

>>118
どこ見てレスしてるんだ？公式FAQに書いてあるだろ？FAQの意味判りませんか？

**名前は開発中のものです。** · 01/11/30 15:47

>>118
具体的にはここ↓。
http://www.gnu.org/copyleft/gpl-faq.html#TOCGPLAndPlugins
標準入出力のことは書いてないから、もしかしたらオプションと終了ステータスのみしか
許してないのかもね。
でっかいデータは、ファイル渡し。

**名前は開発中のものです。** · 01/11/30 16:49

標準入力ってキーボードだよね
んじゃ、GPL側を特定のキーコマンドが来たらあるGPL内の関数を呼ぶようにして
GPLラッパはGPLのDLLにキーメッセージだけを送りつけるだけってのどう？
標準入出力がだめならだめだけど

**118** · 01/11/30 17:14

>>119
>どこ見てレスしてるんだ？
http://www.gnu.org/copyleft/gpl-faq.html#TOCGPLPluginsInNF
ここ。
標準入出力ってどこにかいてあるの？
>FAQの意味判りませんか？
あなたの考えている定義とは違うかも。

**名前は開発中のものです。** · 01/11/30 17:32

どんどん糞スレ化してるね（藁
GPLが存在する限りフレームは消えないのかな。

**名前は開発中のものです。** · 01/11/30 18:35

話をLGPLの方に移したほうが、建設的だと思います。

厨房 · 01/11/30 18:55

結局、標準乳出力は可ってのはデマだったという事ですね。

**名前は開発中のものです。** · 01/11/30 20:36

標準入出力がダメだと、emacsのshellモードで起動できるすべてのコマンドが
GPLにならないといけないんだけど。
DLLのほうは知らん。

**名前は開発中のものです。** · 01/11/30 22:58

単にGPLに違反しているだけなので気にしないでください（藁

**名前は開発中のものです。** · 01/12/01 12:01

>標準入力ってキーボードだよね

これ読んでちょっと目が点になった。そうか、そういう時代なのか。

**名前は開発中のものです。** · 01/12/01 18:43

>>128
初心者にはありがちな誤解なんだから、大目に見てやれば？

**名前は開発中のものです。** · 01/12/01 18:49

ところで、コンソール系のゲームで、GPLやLGPLなコードが採用されたことってあるのかな？
業界人じゃないのでぜんぜん知らないのですが。

**名前は開発中のものです。** · 01/12/02 00:03

コンソール系って何？
コンシューマ？

**名前は開発中のものです。** · 01/12/02 00:58

>>131 ネタか。

**名前は開発中のものです。** · 01/12/02 02:53

>>130-132
これもなにげに英語スレ行きのネタやね。

**名前は開発中のものです。** · 01/12/02 06:45

>>131
定義をはっきりしておく必要がありますな。
コンソール＝コンシューマとは限らないのかもしれないし。

**名前は開発中のものです。** · 01/12/02 06:47

コンシューマはそもそもアーケードに対する用語。
コンソールはPCに対する用語。
日本と欧米のゲーム創生期のころの市場の違いによるものか？

**名前は開発中のものです。** · 01/12/02 06:48

というわけで、ネットカフェに置いてあるPCはありゃなんなのよってことになる。

**名前は開発中のものです。** · 01/12/02 17:17

そもそもあれをPCと呼んでいいものか

**名前は開発中のものです。** · 01/12/02 22:52

「パーソナル」コンピュータかどうかってことか？

**名前は開発中のものです。** · 01/12/03 00:26

ﾊﾟﾌﾞﾘｯｸｺﾝﾋﾟｭｰﾀ

**名前は開発中のものです。** · 01/12/03 01:51

LGPL だけどこういうの発見。これなら組み込み可？

How is FLTK Licensed?
FLTK comes with complete free source code. FLTK is available under the terms of the GNU Library General Public License.
We have ammended the LGPL to explicitly allow static linking of FLTK (or any modified version of FLTK) to your software.
The LGPL is not clear on this and we definately want to allow it.

Can I Use it in Commercial Software Products?
Yes, you can. The LGPL allows you to do this, and you do not need to release
the source code to your program.
You do need to release the source code for any modifications you make to FLTK itself,
but we would hope you would send any improvements like these back to us anyways.
You do not need to release the source for new widgets or other subclasses you create of the FLTK classes.

**名前は開発中のものです。** · 01/12/03 02:06

コンソールって、「ゲームコンソール」のことか。
てっきりVT100とかのことかと思ったヨ……。

**名前は開発中のものです。** · 01/12/03 04:08

>>141
いや、話の流れからみて「コンシューマ」を言い間違った
のだと思われ。

**名前は開発中のものです。** · 01/12/03 10:02

>>142
んなアホな。